Common Lisp library for interaction with ROS (Robot operating system).
See http://www.ros.org/wiki/roslisp
Tested using SBCL.
Client library for writing ROS nodes in idiomatic Common Lisp
Home Page: http://www.ros.org/wiki/roslisp
Common Lisp library for interaction with ROS (Robot operating system).
See http://www.ros.org/wiki/roslisp
Tested using SBCL.
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.
roslisp/env-hooks/99.roslisp.sh
Line 21 in efa052c
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.
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.
When declaring multiple types for a variable, i.e.
(declare (type (or type1 type2) variable))
and using this variable as msg' for use with
roslisp: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.
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.
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
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)))
Currently, Lisp code is not compiled when calling catkin_make
. It would be nice to have that.
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.
Currently, it only accepts strings.
Would be nice to add symbol support, just like, e.g., in MAKE-REQUEST.
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?
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...
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.
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
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.
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? :)
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
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
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.
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*
:
Line 265 in 3aeebb3
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!
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.
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).
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 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?
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.