The simulation team at Open Robotics is happy to announce that Gazebo Fortress 
simulation support is available with ROS Humble! Get started with:
sudo apt install ros-humble-desktop-full
See Fortress in action at this community meeting:
Run ROS 2 demos here
Highlights
- Fortress world : Try out the Fortress demo world, which showcases lots of new features at once!
- Sensors: Support for a dozen sensors out-of-the-box, including the new segmentation camera, force-torque, and GPS; as well as support for creating your own sensors.
- Graphical interface: The 3D view has more features than ever, with various introspection tools, flexible camera control, 3D plotting, satellite map data, control panels and more!
- Feature-rich worlds: Particle effects, heightmaps from Digital Elevation Models, animated humans, .
- SDFormat: It’s never been easier to describe your models. Have you always wanted to use degrees and quaternions, or add, remove, modify or replace elements of included files, export models directly from Blender?
- CLI: Introspect and interact with your simulation with powerful command line tools.
- Headless rendering: Simulating on the cloud? It’s now possible to run Ogre 2 rendering without a window using EGL.
- Python API: Python wrappers are available for a large part of Gazebo’s APIs for easier scripting.
- Test fixture: The new test fixture makes it even easier to write automated tests.
- Rendering engines: Out-of-the box support for Ogre 1 and Ogre 2, with support for Physically Based Rendering, and a plugin interface for new engines.
- Physics engines: Support for DART, Bullet, Trivial Physics Engine, with a plugin interface to other engines.
- Service bridge: From Humble, not only topics, but also services can be bridged from the Gazebo to ROS!
Libraries and tools
Gazebo is more than a simulator: it’s a collection of 16 C++ libraries that can be used independently of the simulator on your robot applications. You can use them on your ROS packages or plain C++ projects. If you need rendering or physics engine abstractions; a GUI framework to create modern robot interfaces; math, graphics or AV utilities, one of these libraries may come in handy!
You can use these rosdep keys in your package.xml
ignition-fortressignition-cmake2ignition-common4ignition-fuel-tools7ignition-gazebo6ignition-gui6ignition-launch5ignition-math6ignition-math6-eigen3ignition-msgs8ignition-physics5ignition-pluginignition-rendering6ignition-sensors6ignition-toolsignition-transport11ignition-utils1sdformat12
Gazebo Development Team
Congrats everyone on the launch!
We’re excited to support ROS 2 Humble in Foxglove Studio and rosbridge.
(screenshot of our upcoming rewritten 3D visualization panel)
We also have a rosbag2 MCAP storage plugin available for those interested in an alternative to sqlite recording. For more information, check out mcap.dev.
I would like to highlight the number of unanswered questions on https://answers.gazebosim.org/questions/
If Gazebo Fortress is going to be the new default simulator for ROS Humble, it is going to be important to answer new users’ questions… no matter how stupid they seem to experienced developers.
FWIW, I just installed ROS Humble via sudo apt install ros-humble-desktop on Ubuntu 22.04 and got a black screen in Gazebo workspace. It is going to be hard to nudge users to the new releases if the tutorials fail on the tier one install.
Congrats on Humble, Gazebo Fortress, Foxglove Studio, and all ROS 2 packages! Awesome news!
We’re excited to announce that the ROS 2 Humble Hawksbill release includes FogROS 2, an open-source cloud-robotics pilot platform from UC Berkeley. Cloud computing using commercial clusters such as Amazon Web Services (AWS) is now fast enough to enable secure compute-intensive robot functions such as SLAM map building from video, grasp planning, and high-dimensional motion planning to be performed in the Cloud using high-performance hardware and GPUs in near real-time. FogROS 2 offers ROS 2 functions to streamline the deployment of robot code. Developers do not need to change their code–they need only to specify an AWS configuration of computers that they want their code to run. FogROS 2 coordinates the details of initiating hardware instances, installing software and dependencies, securing robot-cloud communication, and launching cloud processes.
In example applications, we used FogROS 2 to deploy compute-intensive ROS 2 nodes for SLAM, Grasp Planning, and Motion Planning to the cloud. For Visual SLAM, we ran an ORB-SLAM 2 node on a multi-core cloud computer and we got a 2x speedup. For Grasp Planning, we ran the Dex-Net node on a GPU instance in the cloud and got a 12x speedup. For Motion Planning, we ran Motion Planning Templates on a 96-core cloud computer and got a 28x speedup.
The FogROS 2 team includes: Jeffrey Ichnowski, Kaiyuan (Eric) Chen, Karthik Dharmarajan, Simeon Adebola, Michael Danielczuk, Víctor Mayoral-Vilches, Hugo Zhan, Derek Xu, Ramtin Ghassemi, John Kubiatowicz, Ion Stoica, Joseph Gonzalez, and Ken Goldberg.
Read more:
- GitHub
- More information, tutorials, and documentation
- Paper on the design, architecture, experiments, and results
– The FogROS 2 Team
Cheers on the Humble release 
! The team at Acceleration Robotics and the Hardware Acceleration Working Group is proud to have contributed to bring the following capabilities to Humble:
Hardware Acceleration in ROS 2
ROS 2 stack Hardware Acceleration Architecture @ ROS 2 stack
+-----------+ +---------------------------+
| | | acceleration_examples |
|user land | +-----------------+------------------+--+-----------------+
| | | Drivers | Libraries | Firmware |Cloud |
+-----------+ +-----------------+-+-------------------------+-----------+
| | | ament_1| ament_2 | | | | |
| | +---------------------------------------+ fw_1|fw_2|cloud1|
| tooling | | ament_acceleration|colcon_acceleration| | | |
| | +---------------------------------------------+-----------+
| | | build system | meta build | firmware | cloud|
+-----------+ +--------+----------+-------+-----------+-+--------+--+---+
| rcl | | | | |
+-----------+ | | | |
| rmw | | | | |
+-----------+ + + + +
|rmw_adapter| Pillar I Pillar II Pillar III Pillar IV
+-----------+
(more at REP-2008 PR - ROS 2 Hardware Acceleration Architecture and Conventions)
-
ament_acceleration: CMake macros and utilities to include hardware acceleration in the ROS 2 build system (ament) and its development flows. -
ament_vitis: CMake macros and utilities to include Vitis platform into the ROS 2 build system (ament) and its development flows. -
colcon-hardware-acceleration: An extension for colcon-core to include Hardware Acceleration capabilities. -
ros2acceleration: acceleration command for ROS 2 command line tools. -
tracetools_acceleration: LTTng tracing provider wrapper for ROS 2 packages in the Hardware Acceleration Working Group. -
acceleration_firmware: Base ROS 2 package for hardware acceleration firmware. Used to organize firmware dependencies across vendors. -
adaptive_component: A composable container for Adaptive ROS 2 Node computations. Select between FPGA, CPU or GPU at run-time.
And not shipped in Humble but worth checking:
-
acceleration_examples: ROS 2 package examples demonstrating the use of hardware acceleration.
Humble support in Yocto (Honister) - build custom Linux-based production-grade operating systems for robots
Happy to share an extension (PR) of the meta-ros Yocto/OE recipes that allow building production-grade custom Linux operating system with support for ROS 2 Humble while using Yocto (Honister).
Why Yocto/PetaLinux is a great fit for hardware acceleration in robotics?
Hardware acceleration involves creating custom compute architectures to improve the computing performance. In a nutshell, by designing specialized acceleration kernels, one can build custom brains for robots to hasten their response time. This becomes specially feasible when using adaptive computing and FPGAs which according to previous benchmarks, deliver best results in robotics with ROS.
Creating such custom compute architectures involves both hardware and software customization, thereby:
Yocto. Though complicated ,Yoctoin combination with hardware acceleration helps deliver high performance production-grade robotic systems.
The recipes have been validated with various popular SBCs. Instructions on how to reproduce in the links below:
| Image | Board | Description |
|---|---|---|
 |
