ROS 2 migration pain points

pain.md

Launch

• Where the hell do I find complete docs for XML launch files?
  • https://design.ros2.org/articles/roslaunch_xml.html seems to be the canonical doc
    • but XSD schemata are machine-readable, not human-readable
    • also, it is missing lots of stuff (launch_ros.actions), so e.g. push_ros_namespace is not mentioned in this doc
  • https://docs.ros.org/en/rolling/How-To-Guides/Migrating-from-ROS1/Migrating-Launch-Files.html
    • this is a quite good source, but it isn't comprehensive
• use_sim_time hell (i.e. no support for global parameters)
  • https://discourse.ros.org/t/ros2-use-sim-time-leads-to-inconsistent-clocks/42030/2
  • <set_param> could partially remedy this (but each separately launched file has to set it)
  • Why can't ROS 2 just require a parameter_blackboard node for use_sim_time?
• $(dirname) is broken and unreliable (ros2/launch#618)
• ugly testing for nonempty XML launch args ($(eval 'bool(\'$(var var_name)\')'))
• in Python launch, launch_arguments of IncludeLaunchDescription ingest booleans as 'true'/'false', i.e. strings!
  • launch_arguments=[('use_sim_time', 'true'),]
  • and the error you get if you pass an actual boolean is super cumbersome
• cannot use parameters which are lists of dicts or other non-trivial types (ros2/ros2#1380)
  • the error you get is difficult to understand
• I haven't found any docs on writing custom launch actions (and it took me quite some time to get a little into it)
  • what's missing at minimum is a doc that would tell what are all the steps needed to register the action
    • setup.cfg, make and install as a Python package even if it's a C++ one otherwise, add the decorator...
• No XSD schema for launch_ros with all its actions, only for launch base:
  • ros2/launch#392
  • launch schema is at https://raw.githubusercontent.com/ros2/design/gh-pages/articles/specs/launch.0.1.1.xsd
  • no official example on how to use the schema in launch files
• Setting <arg value> in an <include> will also overwrite the arg in the rest of the launch file (ros2/launch#620 (comment))
  • Workaround: wrap each <include> within its own <group>.
  • It is described in the migration guide, but its meaning is not really obvious to people who want to dive into ROS 2 without prior knowledge:

    • Available in ROS 1, included content was scoped. In ROS 2, it’s not. Nest includes in group tags to scope them.

rclpy

• creating Image, PointCloud2 and other messages with large arrays can be extremely slow
  • https://stackoverflow.com/a/71940633/1076564
  • workaround: assign msg._data instead of msg.data
  • alternative (better) workaround: launch Python with -O: https://docs.python.org/3/using/cmdline.html#cmdoption-O
    • how to do that? #!/usr/bin/env python -O ?

QoS

• I haven't found any complete documentation about qos_overrides parameter. There are some bits and pieces, but e.g. no docs page explains to you that deadline is in nanoseconds.

CLI tools

• ros2 topic hz is unusable because it is in Python and it deserializes all messages (https://discourse.ros.org/t/rmw-zenoh-binaries-for-rolling-jazzy-and-humble/41395/18)
• tab completion of ros2 topic is much worse than ROS 1. Also, the pregenerated message content is incorrect and cannot be used as is
• CLI tools silently ignore RMW_IMPLEMENTATION variable and only talk to the running daemon. So if you first launch something with one RMW and then want to run something else with another RMW, all CLI tools still silently use the first RMW. To solve that, call ros2 daemon stop.

package types

• ament_python packages contain a lot of unnecessary boilerplate: https://discourse.ros.org/t/why-is-there-no-ament-python-simple/42591
• what is a preferred package type for message-only packages? do they need to use ament_cmake? this is a quite common task, so it'd be great to have this documented

ros_gz

• server can be launched as a composable node, but the client can't (need to use Executable)
• topic bridges cannot be launched as composable nodes with the bridge specification passed as arg/parameter (only through YAML config)
  • there is no way how the YAML config of a bridge could be parametrized by world and robot name, which makes these configs practically useless (gazebosim/ros_gz#717)
• topic bridges do not allow easy setting of QoS profiles (but that can be overcome by setting qos_overrides manually)
  • quite important for /clock bridge!
• it is quite difficult to understand how changing a sensor frame_id works, because you have to use gz_frame_id, but that is an undocumented SDF element.
  • SDF defines frame_id, but that doesn't change the ROS frame ID
• <export>ing Gazebo resource paths in package.xml no longer works
  • This needs to be newly implemented using ament hooks and DSV files; the official project template is wrong (gazebosim/ros_gz_project_template#43) and confusing (gazebosim/ros_gz_project_template#44)

Components

• component_container is single-threaded (it even rins its own load/unload callbacks on the single thread)! Use component_container_mt.

package types

• what is a preferred package type for message-only packages? do they need to use ament_cmake? this is a quite common task, so it'd be great to have this documented

They do have to be CMake packages (and thus use ament_cmake). It's mentioned here: https://docs.ros.org/en/rolling/Tutorials/Beginner-Client-Libraries/Custom-ROS2-Interfaces.html#create-a-new-package

Note that it is, and can only be, a CMake package, but this doesn’t restrict in which type of packages you can use your messages and services. You can create your own custom interfaces in a CMake package, and then use it in a C++ or Python node, which will be covered in the last section.

This might not be visible enough, though. Maybe we can make it a reST note.

component_container is single-threaded (it even rins its own load/unload callbacks on the single thread)! Use component_container_mt.

or component_container_isolated with single or multi threads?