You're reading the documentation for an older, but still supported, version of ROS 2. For information on the latest version, please have a look at Galactic.

ROS 2 Humble Hawksbill (codename ‘humble’; May, 2022)

Humble Hawksbill is the eighth release of ROS 2. What follows is highlights of the important changes and features in Humble Hawksbill since the last release.

Supported Platforms

Humble Hawksbill is primarily supported on the following platforms:

Tier 1 platforms:


Tier 2 platforms:


Tier 3 platforms:


For more information about RMW implementations, compiler / interpreter versions, and system dependency versions see REP 2000.


To come.

Changes since the Galactic release


Support Type Adaption for Publishers and Subscriptions

After defining a type adapter, custom data structures can be used directly by publishers and subscribers, which helps to avoid additional work for the programmer and potential sources of errors. This is especially useful when working with complex data types, such as when converting OpenCV’s cv::Map to ROS’s sensor_msgs/msg/Image type.

Here is an example of a type adapter that converts std_msgs::msg::String to std::string:

struct rclcpp::TypeAdapter<
  using is_specialized = std::true_type;
  using custom_type = std::string;
  using ros_message_type = std_msgs::msg::String;

    const custom_type & source,
    ros_message_type & destination)
  { = source;

    const ros_message_type & source,
    custom_type & destination)
    destination =;

And an example of how the type adapter can be used:

using MyAdaptedType = TypeAdapter<std::string, std_msgs::msg::String>;

// Publish a std::string
auto pub = node->create_publisher<MyAdaptedType>(...);
std::string custom_msg = "My std::string"

// Pass a std::string to a subscription's callback
auto sub = node->create_subscription<MyAdaptedType>(
  [](const std::string & msg) {...});

To learn more, see the publisher and subscription) examples, as well as a more complex demo. For more details, see REP 2007.


ros2 topic pub will wait for one matching subscription when using --times/--once/-1

When using --times/--once/-1 flags, ros2 topic pub will wait for one matching subscription to be found before starting to publish. This avoids the issue of the ros2cli node starting to publish before discovering a matching subscription, which results in some of the first messages being lost. This is particularly unexpected when using a reliable qos profile.

The number of matching subscriptions to wait before starting publishing can be configured with the -w/--wait-matching-subscriptions flags, e.g.:

` ros2 topic pub -1 -w 3 /chatter std_msgs/msg/String "{data: 'foo'}" `

to wait for three matching subscriptions before starting to publish.

-w can also be used independently of --times/--once/-1 but it only defaults to one when combined with them, otherwise the -w default is zero.

See for more details.

ros2 param dump default output changed

  • --print option for dump command was deprecated.

    It prints to stdout by default:

    ros2 param dump /my_node_name
  • --output-dir option for dump command was deprecated.

    To dump parameters to a file, run:

    ros2 param dump /my_node_name > my_node_name.yaml

Known Issues

To come.