Migrate to ROS 2

[ShaanGondalia]

Background

ROS is no longer receiving updates and noetic will reach EOL by 2025. We need to migrate our stack to ROS 2 eventually to make sure we have access to the latest tools and versions of our dependencies. We should follow the migration guides as a baseline for updating our code-base.

There are a few ROS 2 features that complicate the migration process:

• Using ament and colcon for builds instead of catkin. For our purposes, this involves replacing all CMakeLists.txt with a setup.py script.
• ROS 2 does not use roscore to create a master node, instead it uses DDS to set up peer-to-peer communication. We need to scope out how this will work across multiple machines (onboard and landside). This tutorial is probably a good starting point.
• The ROS API is now rclpy instead of rospy. The framework for creating nodes changed a bit, so we'll have to modify every script in our code base.

Before we start making efforts to complete the migration, we should conduct a thorough analysis of our ROS dependencies to determine their equivalent packages in ROS 2. Once we've confirmed support or have viable alternatives for all packages, we can start efforts to migrate the rest of our code base. We'll surely run into more hiccups along the way, but for now the following tasks should be a good roadmap for the migration.

Testing

See #387

Important Notes

The general process for migrating a package to ROS2 is:

• Switch build system to ament, replacing CMakeLists.txt with setup.py and modifying file structure.
• Switch client library from rospy to rclpy
• Update pub/sub syntax
• Rewrite launch files in python
• Update README.md

Tasks

• [x] Create current ROS dependency list with ROS 2 equivalents
• [x] Build proof-of-concept to verify cross-machine functionality
  • [ ] Update setup_network.sh to remove ROS master and replace with domain id
  • [x] Test onboard/land-side connection on local machine
  • [ ] Test onboard/land-side connection from robot to local machine
• [ ] Migrate all "easy" packages (landside first, then onboard)
  • [x] landside
    • [x] joystick
    • [x] camera_view
    • [x] simulation
  • [ ] onboard
    • [x] acoustics
    • [x] avt_camera
    • [x] cv
    • [x] data_pub
    • [ ] execute
    • [x] robosub_description
    • [x] sensor_fusion
    • [x] static_transforms
    • [x] system_utils
