search

ihmcrobotics / ihmc-java-ros2-communication

Realtime safe implementation of ROS2 in Java.
Apache License 2.0
21 stars 5 forks source link

Join efforts of ihmc robotics and ros2-java #5

Open wilcobonestroo opened 4 years ago

wilcobonestroo commented 4 years ago

Dear all, In our project we want to develop a Java node for ROS2 (dashing). In our search we encountered your project and also the ros2-java project. The latter was also presented on ROSCon 2018. In the discussion on Discourse about Java and ROS2, one of the developers of ros2-java suggests: "It might make sense to try and consolidate efforts between the two projects, I’m not sure."

Would it be interesting for you to consider joining efforts and work on one Java package for ROS2?

jespersmith commented 4 years ago

I think the main goals behind this project are

As far as I understand, ros2-java is a native wrapper around Ros2. While this certainly has its advantages, it requires a ROS2 installation, and as far as I understand messages are compiled in C++ (which requires compiling on at least three platforms).

My ideal situation is a pure Java implementation of ROS2 below a pure Java implementation of the communication, avoiding any native code. This is however a lot of work.

wilcobonestroo commented 4 years ago

Hi Jesper, Thank you for your answer. I am not a developer of ros2-java. However, according to their presentation it is a layer on top of the RCL C (not C++) api. To me the distinction between Fast-RTPS as a static library or the RCL C api as a library is not really clear. I will ask the developers of ros2-java what they think. As a pure Java implementation, are you thinking about an RTPS implementation in Java? What would be the benefits of having such an implementation compared to ros2-java or ihcm-java-ros2-communication.

jespersmith commented 4 years ago

The RCL C API only really compiles and runs within a ROS2 workspace. We compile a static library (single .so/.dll/.dylib) for FastRTPS, and package that within our JAR files. This makes it easier to re-distribute our applications easier than having to setup ROS2 workspaces on every developers computer. Also, this means being able to convert ROS .msg/.idl files into Java classes without having a ROS2 workspace available.

But the most important is that no object allocation is done at all during runtime. For example Strings are pre-allocated using Stringbuffers in the messages. This is much harder to achieve with third party libraries and requires a full investigation if this is possible. This is due to strict realtime requirements.

The advantage of an RTPS implementation in Java would be that it is much easier to distribute and debug. Currently, updating the library means having to re-compile the code on the three major platorms (win/lin/mac). It would also be easier to port to ARM/Android based platforms.

Note that all the message serialization/deserialization is already done inside Java with our approach. A native Java implementation would be implemented in ihmc-pub-sub and will not require any work on the ROS2 side of things. There is already an intraprocess implementation available that allows communication in the process, without network chatter.