A ROS 2 compatible Java library for publish-subscribe. I dare say it’s the easiest way possible to talk to other ROS 2 nodes; no local ROS 2 installation is required. All you need to do is depend on the library in your Java project (works best with Maven or Gradle).
Works on: Windows, Linux (including NVIDIA Jetson & RPi), and macOS! Android support is planned.
jros2 loosely follows rclcpp regarding API design and usage. Includes the following features:
Publish and subscribe to ROS 2 topic
Supports custom message types
Generate Java classes from ROS 2 .msg files
Fast-DDS backend
Minimal and fast implementation
Fully thread-safe
Async and allocation-free API
Full QoS configuration
(soon) ROS 2 services
(soon) ROS 2 actions
(soon) ROS 2 parameters
jros2 is recommended with javacpp-presets packages such as opencv, librealsense2, cuda! Check out javacpp-presets; they make developing robotics & computer vision software very easy in Java!
This project was developed to fill a requirement at IHMC Robotics, we write a lot of our robotics software in Java. If there’s something you’d like to see in jros2, please make an issue on GitHub!
No, more like removing bloat and unnecessary layers. Also, vastly simplifying the building and distribution.
The goal is to be wire-compatible with ROS 2, not to be a 100% complete implementation. This happened to be a general enough project within our research organization that it was open sourced and branded as something others can use.
Perhaps someone could eventually do an rcljava, but this project isn’t going to be that.
This seems to be a common misconception about ros2-java and ROS 2 in general, if the only thing you need is to be able to communicate with existing ROS 2 systems, the only things you need are a C++11/14-compatible compiler and the rcl, rmw and code generator packages.
Some time ago I ported rcljava to Android, running ROS 2 natively on Android and it only required the packages I’ve mentioned.
The problem with developing a client library without relying on the existing rcl/rmw architecture is that if in the future you may want to change your transport layer (e.g. zenoh), you’d have to implement an API that can work with both DDS and zenoh, and by then you’ll have just reimplemented rcl and rmw. And of course, like @peci1 says, possible incompatible behaviors or bugs. In ROS 1, rospy and roscpp in some cases behaved differenlty, and that’s because they had completely different codebases and they shared nothing at all, that’s why we came up with rcl/rmw for ROS 2 to unify behaviors between all the client libraries.
