Migrate to ROS agnostic version to avoid duplicating between tesseract_ros and tesseract_ros2

[Levi-Armstrong]

I have been thinking about creating a version which leverages gz-transport or DDS directly which is used for ROS1 and ROS2 to avoid duplicating code. @rjoomen, @marip8 @marrts and @johnwason What are your thoughts?

[marip8]

What do you mean exactly? I'm not sure I follow how introducing one of these other transport mechanisms allows for interoperability with ROS1 and ROS2

[Levi-Armstrong]

It would be selecting a default communication protocol for Tesseract. All tesseract components within this package would use this method of communication instead of ROS1 or ROS2.

[marrts]

Is there an example of anyone else doing something like this? It would be super nice to not have to worry about maintaining two repos with duplicate code, but this sounds potentially messy and/or complicated.

[Levi-Armstrong]

For all of my use cases, I interact through the environment monitor or environment monitor interface which already hides the communication layer.

[johnwason]

If you are going to use a third party library Robot Raconteur provided a much better interface for a library like this. It allows you to much more closely match the API. It is in the ROS package manager.

https://github.com/robotraconteur/robotraconteur

I started working on this a while ago but didn't get very far because I didn't have time: https://github.com/robotraconteur-contrib/tesseract_robotraconteur

Here is an example for Gazebo. The design allows you to very closely match the API: https://github.com/robotraconteur-contrib/RobotRaconteur_Gazebo_Server_Plugin/blob/github/gazebo_robotraconteur_server_plugin/org.gazebosim.gazebo.robdef

[Levi-Armstrong]

If you are going to use a third party library Robot Raconteur provided a much better interface for a library like this. It allows you to much more closely match the API. It is in the ROS package manager.

https://github.com/robotraconteur/robotraconteur

I started working on this a while ago but didn't get very far because I didn't have time: https://github.com/robotraconteur-contrib/tesseract_robotraconteur

Here is an example for Gazebo. The design allows you to very closely match the API: https://github.com/robotraconteur-contrib/RobotRaconteur_Gazebo_Server_Plugin/blob/github/gazebo_robotraconteur_server_plugin/org.gazebosim.gazebo.robdef

Does it support message encryption?

[johnwason]

Yes it has excellent TLS support, with centralized certificate distribution (nominal cost) so you don't need to figure out your own certificate authority.

[marip8]

If you did replace the message protocol with something other than ROS1/ROS2, how much does that really buy you? Most of this repo is about defining ROS messages/conversions and making tesseract displays appear in Rviz, so it seems like we would still have to maintain quite a bit of separate code to operate in both ROS1 and ROS2. My guess is that whatever code could eliminated from the ROS/ROS2 repos would just be replaced by the same amount or more code to support some other transport protocol

[marip8]

It would be selecting a default communication protocol for Tesseract. All tesseract components within this package would use this method of communication instead of ROS1 or ROS2.

What would this look like for Rviz integration? It seems like some level of ROS messaging is still required for displays to show up and function in Rviz

For all of my use cases, I interact through the environment monitor or environment monitor interface which already hides the communication layer.

If you are concerned about the burden of code maintenance, we could drop some of these more complicated features, like the environment monitor and planning server ROS interfaces. I personally have never used them and have been more content with writing my own node that owns an environment object and exposes a much more limited set of ROS interfaces that are specific to my application. I'm not sure how widely used these features are outside my own use-cases though

[Levi-Armstrong]

The choosen communication layer would be integrated into tesseract_qt components so the tesseract_rviz would be very minimal.

[Levi-Armstrong]

If you are concerned about the burden of code maintenance, we could drop some of these more complicated features, like the environment monitor and planning server ROS interfaces. I personally have never used them and have been more content with writing my own node that owns an environment object and exposes a much more limited set of ROS interfaces that are specific to my application. I'm not sure how widely used these features are outside my own use-cases though

It just that ROS specific component add no benefit for how it is being used and we could just as easily use a standard communication protocol to manage the communication to avoid duplicating code.

[johnwason]

I think Robot Raconteur should work fine as an RViz plugin, but I haven't tried it.

[Levi-Armstrong]

@johnwason what dependencies would this add to Tesseract?

[johnwason]

@Levi-Armstrong It should be very few packages.

Here are the package.xml for the core library:

https://github.com/robotraconteur/robotraconteur/blob/ros2-humble/package.xml

Most of the dependencies are part of the operating system anyway. There is also a companion library that needs eigen and yaml-cpp, but tesseract already uses them. The companion library provides utility functions and support for the standard Robot Raconteur types: https://github.com/robotraconteur/robotraconteur_companion/tree/master https://github.com/robotraconteur/robotraconteur_standard_robdef

Robot Raconteur was designed to be embeddable so it uses as few dependencies as possible.

[johnwason]

@Levi-Armstrong Python is not necessary for the C++ library, the ROS package contains both. It can be split if that is an issue, the Ubuntu packages are split this way.

[Levi-Armstrong]

Sounds good, I would be interested in giving this a try. I would need some help in the beginning to get things started.

[johnwason]

Sure, I can help. I think a good starting point would be to define the interface you want to use. Robot Raconteur supports multiple objects and functions in the same service, so you have a lot of flexibility in how the interface is designed. A design pattern to consider is the use of varvalue, which is a wildcard object type. It allows you to build up a list of arbitrary structure instances. We use it for communicating "motion programs" which are similar in concept to the command language.

See https://github.com/robotraconteur-contrib/abb_robotraconteur_driver_hmp/blob/master/src/abb_robotraconteur_driver_hmp/experimental.robotics.motion_program.robdef for an example.

In the example, structures like MoveJCommand and MoveCCommand are added to the MotionProgram.motion_program_commands list. The driver then reads the command list and executes it using the MotionProgramRobot.execute_motion_program generator function (https://github.com/robotraconteur-contrib/abb_robotraconteur_driver_hmp/blob/71508b6c115975a1b6832d168b2386ba96e2a25c/src/abb_robotraconteur_driver_hmp/experimental.robotics.motion_program.robdef#L185). The generator function works like a ROS action for long running operations.

[rjoomen]

Keeping both tesseract_ros* projects in sync is a hassle indeed. But I agree with @marip8 in wondering what this proposal would really buy us. We might reduce the amount of duplicate code, but as ROS interfacing is still needed we'd have a shared code base with yet another dependency but still have the (arguably thinner) ROS1 and ROS2 layers on top.