AMD KR260 | The Kria™ KR260 Robotics Starter Kit is a Kria SOM-based development platform for robotics and factory automation applications. With native ROS 2 Humble support, it enables roboticists with a ROS 2-centric dev. flow. |
 |
AMD KV260 | The Kria™ KV260 starter kit is a development platform for the K26, the first adaptive Single Board Computer. KV260 offers a compact board for edge vision and robotics applications. |
 |
AMD ZCU102 | The ZCU102 Evaluation Kit enables designers to jumpstart designs for automotive, industrial, video, and communications applications. This kit features a Zynq® UltraScale+™ MPSoC with a quad-core Arm® Cortex®-A53, dual-core Cortex-R5F real-time processors, and a Mali™-400 MP2 graphics processing unit. |
 |
AMD ZCU104 | The ZCU104 Evaluation Kit enables designers to jumpstart designs for embedded vision applications such as surveillance, Advanced Driver Assisted Systems (ADAS), machine vision, Augmented Reality (AR), drones and medical imaging. This kit features a Zynq® UltraScale+™ MPSoC EV device with video codec and supports many common peripherals and interfaces for embedded vision use case. |
 |
NVIDIA Jetson Nano | The Jetson Nano™ Developer Kit is a small, powerful computer that lets you run multiple neural networks in parallel for applications like image classification, object detection, segmentation, and speech processing. All in an easy-to-use platform that runs in as little as 5 watts. |
 |
