ROS 2 Support (experimental)
ROS 2 support on Leo Rover is still experimental. Expect missing features, broken integrations etc.
Prerequisites
How to use
To use Leo Rover with ROS 2, you need to flash the experimental
LeoOS with ROS 2 support.
Download either the lite or full version and flash the image onto the SD
card:
After starting the robot, connect to the Rover AP and login to Raspberry Pi via SSH:
The ROS 2 version requires different firmware for the motor controller. To firmware update process looks almost exactly the same as it was before:
The only difference is that to invoke the update script, you need to type:
ros2 run leo_fw update
Changes
The experimental OS functions very similarly to the current stable release of LeoOS. The network configuration works the same, no new system services are started, even the ROS API is almost identical. There are, however, a few changes, apart from the ROS distribution, that should be taken into account:
Micro-ROS instead of ROSSerial
As ROSSerial project is not available for ROS 2, we had to find another protocol for serial communication between Raspberry Pi and the motor controller. Thus, the new firmware utilizes the Micro-ROS project to expose the ROS topics and services via the Micro-ROS Agent running on the Raspberry Pi.
New systemd user services
Instead of one system service leo which started the ROS functionality, the new
OS provides two user services:
- ros-nodes - Starts the
/etc/ros/robot.launch.xmlROS 2 launch file. - uros-agent - Starts the Micro-ROS Agent.
Both of these services can be configured through the /etc/ros/setup.bash file.
To facilitate the process of managing these services, we developed a set of bash aliases. For example, to stop both services, you can type:
ros-nodes-stop
uros-agent-stop
v4l2_camera instead of raspicam_node
Due to the Raspberry Pi MMAL libraries no longer being supported on 64 bit systems, we were unable to port raspicam_node to ROS2 Humble. Instead, we switched to using v4l2_camera to expose the camera images on ROS topics.
image_proc nodes running by default
As an experimental feature, we added image_proc debayer and rectify nodes that are running by default. They add the following topics:
/camera/image_mono
/camera/image_color
/camera/image_rect
/camera/image_rect_color
RDP no longer supported
Due to the fact that tigervnc-scraping-server seems to work a lot faster than xrdp and allows utilizing hardware acceleration, we decided to drop support for remote desktop via RDP protocol. The new OS, by default, only allows remote desktop connections via VNC protocol.
Current limitations
Because of the new architecture, some new problems, that limit some functionalities of the robot, were introduced. We are actively trying to mitigate them but you should take them into account for now.
No way to permanently change firmware parameters
The ROSSerial-based firmware was retrieving parameter values from the Parameter Server during initialization. This allowed to change the firmware parameters from Raspberry Pi and make the changes persistent across reboots. As ROS 2 does not have a global parameter server, the new firmware loses this ability.
The new firmware allows changing parameters at runtime via, for example, rqt_reconfigure tool.
Not compatible software integrations
If you used any of our integrations guides, you will have to adapt the software integration parts yourself. In some cases, it won't be possible due to missing ROS 2 packages.
Problems with multi-robot setups
The ROS namespace and domain id of the firmware node (the ROS node running on the motor controller) is currently hardcoded and there's no way to change it without changing firmware code and re-flashing the board. This makes it a lot harder to work with multi-robot setups due to topic name collisions.