Migrated from https://code.ros.org/trac/ros/ticket/3771
Reported by: kruset Owned by: bhaskara
Priority: minor
Last modified ago: Nov 2011

As per ticket #3763 (https://code.ros.org/trac/ros/ticket/3763), I suggest the following change. Please look over the patch as there was a #! /bin/bash in the middle of a script file, and I want to be sure that it really had no business there.

Index: scripts/make_node_exec
===================================================================
--- scripts/make_node_exec      (revision 15383)
+++ scripts/make_node_exec      (working copy)
@@ -1,4 +1,4 @@
-#!/bin/bash
+#! /usr/bin/env bash

 SBCL_CMD=`rospack find sbcl`/scripts/run-sbcl.sh
 if [[ $# == 4 ]]; then
@@ -8,7 +8,7 @@
   output=$4
   $SBCL_CMD --noinform --end-runtime-options --userinit `rospack find roslisp`/scripts/roslisp-sbcl-init --noprint --disable-debugger --load `rospack find roslisp`/scripts/make-roslisp-exec.lisp $pkg $system $entry $output.lisp || exit $?
   cat > $output <<EOF
-#!/bin/bash
+
 ROSLISP_CURRENT_PACKAGE=$pkg \`\$ROS_ROOT/bin/rospack find sbcl\`/scripts/run-sbcl.sh --noinform --end-runtime-options --noprint --no-userinit --disable-debugger --load $output.lisp --end-toplevel-options \$*
 EOF
   chmod a+x $output
Index: scripts/make_roslisp_image
===================================================================
--- scripts/make_roslisp_image  (revision 15383)
+++ scripts/make_roslisp_image  (working copy)
@@ -1,4 +1,4 @@
-#!/bin/bash
+#! /usr/bin/env bash

Changed 14 months ago by bhaskara

Replacing the initial shebang with env bash is good. The #! in the middle of the script is because the script writes out another script. So that middle one should also just be replaced by #!/usr/bin/env bash (though I suppose in this case, the default of sh will work fine).

In the latest doc jobs (e.g. http://build.ros.org/job/Ldoc__ros_comm__ubuntu_xenial_amd64/32 and http://build.ros.org/view/Ldoc/job/Ldoc__roslisp_common__ubuntu_xenial_amd64/3/) the following warning has started to show up:

WARNING:
Couldn't re-execute SBCL with proper personality flags (/proc isn't mounted? setuid?)

The best description I was able to find was https://github.com/dimitri/pgloader/wiki/Running-in-Docker-(SBCL-warning)

Since this package is pulling in the dependency on SBCL can you please come up with a patch how this warning can be avoided since it makes the doc job of multiple packages unstable.

It looks like roslisp tries to use python on Debian Buster. PEP 394 says python could be any version, and on Buster it's Python 2.

I found this by deleting the python executable in a docker container. When sourcing another package it showed:

/home/sloretz/rsp_ws/devel_isolated/robot_state_publisher/env.sh: 1: /home/sloretz/ws/noetic/devel_isolated/roslisp/etc/catkin/profile.d/99.roslisp.sh: python: not found

The problem seems to be here.

One fix might be to add an <exec_depend> on ros_environment and use python${ROS_PYTHON_VERSION}. I don't think that would work on Windows though.

I ran into an inconsistency of timestamps on our robot: I get a timestamped message from a roscpp-node. Upon receipt, I call (roslisp:ros-time). I print both stamps, and the roslisp timestamp is older than the one from roscpp. This seems like a bug to me.

I checked that both my roslisp-node and my roscpp-node run on the same computer and that use_sim_time is set to false on the ROS parameter server. This relates to roslisp version 1.9.17 on ROS Hydro, Ubuntu Precise.

I looked into how roslisp implements its time mechanism. I am doubtful whether the two global variables *time-base* and *internal-time-base* used for calculating the stamp refer to the same moment in time. If they do not, than the timestamp could be wrong by as much as +-1s.
https://github.com/ros/roslisp/blob/master/src/time.lisp#L46

Are there alternatives in SBCL to (get-internal-real-time) which give us a real-time with respective to a globally known reference time? Or should we consider wrapping the c-functions for accessing the sys-time?

the CMake Macro add_lisp_executable fails with the message Directory nonexistent if there is no target-dir in the catkin_ws/devel/lib/<package_name> directory

Mind releasing this repo into Noetic? It looks like all dependencies of packages in this repo have been released already. roslisp appears to be recursively blocking 484 others.

http://repositories.ros.org/status_page/blocked_releases_noetic.html?q=id%3D%22roslisp%22&s=6&r=1

Migrated from https://code.ros.org/trac/ros/ticket/3716
Reported by: kruset Owned by: bhaskara
Priority: minor
Last modified ago: Mar 2012

roslisp fasls are compiled to ~/.ros/roslisp/packagename. This means when switching e.g. between diamondback and electric, that the wrong fasls can get loaded. Instead, fasls should go and be fetched from specialized locations, like ~/.ros/roslisp/path/to/file

Current workaround: delete fasls in ~/.ros/roslisp on each switch

The code is run every loop time, but if the code within the loop sometimes takes LONGER than the loop time (for whatever reason) it may run faster than the requested loop time (it effectively queues the times to run based on the initial call , rather than updating each loop based on the performance of the enclosed code).

The bug is in run-and-increment-delay, which should call (get-internal-real-time) to set the base time for the next call. Here's the patch:

(in-package roslisp-utils)

(defun run-and-increment-delay (l d)
(let ((next-time (+ (get-internal-real-time) (* d internal-time-units-per-second))))
(wait-until-ready l)
(set-next-real-time-to-run l next-time)))

So, I just tested roslisp on Trusty.
First of all, ros-load-manifest doesn't compile anymore.
Reason: it uses asdf:split-string, which is not external in ASDF 3 anymore.

The compilation error looks like this:

caught ERROR:
;   READ error during COMPILE-FILE:
;   
;     The symbol "SPLIT-STRING" is not external in the ASDF/INTERFACE package.
;   
;       Line: 262, Column: 35, File-Position: 12108
;   
;       Stream: #<SB-SYS:FD-STREAM
;                 for "file /home/eris/workspace/catkin/src/roslisp/load-manifest/load-manifest.lisp"
;                 {10099240C3}>
; compilation aborted after 0:00:00.070

I took a quick look and found two occurrences of asdf:split-string in ros_load_manifest/load-manifest.lisp.

As far as I understood, not all the functionality of load-manifest.lisp is actually used right now and many things are there only for backwards compatibility with really old systems. So, I'm not even sure if that particular piece of code is actually needed.

Unfortunately, I won't have time to look into this until Monday night.

@airballking, FYI.

If you call roslisp:get-param on a namespace (This is useful if you use yaml files for configurations ), an xml-rpc-struct is returned. It might be useful to use another format to represent this nested key value pairs(Python uses a dictionary, c++ a std::map ). A HashTable might be a good structure for this...

http://wiki.ros.org/nodelet

It'd be great to have this for, say, publishing images from a sensor at higher rates.

From #4:

Me: Is this the same as nodelets - seems so to me; should I open a separate issue if not?

@Gaya: nodelets is not just for "running multiple ROS nodes in different threads in one process", which this issue is about. Nodelets also allow for efficient message passing between the different nodes of the same process. If you want efficient zero-copy message passing, open a new issue. If you only care about running multiple nodes in one REPL image, this issue is all you need.

...I personally am not going to put effort into implementing this. When I need multiple lisp nodes in my system, I just compile myself an executable (with add_lisp_executable) and run it in a terminal, in addition to my REPL image. One can also start two *inferior-lisp* processes in Emacs and have the other node run there. I've done that too, works pretty well. My lisp nodes usually publish with very low frequency, so I never bothered with the efficient message passing.

Okay, thanks for the clarification! I'm fairly new to ROS, but I'll look in a month or two after some of my other tasks if this is something I can give an attempt and issue a PR.

Migrated from https://code.ros.org/trac/ros/ticket/2896
Reported by: bhaskara Owned by: bhaskara
Priority: major
Last modified ago: Jan 2011

This is a possible feature for diamondback or eastern box. See the discussion at http://www.ros.org/wiki/roslisp/Reviews/2010-07-16%20API%20Review.

Currently, Lisp code is not compiled when calling catkin_make. It would be nice to have that.

This issue issue more or less intends to collect thoughts about if SBCL is the right CLISP implementation for use in ROS.

The primary motivation behind bringing this up is the fact that SBCL is not currently available on ARM, which is becoming more and more useful (and supported) in ROS. This makes roslisp the only desktop-full package which will not install on ARM.

How reasonable would it be to begin migrating to a more widely-available CLSIP implementation such as GNU CLISP? Would it even be possible? How much work?

Looking for thoughts...

When dashes are used, RViz creates illegible errors and that's bad ROS coding style anyway.

Migrated from https://code.ros.org/trac/ros/ticket/3548
Reported by: kruset Owned by: bhaskara
Priority: minor
Last modified ago: May 2011

To reproduce, call a service expecting PoseStamped? with a Pose. E.g. Create a ROS cpp service with this signature

geometry_msgs/PoseStamped pose ---

Then call it from REPL like this: (roslisp:call-service

"message_test" 'beginner_tutorials-srv:MessageTest :pose (make-instance 'geometry_msgs-msg:pose))

Error messages on server and client do not indicate the user send Pose instead of PoseStamped?. Suggest checking type during roslisp serialization independent of sbcl compiler settings

I am installing ROS Indigo distro on Mac OS El Capitan using instructions given here. But when I run:
rosdep install --from-paths src --ignore-src --rosdistro indigo -y
I get the following error:

ERROR: the following packages/stacks could not have their rosdep keys resolved
to system dependencies:
roslisp: Missing resource geneus

Is there any way to resolve this?

I'm trying to both listen and publish to the same topic from one node. No matter in which order I try, I get a broken connection error. Below are the two distilled use cases.

USE-CASE 1:

(progn
  (start-ros-node "my-node")
  (subscribe "/our_topic" "std_msgs/Empty" (lambda (msg) msg))
  (advertise "/our_topic" "std_msgs/Empty"))

This immediately fails with:
Couldn't write to #<FD-STREAM
for "socket 127.0.0.1:44917, peer: 127.0.0.1:40980"
{1005F039C3}>:
Broken pipe
[Condition of type SB-INT:SIMPLE-STREAM-ERROR]

USE-CASE 2:

(progn
  (start-ros-node "my-node")
  (advertise "/our_topic" "std_msgs/Empty")           
  (subscribe "/our_topic" "std_msgs/Empty" (lambda (msg) msg)))

This initially returns but propagates an error after few seconds:
Couldn't write to #<FD-STREAM
for "socket 127.0.0.1:55104, peer: 127.0.0.1:40010"
{100674E493}>:
Broken pipe
[Condition of type SB-INT:SIMPLE-STREAM-ERROR]

P.S.: I also wrote the same sample programs both with roscpp and rospy, there it works. However, --in contrast to roslisp-- both roscpp and rospy then send and receive the data over the same socket of localhost.

I propose to add a following convenience functionality that allows to create a message from a publication object and the message-arguments.

Like this, one can use a publication object to specify the type of the message that shall be created instead of giving its type as a string. This should decrease errors due to miss-spelling of message-types.

P.S.: I already have a patch but don't know how to attach it to this issue. Can someone help? :)

Currently, it only accepts strings.
Would be nice to add symbol support, just like, e.g., in MAKE-REQUEST.

I just realized that, when starting a ROS node using

(roslisp-utilities:start-ros-node)

the environmental variable $ROS_IP is not taken into account for generating the RPC Caller URI. When only setting my $ROS_IP to my ethernet address (i.e. 192.168.0.1), I get the following when executing roswtf:

ERROR: Unknown host [] for node [/nodename]

Similarly, when publishing something from that node, I get the following rostopic info output:

$ rostopic info /nodename/sometopic
Type: visualization_msgs/MarkerArray
Publishers: 
 * /nodename (http://:51309)

but the published messages never reach any other node on the same ROS master (which is definitely set corretly).

When setting $ROS_HOSTNAME to the same value (have only tried setting it to an IP, as my hostname sometimes changes due to DNS/DHCP weirdry), everything works as expected:

$ rostopic info /nodename/sometopic
Type: visualization_msgs/MarkerArray
Publishers: 
 * /nodename (http://192.168.0.1:51309)

and other nodes get my published messages.

So my guess would be, that something is wrong in roslisp/src/node.lisp, somewhere in start-ros-node.

$ROS_IP should be usable for this purpose, shouldn't it? My $ROS_HOSTNAME was definitely not set before.

Migrated from https://code.ros.org/trac/ros/ticket/3561
Reported by: kruset Owned by: bhaskara
Priority: major
Last modified ago: Nov 2011

create roslisp node, start node, run rxloggerlevel. Node should appear, but does not. Not sure whether this is a bug or a missing feature.

Conversation

Changed 18 months ago by bhaskara

type changed from defect to enhancement

This is a missing feature. Roslisp has a similar topic hierarchy to roscpp and a service interface for changing levels at runtime, and so I imagine it would be not too hard to add the specific interface that rxloggerlevel expects, but I haven't looked into this.

Changed 14 months ago by kruset

I created a patch for rospy doing that in #3749 (https://code.ros.org/trac/ros/ticket/3749). It is rather easy to do, just create 2 services returning a list of loggers and setting the level of one. The only problem is that the messages are currently defined in roscpp, so that would introduce a dependency to roscpp for the messages. Do you see any problem with that?

Changed 14 months ago by bhaskara

cc kwc, straszheim added

We should probably move the relevant ros messages into std_msgs and std_srvs, if that api is going to apply to multiple client libraries.

I started a standalone roslisp-script using roslaunch. Topic remapping specified in the launch-file was correctly registered (at least a printout showed up when the node was started, and *remapped-names* is no longer empty). However, the node still subscribes to the unmapped topic.

I'll try to come back with a minimal example, soon.

P.S.: I used roslisp version 1.9.17

Hello,

First of all, let me thank you for your hard work on this very useful project!

I'm having trouble running roslisp on recent versions of SBCL. Specifically, when I run the following to load roslisp:

;; Trick to load roslisb-sbcl-init
(load (concatenate 'string
                   (string-trim '(#\Newline) (asdf/run-program:run-program '("rospack" "find" "roslisp") :output :string))
                   "/scripts/roslisp-sbcl-init"))

;; Load roslisp -- gives below error
(ros-load:load-system :roslisp)

I get the following error:

; caught ERROR:
;   READ error during COMPILE-FILE:
;   
;     Lock on package SB-IMPL violated when interning *DEADLINE-SECONDS* while in
;     package ROSLISP-UTILS.
;   See also:
;     The SBCL Manual, Node "Package Locks"
;   
;     (in form starting at line: 259, column: 0, position: 8512)

; compilation aborted after 0:00:00.037

I'm no expert on the internal workings of roslisp, but I have a hunch what could be going on. Here, roslisp makes use of sbcl-impl:*deadline-seconds*:

This seems to be because SBCL's sleep does not respect deadlines (according to the comment several lines above).

In December 2017, it looks like the *deadline-seconds* symbol was removed in SBCL by this commit. Furthermore, based on this commit a few days later, it seems that SBCL's sleep does now support deadlines.

(I tested on SBCL 1.4.10, but theoretically this should apply to the past few versions).

Any advice would be very much appreciated. Thanks again!

When declaring multiple types for a variable, i.e.

(declare (type (or type1 type2) variable))

and using this variable as msg' for use withroslisp:with-fields` afterwards, e.g.

(roslisp:with-fields (fields) variable ...)

the compiler breaks with the message (OR TYPE1 TYPE2) is not of type SYMBOL.
This seems to be connected to the fact that roslisp:with-fields converts the variable into a list internally and therefore interpretes the type of the variable. The or formulation seems to not be working in this context, though.