Jetson AGX Xavier | The NVIDIA Jetson AGX Xavier Developer Kit is an AI computer for autonomous machines, delivering the performance of a GPU workstation in an embedded module under 30W. Jetson AGX Xavier is designed for robots, drones and other autonomous machines. |
 |
Microchip PolarFire Icicle Kit | The PolarFire SoC Icicle kit is a low-cost development platform that enables evaluation of the five-core Linux capable RISC-V microprocessor subsystem, innovative Linux, and real-time execution, low-power capabilities and the rich set of peripherals of the PolarFire SoC FPGA. |
After the Humble sync, the recipes might go out of date which will require (again) community contributions. If you’re relying on meta-ros, please contribute back, try out the recipes and send PRs with adjustments as needed while reporting your feedback in the Pull Request.
If you have questions about Yocto or need additional rationale on why this is important, check out the original article ROS 2 Humble Hawksbill with Yocto and PetaLinux.
ROS Humble docker images are now available on Dockerhub! 
The ROS latest tag now points to the Humble ros_base image.
Simply run this command to download and start a session in a Humble container:
docker run -it ros:humble
ROS Humble images are available for the following platforms/architectures:
Ubuntu Jammy:
amd64
arm64v8 (aarch64)
The desktop image (amd64 only) is available on the ‘osrf/ros’ docker hub profile
Not that the ros1-bridge image does not exist for Humble as this is the first ROS 2 distribution not coming with ROS 1 support.
In the coming weeks new tags will be made available to provide the new variants (aka perception, simulation and desktop-full).
As always:
- Please report any issue with the images on Issues · osrf/docker_images · GitHub
- Don’t forget to star our official repo so others might discover it!
- You can find the list of tags here
Happy containing!
Friendly reminder to package maintainers to get your Humble Brags in =).
We are celebrating the release of humble, and the new features it brings to enable hardware acceleration for graphs of nodes.
This is a culmination of a 9 month collaboration with Open Robotics to improve ROS performance on hardware accelerated platforms. Our thanks and appreciation goes to Chris Lalancette, Audrow Nash, Gonzalo de Pedro, and William Woodall for all of their hard and relentless efforts; special thanks to Brian Gerkey for partnering on this work.
As robotics applications embrace AI, CV, and other compute intensive workloads, it has become imperative to enable hardware acceleration in ROS. With hardware acceleration, these applications can perform more functions with higher throughput, and better perf/watt. Realizing these benefits are often specific to the hardware implementation and therefore need to be abstracted from ROS.
(example graph of nodes using hardware acceleration in Foxy (top graph) compared to use of type adaption in Humble (bottom graph). Type adaptation reduces copies from CPU to GPU in a pipeline of nodes, while increasing concurrency between the CPU and GPU)
TYPE ADAPTATION
ROS topics can be adapted to a format better suited for acceleration in hardware using type adaptation (REP-2007). A node using an adapted type, can publish, and/or receive the adapted type. Nodes using an adapted type, need to provide functions to convert from the standard type, to the adapted type, and visa-versa. This enables a graph of nodes to use an adapted type which can improve CPU and hardware acceleration concurrency, offload the CPU from compute tasks, and eliminate memory copies between the CPU and hardware accelerator.
TYPE NEGOTIATION
With a graph of ROS nodes using an adapted type, we can further benefit from optimizing the type used between nodes in the graph. Nodes supporting type negotiation (REP-2009) can share a list of types they support as a publisher, and as a subscriber with a weight indicating their preferences. ROS will review the publishers and subscribers participating in type negotiation, and optimize for preferences while maintaining compatibility with nodes that do not support type negotiation. Preferences are a way to reflect performance, or cost of the type, and should be tuned by the developer of the node, but can be overridden by the application developer.
(profile of Jetson AGX Xavier, with 89ms on Foxy vs 32ms on Humble with type adaptation for the same graph of nodes)
As performance was improved with type adaptation, and type negotiation, intra-process topic passing in ROS became a bottleneck. Nsight Systems was used to profile message passing to identify areas for improvement. Changes were made in rcl.cpp to reduce shared memory pointer copies and checking to print debug messages.
(ROS2 node graph operating in sequence on 1080p CUDA buffers in Foxy vs the same node graph in Humble with Type Adaptation; results measured in Hz on Jetpack 5.0 developer preview, Ubuntu 20.04 with Jetson AGX Orin and Xavier. Graph of nodes is designed to test framework performance by minimizing compute workload, bringing focus to overhead in the ROS Client Library)
In pixel processing Jetson AGX Orin went from 0.55 gigapixels/sec in Foxy to 4 gigapixels/sec in Humble on this test.
Hardware accelerated graphs of nodes using type adaption and type negotiation improve performance, concurrency, and perf/watt. There are other alternative approaches to implementing hardware acceleration which fork ROS, bypass ROS topics or introduce incompatibilities with existing nodes. Type adaptation and type negotiation are native to ROS with Humble, compatible with existing nodes, and open to all types of hardware accelerators including GPUs, DSPs, NN accelerators, and other HW blocks.
We are implementing type adaptation and type negotiation in NITROS (NVIDIA Isaac Transport for ROS) to optimize hardware acceleration for ROS2 Humble; this will be released in Isaac ROS late June.
Great work all. Specially Open Robotics, as well as TSC members and leaders. These has a been a significant multi-year effort and collaboration by some of the brightest minds I have been lucky to meet. It has been great to see how many joined the journey and molded a collective vision along the way.
Looking forward to see what the world builds with ROS 2 in the years to come!
Cheers,
Cam
Congratulations for the ROS 2 Humble Hawksbill release! 
The eProsima team is very excited as the new ROS 2 Humble comes with Fast DDS!
In fact, Fast DDS was selected as the default DDS middleware for the ROS 2 Humble, allowing ROS 2 users to develop their robotics applications using a reliable and performance optimized implementation.
Known for many features like
- Real-time behavior
- DDS Security
- Discovery Server
- Shared Memory transport
- Synchronous and asynchronous publishing modes
- and many more
eProsima was able to include even more characteristics in Fast DDS for the Humble release…
- Content Filtered Topic feature (CFT) that provides the Topic with filtering capabilities, enabling users to segment the subset of data of their interest under certain criteria when subscribing to a topic.
- Add remote servers and modify server locators at runtime: now it is possible to programmatically add and modify the participant’s list of remote servers to which the running server or client should connect while a server or client is running.
- Static Discovery new format: the new exchange format reduces the necessary network bandwidth to transmit Static.
- XML support for Fast DDS CLI.
- Complete events support: incompatible QoS notification for Publisher and Subscriber.
Stay tuned because more features are coming!!
The MoveIt team at PickNik Robotics is excited to announce that MoveIt 2 is available with ROS Humble! MoveIt continues to be the #1 ROS application for manipulation and motion planning in complex environments.
Example of supervised autonomy door opening with MoveIt 2, MoveIt Studio, and the UR driver for ROS 2.
PickNik and Fraunhofer IPA have applied MoveIt 2 to advanced robotic welding techniques. Full video here
We’ve put a lot of effort into revamping the tutorials with an improved learning-oriented content structure! Get started by building from source or using our Rolling binary release. Humble binary release coming soon!
Highlights
- Hybrid Planning: use a (slower) global motion planner with a (faster) local motion planner to enable a robot to solve different tasks online and in dynamic environments
- TOTG: now default parameterization method
- Ruckig: improved time parameterization and jerk smoothing that allows for nonzero initial/final conditions
- MoveIt Setup Assistant: the entry point for using MoveIt, now for ROS 2
- MoveIt Config Utilities: simplify loading parameters
- Lots of new ROS 2 drivers for arms (Universal Robotics and more announced soon)
Thanks to our Maintainers and Contributors
Andy Zelenak, Jafar Abdi, Vatan Aksoy Tezer, Tyler Weaver, Henning Kayser, Abi Sivaraman, David V. Lu!!, Sebastian Jahr, Stephanie Eng
rclc - The ROS 2 C-API for micro-controllers
The rclc package complements the ROS Client Support Library (rcl) to provide a complete ROS 2 client library for the C programming language. That is, rclc does not add a new layer of types on top of rcl (like rclcpp and rclpy do) but only provides convenience functions that ease the programming with the rcl types.
With Humble, it supports not only all communication types like subscriptions, timers, services, clients etc. but also parameters, actions and lifecycle. It comes with its own Executor enabling more deterministic and real-time execution management. It serves as a fully-compliant ROS 2 programming interface for micro-ROS applications on micro-controllers. An overview, concepts, tutorials, supported micro-controllers and RTOSes can be found at micro.ros.org.
Check out the Tutorials today and get started with first applications on your micro-controller on https://github.com/micro-ROS/.
Micro-ROS stack
Highlights of new features in Humble
- Added support for ROS 2 Parameters including command-line tools.
- Added support for ROS 2 Actions.
- Added support for Lifecycle Services in the rclc lifecycle nodes.
- API to remove subscriptions (and other handles) from Executor at runtime.
- API to add subscriptions (and others handles) with a Quality-of-Service parameter.
- API to add subscriptions with a context pointer parameter. This allows the callback to access global data structures.
- … and many more improvements and bug fixes (more than 60 pull requests since the Galactic release).
Many thanks to our Maintainers and Contributors
Antonio Cuadros, Brett Downing, Pablo Garrido, Ilya Guterman, Ralph Lange, Ted Miller, Arne Nordmann, Ivan Santiago Paunovic, Steven! Ragnarök, Błażej Sowa, Jan Staschulat.
micro-ROS Humble release!
Congratulations for the release of ROS 2 Humble Hawksbill from micro-ROS!
We worked as fast as possible to get the small turtle ready, and are proud to announce the corresponding micro-ROS Humble release. Careful, it just hatched.
Since last year a lot has happened in ROS 2 but not less in micro-ROS!
First and foremost, micro-ROS was able to drastically improve its overall performance, making the framework less memory-hungry, more reliable, more multi-thread capable and real-time ready.
Further important features included until this Humble release are:
- new RCLC characteristics
- new support for various boards: RENESAS RA Family, TI Tiva™ C Series,
- new support for numerous platforms: Platforms IO, St STMCube, Microsoft Azure RTOS, Espressif ESP-IDF
- new embeddedRTPS experimental RMW
- Micro XRCE-DDS v2.1.1
All the details can be found in the micro-ROS Humble release notes.
Get creative!
I have some questions regarding the performance enhancement with Isaac ROS :
-
Is the repo of graph nodes used for benchmarking publicly available?
-
Is there no copy at all (e.g. cudamemcpy) between CPU and GPU for this ROS2 node graph ?
An open source CUDA example on how to use this will be released in the next few weeks.
The NITROS package implementing this will be part of the Isaac ROS release.
There is an initial copy from CPU to GPU at the start of the node graph, and a copy from GPU to CPU at the end of the node graph. This is visible as the red & orange rectangles in the profile of the CUDA API.
In practice, a USB or Ethernet camera (for example Realsense) has both the copy from CPU->GPU at the start of a node graph, and results from GPU->CPU at the end of the node graph.
More optimally a CSI or GMSL camera’s are used to improve performance as the camera stream would come directly into GPU memory off the hardware interface, and remain in GPU memory until results from a perception function are pulled back to the CPU.
Thanks.
Nav2
Hi all, we have a lot of changes from Galactic to Humble to announce. You can find a full accounting on our Migration Guide however: Galactic to Humble — Navigation 2 1.0.0 documentation.
Highlights
- Massive improvements to the Smac Planner in run-time, organization, heuristics, and adding in new State Lattice planner, and more.
- Adding in a Python3 API for Nav2 application developers that can access all of Nav2’s systems from a pythonic API.
- Improvements in run-time performance across the stack reducing the number of nodes, explicitly controlling executors, and enabling composition by default so all of Nav2 is in a single process reducing CPU overhead by 15% and reducing memory by 70%. Tested to run easily on a raspberry pi with plenty of room left for custom robot code.
- Inclusion of new algorithms: State Lattice, Rotation Shim, Simple Smoother, Constrained Smoother, (soon to add) Velocity Smoother
- Dynamic reconfiguration of all appropriate parameters
- Addition of a new Smoother Server in the Nav2 core architecture for global path smoothing
- Added respawn support to Lifecycle Manager and Nav2 bringup
- Several new documentation pages, tutorials, etc.
And much more!
Enjoy the new architecture diagram ™!
Hello!
Thank you for the great work on ROS.
I would like to ask to default DDS implementation in Humble. I read the post here:
But if I open the official Humble documentation I read the Connext DDS is the default in Humble.
https://docs.ros.org/en/humble/Releases/Release-Humble-Hawksbill.html#rmw-connextdds
I have one more related question. Does Humble release change default DDS implementation in rolling?
Thank you, Mat.
ROS Humble is using Connext 6 as default for rmw_connextdds:
By default, Humble Hawksbill uses Connext 6.0.1 as the DDS implementation for
rmw_connextdds. It is still possible to use Connext 5.3.1 withrmw_connextdds, but it must be rebuilt from source.
But rmw_connextdds is not the default DDS implementation for ROS Humble.
Yes. We always change Rolling first, and then the next release inherits the default from Rolling. So in this case, both Rolling and Humble now use Fast-DDS by default.