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>