ROS Integration

[dehann]

Please add your comments or support for this requirement here.

[dehann]

also see:

• http://www.juliarobotics.org/Caesar.jl/latest/concepts/multilang/
• https://github.com/GearsAD/GraffSDK.jl
• https://github.com/MarineRoboticsGroup/graff_cpp
• https://github.com/nicrip/SynchronySDK_py
• https://github.com/pvazteixeira/caesar-lcm

[colinxs]

With ROS1 development currently frozen, I would consider ROS2. ROS2 addresses many of the shortcomings of ROS1, and is coming up on its third stable release. I have no personal experience with ROS2, but am considering using it in my own research.
https://index.ros.org/doc/ros2/

[dehann]

FYI:
https://github.com/ros2/rclc

[dehann]

FROM SLACK

• Graff, ZMQ and ROS should all go through something like src/middleware/MsgSpec.jl to maximize reuse,
• On the ROS side it would be good to mimic most of the GMapping behavior(to make switching easier ?)

@pvazteixeira

• i agree with mimicking gmapping if we're implementing a sample front-end - that we can do in julia and subscribe to odoms/laserscans through RobotOS.jl
• for the bigger goal of a ROS interface, my guess is that we have to come up with a slam_msgs or caesar_msgs that encapsulates the methods to interact with a factor graph

[dehann]

• well, roscpp.jl will expose a ros interface, and if you want to build a front-end on the julia side then there's little that needs to be done, right?
• the issue is with having a front-end on the ros side of things, which requires going through the graff exercise again
• a new ros interface, like graff, amounts to exposing factor graph operations through a message spec
• a ROS interface would look just like graff in terms of syntax, but would exist as a caesar_msgs package in ROS, combined with a julia endpoint using either RobotOS.jl or roscpp.jl

[dehann]

Id like to look at the messages that GMapping uses. The way ZMQ interface works is only one message type but then JSON pack the instructions inside that message. We could go either way, and pretty sure we will end up changing it again. My feeling is we should choose one direction to get the functionality in place and then tune the API once we have some experience?

[dehann]

https://husarion.com/tutorials/ros-tutorials/6-slam-navigation/

[dehann]

Imagine using turtlesim as driver for Tutorial 101 in ROS,

[dehann]

Looks like these are the two main messages in the example:

#include <geometry_msgs/PoseStamped.h>
#include <tf/transform_broadcaster.h>

[pvazteixeira]

I think the gmapping/turtlebot example should be separated from the wider ROS integration issue.
Caesar integration with ROS can happen in a few different ways:

1. Build a front-end in julia and rely on RobotOS.jl (or a roscpp equivalent), in which case there is little to no work to do now. This is also where the turtlebot and gmapping examples fall: you subscribe to the relevant topics from the Julia side, and publish as needed. It's not really integration as all of Caesar remains in julia and it's up to the user/developer to play with RobotOS.jl to talk to ROS
2. Expose an interface to factor graph operations (add/remove node/factor) - similar to the graff concept. With ROS, this could happen either as:
   2.1. A caesar_msgs package in ROS - we'd specify the messages and use RobotOS.jl to create an endpoint on the julia side.
   2.2. A ROS node implementing that interface as a set of services. In this case, we'd need to handle the transport/marshaling ourselves (e.g. use graff)

2.1. is very similar in spirit to isam server; 2.2. exposes the interface as a set of services and is much closer to the request/reply concept we discussed when building graff. As I'm biased to the latter, I'll try to get a proof of concept going and report back.

In any event, it would be good to get some more opinions on this before fully committing one way or another

[pvazteixeira]

Here a very limited version of what I meant with 2.2. in the previous comment. It uses graff to talk back to caesar.

[dehann]

right cool, i like the second option too (but biased to do that directly in Julia like first) and also skip Graff. We can then replicate the Graff calls inside Caesar. I mean something like start up CaesarCore and it works via ROS

very similar in spirit to isam server

[dehann]

Also, if the go between is in C++ can rather work through ZMQ than Graff.

[pvazteixeira]

see also: ROS PoC wiki page

[autonomobil]

Is there an update for roscpp.jl?

[dehann]

Hi @autonomobil, I didn't see your post until now, sorry! We have been using the RobotOS.jl interface (using PyCall) but haven't worked more on the roscpp implementation yet. Here is the latest work that allows consumption of bagfiles without using roscore:

Caesar.jl/src/ros/Utils/RosbagSubscriber.jl

Line 49 in 09f0502

function loop!(rbs::RosbagSubscriber, args...)

[dehann]

I should add this is becoming a standard feature that still requires some documentation, the basic idea is, and make sure ROS is in the environment before running:

using Pkg
ENV["PYTHON"]="/usr/bin/python" # or whichever one can run >>> import rospy
Pkg.build(PyCall)
using RobotOS
using Caesar

That should activate the ROS features in Caesar.

Current Examples

They might be slightly out of date, but fairly close. We are currently working here so these will be updated in due course.

• https://github.com/JuliaRobotics/Caesar.jl/blob/master/examples/wheeled/racecar/ros/CarFeedMono.jl
• https://github.com/JuliaRobotics/Caesar.jl/blob/master/examples/marine/asv/rex/RExFeed.jl