• [ ] Migrate all "hard" packages (controls, offboard_comms, task planning, gui?)
  • [x] Dereference pid package in controls, rewriting PID logic
  • [ ] Rewrite current state of task planning to use executive-smach or some other tool
  • [ ] Implement micro-ros in place of rosserial, which involves swapping hardware (See #375)
  • [ ] Once everything is updated, we can migrate gui.
• [x] Update build.sh to use colcon instead of catkin
• [ ] Update docker images with ROS 2 dependencies (base image and packages)
  • [ ] Update pytorch installation version and jetson-pytorch image? Not sure if cv is using pytorch anymore.
• [x] Update Github CI (particularly launch file testing and building)
• [ ] Test each package on Cthulhu. See #387
• [ ] Make a ROS2 knowledge transfer video documenting how the code-base changed how the new system works
• [ ] Update main README and tutorial documentation.

[ShaanGondalia]

Dependencies

ROS Package	ROS 2 Equivalent	Affected Packages
std_msgs	std_msgs	custom_msgs, camera_view, simulation, controls, data_pub, offboard_comms, task_planning
geometry_msgs	geometry_msgs	custom_msgs, joystick, simulation, controls, data_pub, sensor_fusion, task_planning
actionlib_msgs	actionlib_msgs	custom_msgs
message_generation	rosidl_default_generators	custom_msgs
message_runtime	rosidl_default_runtime	custom_msgs
image_view	image_view	camera_view
image_publisher	image_publisher	camera_view
rosbag	ros2bag	camera_view
sensor_msgs	sensor_msgs	camera_view, joystick, simulation, avt_camera, cv, offboard_comms, sensor_fusion
cv_bridge	cv_bridge	camera_view, avt_camera, cv
resource_retriever	resource_retriever	camera_view, joystick, controls, cv
joy	joy	joystick
actionlib	N/A (built into rclpy)	acoustics
nav_msgs	nav_msgs	controls, data_pub, sensor_fusion, task_planning
std_srvs	std_srvs	controls
tf	⚠️ tf2 ⚠️	controls, data_pub, task_planning
pid	⚠️ control_toolbox, ros2_control ⚠️	controls
depthai	depthai	cv
rosserial	❌ micro-ros ❌	offboard_comms
rosserial_arduino	❌ micro-ros ❌	offboard_comms
tf2_ros	tf2_ros	static_transforms
tf2	tf2	task_planning
smach	❌	task_planning

Concerns

tf

tf isn't supported in ROS2, so we need to upgrade all references of tf to tf2. The main usage of tf in our code-base is for the quaternion_from_euler and euler_from_quaternion utility methods that are part of tf.transformations. This package provides these utility methods but we can directly import the transforms3d python library if we don't want to use an individually-maintained ROS package.

pid

ROS2 doesn't have a dedicated pid package, but they provide control_toolbox and ros2_control. Some combination of these should allow us to spin up our PID loops, but there will have to be some effort in understanding how these packages work. It's likely that our launch files will be completely scrapped. Alternatively, we can explore writing an in house pid controller that might be better suited to our specific use case.

rosserial and rosserial_arduino

The general consensus is that MicroROS is the alternative to rosserial and rosserial_arduino. It does not support the Nano Every, so we would have to upgrade to the Nano RP2040 Connect, a more powerful Nano. I looked at its specs and I can't see an immediate issue with upgrading to this sku, but we need to investigate this more.

smach

Smach is not supported on ROS2, and I haven't seen any communication indicating that it will be in the future. Before upgrading, we would need to migrate to a different task framework. This is particularly painful because we've invested a lot of time into getting smach working and that seems to be a major area of interest this year.

[muthuArivoli]

For smach, since it doesn't look like you're using smach_ros (the ros extensions for smach), you should just be able to copy it from the smach repo over to here (its just the smach folder at https://github.com/ros/executive_smach). Only porting you'll have to do is to update the build system stuff, which should be fairly simple, especially since they are already using a setup.py. If you do need the ROS extensions, it shouldn't be hard to port over if you choose to do so. I'd also be happy to do that and release it to the larger ROS community, just lmk.

Also, just to note, I think I saw a few people port smach to ROS2, but not sure where that code is (it'll only be community supported).

cc @Brokemia

[ShaanGondalia]

Thanks for looking into that! We have some contacts with this year's finalist teams (BumbleBee, etc.) so we'll reach out to them to see what kind of systems they use for task planning. After speaking with @Brokemia and @Will-Denton I think the consensus is to just use a python package (whether that be smach or whatever) to handle state machines because we aren't really leveraging the ROS portion of smach. Will keep you in the loop with whatever decisions we make on this.

[ShaanGondalia]

Updates

Offboard comms

Instead of using MicroROS, I think that we should implement our own serial bridge and get rid of all of the ROS code in the Arduino. MicroROS has some pretty serious limitations with low memory controllers (like the Nano) that seem to make it more hassle than its worth. Instead, we should create a python ROS node in offboard comms that subscribes to the servo and thruster topics and sends them to the arduino over serial. It will also receive pressure data over serial from the arduino and convert it to the expected ROS topic. This will also let us use ROS2 without having to upgrade our Arduino, even though that should be done regardless.

Controls

The migrated pid loops expose a similar ROS interface as before with services replacing the enable and reset topics. I have some concerns on the performance of the loops as they're now written in python instead of c++, but we'll monitor this and determine if we need to do anything about it. There are a couple of things we can do to speed things up:

1. Use numba to accelerate our python code
2. Extract the pid node to another package that's written in c++, or convert controls into a hybrid python c++ package
3. Convert the pid script into a python API instead of a ROS Node. The PIDManager can then create objects for each loop and manage them directly, which can cut down ROS overhead.

Task Planning

We're currently in the process of refactoring task planning on our main ROS branch (See #371). For now we can hold off on migrating this to ROS2 as there's plenty of stuff to test before we migrate task planning. Once offboard_comms is migrated, the ROS2 code-base should be ready for system-wide testing.