Current participants as of December 08, 2025 08:16 AM (UTC):
ASL ETHZ, Achu Wilson, CAR: Components, Agents, and Robots with Dynamic Languages, David Hodo, Isaac Saito, John Stowers, Mat Sadowski Blog, Michael Ferguson, MobileWill, MoveIt!, NooTriX, Open Source Robotics Foundation, PAL Robotics blog, Pi Robot, ROS Discourse General, ROS Industrial, ROS news, ROSVirtual, Robbie The Robot, Robots For Robots, Sachin Chitta's Blog, TORK, Transitive Robotics Blog, William Woodall, Yujin R&D, mobotica,

Want your blog to be on the awesome planet ROS ?

If you are a ROS developer/user and you blog about it, ROS wants those contributions on this page ! All you need for that to happen is:

• have an RSS/Atom blog (no Tweeter/Facebook/Google+ posts)
• open a pull request on planet.ros tracker indicating your name and your RSS feed/ATOM url. (You can just edit the file and click "Propose File Change" to open a pull request.)
• make your ROS related posts tagged with any of the following categories: "ROS", "R.O.S.", "ros", "r.o.s."

Warnings

For security reasons, html iframe, embed, object, javascript will be stripped out. Only Youtube videos in object and embed will be kept.

Guidelines

Planet ROS is one of the public faces of ROS and is read by users and potential contributors. The content remains the opinion of the bloggers but Planet ROS reserves the right to remove offensive posts.

Blogs should be related to ROS but that does not mean they should be devoid of personal subjects and opinions : those are encouraged since Planet ROS is a chance to know more about ROS developers.

Posts can be positive and promote ROS, or constructive and describe issues but should not contain useless flaming opinions. We want to keep ROS welcoming :)

ROS covers a wide variety of people and cultures. Profanities, prejudice, lewd comments and content likely to offend are to be avoided. Do not make personal attacks or attacks against other projects on your blog.

Suggestions ?

If you find any bug or have any suggestion, please file a bug on the planet.ros tracker.

Hello everyone,

I would like to have your recommendations on ROS2-compatible drones suitable for educational and research purposes. I’ve been through several options but haven’t found the ideal solution yet.

My Requirements:

• ROS2 native support or well-maintained ROS2 integration

• Onboard sensors capable of SLAM (3D LiDAR, RGBD camera, or stereo camera)

• Ability to operate indoors without external positioning infrastructure

• Budget: approximately $6,000 USD

What I’ve Tried/Considered:

I came across this helpful discussion: https://discourse.openrobotics.org/t/trying-to-find-pre-built-drones/44168, which recommends the Crazyflie platform. While Crazyflie is excellent for swarm research and basic control, it requires external infrastructure such as motion capture systems or marker-based localisation (e.g., Lighthouse or Loco Positioning), which isn’t practical for my use case.

Similarly, I’ve used DJI Tello drones, but they share the same limitation—reliance on external environmental setup for accurate localisation and mapping.

What I’m Currently Considering:

I’ve been looking at the ModalAI Starling 2 Max (https://www.modalai.com/products/starling-2-max?variant=48172375900484), which appears promising with its VOXL 2 flight computer, stereo cameras, and PX4/ROS2 support. However, I’d appreciate feedback from anyone who has hands-on experience with this platform, particularly regarding:

• Ease of integration with ROS2

• Reliability of onboard VIO/SLAM for indoor navigation

• Suitability for student projects and coursework

• Documentation quality and community support

Use Case:

The drones will be used for teaching autonomous navigation, path planning, and SLAM concepts to postgraduate students. Ideally, students should be able to develop and test algorithms in simulation (Gazebo/Webots/PyBullet) and deploy them on real hardware with minimal friction.

I’d greatly appreciate any recommendations, alternatives, or insights from those with experience in this area. If there are other platforms I should consider within this budget range, please do share.

Thank you in advance for your help!

1 post - 1 participant

Read full topic

Hi community.

I have created an awesome list of ROS2 packages on my github. It covers a wide range of topics, like motion and planning, localization (SLAM algorithms), logging, monitoring, client libraries for different languages, useful tools for development, AI based tools etc.

It’s regularly updated with new intreresting packages. Hope it will be useful for everyone in the community.

Here is this Awesome list of ROS2 packages.

1 post - 1 participant

Read full topic

The next ROS 2 Rust Meeting will be Mon, Dec 8, 2025 2:00 PM UTC

The meeting room will be at https://meet.google.com/rxr-pvcv-hmu

In the unlikely event that the room needs to change, we will update this thread with the new info!

1 post - 1 participant

Read full topic

Hey everyone!

At ROSCon Spain 2025 we ran a hands-on workshop about ROS 2 testing as part of our work at Ekumen, covering everything from basic linters and unit tests to integration testing and CI. Several people asked if the materials would be shared publicly, so here they are in case they’re useful to others as well:

Repository: https://github.com/Ekumen-OS/ros2_testing_workshop_roscon_es_25
Slides are included in the repo.

Everything is built around small C++ examples and simple exercises. Nothing fancy, just practical patterns we’ve found helpful when trying to make ROS 2 codebases more reliable and easier to maintain.

If you end up going through it or applying parts of it in your projects, we’re more than happy to get feedback, questions, or suggestions. Feel free to open issues or comment here in the thread.

Thanks to everyone who joined at the workshop, and to the ROSConES organizers for a great event. Hope this can help more people working on testing in ROS 2.

1 post - 1 participant

Read full topic

Today, I am excited to introduce Genesys, a new framework I built, designed to make ROS 2 development faster, cleaner, and more intuitive for everyone.

We’ve all faced the boilerplate, complex build systems, and fragmented tooling that can slow down robotics projects. Genesys is our solution. It’s an opinionated framework that simplifies common workflows and provides a single, unified CLI (genesys) to manage your entire project lifecycle, from scaffolding to simulation.

What makes Genesys different?

• Zero Boilerplate: Use elegant Python decorators (@node, @publisher, @subcriber, @service,@timer, etc) and C++ Macros (ROS_PUBLISHING_NODE, ROS_UNIVERSAL_NODE) to define your components without writing repetitive code. The framework auto-generates your build and launch files for you.
• Unified CLI: Say goodbye to juggling multiple commands. A single genesys entry point handles everything from “genesys new” for project setup to “genesys build” and “genesys run” for execution the genesys build command also comes with a “- -persist” flag that allows you build once and run on any terminal, this flag will add a command to source your workspace’s install/setup.bash file to your shell’s startup script, “genesys sim create” creates a new *_gazebo package in the sim/ directory, fully configured for a specific robot. “genesys sim run” launches a Gazebo simulation from one of the *_gazebo packages.
• 100% ROS 2 Compatible: Genesys isn’t a replacement for ROS 2, it’s an enhancement. Every Genesys project is a valid ROS 2 project, meaning you can always fall back to the standard colcon and ros2 commands whenever you need to.

Genesys is about getting you back to what you love: building amazing robots. We’re on a mission to create a “happy path” for robotics development, and this is just the beginning.

Ready to streamline your workflow? Learn more about Genesys and get started today!

Check out the genesys documentation for further insight https://genesys-docs.vercel.app/

Check out and star the repo on GitHub! GitHub - isaac-hash/Genesys: A robotics framework built on ROS2 to speed up development, reduce configs and boilerplate

ros2 robotics #Genesys python #RoboticsDevelopment #OpenSource

1 post - 1 participant

Read full topic

I recently had the following warning when loading a node inside an rclcpp_component manager.

[rcl.logging_rosout]: Publisher already registered for node name: ‘my_manager’. If this is due to multiple nodes with the same name then all logs for the logger named ‘my_manager’ will go out over the existing publisher. As soon as any node with that name is destructed it will unregister the publisher, preventing any further logs for that name from being published on the rosout topic.

It also showed two nodes named “my_manager” in the node list, with each their own parameter’s related services.

After digging, it appears that MoveIt’s RobotModelLoader calls moveit::getLogger, which itself creates a new node. However, because the component manager was started with -r __node:=foobar, all subsequent nodes created inside the same process would inherit the same name.

The same problem can appears without rclcpp_component, with this example:

#include <moveit/robot_model_loader/robot_model_loader.hpp>
#include <rclcpp/rclcpp.hpp>

// Try to run it with and without --ros-args -r __node:=foobar
int main(int argc, char** argv)
{
    rclcpp::init(argc, argv);
    rclcpp::Node::SharedPtr myNode = rclcpp::Node::make_shared("my_node");
    myNode->declare_parameter("my_param", 42.0);
    robot_model_loader::RobotModelLoader rml {myNode, "robot_description", false};
    rclcpp::spin(myNode);
    rclcpp::shutdown();
}

Now, this didn’t cause any problem as far as I could tell, but I don’t like warnings and I really don’t like multiple nodes sharing the same name.

I see multiple solutions:

1. Rename the node using its orignal name, e.g. -r my_node:__node:=foobar. This requires knowing the original node name, and it doesn’t work with launch_ros, namely ComposableNodeContainer which crafts the renaming argument itself and needs to know the manager’s name to load the components inside. Maybe modify launch_ros in consequence.
2. Ask MoveIt not to create a new node, or at least accept a custom logger argument for the RobotModelLoader
3. Modify rcl to only apply the __node renaming to the first created node.
4. Ignore the warning, maybe disable the parameters services from the node created by moveit::getLogger.

What do you think? Is there a guideline on how to use __node:= and creating multiple nodes in the same process?

1 post - 1 participant

Read full topic

Follow up of Robotics Distributed System based on Kubernetes (really old, but i believe there are many interests how to manage ROS and ROS 2 application with Kubernetes.)

Hi All,

(we have been working on this with CNCF for a long time) we recently added the new feature in KubeEdge, called “Resource Upgrade Control at Edge”. i understand that this is not only for ROS 2 but other IoT workloads controlled by Kuberentes and KubeEdge, this is one of the differentiating feature developed for ROS 2 application workloads.

This feature lets you control when and how resources are upgraded on each edge node, giving full flexibility over deployment timing under Kubernetes Cluster. That means for edge AI, robots, drones and EVs, you can now coordinate updates safely and precisely — no more unintentional service interruptions or synchronization issues.

Each edge node can control the upgrade timing at edge with Kubernetes even with rolling upgrade policy !

Please take a look how this feature works before and after:

we also work on other projects to un-gap the boundary between cloud and edge, that are really related to robot and robotics application.

i will allocate some time to summarize our activity and share the update including all the development some time later.

Happy ROSing!
Tomoya

1 post - 1 participant

Read full topic

hello!

we are trying to play with robots this week with SUSE.

see SUSE Hack Week: SUSE Robotics

anyone want to join? we would like to make some SUSE base available for ROS2, maybe reaching Tear 1 support!

happy hacking!

1 post - 1 participant

Read full topic

Qualcomm open source a set of ROS2 packages based on Qualcomm devices: Robot Operating System (ROS) for QualcommTechnologies, Inc. · GitHub

These packages provide the features such as hardware acceleration, zero copy and AI inference, most of them are supported on Ubuntu, can be simply installed by “apt install xxx“.

Hope it is helpful to you.

2 posts - 2 participants

Read full topic

Hey everyone

I’m working on SeekSense AI, a training-free semantic search layer for indoor mobile robots – basically letting robots handle “find-by-name” tasks (e.g. “find the missing trolley in aisle 3”, “locate pallet 18B”) on top of ROS2/Nav without per-site detectors or tons of waypoint scripts.

I’ve put together a quick 3–4 minute survey for people who deploy or plan to deploy mobile robots in warehouses, industrial sites, campuses or labs. It focuses on pain points like:

• handling “find this asset/location” requests today,

• retraining / retuning perception per site,

• dealing with layout changes and manual recovery runs.

Survey: [form link]
More about the project: https://www.seeksense-ai.com

At the end there’s an optional field if you’d like to be considered for early alpha testing later on – no obligation, just permission to reach out when there’s something concrete.

If you’re working with AMRs / AGVs / research platforms indoors, your input would really help me shape this properly

1 post - 1 participant

Read full topic

jros2

A ROS 2 compatible Java library for publish-subscribe. I dare say it’s the easiest way possible to talk to other ROS 2 nodes; no local ROS 2 installation is required. All you need to do is depend on the library in your Java project (works best with Maven or Gradle).

Works on: Windows, Linux (including NVIDIA Jetson & RPi), and macOS! Android support is planned.

jros2 loosely follows rclcpp regarding API design and usage. Includes the following features:

• Publish and subscribe to ROS 2 topic
• Supports custom message types
• Generate Java classes from ROS 2 .msg files
• Fast-DDS backend
• Minimal and fast implementation
• Fully thread-safe
• Async and allocation-free API
• Full QoS configuration
• (soon) ROS 2 services
• (soon) ROS 2 actions
• (soon) ROS 2 parameters

jros2 is recommended with javacpp-presets packages such as opencv, librealsense2, cuda! Check out javacpp-presets; they make developing robotics & computer vision software very easy in Java!

This project was developed to fill a requirement at IHMC Robotics, we write a lot of our robotics software in Java. If there’s something you’d like to see in jros2, please make an issue on GitHub!

8 posts - 3 participants

Read full topic

When updating e.g. Jazzy→Kilted, is there something similar to Noetic migration ? All I’ve found are ROS 1→2 migration docs.

3 posts - 2 participants

Read full topic

From 27–30 October 2025, Singapore became the beating heart of the global ROS ecosystem.

Over three days, **ROSCon 2025 (27–29 Oct) ** convened more than 1,000 participants from 52 countries maintainers, developers, startups, MNCs, public agencies and researchers—united by a shared belief in open-source as the fastest path to real-world robotics at scale.

This was more than a conference week. It was a signal: open, interoperable robotics—anchored in Singapore, built with the world - is here to stay.

Where Code Meets Collaboration: Reflections from ROSCon 2025 Singapore

Hosted in Singapore for the first time, ROSCon 2025 brought the global ROS community to Marina Bay with three intense days of technical talks, tutorials, demos and hallway architecture debates.

The event was honoured by the presence of Prof Tan Chor Chuan, Chairman of A*STAR

In his remarks, Prof Tan highlighted how open-source innovation, collaborative standards, and talent development are becoming the cornerstones of Singapore’s advanced manufacturing and robotics strategy.
He commended the Open Source Robotics Foundation (OSRF) and A*STAR’s Advanced Remanufacturing and Technology Centre (ARTC) for their leadership in cultivating an ecosystem that bridges research and industry, noting that:

“Open-source robotics represents not only technological advancement but also a new model of global cooperation. By enabling interoperability and collective innovation, we can accelerate deployment across sectors — from manufacturing to healthcare — while nurturing the next generation of deep-tech talent in Singapore.”

Prof Tan’s message set the tone for the conference — underscoring Singapore’s commitment to being a neutral and collaborative hub for open-source robotics, embodied AI, and digital transformation.

Beyond the energy on stage and in the expo hall, several milestones framed the week:

1.OSRF–ARTC Collaboration on Open-RMF

At ROSCon, the Open Source Robotics Foundation (OSRF) and A*STAR’s Advanced Remanufacturing and Technology Centre (ARTC) announced a strategic collaboration to:

• Co-develop best practices, guidelines and testing plans for Open-RMF as a foundation for global robot interoperability.

• Use Singapore’s new national sandbox at BCA Braddell Campus as a reference site for validation and certification of RMF-based deployments.

• Strengthen community engagement so that Open-RMF continues to evolve as a truly open, production-grade standard.

This partnership cements Singapore’s role not just as a user of open-source robotics, but as a shaper of global interoperability standards

2. National Standards & Testbeds for Interoperability

Announcements around SS 713 (data exchange between robots, lifts and automated doorways) and TR 130 (interoperability between robots and central command systems) showcased how regulation, infrastructure and open-source can move in lockstep to make multi-vendor robot fleets safe and scalable.

3. Singapore as Neutral, Open Hub

With delegates and contributors from across the US, Europe, China, India, and the broader Asia Pacific, ROSCon 2025 reinforced Singapore’s unique role as:

• A neutral ground for collaboration amid a more fragmented geopolitical landscape.

• A trusted environment to host shared infrastructure, reference implementations and standards for open-source robotics, embodied AI and Open-RMF-driven ecosystems.

As the curtains close on ROSCon 2025 in Singapore, we are deeply honoured and inspired to have hosted this extraordinary gathering of over a thousand innovators, engineers, and visionaries from across 52 countries. The energy, ideas, and partnerships sparked over these few days reaffirm the strength of the open-source robotics community — one that thrives on collaboration, inclusivity, and shared purpose.

At A*STAR’s Advanced Remanufacturing and Technology Centre (ARTC) and ROS-Industrial Consortium Asia Pacifi, we are excited to continue nurturing these collaborations — strengthening our ties with OSRF and the global ROS community, advancing Open-RMF, and building pathways that connect research to real-world adoption.

As we look ahead, we can’t wait to see how the community will come together again for ROSCon 2026 in Toronto — where new ideas will take flight, new contributors will emerge, and the open-source movement will reach even greater heights.

 

Hi,

I see some project uses ament_auto_add_library extensively, but when I tried to lookup the document of ament_auto_add_library, I can barely find any.

At the document of ament_cmake, ament_cmake user documentation — ROS 2 Documentation: Jazzy documentation, ament_auto_add_library is actually not mentioned, instead, it says to use add_library to create a library project.

So I’d like to check what is the recommended way to use ament_cmake to create a project (library or executable).

Thanks.

4 posts - 3 participants

Read full topic

Hi everyone, I’ve created an AI coding agent specialized for ROS. I got tired of the current LLMs being useless/hallucinating and decided to train something that actually understands ROS conventions and workspaces. You can find it here at www.contouragent.com, I’d love your feedback.

3 posts - 3 participants

Read full topic

Hi guys, I’ve just noticed I had rmw_zenoh_cpp without explicitly installing it. Not that I would mind

Backtracking who brought it into the system, the reverse dependecies are: rmw_test_fixture_implementation ← ament_cmake_ros .

Is that right? I thought there’s only one default RMW installed (FastDDS).

1 post - 1 participant

Read full topic

Package Updates for Humble

Added Packages [30]:

• ros-humble-nav2-route: 1.1.20-1
• ros-humble-nav2-route-dbgsym: 1.1.20-1
• ros-humble-ouster-ros: 0.13.15-1
• ros-humble-ouster-ros-dbgsym: 0.13.15-1
• ros-humble-pal-sea-arm: 1.21.0-1
• ros-humble-pal-sea-arm-bringup: 1.21.0-1
• ros-humble-pal-sea-arm-controller-configuration: 1.21.0-1
• ros-humble-pal-sea-arm-description: 1.21.0-1
• ros-humble-pal-sea-arm-gazebo: 1.0.4-1
• ros-humble-pal-sea-arm-moveit-config: 1.0.5-1
• ros-humble-pal-sea-arm-simulation: 1.0.4-1
• ros-humble-play-motion2-cli: 1.8.2-1
• ros-humble-replay-testing: 0.0.3-1
• ros-humble-rosbag2rawlog: 3.0.2-1
• ros-humble-rosbag2rawlog-dbgsym: 3.0.2-1
• ros-humble-synchros2: 1.0.4-1
• ros-humble-tiago-pro-2dnav: 2.13.3-1
• ros-humble-tiago-pro-bringup: 1.32.1-1
• ros-humble-tiago-pro-controller-configuration: 1.32.1-1
• ros-humble-tiago-pro-description: 1.32.1-1
• ros-humble-tiago-pro-gazebo: 1.12.2-1
• ros-humble-tiago-pro-head-gazebo: 1.0.2-1
• ros-humble-tiago-pro-head-robot: 1.7.0-1
• ros-humble-tiago-pro-head-simulation: 1.0.2-1
• ros-humble-tiago-pro-laser-sensors: 2.13.3-1
• ros-humble-tiago-pro-moveit-config: 1.3.2-1
• ros-humble-tiago-pro-navigation: 2.13.3-1
• ros-humble-tiago-pro-rgbd-sensors: 2.13.3-1
• ros-humble-tiago-pro-robot: 1.32.1-1
• ros-humble-tiago-pro-simulation: 1.12.2-1

Updated Packages [654]:

• ros-humble-ackermann-steering-controller: 2.50.1-1 → 2.50.2-1
• ros-humble-ackermann-steering-controller-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-action-tutorials-cpp: 0.20.6-1 → 0.20.7-1
• ros-humble-action-tutorials-cpp-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-action-tutorials-interfaces: 0.20.6-1 → 0.20.7-1
• ros-humble-action-tutorials-interfaces-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-action-tutorials-py: 0.20.6-1 → 0.20.7-1
• ros-humble-admittance-controller: 2.50.1-1 → 2.50.2-1
• ros-humble-admittance-controller-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-automatika-embodied-agents: 0.4.2-1 → 0.4.3-1
• ros-humble-automatika-embodied-agents-dbgsym: 0.4.2-1 → 0.4.3-1
• ros-humble-automatika-ros-sugar: 0.3.2-1 → 0.4.1-1
• ros-humble-automatika-ros-sugar-dbgsym: 0.3.2-1 → 0.4.1-1
• ros-humble-autoware-adapi-v1-msgs: 1.9.0-1 → 1.9.1-2
• ros-humble-autoware-adapi-v1-msgs-dbgsym: 1.9.0-1 → 1.9.1-2
• ros-humble-autoware-adapi-version-msgs: 1.9.0-1 → 1.9.1-2
• ros-humble-autoware-adapi-version-msgs-dbgsym: 1.9.0-1 → 1.9.1-2
• ros-humble-autoware-cmake: 1.0.2-1 → 1.1.0-1
• ros-humble-autoware-common-msgs: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-common-msgs-dbgsym: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-control-msgs: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-control-msgs-dbgsym: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-internal-debug-msgs: 1.12.0-1 → 1.12.0-2
• ros-humble-autoware-internal-debug-msgs-dbgsym: 1.12.0-1 → 1.12.0-2
• ros-humble-autoware-internal-localization-msgs: 1.12.0-1 → 1.12.0-2
• ros-humble-autoware-internal-localization-msgs-dbgsym: 1.12.0-1 → 1.12.0-2
• ros-humble-autoware-internal-metric-msgs: 1.12.0-1 → 1.12.0-2
• ros-humble-autoware-internal-metric-msgs-dbgsym: 1.12.0-1 → 1.12.0-2
• ros-humble-autoware-internal-msgs: 1.12.0-1 → 1.12.0-2
• ros-humble-autoware-internal-msgs-dbgsym: 1.12.0-1 → 1.12.0-2
• ros-humble-autoware-internal-perception-msgs: 1.12.0-1 → 1.12.0-2
• ros-humble-autoware-internal-perception-msgs-dbgsym: 1.12.0-1 → 1.12.0-2
• ros-humble-autoware-internal-planning-msgs: 1.12.0-1 → 1.12.0-2
• ros-humble-autoware-internal-planning-msgs-dbgsym: 1.12.0-1 → 1.12.0-2
• ros-humble-autoware-lanelet2-extension: 0.8.0-1 → 0.10.0-1
• ros-humble-autoware-lanelet2-extension-dbgsym: 0.8.0-1 → 0.10.0-1
• ros-humble-autoware-lanelet2-extension-python: 0.8.0-1 → 0.10.0-1
• ros-humble-autoware-lanelet2-extension-python-dbgsym: 0.8.0-1 → 0.10.0-1
• ros-humble-autoware-lint-common: 1.0.2-1 → 1.1.0-1
• ros-humble-autoware-localization-msgs: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-localization-msgs-dbgsym: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-map-msgs: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-map-msgs-dbgsym: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-msgs: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-perception-msgs: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-perception-msgs-dbgsym: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-planning-msgs: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-planning-msgs-dbgsym: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-sensing-msgs: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-sensing-msgs-dbgsym: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-system-msgs: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-system-msgs-dbgsym: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-utils: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-debug: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-diagnostics: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-diagnostics-dbgsym: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-geometry: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-geometry-dbgsym: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-logging: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-logging-dbgsym: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-math: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-math-dbgsym: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-pcl: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-rclcpp: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-system: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-system-dbgsym: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-tf: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-uuid: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-visualization: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-utils-visualization-dbgsym: 1.4.2-1 → 1.4.2-2
• ros-humble-autoware-v2x-msgs: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-v2x-msgs-dbgsym: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-vehicle-msgs: 1.9.0-1 → 1.11.0-1
• ros-humble-autoware-vehicle-msgs-dbgsym: 1.9.0-1 → 1.11.0-1
• ros-humble-bicycle-steering-controller: 2.50.1-1 → 2.50.2-1
• ros-humble-bicycle-steering-controller-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-bosch-locator-bridge: 2.1.14-1 → 2.1.15-1
• ros-humble-bosch-locator-bridge-dbgsym: 2.1.14-1 → 2.1.15-1
• ros-humble-bosch-locator-bridge-utils: 2.1.14-1 → 2.1.15-1
• ros-humble-bosch-locator-bridge-utils-dbgsym: 2.1.14-1 → 2.1.15-1
• ros-humble-clearpath-ros2-socketcan-interface: 1.0.3-1 → 1.0.4-1
• ros-humble-clearpath-ros2-socketcan-interface-dbgsym: 1.0.3-1 → 1.0.4-1
• ros-humble-composition: 0.20.6-1 → 0.20.7-1
• ros-humble-composition-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-controller-interface: 2.52.0-1 → 2.52.2-1
• ros-humble-controller-interface-dbgsym: 2.52.0-1 → 2.52.2-1
• ros-humble-controller-manager: 2.52.0-1 → 2.52.2-1
• ros-humble-controller-manager-dbgsym: 2.52.0-1 → 2.52.2-1
• ros-humble-controller-manager-msgs: 2.52.0-1 → 2.52.2-1
• ros-humble-controller-manager-msgs-dbgsym: 2.52.0-1 → 2.52.2-1
• ros-humble-costmap-queue: 1.1.19-1 → 1.1.20-1
• ros-humble-costmap-queue-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-demo-nodes-cpp: 0.20.6-1 → 0.20.7-1
• ros-humble-demo-nodes-cpp-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-demo-nodes-cpp-native: 0.20.6-1 → 0.20.7-1
• ros-humble-demo-nodes-cpp-native-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-demo-nodes-py: 0.20.6-1 → 0.20.7-1
• ros-humble-diff-drive-controller: 2.50.1-1 → 2.50.2-1
• ros-humble-diff-drive-controller-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-draco-point-cloud-transport: 1.0.12-1 → 1.0.13-1
• ros-humble-draco-point-cloud-transport-dbgsym: 1.0.12-1 → 1.0.13-1
• ros-humble-dummy-map-server: 0.20.6-1 → 0.20.7-1
• ros-humble-dummy-map-server-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-dummy-robot-bringup: 0.20.6-1 → 0.20.7-1
• ros-humble-dummy-sensors: 0.20.6-1 → 0.20.7-1
• ros-humble-dummy-sensors-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-dwb-core: 1.1.19-1 → 1.1.20-1
• ros-humble-dwb-core-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-dwb-critics: 1.1.19-1 → 1.1.20-1
• ros-humble-dwb-critics-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-dwb-msgs: 1.1.19-1 → 1.1.20-1
• ros-humble-dwb-msgs-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-dwb-plugins: 1.1.19-1 → 1.1.20-1
• ros-humble-dwb-plugins-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-effort-controllers: 2.50.1-1 → 2.50.2-1
• ros-humble-effort-controllers-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-event-camera-codecs: 2.0.0-1 → 2.0.1-1
• ros-humble-event-camera-codecs-dbgsym: 2.0.0-1 → 2.0.1-1
• ros-humble-examples-rclcpp-async-client: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-async-client-dbgsym: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-cbg-executor: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-cbg-executor-dbgsym: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-action-client: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-action-client-dbgsym: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-action-server: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-action-server-dbgsym: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-client: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-client-dbgsym: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-composition: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-composition-dbgsym: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-publisher: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-publisher-dbgsym: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-service: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-service-dbgsym: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-subscriber: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-subscriber-dbgsym: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-timer: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-minimal-timer-dbgsym: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-multithreaded-executor: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-multithreaded-executor-dbgsym: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-wait-set: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclcpp-wait-set-dbgsym: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclpy-executors: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclpy-guard-conditions: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclpy-minimal-action-client: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclpy-minimal-action-server: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclpy-minimal-client: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclpy-minimal-publisher: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclpy-minimal-service: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclpy-minimal-subscriber: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-rclpy-pointcloud-publisher: 0.15.4-1 → 0.15.5-1
• ros-humble-examples-tf2-py: 0.25.16-1 → 0.25.17-1
• ros-humble-flir-camera-description: 3.0.3-1 → 3.0.4-1
• ros-humble-flir-camera-msgs: 3.0.3-1 → 3.0.4-1
• ros-humble-flir-camera-msgs-dbgsym: 3.0.3-1 → 3.0.4-1
• ros-humble-force-torque-sensor-broadcaster: 2.50.1-1 → 2.50.2-1
• ros-humble-force-torque-sensor-broadcaster-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-forward-command-controller: 2.50.1-1 → 2.50.2-1
• ros-humble-forward-command-controller-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-foxglove-bridge: 3.2.1-1 → 3.2.2-1
• ros-humble-foxglove-bridge-dbgsym: 3.2.1-1 → 3.2.2-1
• ros-humble-foxglove-msgs: 3.2.1-1 → 3.2.2-1
• ros-humble-foxglove-msgs-dbgsym: 3.2.1-1 → 3.2.2-1
• ros-humble-geometry2: 0.25.16-1 → 0.25.17-1
• ros-humble-gpio-controllers: 2.50.1-1 → 2.50.2-1
• ros-humble-gpio-controllers-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-gripper-controllers: 2.50.1-1 → 2.50.2-1
• ros-humble-gripper-controllers-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-hardware-interface: 2.52.0-1 → 2.52.2-1
• ros-humble-hardware-interface-dbgsym: 2.52.0-1 → 2.52.2-1
• ros-humble-hardware-interface-testing: 2.52.0-1 → 2.52.2-1
• ros-humble-hardware-interface-testing-dbgsym: 2.52.0-1 → 2.52.2-1
• ros-humble-image-tools: 0.20.6-1 → 0.20.7-1
• ros-humble-image-tools-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-imu-sensor-broadcaster: 2.50.1-1 → 2.50.2-1
• ros-humble-imu-sensor-broadcaster-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-intra-process-demo: 0.20.6-1 → 0.20.7-1
• ros-humble-intra-process-demo-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-joint-limits: 2.52.0-1 → 2.52.2-1
• ros-humble-joint-limits-dbgsym: 2.52.0-1 → 2.52.2-1
• ros-humble-joint-state-broadcaster: 2.50.1-1 → 2.50.2-1
• ros-humble-joint-state-broadcaster-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-joint-trajectory-controller: 2.50.1-1 → 2.50.2-1
• ros-humble-joint-trajectory-controller-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-jrl-cmakemodules: 1.1.0-2 → 1.1.2-1
• ros-humble-kitti-metrics-eval: 2.0.0-1 → 2.2.1-1
• ros-humble-kitti-metrics-eval-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-launch: 1.0.11-1 → 1.0.13-1
• ros-humble-launch-pal: 0.17.0-1 → 0.19.0-1
• ros-humble-launch-pytest: 1.0.11-1 → 1.0.13-1
• ros-humble-launch-ros: 0.19.12-1 → 0.19.13-1
• ros-humble-launch-testing: 1.0.11-1 → 1.0.13-1
• ros-humble-launch-testing-ament-cmake: 1.0.11-1 → 1.0.13-1
• ros-humble-launch-testing-examples: 0.15.4-1 → 0.15.5-1
• ros-humble-launch-testing-ros: 0.19.12-1 → 0.19.13-1
• ros-humble-launch-xml: 1.0.11-1 → 1.0.13-1
• ros-humble-launch-yaml: 1.0.11-1 → 1.0.13-1
• ros-humble-lifecycle: 0.20.6-1 → 0.20.7-1
• ros-humble-lifecycle-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-lifecycle-py: 0.20.6-1 → 0.20.7-1
• ros-humble-logging-demo: 0.20.6-1 → 0.20.7-1
• ros-humble-logging-demo-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-mecanum-drive-controller: 2.50.1-1 → 2.50.2-1
• ros-humble-mecanum-drive-controller-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-microstrain-inertial-description: 4.7.0-1 → 4.8.0-1
• ros-humble-microstrain-inertial-driver: 4.7.0-1 → 4.8.0-1
• ros-humble-microstrain-inertial-driver-dbgsym: 4.7.0-1 → 4.8.0-1
• ros-humble-microstrain-inertial-examples: 4.7.0-1 → 4.8.0-1
• ros-humble-microstrain-inertial-msgs: 4.7.0-1 → 4.8.0-1
• ros-humble-microstrain-inertial-msgs-dbgsym: 4.7.0-1 → 4.8.0-1
• ros-humble-microstrain-inertial-rqt: 4.7.0-1 → 4.8.0-1
• ros-humble-mocap4r2-msgs: 0.0.5-1 → 0.0.6-2
• ros-humble-mocap4r2-msgs-dbgsym: 0.0.5-1 → 0.0.6-2
• ros-humble-mola: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-bridge-ros2: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-bridge-ros2-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-common: 0.5.1-1 → 0.5.2-1
• ros-humble-mola-demos: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-imu-preintegration: 1.13.1-1 → 1.14.0-1
• ros-humble-mola-imu-preintegration-dbgsym: 1.13.1-1 → 1.14.0-1
• ros-humble-mola-input-euroc-dataset: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-euroc-dataset-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-kitti-dataset: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-kitti-dataset-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-kitti360-dataset: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-kitti360-dataset-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-lidar-bin-dataset: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-lidar-bin-dataset-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-mulran-dataset: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-mulran-dataset-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-paris-luco-dataset: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-paris-luco-dataset-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-rawlog: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-rawlog-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-rosbag2: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-rosbag2-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-video: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-input-video-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-kernel: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-kernel-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-launcher: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-launcher-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-lidar-odometry: 1.0.0-1 → 1.2.2-1
• ros-humble-mola-lidar-odometry-dbgsym: 1.0.0-1 → 1.2.2-1
• ros-humble-mola-metric-maps: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-metric-maps-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-msgs: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-msgs-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-pose-list: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-pose-list-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-relocalization: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-relocalization-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-state-estimation: 1.11.0-1 → 1.11.1-1
• ros-humble-mola-state-estimation-simple: 1.11.0-1 → 1.11.1-1
• ros-humble-mola-state-estimation-simple-dbgsym: 1.11.0-1 → 1.11.1-1
• ros-humble-mola-state-estimation-smoother: 1.11.0-1 → 1.11.1-1
• ros-humble-mola-state-estimation-smoother-dbgsym: 1.11.0-1 → 1.11.1-1
• ros-humble-mola-traj-tools: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-traj-tools-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-viz: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-viz-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-yaml: 2.0.0-1 → 2.2.1-1
• ros-humble-mola-yaml-dbgsym: 2.0.0-1 → 2.2.1-1
• ros-humble-mp2p-icp: 2.0.0-1 → 2.1.1-1
• ros-humble-mp2p-icp-dbgsym: 2.0.0-1 → 2.1.1-1
• ros-humble-mrpt-apps: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-apps-dbgsym: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-generic-sensor: 0.2.3-1 → 0.2.4-1
• ros-humble-mrpt-generic-sensor-dbgsym: 0.2.3-1 → 0.2.4-1
• ros-humble-mrpt-libapps: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libapps-dbgsym: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libbase: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libbase-dbgsym: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libgui: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libgui-dbgsym: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libhwdrivers: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libhwdrivers-dbgsym: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libmaps: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libmaps-dbgsym: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libmath: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libmath-dbgsym: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libnav: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libnav-dbgsym: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libobs: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libobs-dbgsym: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libopengl: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libopengl-dbgsym: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libposes: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libposes-dbgsym: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libros-bridge: 2.14.16-1 → 3.0.2-1
• ros-humble-mrpt-libros-bridge-dbgsym: 2.14.16-1 → 3.0.2-1
• ros-humble-mrpt-libslam: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libslam-dbgsym: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-libtclap: 2.14.16-1 → 2.15.1-2
• ros-humble-mrpt-map-server: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-map-server-dbgsym: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-msgs: 0.5.0-1 → 0.6.0-1
• ros-humble-mrpt-msgs-bridge: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-msgs-dbgsym: 0.5.0-1 → 0.6.0-1
• ros-humble-mrpt-nav-interfaces: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-nav-interfaces-dbgsym: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-navigation: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-path-planning: 0.2.2-1 → 0.2.3-1
• ros-humble-mrpt-path-planning-dbgsym: 0.2.2-1 → 0.2.3-1
• ros-humble-mrpt-pf-localization: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-pf-localization-dbgsym: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-pointcloud-pipeline: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-pointcloud-pipeline-dbgsym: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-reactivenav2d: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-reactivenav2d-dbgsym: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-sensor-bumblebee-stereo: 0.2.3-1 → 0.2.4-1
• ros-humble-mrpt-sensor-bumblebee-stereo-dbgsym: 0.2.3-1 → 0.2.4-1
• ros-humble-mrpt-sensor-gnss-nmea: 0.2.3-1 → 0.2.4-1
• ros-humble-mrpt-sensor-gnss-nmea-dbgsym: 0.2.3-1 → 0.2.4-1
• ros-humble-mrpt-sensor-gnss-novatel: 0.2.3-1 → 0.2.4-1
• ros-humble-mrpt-sensor-gnss-novatel-dbgsym: 0.2.3-1 → 0.2.4-1
• ros-humble-mrpt-sensor-imu-taobotics: 0.2.3-1 → 0.2.4-1
• ros-humble-mrpt-sensor-imu-taobotics-dbgsym: 0.2.3-1 → 0.2.4-1
• ros-humble-mrpt-sensorlib: 0.2.3-1 → 0.2.4-1
• ros-humble-mrpt-sensors: 0.2.3-1 → 0.2.4-1
• ros-humble-mrpt-tps-astar-planner: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-tps-astar-planner-dbgsym: 2.2.3-1 → 2.3.0-1
• ros-humble-mrpt-tutorials: 2.2.3-1 → 2.3.0-1
• ros-humble-mvsim: 0.14.0-1 → 0.14.2-1
• ros-humble-mvsim-dbgsym: 0.14.0-1 → 0.14.2-1
• ros-humble-nav-2d-msgs: 1.1.19-1 → 1.1.20-1
• ros-humble-nav-2d-msgs-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav-2d-utils: 1.1.19-1 → 1.1.20-1
• ros-humble-nav-2d-utils-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-amcl: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-amcl-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-behavior-tree: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-behavior-tree-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-behaviors: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-behaviors-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-bringup: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-bt-navigator: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-bt-navigator-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-collision-monitor: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-collision-monitor-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-common: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-constrained-smoother: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-constrained-smoother-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-controller: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-controller-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-core: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-costmap-2d: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-costmap-2d-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-dwb-controller: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-graceful-controller: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-graceful-controller-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-lifecycle-manager: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-lifecycle-manager-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-map-server: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-map-server-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-mppi-controller: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-mppi-controller-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-msgs: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-msgs-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-navfn-planner: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-navfn-planner-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-planner: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-planner-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-regulated-pure-pursuit-controller: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-regulated-pure-pursuit-controller-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-rotation-shim-controller: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-rotation-shim-controller-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-rviz-plugins: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-rviz-plugins-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-simple-commander: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-smac-planner: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-smac-planner-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-smoother: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-smoother-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-system-tests: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-system-tests-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-theta-star-planner: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-theta-star-planner-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-util: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-util-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-velocity-smoother: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-velocity-smoother-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-voxel-grid: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-voxel-grid-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-waypoint-follower: 1.1.19-1 → 1.1.20-1
• ros-humble-nav2-waypoint-follower-dbgsym: 1.1.19-1 → 1.1.20-1
• ros-humble-navigation2: 1.1.19-1 → 1.1.20-1
• ros-humble-ntrip-client-node: 0.6.1-1 → 0.7.0-1
• ros-humble-ntrip-client-node-dbgsym: 0.6.1-1 → 0.7.0-1
• ros-humble-omni-base-2dnav: 2.18.0-1 → 2.19.1-1
• ros-humble-omni-base-bringup: 2.12.0-1 → 2.14.1-1
• ros-humble-omni-base-controller-configuration: 2.12.0-1 → 2.14.1-1
• ros-humble-omni-base-description: 2.12.0-1 → 2.14.1-1
• ros-humble-omni-base-gazebo: 2.9.0-1 → 2.10.1-1
• ros-humble-omni-base-laser-sensors: 2.18.0-1 → 2.19.1-1
• ros-humble-omni-base-navigation: 2.18.0-1 → 2.19.1-1
• ros-humble-omni-base-rgbd-sensors: 2.18.0-1 → 2.19.1-1
• ros-humble-omni-base-robot: 2.12.0-1 → 2.14.1-1
• ros-humble-omni-base-simulation: 2.9.0-1 → 2.10.1-1
• ros-humble-orbbec-camera: 1.5.14-1 → 2.5.5-2
• ros-humble-orbbec-camera-dbgsym: 1.5.14-1 → 2.5.5-2
• ros-humble-orbbec-camera-msgs: 1.5.14-1 → 2.5.5-2
• ros-humble-orbbec-camera-msgs-dbgsym: 1.5.14-1 → 2.5.5-2
• ros-humble-orbbec-description: 1.5.14-1 → 2.5.5-2
• ros-humble-ouster-sensor-msgs: 0.13.14-2 → 0.13.15-1
• ros-humble-ouster-sensor-msgs-dbgsym: 0.13.14-2 → 0.13.15-1
• ros-humble-pal-gazebo-plugins: 4.1.0-1 → 4.1.1-1
• ros-humble-pal-gazebo-plugins-dbgsym: 4.1.0-1 → 4.1.1-1
• ros-humble-pal-gazebo-worlds: 4.3.0-1 → 4.10.0-1
• ros-humble-pal-gripper: 3.5.0-1 → 3.6.0-1
• ros-humble-pal-gripper-controller-configuration: 3.5.0-1 → 3.6.0-1
• ros-humble-pal-gripper-description: 3.5.0-1 → 3.6.0-1
• ros-humble-pal-gripper-simulation: 3.5.0-1 → 3.6.0-1
• ros-humble-pal-maps: 0.0.5-1 → 0.2.0-1
• ros-humble-pal-pro-gripper: 1.7.2-1 → 1.8.0-1
• ros-humble-pal-pro-gripper-bringup: 1.7.2-1 → 1.8.0-1
• ros-humble-pal-pro-gripper-controller-configuration: 1.7.2-1 → 1.8.0-1
• ros-humble-pal-pro-gripper-description: 1.7.2-1 → 1.8.0-1
• ros-humble-pal-pro-gripper-wrapper: 1.7.2-1 → 1.8.0-1
• ros-humble-pal-urdf-utils: 2.2.1-1 → 2.3.3-1
• ros-humble-pendulum-control: 0.20.6-1 → 0.20.7-1
• ros-humble-pendulum-control-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-pendulum-msgs: 0.20.6-1 → 0.20.7-1
• ros-humble-pendulum-msgs-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-pid-controller: 2.50.1-1 → 2.50.2-1
• ros-humble-pid-controller-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-play-motion2: 1.7.0-1 → 1.8.2-1
• ros-humble-play-motion2-dbgsym: 1.7.0-1 → 1.8.2-1
• ros-humble-play-motion2-msgs: 1.7.0-1 → 1.8.2-1
• ros-humble-play-motion2-msgs-dbgsym: 1.7.0-1 → 1.8.2-1
• ros-humble-pmb2-2dnav: 4.17.0-1 → 4.18.2-1
• ros-humble-pmb2-bringup: 5.9.0-1 → 5.10.2-1
• ros-humble-pmb2-controller-configuration: 5.9.0-1 → 5.10.2-1
• ros-humble-pmb2-description: 5.9.0-1 → 5.10.2-1
• ros-humble-pmb2-gazebo: 4.8.0-1 → 4.9.1-1
• ros-humble-pmb2-laser-sensors: 4.17.0-1 → 4.18.2-1
• ros-humble-pmb2-navigation: 4.17.0-1 → 4.18.2-1
• ros-humble-pmb2-rgbd-sensors: 4.17.0-1 → 4.18.2-1
• ros-humble-pmb2-robot: 5.9.0-1 → 5.10.2-1
• ros-humble-pmb2-simulation: 4.8.0-1 → 4.9.1-1
• ros-humble-point-cloud-interfaces: 1.0.12-1 → 1.0.13-1
• ros-humble-point-cloud-interfaces-dbgsym: 1.0.12-1 → 1.0.13-1
• ros-humble-point-cloud-transport: 1.0.19-1 → 1.0.20-1
• ros-humble-point-cloud-transport-dbgsym: 1.0.19-1 → 1.0.20-1
• ros-humble-point-cloud-transport-plugins: 1.0.12-1 → 1.0.13-1
• ros-humble-point-cloud-transport-py: 1.0.19-1 → 1.0.20-1
• ros-humble-pose-broadcaster: 2.50.1-1 → 2.50.2-1
• ros-humble-pose-broadcaster-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-position-controllers: 2.50.1-1 → 2.50.2-1
• ros-humble-position-controllers-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-proto2ros: 1.0.0-3 → 1.0.1-1
• ros-humble-proto2ros-dbgsym: 1.0.0-3 → 1.0.1-1
• ros-humble-py-trees: 2.3.0-1 → 2.4.0-1
• ros-humble-py-trees-ros: 2.3.0-1 → 2.4.0-1
• ros-humble-py-trees-ros-tutorials: 2.3.0-1 → 2.4.0-1
• ros-humble-pymoveit2: 4.0.0-1 → 4.2.0-1
• ros-humble-python-mrpt: 2.14.9-1 → 2.15.1-1
• ros-humble-quality-of-service-demo-cpp: 0.20.6-1 → 0.20.7-1
• ros-humble-quality-of-service-demo-cpp-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-quality-of-service-demo-py: 0.20.6-1 → 0.20.7-1
• ros-humble-range-sensor-broadcaster: 2.50.1-1 → 2.50.2-1
• ros-humble-range-sensor-broadcaster-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-rcl: 5.3.10-1 → 5.3.11-1
• ros-humble-rcl-action: 5.3.10-1 → 5.3.11-1
• ros-humble-rcl-action-dbgsym: 5.3.10-1 → 5.3.11-1
• ros-humble-rcl-dbgsym: 5.3.10-1 → 5.3.11-1
• ros-humble-rcl-lifecycle: 5.3.10-1 → 5.3.11-1
• ros-humble-rcl-lifecycle-dbgsym: 5.3.10-1 → 5.3.11-1
• ros-humble-rcl-yaml-param-parser: 5.3.10-1 → 5.3.11-1
• ros-humble-rcl-yaml-param-parser-dbgsym: 5.3.10-1 → 5.3.11-1
• ros-humble-rclcpp: 16.0.15-1 → 16.0.16-1
• ros-humble-rclcpp-action: 16.0.15-1 → 16.0.16-1
• ros-humble-rclcpp-action-dbgsym: 16.0.15-1 → 16.0.16-1
• ros-humble-rclcpp-components: 16.0.15-1 → 16.0.16-1
• ros-humble-rclcpp-components-dbgsym: 16.0.15-1 → 16.0.16-1
• ros-humble-rclcpp-dbgsym: 16.0.15-1 → 16.0.16-1
• ros-humble-rclcpp-lifecycle: 16.0.15-1 → 16.0.16-1
• ros-humble-rclcpp-lifecycle-dbgsym: 16.0.15-1 → 16.0.16-1
• ros-humble-rclpy: 3.3.17-1 → 3.3.19-1
• ros-humble-rmw-connextdds: 0.11.3-1 → 0.11.5-1
• ros-humble-rmw-connextdds-common: 0.11.3-1 → 0.11.5-1
• ros-humble-rmw-connextdds-common-dbgsym: 0.11.3-1 → 0.11.5-1
• ros-humble-rmw-connextdds-dbgsym: 0.11.3-1 → 0.11.5-1
• ros-humble-rmw-stats-shim: 0.2.2-1 → 0.2.3-1
• ros-humble-rmw-stats-shim-dbgsym: 0.2.2-1 → 0.2.3-1
• ros-humble-rmw-zenoh-cpp: 0.1.7-1 → 0.1.8-1
• ros-humble-rmw-zenoh-cpp-dbgsym: 0.1.7-1 → 0.1.8-1
• ros-humble-ros2-control: 2.52.0-1 → 2.52.2-1
• ros-humble-ros2-control-test-assets: 2.52.0-1 → 2.52.2-1
• ros-humble-ros2-controllers: 2.50.1-1 → 2.50.2-1
• ros-humble-ros2-controllers-test-nodes: 2.50.1-1 → 2.50.2-1
• ros-humble-ros2-fmt-logger: 1.0.1-1 → 1.0.2-1
• ros-humble-ros2-fmt-logger-dbgsym: 1.0.1-1 → 1.0.2-1
• ros-humble-ros2action: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2cli: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2cli-test-interfaces: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2cli-test-interfaces-dbgsym: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2component: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2controlcli: 2.52.0-1 → 2.52.2-1
• ros-humble-ros2doctor: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2interface: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2launch: 0.19.12-1 → 0.19.13-1
• ros-humble-ros2lifecycle: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2lifecycle-test-fixtures: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2lifecycle-test-fixtures-dbgsym: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2multicast: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2node: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2param: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2pkg: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2run: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2service: 0.18.14-1 → 0.18.15-1
• ros-humble-ros2topic: 0.18.14-1 → 0.18.15-1
• ros-humble-rosapi: 2.0.1-1 → 2.0.4-1
• ros-humble-rosapi-msgs: 2.0.1-1 → 2.0.4-1
• ros-humble-rosapi-msgs-dbgsym: 2.0.1-1 → 2.0.4-1
• ros-humble-rosbridge-library: 2.0.1-1 → 2.0.4-1
• ros-humble-rosbridge-msgs: 2.0.1-1 → 2.0.4-1
• ros-humble-rosbridge-msgs-dbgsym: 2.0.1-1 → 2.0.4-1
• ros-humble-rosbridge-server: 2.0.1-1 → 2.0.4-1
• ros-humble-rosbridge-suite: 2.0.1-1 → 2.0.4-1
• ros-humble-rosbridge-test-msgs: 2.0.1-1 → 2.0.4-1
• ros-humble-rosbridge-test-msgs-dbgsym: 2.0.1-1 → 2.0.4-1
• ros-humble-rosgraph-monitor: 0.2.2-1 → 0.2.3-1
• ros-humble-rosgraph-monitor-dbgsym: 0.2.2-1 → 0.2.3-1
• ros-humble-rosgraph-monitor-msgs: 0.2.2-1 → 0.2.3-1
• ros-humble-rosgraph-monitor-msgs-dbgsym: 0.2.2-1 → 0.2.3-1
• ros-humble-rqt: 1.1.8-1 → 1.1.9-1
• ros-humble-rqt-controller-manager: 2.52.0-1 → 2.52.2-1
• ros-humble-rqt-gui: 1.1.8-1 → 1.1.9-1
• ros-humble-rqt-gui-cpp: 1.1.8-1 → 1.1.9-1
• ros-humble-rqt-gui-cpp-dbgsym: 1.1.8-1 → 1.1.9-1
• ros-humble-rqt-gui-py: 1.1.8-1 → 1.1.9-1
• ros-humble-rqt-joint-trajectory-controller: 2.50.1-1 → 2.50.2-1
• ros-humble-rqt-py-common: 1.1.8-1 → 1.1.9-1
• ros-humble-rti-connext-dds-cmake-module: 0.11.3-1 → 0.11.5-1
• ros-humble-rviz-2d-overlay-msgs: 1.3.1-1 → 1.4.0-1
• ros-humble-rviz-2d-overlay-msgs-dbgsym: 1.3.1-1 → 1.4.0-1
• ros-humble-rviz-2d-overlay-plugins: 1.3.1-1 → 1.4.0-1
• ros-humble-rviz-2d-overlay-plugins-dbgsym: 1.3.1-1 → 1.4.0-1
• ros-humble-rviz-assimp-vendor: 11.2.22-1 → 11.2.23-1
• ros-humble-rviz-common: 11.2.22-1 → 11.2.23-1
• ros-humble-rviz-common-dbgsym: 11.2.22-1 → 11.2.23-1
• ros-humble-rviz-default-plugins: 11.2.22-1 → 11.2.23-1
• ros-humble-rviz-default-plugins-dbgsym: 11.2.22-1 → 11.2.23-1
• ros-humble-rviz-ogre-vendor: 11.2.22-1 → 11.2.23-1
• ros-humble-rviz-ogre-vendor-dbgsym: 11.2.22-1 → 11.2.23-1
• ros-humble-rviz-rendering: 11.2.22-1 → 11.2.23-1
• ros-humble-rviz-rendering-dbgsym: 11.2.22-1 → 11.2.23-1
• ros-humble-rviz-rendering-tests: 11.2.22-1 → 11.2.23-1
• ros-humble-rviz-visual-testing-framework: 11.2.22-1 → 11.2.23-1
• ros-humble-rviz2: 11.2.22-1 → 11.2.23-1
• ros-humble-rviz2-dbgsym: 11.2.22-1 → 11.2.23-1
• ros-humble-sbg-driver: 3.2.0-1 → 3.3.2-1
• ros-humble-sbg-driver-dbgsym: 3.2.0-1 → 3.3.2-1
• ros-humble-sick-scan-xd: 3.7.0-7 → 3.8.0-1
• ros-humble-sick-scan-xd-dbgsym: 3.7.0-7 → 3.8.0-1
• ros-humble-smacc2: 2.3.18-1 → 2.3.20-2
• ros-humble-smacc2-dbgsym: 2.3.18-1 → 2.3.20-2
• ros-humble-smacc2-msgs: 2.3.18-1 → 2.3.20-2
• ros-humble-smacc2-msgs-dbgsym: 2.3.18-1 → 2.3.20-2
• ros-humble-spinnaker-camera-driver: 3.0.3-1 → 3.0.4-1
• ros-humble-spinnaker-camera-driver-dbgsym: 3.0.3-1 → 3.0.4-1
• ros-humble-spinnaker-synchronized-camera-driver: 3.0.3-1 → 3.0.4-1
• ros-humble-spinnaker-synchronized-camera-driver-dbgsym: 3.0.3-1 → 3.0.4-1
• ros-humble-steering-controllers-library: 2.50.1-1 → 2.50.2-1
• ros-humble-steering-controllers-library-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-talos-bringup: 2.1.0-1 → 2.9.1-1
• ros-humble-talos-controller-configuration: 2.1.0-1 → 2.9.1-1
• ros-humble-talos-description: 2.1.0-1 → 2.9.1-1
• ros-humble-talos-description-calibration: 2.1.0-1 → 2.9.1-1
• ros-humble-talos-description-inertial: 2.1.0-1 → 2.9.1-1
• ros-humble-talos-gazebo: 2.0.0-1 → 2.0.3-1
• ros-humble-talos-robot: 2.1.0-1 → 2.9.1-1
• ros-humble-tf2: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-bullet: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-dbgsym: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-eigen: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-eigen-kdl: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-eigen-kdl-dbgsym: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-geometry-msgs: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-kdl: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-msgs: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-msgs-dbgsym: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-py: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-py-dbgsym: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-ros: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-ros-dbgsym: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-ros-py: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-sensor-msgs: 0.25.16-1 → 0.25.17-1
• ros-humble-tf2-tools: 0.25.16-1 → 0.25.17-1
• ros-humble-tiago-bringup: 4.18.0-1 → 4.22.0-1
• ros-humble-tiago-controller-configuration: 4.18.0-1 → 4.22.0-1
• ros-humble-tiago-description: 4.18.0-1 → 4.22.0-1
• ros-humble-tiago-gazebo: 4.7.1-1 → 4.8.0-1
• ros-humble-tiago-gazebo-dbgsym: 4.7.1-1 → 4.8.0-1
• ros-humble-tiago-pro-head-bringup: 1.6.0-1 → 1.7.0-1
• ros-humble-tiago-pro-head-controller-configuration: 1.6.0-1 → 1.7.0-1
• ros-humble-tiago-pro-head-description: 1.6.0-1 → 1.7.0-1
• ros-humble-tiago-robot: 4.18.0-1 → 4.22.0-1
• ros-humble-tiago-simulation: 4.7.1-1 → 4.8.0-1
• ros-humble-tinyxml2-vendor: 0.7.6-1 → 0.7.7-1
• ros-humble-topic-monitor: 0.20.6-1 → 0.20.7-1
• ros-humble-topic-statistics-demo: 0.20.6-1 → 0.20.7-1
• ros-humble-topic-statistics-demo-dbgsym: 0.20.6-1 → 0.20.7-1
• ros-humble-transmission-interface: 2.52.0-1 → 2.52.2-1
• ros-humble-transmission-interface-dbgsym: 2.52.0-1 → 2.52.2-1
• ros-humble-tricycle-controller: 2.50.1-1 → 2.50.2-1
• ros-humble-tricycle-controller-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-tricycle-steering-controller: 2.50.1-1 → 2.50.2-1
• ros-humble-tricycle-steering-controller-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-ublox-dgnss: 0.6.1-1 → 0.7.0-1
• ros-humble-ublox-dgnss-node: 0.6.1-1 → 0.7.0-1
• ros-humble-ublox-dgnss-node-dbgsym: 0.6.1-1 → 0.7.0-1
• ros-humble-ublox-nav-sat-fix-hp-node: 0.6.1-1 → 0.7.0-1
• ros-humble-ublox-nav-sat-fix-hp-node-dbgsym: 0.6.1-1 → 0.7.0-1
• ros-humble-ublox-ubx-interfaces: 0.6.1-1 → 0.7.0-1
• ros-humble-ublox-ubx-interfaces-dbgsym: 0.6.1-1 → 0.7.0-1
• ros-humble-ublox-ubx-msgs: 0.6.1-1 → 0.7.0-1
• ros-humble-ublox-ubx-msgs-dbgsym: 0.6.1-1 → 0.7.0-1
• ros-humble-ur: 2.9.0-1 → 2.10.0-1
• ros-humble-ur-bringup: 2.9.0-1 → 2.10.0-1
• ros-humble-ur-calibration: 2.9.0-1 → 2.10.0-1
• ros-humble-ur-calibration-dbgsym: 2.9.0-1 → 2.10.0-1
• ros-humble-ur-client-library: 2.4.0-1 → 2.6.0-1
• ros-humble-ur-client-library-dbgsym: 2.4.0-1 → 2.6.0-1
• ros-humble-ur-controllers: 2.9.0-1 → 2.10.0-1
• ros-humble-ur-controllers-dbgsym: 2.9.0-1 → 2.10.0-1
• ros-humble-ur-dashboard-msgs: 2.9.0-1 → 2.10.0-1
• ros-humble-ur-dashboard-msgs-dbgsym: 2.9.0-1 → 2.10.0-1
• ros-humble-ur-moveit-config: 2.9.0-1 → 2.10.0-1
• ros-humble-ur-robot-driver: 2.9.0-1 → 2.10.0-1
• ros-humble-ur-robot-driver-dbgsym: 2.9.0-1 → 2.10.0-1
• ros-humble-velocity-controllers: 2.50.1-1 → 2.50.2-1
• ros-humble-velocity-controllers-dbgsym: 2.50.1-1 → 2.50.2-1
• ros-humble-yasmin: 3.5.0-1 → 3.5.1-1
• ros-humble-yasmin-dbgsym: 3.5.0-1 → 3.5.1-1
• ros-humble-yasmin-demos: 3.5.0-1 → 3.5.1-1
• ros-humble-yasmin-demos-dbgsym: 3.5.0-1 → 3.5.1-1
• ros-humble-yasmin-msgs: 3.5.0-1 → 3.5.1-1
• ros-humble-yasmin-msgs-dbgsym: 3.5.0-1 → 3.5.1-1
• ros-humble-yasmin-ros: 3.5.0-1 → 3.5.1-1
• ros-humble-yasmin-ros-dbgsym: 3.5.0-1 → 3.5.1-1
• ros-humble-yasmin-viewer: 3.5.0-1 → 3.5.1-1
• ros-humble-yasmin-viewer-dbgsym: 3.5.0-1 → 3.5.1-1
• ros-humble-zed-msgs: 5.1.0-1 → 5.1.1-1
• ros-humble-zed-msgs-dbgsym: 5.1.0-1 → 5.1.1-1
• ros-humble-zenoh-cpp-vendor: 0.1.7-1 → 0.1.8-1
• ros-humble-zenoh-cpp-vendor-dbgsym: 0.1.7-1 → 0.1.8-1
• ros-humble-zenoh-security-tools: 0.1.7-1 → 0.1.8-1
• ros-humble-zenoh-security-tools-dbgsym: 0.1.7-1 → 0.1.8-1
• ros-humble-zlib-point-cloud-transport: 1.0.12-1 → 1.0.13-1
• ros-humble-zlib-point-cloud-transport-dbgsym: 1.0.12-1 → 1.0.13-1
• ros-humble-zstd-point-cloud-transport: 1.0.12-1 → 1.0.13-1
• ros-humble-zstd-point-cloud-transport-dbgsym: 1.0.12-1 → 1.0.13-1

Removed Packages [2]:

• ros-humble-mrpt-rawlog
• ros-humble-mrpt-rawlog-dbgsym

Thanks to all ROS maintainers who make packages available to the ROS community. The above list of packages was made possible by the work of the following maintainers:

• Aditya Pande
• Adria Roig
• Aina Irisarri
• Alberto Tudela
• Alejandro Hernández
• Alexey Merzlyakov
• Andrea Capodacqua
• Andrea Sorbini
• Andrej Orsula
• Antonio Brandi
• Audrow Nash
• Automatika Robotics
• Autoware
• Bence Magyar
• Berkay Karaman
• Bernd Pfrommer
• Brett Aldrich
• Brian Wilcox
• Błażej Sowa
• Carl Delsey
• Carlos Orduno
• Chris Lalancette
• Daniel Stonier
• David V. Lu!!
• David ter Kuile
• Dorian Scholz
• Emerson Knapp
• Evan Flynn
• Felix Exner
• Foxglove
• Francisco Martín
• Geoff Sokoll
• Guilhem Saurel
• Hilario Tome
• Isaac Acevedo
• Ivan Paunovic
• Jacob Perron
• Jian Kang
• Joe Dong
• Jordan Palacios
• Jordi Pages
• José Luis Blanco-Claraco
• Luis Camero
• M. Fatih Cırıt
• Mabel Zhang
• Mamoru Sobue
• Markus Bader
• Martin Pecka
• Matej Vargovcik
• Mete Fatih Cırıt
• Michael Jeronimo
• Miguel Ángel González Santamarta
• Mohammad Haghighipanah
• Narcis Miguel
• Nick Hortovanyi
• Noel Jimenez
• Oscar Martinez
• Pablo Inigo Blasco
• RAI Institute
• Ralph Lange
• Rob Fisher
• Robotics and AI Institute LLC dba RAI Institute
• Ryohsuke Mitsudome
• SBG Systems
• STEREOLABS
• Sai Kishor Kothakota
• Sergio Moyano
• Shane Loretz
• Stefan Laible
• Steve Macenski
• TIAGo support team
• Takagi, Isamu
• Team Spatzenhirn
• Temkei Kem
• Thomas Peyrucain
• Tim Clephas
• Troy Gibb
• William Woodall
• Yadunund
• Yue Erro
• Yukihiro Saito
• miguel
• mitsudome-r
• ouster developers
• rostest
• steve
• toosimple

1 post - 1 participant

Read full topic

Scan-N-Plan technologies provide tools for real-time robot trajectory planning based on 3D scan data, addressing the limitations of traditional industrial robot programming methods like teach-pendant programming or offline simulation. This approach is ideal for applications where:

• High part variability makes manual programming impractical
• CAD models are unavailable
• Flexible or deformable parts prevent pre-programming
• Part-to-part variability cannot be handled with static programming
• Flexible or no fixturing is required

The ROS-Industrial Consortium has been advancing tools to support the development of innovative end-user applications and has made them accessible for broader use. The scan_n_plan_workshop offers a ROS 2-based software framework for perception-driven surface processing, providing all the foundational elements needed to understand and implement Scan-N-Plan solutions.

Recently an updated documentation page was publisehd to serve as a comprehensive resource for developers and learners interested in Scan-N-Plan or in using ROS 2 to build industrial applications. It outlines what is included, how to get started, and how ROS 2 can be leveraged effectively.

Key features of the documentation include:

• A detailed architecture diagram
• Step-by-step instructions to get started
• Customization guidance using behavior tree plugins
• Example deployments for reference

We’re excited to see how the community adopts and engages with these resources. If you have any questions or requests, don’t hesitate to reach out!

Hi all - wanted to share some work we’ve been doing internally to help with static recovery and visualization of our ROS graph. We did this by hijacking some other tools we’ve been using to standardize our package structure and simplify our launch files.

We ended up creating and open sourcing three packages:

• cake ( GitHub - greenforge-labs/cake: Declarative code generation for ROS 2 nodes )
• clingwrap ( GitHub - greenforge-labs/clingwrap: A ROS2 launch wrapper to simplify writing python launch files )
• breadcrumb ( GitHub - greenforge-labs/breadcrumb: A ROS graph static analysis tool that works with cake and clingwrap )

cake is a concept that started as trying to simplify the boilerplate required to set up a C++ node by using a more functional approach to node initialization. For the purposes of static graph analysis, we extended it to include a declarative interface file (publishers, subscribers, etc) which would be consumed at build time to generate the ROS code required for these interfaces. A lot of inspiration was taken from the picknik robotics generate_parameter_library (in fact we wrapped this package and included parameters in the node interface file). If you follow the folder structure suggested, cake also provides an automatic cmake macro, which uses ament_cmake_auto under the hood.

clingwrap is yet another python launch wrapper. Arguments about reinventing the launch wrapper wheel aside, it was convenient for us as we were already using it in all our launch files so it provided a good way to instrument all our launch files to statically extract node launch details. clingwrap provides a LaunchBuilder object which is a subclass of LaunchDescription. The idea is that LaunchBuilder is a mutable object which will track all launch actions as it gets mutated, meaning you just have to return it at the end of generate_launch_description. This lets us add extra tracking logic inside the LaunchBuilder class and expose a get_static_information method on it which lets the user call generate_launch_description and then get_static_information on the resulting object - which returns a dataclass of node information such as package and executable name, remappings, etc. We explored parsing the underlying actions that come out of the base launchfile system, but this got complicated quickly (especially recovering composable node information!) so we fell back to this simpler solution.

breadcrumb is a cli tool that uses the static interfaces from cake and the launch information from clingwrap to generate the final runtime ROS graph, based on a launchfile provided (without executing a ROS launch). It then spits out the graph as a json file or a graphviz dot file.

The breadcrumb repo also has an example cartpole project that shows how all three packages work together in one system: breadcrumb/breadcrumb_example at main · greenforge-labs/breadcrumb · GitHub

All of these packages are still very fresh - we are rolling them out in our codebase currently, and expect to extend them where we find extra usecases / corner cases.

Whilst they are somewhat specific to our current system (i.e. you can’t use breadcrumb without rewriting all your launchfiles with clingwrap) I thought it was worth sharing what we’ve come up with for moving our ROS codebase towards being more declarative and statically analyzable.

(the statically generated ROS graph diagram from the breadcrumb example project)

2 posts - 1 participant

Read full topic

NVIDIA Isaac ROS 4.0 for Thor is HERE.

NVIDIA Isaac ROS 4.0, an open-source platform of accelerated packages and reference applications for the ROS 2 ecosystem, is now generally available.

With support for Jetpack 7.0 and Isaac Sim 5.1, you can now unlock the power of Jetson AGX Thor with your Isaac ROS applications. This release includes a new Isaac for Manipulation reference application for deploying learned policies with motion planning for a gear insertion task. The new multi-object pick-and-place workflow using behavior tree orchestration showcases new packages for FoundationStereo and GroundingDINO. Finally, improvements for FoundationPose, NITROS performance, and visual mapping and location along with new Segment Anything 2 round out Isaac ROS with the power of Thor.

Check out the full details here.

2 posts - 2 participants

Read full topic

We would like to share the announcement for the IEEE MRS Summer School 2026, taking place July 29 – August 4, 2026 in Prague.

The event is open to anyone working in multi-robot systems, autonomous UAV/UGV control, distributed coordination, perception, planning, or ROS-based robotics. Over the years the summer school has welcomed more than 1000 participants from academic labs and industry teams worldwide.
The main goal is to bring together people working on similar MRS challenges and create space for collaboration, exchange of ideas, and hands-on experimentation.

What the program includes:

• practical sessions with real multi-robot platforms
• talks from leading researchers in MRS, autonomy, and swarm robotics
• team assignments focusing on coordination, planning, and deployment
• a free weekend for group trips around Prague to encourage networking and community building

Registration:
Early registration fees apply until December 31.
If anyone in your team needs a few extra days, the organizers can extend the reduced fee individually.

Application link:
https://forms.gle/1PWThrYoNZwtAtAU9

Event page:
https://mrs.fel.cvut.cz/summer-school-2026/

If you or your colleagues are working with multi-robot systems, this is a solid opportunity to join the global community, work with real hardware, and connect with people solving similar problems.

1 post - 1 participant

Read full topic

I’m running into a bit of a weird problem. Maybe it’s more of an observation. There are times where I struggle to find the documentation for ROS code on google.

Take the following examples:

• tf2::BufferCore::lookupVelocity: The search query I came up with on google ros tf2 lookupvelocity returns no relevant results on the first page. tf2 kilted lookupVelocity also returns nothing. tf2 buffercore lookupVelocity lists the documentation from jade, foxy as the first two options but neither version of those documentation pages has lookupVelocity. Even a query like tf2 “lookupvelocity” does not yield any results. From a git blame, lookupVelocity was

• Launch python documentation: ros2 launch python includelaunchdescription yields only examples, stack exchange questions and no actual API documentation.

I noticed very clearly that google never gives me ROS source code, and very often outdated API documentation pages. This is really frustrating as it takes longer than I expect to get answers about very normal functions.

I’m really not sure what’s causing this. Is it just bad SEO? Is no one linking to ROS2 docs on the web and so google doesn’t prioritize them? Am I just bad at googling? I’m curious if other people have noticed this. It’s making me feel a little crazy

7 posts - 5 participants

Read full topic

edited: fix link for wrapper repo

This is a repost from openrobotics.zulipchat.com that I made earlier, it was suggested I post here, so here goes…

So, over the past couple days we’ve been working on getting Depth Anything 3 (DA3 - the new monocular depth estimation model from ByteDance) running with ROS2. For those unfamiliar, Depth Anything 3 is basically a neural network that can estimate depth from a single camera image - no stereo rig or LiDAR needed. It’s pretty impressive compared to older methods like MiDaS.

Depth Anything V3 paper: [2408.02532] Singularity categories of rational double points in arbitrary characteristic
Official DA3 repo: GitHub - ByteDance-Seed/Depth-Anything-3: Depth Anything 3
Our GitHub DA3 ROS2 Wrapper Repo:

Here’s what the system looks like running on our Jetson: GitHub - GerdsenAI/GerdsenAI-Depth-Anything-3-ROS2-Wrapper: ROS2 wrapper for Depth Anything 3 (https://github.com/ByteDance-Seed/Depth-Anything-3)

You can see three terminals:

• Left: USB camera node publishing at 640x480 @ 30 FPS
• Middle: Depth estimation running with the colored depth output
• Right: Depth viewer displaying the results

The depth visualization uses a turbo colormap (blue = close, red/orange = far). The quality is honestly better than we expected for monocular depth.

Platform: NVIDIA Jetson AGX Orin 64GB (Syslogic A4AGX64 industrial variant)

• OS: Ubuntu 22.04 + JetPack 6.2.1
• CUDA: 12.6
• ROS2: Humble

Camera: Anker PowerConf C200 2K USB webcam

• Running at 640x480 resolution
• 30 FPS output (though depth processing can’t keep up, feel free to help!! )

Software:

• PyTorch 2.8.0 (Jetson-optimized from nvidia-ai-lab)
• Depth Anything 3 SMALL model (25M parameters)
• Standard v4l2_camera for USB input

Current Performance (This is Where We Need Help)

Here’s what we’re seeing:

Inference Performance:

• FPS: 6.35 (way slower than we hoped)
• Inference time: 153ms per frame
• GPU utilization: 35-69%
• RAM usage: ~6 GB (out of 64 GB available)

Is PyTorch the problem? We’re running standard PyTorch with CUDA. Would TensorRT conversion give us a significant speedup? Has anyone done DA3 → TensorRT on Jetson?

Memory bandwidth? Could we be hitting memory bandwidth limits moving tensors around?

Is the model just too big for real-time? The SMALL model is 25M params. Maybe we need to quantize to FP16 or INT8?

FP16 precision - The Ampere GPU supports FP16 tensor cores. Depth estimation might not need FP32 precision.

Optimize the preprocessing - Right now we’re doing image normalization and resizing in Python/PyTorch. Could we push this to GPU kernels?

Has anyone done any of this successfully? Especially interested if anyone’s gotten DA3 or similar transformers running fast on Jetson.

The paper claims real-time performance but they’re probably testing on desktop GPUs. Getting this fast on embedded hardware is the challenge.

But, we got it working, which is cool, but 6 FPS is pretty far from real-time for most robotics applications. We’re probably doing something obviously wrong or inefficient - this is our first attempt at deploying a transformer model on Jetson.

Contact: GerdsenAI · GitHub
License: MIT

Feel free to contribute!

2 posts - 1 participant

Read full topic

I’m a robotics engineer turned product builder. After years in R&D and recently interviewing around 30 robotics teams, I noticed a pattern that honestly surprised me:

Even teams with mature deployments are still relying on fragile, “temporary” setups for remote debugging.

You may recognize some of these:

• The Classics: frp + rosbridge, usually fine… until the moment you really need it.

• The Painful: SSH X11 forwarding for RViz (enjoy those multi-second frame drops).

• The Network Hell: Strict customer firewalls, unpredictable industrial WiFi, or 4G/5G uplinks that work only when the robot is facing north on a Thursday.

• The Modern Mesh: Tailscale / ZeroTier: great connectivity, but no robotics-specific QoS, telemetry semantics, or tooling.

Enterprise platforms (Formant, Freedom, etc.) are powerful but often expensive or too heavy for simple debugging needs. Meanwhile, open-source solutions feel fragmented.

My Hypothesis: We don’t need another heavy “platform.” We need a simple, reliable, UNIX-style pipe that just works.

I’m exploring a “stupidly simple” API focused purely on transport (low latency, resilient under packet loss). But before I commit to the architecture, I want to validate my assumptions with you.

---

---

What’s in it for you?

1. The Data: I’ll compile the responses into an open “2025 ROS Remote Access Landscape Report” and share it here.

2. The Access: I’m looking for beta testers — 10 random participants will receive lifetime free access to the managed API tier at launch.

PS: After you fill out the form, drop a quick reply below (e.g., “Done” or your biggest pain point). It helps keep this thread visible so we can get more community data!

Cheers, Russell [russellshe at gmail dot com]

5 posts - 2 participants

Read full topic

Hi, I’ve been working on building our software stack using only release mode and not building any packages which are test_depend. The problem I’m having is colcon scoops up all the dependencies no matter how they’re marked in the package.xml. I do not use rosdep as I don’t necessarily trust every dev out there chose wisely when building their package.xml anyways, so I’m trying to do this in a more manual way. I don’t believe I should have to build something like ament_cmake_pep257 if I have no plan to build any tests. I also shouldn’t be installing *-dev debian packages in release builds. E.g. a package I have depends on libglib2.0-dev for building, but only needs libglib2.0-0 at runtime, so the process I want is to build the package in release mode, then create a new image with only the release dependencies, and copy over the install/ space to that new image. Colcon though won’t let me separate out those packages that I don’t want to build, even though they are only <test_depend>. Does anyone else do this or have thoughts?

7 posts - 4 participants

Read full topic