August 27, 2025
Guidance Nav2 for similar project: straight lines trajectory

Hi there,

I am currently working on a project which has similarities to something showcased on the Nav2 website landing page. I would be after recommendations of global planner and local planner/controller plugins to execute a trajectory made of parallel passes spaced by a given constant offset distance. It is similar to what is visible below (visible on Nav2) website:

output

I was not sure in the example above which type of localization method was employed (GPS based for outdoor application, as it seem close to an agricultural outdoor application?). Unsure also who or which company would be behind (I could have given them credit for the illustration above), so would be thankful if the community would know who or which company is behind this illustration.

On my case, at the end of each straight pass (in blue), the robot could reposition via a curved trajectory or pause and execute two turns in place for the repositioning pass. I do not need to maintain speed during the turns.

So far I have explored the straight line global planner plugin as shown in the Nav2 example and trialed the Regulated Pure Pursuit and Vector Pursuit as local planner / controller. Is there other local planner I should consider for this type of application (straight line then repositioning to next straight line)? The goal is to be able to maintain a precise trajectory for the straight passes while going on an acceleration, cruise, deceleration speed profile on the straight lines. I am currently trialing those in Gazebo simulating the environment where the robot will be deployed. I am able to generate the required waypoints via the simple commander API and using AMCL for now as my application is indoor.

Using Gazebo and AMCL, here are the kind of things I obtain via PlotJuggler:

First of, there are differences between ACML and groundtruth, so AMCL would require some improvements, but I can see the AMCL goes by each corner which are waypoints, so the robot from its perception goes to all waypoints. Second the trajectory followed (groundtruth) is within +/-10cm of the target. Not sure if other or better tuned controller can improve the order of magnitude of the accuracy, I would be aiming to about +/-1cm at 1m/s. This is a combination of localization + control method. Open to discuss if I need to improve localization first (AMCL or other, such as Visual + IMU odometry, UWB, …). I am also using Humble which does not have the python API driveOnHeading, to trial a pure straight line command (maybe similar to broadcasting in /cmd_vel a positive x component).

Thank you very much for your help and guidance,

Nicolas

PS: first post on my side, so apologies if this is the wrong platform, I was trying to find out about a specific Nav2 platform but could not join the Nav2 slack.

2 posts - 2 participants

Read full topic

by Nico2025 on August 27, 2025 04:26 AM

August 26, 2025
ROS 2 Desktop Apps with rclnodejs + Electron

Looking for an alternative to traditional ROS visualization tools? Want to create custom robotics interfaces that are modern, interactive, and cross-platform?

The rclnodejs + Electron combination offers a powerful solution for building ROS 2 desktop applications using familiar web technologies, giving you the flexibility to create exactly the interface your project needs.

Why Use This?

  • Cross-platform - Windows, macOS, Linux

  • Modern UI - HTML5, CSS3, Three.js, WebGL

  • Easy deployment - Standalone desktop apps

Architecture

Example: Turtle TF2 Demo

Real-time TF2 coordinate frame visualization with interactive 3D graphics:

turtle-tf2-demo

Perfect for: Robot dashboards, monitoring tools, educational apps, research prototypes.

Learn more: https://github.com/RobotWebTools/rclnodejs

1 post - 1 participant

Read full topic

by minggangw on August 26, 2025 10:30 AM

Think Outside the Box: Controlling a Robotic Arm with a Mobile Phone Gyroscope

:waving_hand: Hi ROS Community,

We’d like to share an experimental project where we explored controlling a robotic arm using the gyroscope and IMU sensors of a mobile phone. By streaming the phone’s sensor data via WebSocket, performing attitude estimation with an EKF, and mapping the results to the robotic arm, we managed to achieve intuitive motion control without the need for traditional joysticks or external controllers.

This post documents the setup process, environment configuration, and code usage so you can try it out yourself or adapt it to your own robotic applications. :rocket:


Abstract

This project implements robotic arm control using mobile phone sensor data (accelerometer, IMU, magnetometer).
The data is transmitted from the mobile phone to a local Python script in real time via WebSocket.
After attitude calculation, the script controls the movement of the robotic arm.


Tags

Mobile Phone Sensor, Attitude Remote Control, IMU, Attitude Calculation, EKF


Code Repository

GitHub: Agilex-College/piper/mobilePhoneCtl


Function Demonstration

Robots by phone?!


Environment Configuration

  • Operating System: Ubuntu 18.04+ (recommended)
  • Python Environment: Python 3.6+
  • Clone the project:
git clone https://github.com/agilexrobotics/Agilex-College.git
cd Agilex-College/piper/mobilePhoneCtl/
  • Install dependencies:
pip install -r requirements.txt --upgrade
  • Ensure that piper_sdk and its hardware dependencies are properly installed and configured.

Mobile Phone App Installation

We recommend using Sensor Stream IMU+ (a paid app) for mobile phone–side data collection and transmission:

  • Install the app from the official website or app store.
  • Supports both iOS and Android.

App Usage Instructions

  1. Open the Sensor Stream IMU+ app.
  2. Enter the IP address and port of the computer running this script (default port: 5000), e.g., 192.168.1.100:5000.
  3. Select sensors to transmit: Accelerometer, Gyroscope, Magnetometer.
  4. Set an update interval (e.g., 20 ms).
  5. Tap Start Streaming to begin data transmission.

Python Script Usage

  1. Connect the robotic arm and activate the CAN module:
sudo ip link set can0 up type can bitrate 1000000
  1. Run main.py in this directory:
python3 main.py
  1. The script will display the local IP address and port—fill this into the app.
  2. Once the app starts streaming, the script performs attitude calculation and sends the results to the robotic arm via the EndPoseCtrl interface of piper_sdk.

Data Transmission & Control Explanation

  • The mobile phone sends 3-axis accelerometer, gyroscope, and magnetometer data in real time via WebSocket.
  • The script employs an Extended Kalman Filter (EKF) to compute Euler angles (roll, pitch, yaw).
  • Calculated attitudes are sent to the robotic arm via piper_sdk’s EndPoseCtrl for real-time motion control.

Precautions

  • Ensure the mobile phone and computer are on the same LAN, and that port 5000 is allowed through the firewall.
  • Safety first—be cautious of the robotic arm moving to avoid any collisions.
  • To modify port or initial pose, edit the relevant parameters in main.py .

Related Projects

Check out these previous tutorials on controlling the AgileX PIPER robotic arm:


:white_check_mark: That’s all for this demo!
If you’re interested in experimenting with mobile-sensor-based robot control, feel free to check out the GitHub repo (again) and give it a try.

We’d love to hear your thoughts, suggestions, or ideas for extending this approach—whether it’s integrating ROS2 teleoperation, improving the EKF pipeline, or adding gesture control.

Looking forward to your feedback and discussions! :raising_hands:

1 post - 1 participant

Read full topic

by Agilex_Robotics on August 26, 2025 10:18 AM

August 25, 2025
Don't trust LLM math with your rosbags? Bagel has a solution

Hi ROS Community,

Couple weeks ago, we launched an open source tool called Bagel. It allows you to troubleshoot rosbags using natural language, just like how you use ChatGPT.

We released a new feature today to address a common concern raised by the ROS community.

:speaking_head: “We don’t trust LLM math.”:man_gesturing_no:

That’s feedback we kept hearing from the ROS community regarding Bagel.:bagel:

:ear: We heard you, so we built a solution: whenever Bagel needs to do a mathematical calculation on a robotics log, it now creates a DuckDB table and runs a clear SQL query against the data.

:brain: That makes Bagel’s math:

• Transparent – you see the query and verify it manually.

• Deterministic – no “LLM guesswork.”

We’re launching this today and would love community feedback :rocket: . Love it :heart: or hate it :-1: ? Let us know! Or yell at us in our Discord :rofl:.

https://github.com/Extelligence-ai/bagel

3 posts - 2 participants

Read full topic

by shouheng on August 25, 2025 05:12 PM

Image_transport and point_cloud_transport improvements

During the last months we have being improving point_cloud_transport and image_point_transport API, in particular to close some major ROS 2 feature gaps

  • Be able to use lifecycle node
  • replace rmw_qos_profile_t with rclcpp::QoS

Related PR: https://github.com/ros-perception/image_common/pull/364 Support lifecycle node - NodeInterfaces by ahcorde · Pull Request #352 · ros-perception/image_common · GitHub Removed deprecated code by ahcorde · Pull Request #356 · ros-perception/image_common · GitHub Update subscriber filter by elsayedelsheikh · Pull Request #126 · ros-perception/point_cloud_transport · GitHub Simplify NodeInterface API mehotd call by ahcorde · Pull Request #129 · ros-perception/point_cloud_transport · GitHub Deprecated rmw_qos_profile_t by ahcorde · Pull Request #125 · ros-perception/point_cloud_transport · GitHub Feat/Add LifecycleNode Support by elsayedelsheikh · Pull Request #109 · ros-perception/point_cloud_transport · GitHub

Some of these changes are breaking ABI (only on rolling). If you are maintaining a point_cloud_transport or image_transport plugins you should probably update a little bit your code to remove new deprecation warnings and avoid potencial segfaults due these new changes.

Thank you everyone involved in these changes and hope this help!

1 post - 1 participant

Read full topic

by ahcorde on August 25, 2025 11:45 AM

August 22, 2025
Industrial Calibration Refresh

A number of ease of use updates have been made to the ROS-Industrial Industrial Calibration repository. These updates seek to improve the ease of use and provides a significant update around documentation. The updates include:

  1. Cleaning up the intrinsic and extrinsic calibration widgets so they now share common infrastructure reducing total code.
  2. The widgets are now in the application main window such that the widgets may now more easily used in Rviz where the image display cannot or does not need to be in the main widget.
  3. The update also includes a widget that separates the calibration configuration/data viewer from the results page (also added to support usage in other contexts (like Rviz) that are more limited on vertical space, and it makes both pages more easily readable).
  4. An “instructions” action and tool bar button has been added to provide information on how to run the calibration apps.

A new documentation page has been created that includes information and examples to help users get the most out of the calibration and get the most accurate hand-eye calibration. This includes an example and unit test for the camera intrinsic calibration using the 10 x 10 modified circle grid data set.

 The updated documentation page includes a primer on calibration that covers the basics of calibration and a “getting started” page that includes guidance on building the application and the ROS 1 and ROS 2 interfaces, as well as links to the GUI applications. A docker has also been provided for those that prefer to work from a Docker container.

 We look forward to getting feedback on this latest update and hope that the community finds this update useful relative to having robust industrial calibration for your robotic perception systems and applications.

by Michael Ripperger on August 22, 2025 08:24 PM

Ros-python-wheels: pip-installable ROS 2 packages

Hello ROS community,

I’d like to share that I’ve been working on making ROS 2 packages pip-installable with a project called ros-python-wheels! Furthermore, a select number of ROS packages are made available on a Python package index which I’ve hosted at Cloudsmith.io

Getting started with ROS 2 in Python is as simple as running:

pip install --extra-index-url https://dl.cloudsmith.io/public/ros-python-wheels/kilted/python/simple ros-rclpy[fastrtps]

Key Benefits

This enable a first-class developer experience when working with ROS in Python projects:

  • Easy Project Integration: To include the ROS Python Client (rclpy) in a Python project, simply add ros-rclpy[fastrtps] with its package repository to your pyproject.toml file.

  • Enable Modern Python Tooling: Easily manage Python ROS dependencies using modern Python tools like uv and Poetry.

  • Lightweight: The wheels of rclpy all of its dependencies have a total size of around 15MB.

  • Portable: Allows ROS to be run on different Linux distributions.

Comparison

This approach provides a distinct alternative to existing solutions:

  • In comparison to RoboStack, wheels are more lightweight and flexible than conda packages.
  • rospypi is a similar approach for ROS 1, whereas ros-python-wheels targets ROS 2.

I’d love to hear your thoughts on this project. I’d also appreciate a star on my project if you find this useful or if you think this is a good direction for ROS!

4 posts - 2 participants

Read full topic

by ycheng517 on August 22, 2025 01:36 PM

August 21, 2025
Announcement: rclrs 0.5.0 Release

We are thrilled to announce the latest official release of rclrs (0.5.0), the Rust client library for ROS 2! This latest version brings significant improvements and enhancements to rclrs, making it easier than ever to develop robotics applications in Rust.

Some of the highlights of this release include:

  • Fully async API, compatible with any async runtime (tokio, async_std, etc.)
  • Support for Windows
  • Support for Jazzy, Kilted and Rolling
  • Parameter services

In addition to the new release of rclrs, we’re also happy to announce that rosidl_generator_rs is now released on the ROS buildfarm ( ROS Package: rosidl_generator_rs ). Paving the way for shipping generated Rust messages alongside current messages for C++ and Python.

I’ll be giving a talk at ROSCon UK in Edinburgh and at ROSCon in Singapore about ros2-rust, rclrs and all the projects that we’ve been working on to bring Rust support to ROS. Happy to chat with anyone interested in our work, or in Rust in ROS in general :slight_smile:

And if you want to be part of the development of the next release, you’re more than welcome to join us on our Matrix chat channel!

I can’t emphasize enough how much this release was a community effort, we’re happy to have people from so many different affiliations contributing to rclrs. This release wouldn’t have been possible without:

  • Abhishek Kashyap
  • Agustin Alba Chicar
  • alluring-mushroom
  • Arjo Chakravarty
  • Javier Balloffet
  • Jacob Hassold
  • Kimberly N. McGuire
  • Luca Della Vedova
  • Lucas Chiesa
  • Marco Boneberger
  • Michael X. Grey
  • Milan Vukov
  • Nathan Wiebe Neufeldt
  • Oscarchoi
  • Romain Reignier
  • Rufus Wong
  • Sam Privett
  • Saron Kim
  • Xavier L’Heureux

1 post - 1 participant

Read full topic

by esteve on August 21, 2025 03:26 PM

[Project] ROS 2 MediaPipe Suite — parameterized multi-model node with landmarks & gesture events

We’re releasing a small ROS 2 suite that turns Google MediaPipe Tasks into reusable components.
A single parameterized node switches between hand / pose / face, publishes landmarks + high-level gesture events, ships RViz viz (overlay + MarkerArray), and a turtlesim demo for perception → event → behavior.

Newcomer note: This is my first ROS 2 package—I kept the setup minimal so students and prototypers can plug MediaPipe into ROS 2 in minutes.

Turtlesim Demo:

Repo: https://github.com/PME26Elvis/mediapipe_ros2_suite · ROS 2: Humble (CI), Jazzy (experimental) · License: Apache-2.0
CI: Humble — passing (required) · Jazzy — experimental (non-blocking)
Quick start:

ros2 run v4l2_camera v4l2_camera_node
ros2 launch mediapipe_ros2_py mp_node.launch.py model:=hand image_topic:=/image_raw start_rviz:=true
ros2 run turtlesim turtlesim_node & ros2 run mediapipe_ros2_py gesture_to_turtlesim

Feedback & contributions welcome.

1 post - 1 participant

Read full topic

by PME26Elvis on August 21, 2025 03:03 PM

August 20, 2025
New packages and patch release for Jazzy Jalisco 2025-08-20

We’re happy to announce 82 new packages and 705 updates are now available on Ubuntu Noble on amd64 for Jazzy Jalisco.

This sync was tagged as jazzy/2025-08-20 .

:jazzy::jazzy::jazzy:

Package Updates for jazzy

Note that package counts include dbgsym packages which have been filtered out from the list below

Added Packages [82]:

  • ros-jazzy-automatika-embodied-agents: 0.4.1-1
  • ros-jazzy-automatika-embodied-agents-dbgsym: 0.4.1-1
  • ros-jazzy-crazyflie: 1.0.3-1
  • ros-jazzy-crazyflie-dbgsym: 1.0.3-1
  • ros-jazzy-crazyflie-examples: 1.0.3-1
  • ros-jazzy-crazyflie-interfaces: 1.0.3-1
  • ros-jazzy-crazyflie-interfaces-dbgsym: 1.0.3-1
  • ros-jazzy-crazyflie-py: 1.0.3-1
  • ros-jazzy-crazyflie-sim: 1.0.3-1
  • ros-jazzy-cx-ament-index-plugin: 0.1.2-1
  • ros-jazzy-cx-ament-index-plugin-dbgsym: 0.1.2-1
  • ros-jazzy-cx-clips-env-manager: 0.1.2-1
  • ros-jazzy-cx-clips-env-manager-dbgsym: 0.1.2-1
  • ros-jazzy-cx-config-plugin: 0.1.2-1
  • ros-jazzy-cx-config-plugin-dbgsym: 0.1.2-1
  • ros-jazzy-cx-example-plugin: 0.1.2-1
  • ros-jazzy-cx-example-plugin-dbgsym: 0.1.2-1
  • ros-jazzy-cx-executive-plugin: 0.1.2-1
  • ros-jazzy-cx-executive-plugin-dbgsym: 0.1.2-1
  • ros-jazzy-cx-file-load-plugin: 0.1.2-1
  • ros-jazzy-cx-file-load-plugin-dbgsym: 0.1.2-1
  • ros-jazzy-cx-msgs: 0.1.2-1
  • ros-jazzy-cx-msgs-dbgsym: 0.1.2-1
  • ros-jazzy-cx-plugin: 0.1.2-1
  • ros-jazzy-cx-plugin-dbgsym: 0.1.2-1
  • ros-jazzy-cx-protobuf-plugin: 0.1.2-1
  • ros-jazzy-cx-protobuf-plugin-dbgsym: 0.1.2-1
  • ros-jazzy-cx-ros-comm-gen: 0.1.2-1
  • ros-jazzy-cx-ros-msgs-plugin: 0.1.2-1
  • ros-jazzy-cx-ros-msgs-plugin-dbgsym: 0.1.2-1
  • ros-jazzy-cx-tf2-pose-tracker-plugin: 0.1.2-1
  • ros-jazzy-cx-tf2-pose-tracker-plugin-dbgsym: 0.1.2-1
  • ros-jazzy-cx-utils: 0.1.2-1
  • ros-jazzy-cx-utils-dbgsym: 0.1.2-1
  • ros-jazzy-ffw-robot-manager: 1.1.9-1
  • ros-jazzy-ffw-robot-manager-dbgsym: 1.1.9-1
  • ros-jazzy-ffw-swerve-drive-controller: 1.1.9-1
  • ros-jazzy-ffw-swerve-drive-controller-dbgsym: 1.1.9-1
  • ros-jazzy-husarion-components-description: 0.0.2-2
  • ros-jazzy-live555-vendor: 0.20250719.0-1
  • ros-jazzy-live555-vendor-dbgsym: 0.20250719.0-1
  • ros-jazzy-omni-wheel-drive-controller: 4.30.1-1
  • ros-jazzy-omni-wheel-drive-controller-dbgsym: 4.30.1-1
  • ros-jazzy-protobuf-comm: 0.9.3-1
  • ros-jazzy-protobuf-comm-dbgsym: 0.9.3-1
  • ros-jazzy-reductstore-agent: 0.2.0-1
  • ros-jazzy-rosbag2-performance-benchmarking-dbgsym: 0.26.9-1
  • ros-jazzy-rosbag2-performance-benchmarking-msgs-dbgsym: 0.26.9-1
  • ros-jazzy-rosidlcpp: 0.3.0-1
  • ros-jazzy-rosidlcpp-generator-c: 0.3.0-1
  • ros-jazzy-rosidlcpp-generator-c-dbgsym: 0.3.0-1
  • ros-jazzy-rosidlcpp-generator-core: 0.3.0-1
  • ros-jazzy-rosidlcpp-generator-core-dbgsym: 0.3.0-1
  • ros-jazzy-rosidlcpp-generator-cpp: 0.3.0-1
  • ros-jazzy-rosidlcpp-generator-cpp-dbgsym: 0.3.0-1
  • ros-jazzy-rosidlcpp-generator-py: 0.3.0-1
  • ros-jazzy-rosidlcpp-generator-py-dbgsym: 0.3.0-1
  • ros-jazzy-rosidlcpp-generator-type-description: 0.3.0-1
  • ros-jazzy-rosidlcpp-generator-type-description-dbgsym: 0.3.0-1
  • ros-jazzy-rosidlcpp-parser: 0.3.0-1
  • ros-jazzy-rosidlcpp-parser-dbgsym: 0.3.0-1
  • ros-jazzy-rosidlcpp-typesupport-c: 0.3.0-1
  • ros-jazzy-rosidlcpp-typesupport-c-dbgsym: 0.3.0-1
  • ros-jazzy-rosidlcpp-typesupport-cpp: 0.3.0-1
  • ros-jazzy-rosidlcpp-typesupport-cpp-dbgsym: 0.3.0-1
  • ros-jazzy-rosidlcpp-typesupport-fastrtps-c: 0.3.0-1
  • ros-jazzy-rosidlcpp-typesupport-fastrtps-c-dbgsym: 0.3.0-1
  • ros-jazzy-rosidlcpp-typesupport-fastrtps-cpp: 0.3.0-1
  • ros-jazzy-rosidlcpp-typesupport-fastrtps-cpp-dbgsym: 0.3.0-1
  • ros-jazzy-rosidlcpp-typesupport-introspection-c: 0.3.0-1
  • ros-jazzy-rosidlcpp-typesupport-introspection-c-dbgsym: 0.3.0-1
  • ros-jazzy-rosidlcpp-typesupport-introspection-cpp: 0.3.0-1
  • ros-jazzy-rosidlcpp-typesupport-introspection-cpp-dbgsym: 0.3.0-1
  • ros-jazzy-turtlebot3-home-service-challenge: 1.0.5-1
  • ros-jazzy-turtlebot3-home-service-challenge-aruco: 1.0.5-1
  • ros-jazzy-turtlebot3-home-service-challenge-core: 1.0.5-1
  • ros-jazzy-turtlebot3-home-service-challenge-manipulator: 1.0.5-1
  • ros-jazzy-turtlebot3-home-service-challenge-manipulator-dbgsym: 1.0.5-1
  • ros-jazzy-turtlebot3-home-service-challenge-tools: 1.0.5-1
  • ros-jazzy-yasmin-dbgsym: 3.3.0-1
  • ros-jazzy-yasmin-ros-dbgsym: 3.3.0-1
  • ros-jazzy-yasmin-viewer-dbgsym: 3.3.0-1

Updated Packages [705]:

  • ros-jazzy-ackermann-steering-controller: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-ackermann-steering-controller-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-action-msgs: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-action-msgs-dbgsym: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-action-tutorials-cpp: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-action-tutorials-cpp-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-action-tutorials-interfaces: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-action-tutorials-interfaces-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-action-tutorials-py: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-admittance-controller: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-admittance-controller-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-ament-clang-format: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-clang-tidy: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-clang-format: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-clang-tidy: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-copyright: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-cppcheck: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-cpplint: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-flake8: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-lint-cmake: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-mypy: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-pclint: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-pep257: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-pycodestyle: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-pyflakes: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-uncrustify: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cmake-xmllint: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-copyright: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cppcheck: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-cpplint: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-flake8: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-lint: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-lint-auto: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-lint-cmake: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-lint-common: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-mypy: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-pclint: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-pep257: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-pycodestyle: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-pyflakes: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-uncrustify: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-ament-xmllint: 0.17.2-1 → 0.17.3-1
  • ros-jazzy-apriltag: 3.4.3-1 → 3.4.4-1
  • ros-jazzy-apriltag-dbgsym: 3.4.3-1 → 3.4.4-1
  • ros-jazzy-apriltag-detector: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-apriltag-detector-dbgsym: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-apriltag-detector-mit: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-apriltag-detector-mit-dbgsym: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-apriltag-detector-umich: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-apriltag-detector-umich-dbgsym: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-apriltag-draw: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-apriltag-draw-dbgsym: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-apriltag-tools: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-apriltag-tools-dbgsym: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-automatika-ros-sugar: 0.2.9-1 → 0.3.1-1
  • ros-jazzy-automatika-ros-sugar-dbgsym: 0.2.9-1 → 0.3.1-1
  • ros-jazzy-axis-camera: 3.0.1-1 → 3.0.2-1
  • ros-jazzy-axis-description: 3.0.1-1 → 3.0.2-1
  • ros-jazzy-axis-msgs: 3.0.1-1 → 3.0.2-1
  • ros-jazzy-axis-msgs-dbgsym: 3.0.1-1 → 3.0.2-1
  • ros-jazzy-backward-ros: 1.0.7-1 → 1.0.8-1
  • ros-jazzy-backward-ros-dbgsym: 1.0.7-1 → 1.0.8-1
  • ros-jazzy-bicycle-steering-controller: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-bicycle-steering-controller-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-builtin-interfaces: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-builtin-interfaces-dbgsym: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-canboat-vendor: 0.0.3-1 → 0.0.5-1
  • ros-jazzy-canboat-vendor-dbgsym: 0.0.3-1 → 0.0.5-1
  • ros-jazzy-clearpath-bt-joy: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-clearpath-common: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-clearpath-config: 2.5.0-1 → 2.6.2-1
  • ros-jazzy-clearpath-control: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-clearpath-customization: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-clearpath-description: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-clearpath-diagnostics: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-clearpath-diagnostics-dbgsym: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-clearpath-generator-common: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-clearpath-generator-common-dbgsym: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-clearpath-manipulators: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-clearpath-manipulators-description: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-clearpath-motor-msgs: 2.4.0-1 → 2.6.0-1
  • ros-jazzy-clearpath-motor-msgs-dbgsym: 2.4.0-1 → 2.6.0-1
  • ros-jazzy-clearpath-mounts-description: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-clearpath-msgs: 2.4.0-1 → 2.6.0-1
  • ros-jazzy-clearpath-platform-description: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-clearpath-platform-msgs: 2.4.0-1 → 2.6.0-1
  • ros-jazzy-clearpath-platform-msgs-dbgsym: 2.4.0-1 → 2.6.0-1
  • ros-jazzy-clearpath-sensors-description: 2.5.1-1 → 2.6.4-1
  • ros-jazzy-coin-d4-driver: 1.0.0-1 → 1.0.1-1
  • ros-jazzy-coin-d4-driver-dbgsym: 1.0.0-1 → 1.0.1-1
  • ros-jazzy-composition: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-composition-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-composition-interfaces: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-composition-interfaces-dbgsym: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-compressed-depth-image-transport: 4.0.4-1 → 4.0.5-1
  • ros-jazzy-compressed-depth-image-transport-dbgsym: 4.0.4-1 → 4.0.5-1
  • ros-jazzy-compressed-image-transport: 4.0.4-1 → 4.0.5-1
  • ros-jazzy-compressed-image-transport-dbgsym: 4.0.4-1 → 4.0.5-1
  • ros-jazzy-control-msgs: 5.4.1-1 → 5.5.0-1
  • ros-jazzy-control-msgs-dbgsym: 5.4.1-1 → 5.5.0-1
  • ros-jazzy-control-toolbox: 4.5.0-1 → 4.6.0-1
  • ros-jazzy-control-toolbox-dbgsym: 4.5.0-1 → 4.6.0-1
  • ros-jazzy-controller-interface: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-controller-interface-dbgsym: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-controller-manager: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-controller-manager-dbgsym: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-controller-manager-msgs: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-controller-manager-msgs-dbgsym: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-demo-nodes-cpp: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-demo-nodes-cpp-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-demo-nodes-cpp-native: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-demo-nodes-cpp-native-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-demo-nodes-py: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-diff-drive-controller: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-diff-drive-controller-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-ds-dbw: 2.3.3-1 → 2.3.5-1
  • ros-jazzy-ds-dbw-can: 2.3.3-1 → 2.3.5-1
  • ros-jazzy-ds-dbw-can-dbgsym: 2.3.3-1 → 2.3.5-1
  • ros-jazzy-ds-dbw-joystick-demo: 2.3.3-1 → 2.3.5-1
  • ros-jazzy-ds-dbw-joystick-demo-dbgsym: 2.3.3-1 → 2.3.5-1
  • ros-jazzy-ds-dbw-msgs: 2.3.3-1 → 2.3.5-1
  • ros-jazzy-ds-dbw-msgs-dbgsym: 2.3.3-1 → 2.3.5-1
  • ros-jazzy-dummy-map-server: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-dummy-map-server-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-dummy-robot-bringup: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-dummy-sensors: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-dummy-sensors-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-dynamixel-hardware-interface: 1.4.8-1 → 1.4.11-1
  • ros-jazzy-dynamixel-hardware-interface-dbgsym: 1.4.8-1 → 1.4.11-1
  • ros-jazzy-effort-controllers: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-effort-controllers-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-etsi-its-cam-coding: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cam-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cam-conversion: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cam-msgs: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cam-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cam-ts-coding: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cam-ts-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cam-ts-conversion: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cam-ts-msgs: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cam-ts-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-coding: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-conversion: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-conversion-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cpm-ts-coding: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cpm-ts-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cpm-ts-conversion: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cpm-ts-msgs: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-cpm-ts-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-denm-coding: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-denm-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-denm-conversion: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-denm-msgs: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-denm-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-denm-ts-coding: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-denm-ts-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-denm-ts-conversion: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-denm-ts-msgs: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-denm-ts-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-mapem-ts-coding: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-mapem-ts-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-mapem-ts-conversion: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-mapem-ts-msgs: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-mapem-ts-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-mcm-uulm-coding: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-mcm-uulm-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-mcm-uulm-conversion: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-mcm-uulm-msgs: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-mcm-uulm-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-messages: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-msgs: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-msgs-utils: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-primitives-conversion: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-rviz-plugins: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-rviz-plugins-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-spatem-ts-coding: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-spatem-ts-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-spatem-ts-conversion: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-spatem-ts-msgs: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-spatem-ts-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-vam-ts-coding: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-vam-ts-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-vam-ts-conversion: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-vam-ts-msgs: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-etsi-its-vam-ts-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-jazzy-event-camera-renderer: 2.0.0-1 → 2.0.1-2
  • ros-jazzy-event-camera-renderer-dbgsym: 2.0.0-1 → 2.0.1-2
  • ros-jazzy-examples-rclcpp-async-client: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-async-client-dbgsym: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-cbg-executor: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-cbg-executor-dbgsym: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-action-client: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-action-client-dbgsym: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-action-server: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-action-server-dbgsym: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-client: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-client-dbgsym: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-composition: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-composition-dbgsym: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-publisher: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-publisher-dbgsym: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-service: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-service-dbgsym: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-subscriber: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-subscriber-dbgsym: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-timer: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-minimal-timer-dbgsym: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-multithreaded-executor: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-multithreaded-executor-dbgsym: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-wait-set: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclcpp-wait-set-dbgsym: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclpy-executors: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclpy-guard-conditions: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclpy-minimal-action-client: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclpy-minimal-action-server: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclpy-minimal-client: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclpy-minimal-publisher: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclpy-minimal-service: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclpy-minimal-subscriber: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-rclpy-pointcloud-publisher: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-examples-tf2-py: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-fastrtps: 2.14.4-1 → 2.14.5-2
  • ros-jazzy-fastrtps-cmake-module: 3.6.1-1 → 3.6.2-1
  • ros-jazzy-fastrtps-dbgsym: 2.14.4-1 → 2.14.5-2
  • ros-jazzy-feetech-ros2-driver: 0.1.0-3 → 0.2.0-1
  • ros-jazzy-feetech-ros2-driver-dbgsym: 0.1.0-3 → 0.2.0-1
  • ros-jazzy-ffw: 1.0.9-1 → 1.1.9-1
  • ros-jazzy-ffw-bringup: 1.0.9-1 → 1.1.9-1
  • ros-jazzy-ffw-description: 1.0.9-1 → 1.1.9-1
  • ros-jazzy-ffw-joint-trajectory-command-broadcaster: 1.0.9-1 → 1.1.9-1
  • ros-jazzy-ffw-joint-trajectory-command-broadcaster-dbgsym: 1.0.9-1 → 1.1.9-1
  • ros-jazzy-ffw-joystick-controller: 1.0.9-1 → 1.1.9-1
  • ros-jazzy-ffw-joystick-controller-dbgsym: 1.0.9-1 → 1.1.9-1
  • ros-jazzy-ffw-moveit-config: 1.0.9-1 → 1.1.9-1
  • ros-jazzy-ffw-spring-actuator-controller: 1.0.9-1 → 1.1.9-1
  • ros-jazzy-ffw-spring-actuator-controller-dbgsym: 1.0.9-1 → 1.1.9-1
  • ros-jazzy-ffw-teleop: 1.0.9-1 → 1.1.9-1
  • ros-jazzy-filters: 2.2.1-1 → 2.2.2-1
  • ros-jazzy-filters-dbgsym: 2.2.1-1 → 2.2.2-1
  • ros-jazzy-flir-camera-description: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-flir-camera-msgs: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-flir-camera-msgs-dbgsym: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-force-torque-sensor-broadcaster: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-force-torque-sensor-broadcaster-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-forward-command-controller: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-forward-command-controller-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-fuse: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-constraints: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-constraints-dbgsym: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-core: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-core-dbgsym: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-doc: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-graphs: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-graphs-dbgsym: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-loss: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-loss-dbgsym: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-models: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-models-dbgsym: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-msgs: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-msgs-dbgsym: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-optimizers: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-optimizers-dbgsym: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-publishers: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-publishers-dbgsym: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-tutorials: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-tutorials-dbgsym: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-variables: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-variables-dbgsym: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-viz: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-fuse-viz-dbgsym: 1.1.1-1 → 1.1.3-1
  • ros-jazzy-geometry2: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-gpio-controllers: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-gpio-controllers-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-gps-msgs: 2.1.0-1 → 2.1.1-1
  • ros-jazzy-gps-msgs-dbgsym: 2.1.0-1 → 2.1.1-1
  • ros-jazzy-gps-sensor-broadcaster: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-gps-sensor-broadcaster-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-gps-tools: 2.1.0-1 → 2.1.1-1
  • ros-jazzy-gps-tools-dbgsym: 2.1.0-1 → 2.1.1-1
  • ros-jazzy-gps-umd: 2.1.0-1 → 2.1.1-1
  • ros-jazzy-gpsd-client: 2.1.0-1 → 2.1.1-1
  • ros-jazzy-gpsd-client-dbgsym: 2.1.0-1 → 2.1.1-1
  • ros-jazzy-gripper-controllers: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-gripper-controllers-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-gz-ros2-control: 1.2.13-1 → 1.2.14-1
  • ros-jazzy-gz-ros2-control-dbgsym: 1.2.13-1 → 1.2.14-1
  • ros-jazzy-gz-ros2-control-demos: 1.2.13-1 → 1.2.14-1
  • ros-jazzy-gz-ros2-control-demos-dbgsym: 1.2.13-1 → 1.2.14-1
  • ros-jazzy-hardware-interface: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-hardware-interface-dbgsym: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-hardware-interface-testing: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-hardware-interface-testing-dbgsym: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-hebi-cpp-api: 3.12.3-1 → 3.13.0-3
  • ros-jazzy-hebi-cpp-api-dbgsym: 3.12.3-1 → 3.13.0-3
  • ros-jazzy-image-tools: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-image-tools-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-image-transport-plugins: 4.0.4-1 → 4.0.5-1
  • ros-jazzy-imu-sensor-broadcaster: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-imu-sensor-broadcaster-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-intra-process-demo: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-intra-process-demo-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-joint-limits: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-joint-limits-dbgsym: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-joint-state-broadcaster: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-joint-state-broadcaster-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-joint-trajectory-controller: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-joint-trajectory-controller-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-kompass: 0.2.1-1 → 0.3.0-1
  • ros-jazzy-kompass-interfaces: 0.2.1-1 → 0.3.0-1
  • ros-jazzy-kompass-interfaces-dbgsym: 0.2.1-1 → 0.3.0-1
  • ros-jazzy-laser-filters: 2.0.8-1 → 2.0.9-1
  • ros-jazzy-laser-filters-dbgsym: 2.0.8-1 → 2.0.9-1
  • ros-jazzy-launch: 3.4.5-1 → 3.4.6-1
  • ros-jazzy-launch-pytest: 3.4.5-1 → 3.4.6-1
  • ros-jazzy-launch-testing: 3.4.5-1 → 3.4.6-1
  • ros-jazzy-launch-testing-ament-cmake: 3.4.5-1 → 3.4.6-1
  • ros-jazzy-launch-testing-examples: 0.19.5-1 → 0.19.6-1
  • ros-jazzy-launch-xml: 3.4.5-1 → 3.4.6-1
  • ros-jazzy-launch-yaml: 3.4.5-1 → 3.4.6-1
  • ros-jazzy-leo-bringup: 2.3.0-1 → 2.4.0-1
  • ros-jazzy-leo-filters: 2.3.0-1 → 2.4.0-1
  • ros-jazzy-leo-filters-dbgsym: 2.3.0-1 → 2.4.0-1
  • ros-jazzy-leo-fw: 2.3.0-1 → 2.4.0-1
  • ros-jazzy-leo-fw-dbgsym: 2.3.0-1 → 2.4.0-1
  • ros-jazzy-leo-robot: 2.3.0-1 → 2.4.0-1
  • ros-jazzy-libcaer-driver: 1.5.1-1 → 1.5.2-1
  • ros-jazzy-libcaer-driver-dbgsym: 1.5.1-1 → 1.5.2-1
  • ros-jazzy-liblz4-vendor: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-librealsense2: 2.55.1-1 → 2.56.4-1
  • ros-jazzy-librealsense2-dbgsym: 2.55.1-1 → 2.56.4-1
  • ros-jazzy-lifecycle: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-lifecycle-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-lifecycle-msgs: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-lifecycle-msgs-dbgsym: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-lifecycle-py: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-logging-demo: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-logging-demo-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-lttngpy: 8.2.3-1 → 8.2.4-1
  • ros-jazzy-mapviz: 2.5.6-1 → 2.5.8-1
  • ros-jazzy-mapviz-dbgsym: 2.5.6-1 → 2.5.8-1
  • ros-jazzy-mapviz-interfaces: 2.5.6-1 → 2.5.8-1
  • ros-jazzy-mapviz-interfaces-dbgsym: 2.5.6-1 → 2.5.8-1
  • ros-jazzy-mapviz-plugins: 2.5.6-1 → 2.5.8-1
  • ros-jazzy-mapviz-plugins-dbgsym: 2.5.6-1 → 2.5.8-1
  • ros-jazzy-mcap-vendor: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-mcap-vendor-dbgsym: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-mecanum-drive-controller: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-mecanum-drive-controller-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-message-filters: 4.11.6-1 → 4.11.7-1
  • ros-jazzy-message-filters-dbgsym: 4.11.6-1 → 4.11.7-1
  • ros-jazzy-mola-test-datasets: 0.4.1-1 → 0.4.2-1
  • ros-jazzy-mrpt-map-server: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-map-server-dbgsym: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-msgs-bridge: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-nav-interfaces: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-nav-interfaces-dbgsym: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-navigation: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-path-planning: 0.2.1-1 → 0.2.2-1
  • ros-jazzy-mrpt-path-planning-dbgsym: 0.2.1-1 → 0.2.2-1
  • ros-jazzy-mrpt-pf-localization: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-pf-localization-dbgsym: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-pointcloud-pipeline: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-pointcloud-pipeline-dbgsym: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-rawlog: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-rawlog-dbgsym: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-reactivenav2d: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-reactivenav2d-dbgsym: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-tps-astar-planner: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-tps-astar-planner-dbgsym: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-mrpt-tutorials: 2.2.1-1 → 2.2.3-1
  • ros-jazzy-multires-image: 2.5.6-1 → 2.5.8-1
  • ros-jazzy-multires-image-dbgsym: 2.5.6-1 → 2.5.8-1
  • ros-jazzy-mvsim: 0.13.3-1 → 0.14.0-1
  • ros-jazzy-mvsim-dbgsym: 0.13.3-1 → 0.14.0-1
  • ros-jazzy-om-gravity-compensation-controller: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-om-gravity-compensation-controller-dbgsym: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-om-joint-trajectory-command-broadcaster: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-om-joint-trajectory-command-broadcaster-dbgsym: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-om-spring-actuator-controller: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-om-spring-actuator-controller-dbgsym: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-open-manipulator: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-open-manipulator-bringup: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-open-manipulator-collision: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-open-manipulator-collision-dbgsym: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-open-manipulator-description: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-open-manipulator-gui: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-open-manipulator-gui-dbgsym: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-open-manipulator-moveit-config: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-open-manipulator-playground: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-open-manipulator-playground-dbgsym: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-open-manipulator-teleop: 4.0.1-1 → 4.0.6-1
  • ros-jazzy-osrf-pycommon: 2.1.6-1 → 2.1.7-1
  • ros-jazzy-pal-statistics: 2.6.2-1 → 2.6.4-1
  • ros-jazzy-pal-statistics-dbgsym: 2.6.2-1 → 2.6.4-1
  • ros-jazzy-pal-statistics-msgs: 2.6.2-1 → 2.6.4-1
  • ros-jazzy-pal-statistics-msgs-dbgsym: 2.6.2-1 → 2.6.4-1
  • ros-jazzy-parallel-gripper-controller: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-parallel-gripper-controller-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-pendulum-control: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-pendulum-control-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-pendulum-msgs: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-pendulum-msgs-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-pid-controller: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-pid-controller-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-plotjuggler: 3.9.2-1 → 3.10.11-1
  • ros-jazzy-plotjuggler-dbgsym: 3.9.2-1 → 3.10.11-1
  • ros-jazzy-plotjuggler-ros: 2.1.2-2 → 2.3.0-1
  • ros-jazzy-plotjuggler-ros-dbgsym: 2.1.2-2 → 2.3.0-1
  • ros-jazzy-pose-broadcaster: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-pose-broadcaster-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-pose-cov-ops: 0.3.13-1 → 0.4.0-1
  • ros-jazzy-pose-cov-ops-dbgsym: 0.3.13-1 → 0.4.0-1
  • ros-jazzy-position-controllers: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-position-controllers-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-quality-of-service-demo-cpp: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-quality-of-service-demo-cpp-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-quality-of-service-demo-py: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-range-sensor-broadcaster: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-range-sensor-broadcaster-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-rc-genicam-api: 2.6.5-2 → 2.8.1-1
  • ros-jazzy-rc-genicam-api-dbgsym: 2.6.5-2 → 2.8.1-1
  • ros-jazzy-rc-genicam-driver: 0.3.1-1 → 0.3.2-1
  • ros-jazzy-rc-genicam-driver-dbgsym: 0.3.1-1 → 0.3.2-1
  • ros-jazzy-rc-reason-clients: 0.4.0-2 → 0.5.0-1
  • ros-jazzy-rc-reason-msgs: 0.4.0-2 → 0.5.0-1
  • ros-jazzy-rc-reason-msgs-dbgsym: 0.4.0-2 → 0.5.0-1
  • ros-jazzy-rcl-interfaces: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-rcl-interfaces-dbgsym: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-rclcpp: 28.1.10-1 → 28.1.11-1
  • ros-jazzy-rclcpp-action: 28.1.10-1 → 28.1.11-1
  • ros-jazzy-rclcpp-action-dbgsym: 28.1.10-1 → 28.1.11-1
  • ros-jazzy-rclcpp-components: 28.1.10-1 → 28.1.11-1
  • ros-jazzy-rclcpp-components-dbgsym: 28.1.10-1 → 28.1.11-1
  • ros-jazzy-rclcpp-dbgsym: 28.1.10-1 → 28.1.11-1
  • ros-jazzy-rclcpp-lifecycle: 28.1.10-1 → 28.1.11-1
  • ros-jazzy-rclcpp-lifecycle-dbgsym: 28.1.10-1 → 28.1.11-1
  • ros-jazzy-rclpy: 7.1.4-1 → 7.1.5-1
  • ros-jazzy-rcutils: 6.7.2-1 → 6.7.3-1
  • ros-jazzy-rcutils-dbgsym: 6.7.2-1 → 6.7.3-1
  • ros-jazzy-realsense2-camera: 4.55.1-3 → 4.56.4-1
  • ros-jazzy-realsense2-camera-dbgsym: 4.55.1-3 → 4.56.4-1
  • ros-jazzy-realsense2-camera-msgs: 4.55.1-3 → 4.56.4-1
  • ros-jazzy-realsense2-camera-msgs-dbgsym: 4.55.1-3 → 4.56.4-1
  • ros-jazzy-realsense2-description: 4.55.1-3 → 4.56.4-1
  • ros-jazzy-rmf-building-sim-gz-plugins: 2.3.2-1 → 2.3.3-1
  • ros-jazzy-rmf-building-sim-gz-plugins-dbgsym: 2.3.2-1 → 2.3.3-1
  • ros-jazzy-rmf-robot-sim-common: 2.3.2-1 → 2.3.3-1
  • ros-jazzy-rmf-robot-sim-common-dbgsym: 2.3.2-1 → 2.3.3-1
  • ros-jazzy-rmf-robot-sim-gz-plugins: 2.3.2-1 → 2.3.3-1
  • ros-jazzy-rmf-robot-sim-gz-plugins-dbgsym: 2.3.2-1 → 2.3.3-1
  • ros-jazzy-rmw-fastrtps-cpp: 8.4.2-1 → 8.4.3-1
  • ros-jazzy-rmw-fastrtps-cpp-dbgsym: 8.4.2-1 → 8.4.3-1
  • ros-jazzy-rmw-fastrtps-dynamic-cpp: 8.4.2-1 → 8.4.3-1
  • ros-jazzy-rmw-fastrtps-dynamic-cpp-dbgsym: 8.4.2-1 → 8.4.3-1
  • ros-jazzy-rmw-fastrtps-shared-cpp: 8.4.2-1 → 8.4.3-1
  • ros-jazzy-rmw-fastrtps-shared-cpp-dbgsym: 8.4.2-1 → 8.4.3-1
  • ros-jazzy-rmw-implementation: 2.15.5-1 → 2.15.6-1
  • ros-jazzy-rmw-implementation-dbgsym: 2.15.5-1 → 2.15.6-1
  • ros-jazzy-ros-gz: 1.0.15-1 → 1.0.16-1
  • ros-jazzy-ros-gz-bridge: 1.0.15-1 → 1.0.16-1
  • ros-jazzy-ros-gz-bridge-dbgsym: 1.0.15-1 → 1.0.16-1
  • ros-jazzy-ros-gz-image: 1.0.15-1 → 1.0.16-1
  • ros-jazzy-ros-gz-image-dbgsym: 1.0.15-1 → 1.0.16-1
  • ros-jazzy-ros-gz-interfaces: 1.0.15-1 → 1.0.16-1
  • ros-jazzy-ros-gz-interfaces-dbgsym: 1.0.15-1 → 1.0.16-1
  • ros-jazzy-ros-gz-sim: 1.0.15-1 → 1.0.16-1
  • ros-jazzy-ros-gz-sim-dbgsym: 1.0.15-1 → 1.0.16-1
  • ros-jazzy-ros-gz-sim-demos: 1.0.15-1 → 1.0.16-1
  • ros-jazzy-ros2-control: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-ros2-control-test-assets: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-ros2-controllers: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-ros2-controllers-test-nodes: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-ros2action: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2bag: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-ros2cli: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2cli-test-interfaces: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2cli-test-interfaces-dbgsym: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2component: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2controlcli: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-ros2doctor: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2interface: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2lifecycle: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2lifecycle-test-fixtures: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2lifecycle-test-fixtures-dbgsym: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2multicast: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2node: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2param: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2pkg: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2run: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2service: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2topic: 0.32.4-1 → 0.32.5-1
  • ros-jazzy-ros2trace: 8.2.3-1 → 8.2.4-1
  • ros-jazzy-rosbag2: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-compression: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-compression-dbgsym: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-compression-zstd: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-compression-zstd-dbgsym: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-cpp: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-cpp-dbgsym: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-examples-cpp: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-examples-cpp-dbgsym: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-examples-py: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-interfaces: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-interfaces-dbgsym: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-performance-benchmarking: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-performance-benchmarking-msgs: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-py: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-storage: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-storage-dbgsym: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-storage-default-plugins: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-storage-mcap: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-storage-mcap-dbgsym: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-storage-sqlite3: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-storage-sqlite3-dbgsym: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-test-common: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-test-msgdefs: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-test-msgdefs-dbgsym: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-tests: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-transport: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosbag2-transport-dbgsym: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-rosgraph-msgs: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-rosgraph-msgs-dbgsym: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-rosidl-adapter: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-cli: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-cmake: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-generator-c: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-generator-cpp: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-generator-type-description: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-parser: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-pycommon: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-runtime-c: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-runtime-c-dbgsym: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-runtime-cpp: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-typesupport-fastrtps-c: 3.6.1-1 → 3.6.2-1
  • ros-jazzy-rosidl-typesupport-fastrtps-c-dbgsym: 3.6.1-1 → 3.6.2-1
  • ros-jazzy-rosidl-typesupport-fastrtps-cpp: 3.6.1-1 → 3.6.2-1
  • ros-jazzy-rosidl-typesupport-fastrtps-cpp-dbgsym: 3.6.1-1 → 3.6.2-1
  • ros-jazzy-rosidl-typesupport-interface: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-typesupport-introspection-c: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-typesupport-introspection-c-dbgsym: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-typesupport-introspection-cpp: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rosidl-typesupport-introspection-cpp-dbgsym: 4.6.5-1 → 4.6.6-1
  • ros-jazzy-rqt-bag: 1.5.4-1 → 1.5.5-1
  • ros-jazzy-rqt-bag-plugins: 1.5.4-1 → 1.5.5-1
  • ros-jazzy-rqt-controller-manager: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-rqt-graph: 1.5.4-1 → 1.5.5-1
  • ros-jazzy-rqt-joint-trajectory-controller: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-rqt-plot: 1.4.3-1 → 1.4.4-1
  • ros-jazzy-rqt-robot-steering: 1.0.1-2 → 2.0.0-1
  • ros-jazzy-rtabmap: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-conversions: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-conversions-dbgsym: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-dbgsym: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-demos: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-examples: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-launch: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-msgs: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-msgs-dbgsym: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-odom: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-odom-dbgsym: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-python: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-ros: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-rviz-plugins: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-rviz-plugins-dbgsym: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-slam: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-slam-dbgsym: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-sync: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-sync-dbgsym: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-util: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-util-dbgsym: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-viz: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rtabmap-viz-dbgsym: 0.22.0-1 → 0.22.1-1
  • ros-jazzy-rviz-assimp-vendor: 14.1.12-1 → 14.1.13-1
  • ros-jazzy-rviz-common: 14.1.12-1 → 14.1.13-1
  • ros-jazzy-rviz-common-dbgsym: 14.1.12-1 → 14.1.13-1
  • ros-jazzy-rviz-default-plugins: 14.1.12-1 → 14.1.13-1
  • ros-jazzy-rviz-default-plugins-dbgsym: 14.1.12-1 → 14.1.13-1
  • ros-jazzy-rviz-ogre-vendor: 14.1.12-1 → 14.1.13-1
  • ros-jazzy-rviz-ogre-vendor-dbgsym: 14.1.12-1 → 14.1.13-1
  • ros-jazzy-rviz-rendering: 14.1.12-1 → 14.1.13-1
  • ros-jazzy-rviz-rendering-dbgsym: 14.1.12-1 → 14.1.13-1
  • ros-jazzy-rviz-rendering-tests: 14.1.12-1 → 14.1.13-1
  • ros-jazzy-rviz-visual-testing-framework: 14.1.12-1 → 14.1.13-1
  • ros-jazzy-rviz2: 14.1.12-1 → 14.1.13-1
  • ros-jazzy-rviz2-dbgsym: 14.1.12-1 → 14.1.13-1
  • ros-jazzy-sdformat-vendor: 0.0.9-1 → 0.0.10-1
  • ros-jazzy-sdformat-vendor-dbgsym: 0.0.9-1 → 0.0.10-1
  • ros-jazzy-service-msgs: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-service-msgs-dbgsym: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-shared-queues-vendor: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-spinnaker-camera-driver: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-spinnaker-camera-driver-dbgsym: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-spinnaker-synchronized-camera-driver: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-spinnaker-synchronized-camera-driver-dbgsym: 3.0.2-1 → 3.0.3-1
  • ros-jazzy-sqlite3-vendor: 0.26.7-1 → 0.26.9-1
  • ros-jazzy-sros2: 0.13.3-1 → 0.13.4-1
  • ros-jazzy-sros2-cmake: 0.13.3-1 → 0.13.4-1
  • ros-jazzy-statistics-msgs: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-statistics-msgs-dbgsym: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-steering-controllers-library: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-steering-controllers-library-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-swri-cli-tools: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-console-util: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-console-util-dbgsym: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-dbw-interface: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-geometry-util: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-geometry-util-dbgsym: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-image-util: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-image-util-dbgsym: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-math-util: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-math-util-dbgsym: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-opencv-util: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-opencv-util-dbgsym: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-roscpp: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-roscpp-dbgsym: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-route-util: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-route-util-dbgsym: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-serial-util: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-serial-util-dbgsym: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-transform-util: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-swri-transform-util-dbgsym: 3.8.4-1 → 3.8.7-1
  • ros-jazzy-teleop-twist-joy: 2.6.3-1 → 2.6.5-1
  • ros-jazzy-teleop-twist-joy-dbgsym: 2.6.3-1 → 2.6.5-1
  • ros-jazzy-test-msgs: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-test-msgs-dbgsym: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-tf2: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-2d: 1.0.1-4 → 1.4.0-1
  • ros-jazzy-tf2-bullet: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-dbgsym: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-eigen: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-eigen-kdl: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-eigen-kdl-dbgsym: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-geometry-msgs: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-kdl: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-msgs: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-msgs-dbgsym: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-py: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-py-dbgsym: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-ros: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-ros-dbgsym: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-ros-py: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-sensor-msgs: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-tf2-tools: 0.36.12-1 → 0.36.14-1
  • ros-jazzy-theora-image-transport: 4.0.4-1 → 4.0.5-1
  • ros-jazzy-theora-image-transport-dbgsym: 4.0.4-1 → 4.0.5-1
  • ros-jazzy-tile-map: 2.5.6-1 → 2.5.8-1
  • ros-jazzy-tile-map-dbgsym: 2.5.6-1 → 2.5.8-1
  • ros-jazzy-topic-based-ros2-control: 0.2.0-3 → 0.3.0-4
  • ros-jazzy-topic-based-ros2-control-dbgsym: 0.2.0-3 → 0.3.0-4
  • ros-jazzy-topic-monitor: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-topic-statistics-demo: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-topic-statistics-demo-dbgsym: 0.33.5-1 → 0.33.6-1
  • ros-jazzy-trac-ik: 2.0.1-1 → 2.0.2-1
  • ros-jazzy-trac-ik-kinematics-plugin: 2.0.1-1 → 2.0.2-1
  • ros-jazzy-trac-ik-kinematics-plugin-dbgsym: 2.0.1-1 → 2.0.2-1
  • ros-jazzy-trac-ik-lib: 2.0.1-1 → 2.0.2-1
  • ros-jazzy-trac-ik-lib-dbgsym: 2.0.1-1 → 2.0.2-1
  • ros-jazzy-tracetools: 8.2.3-1 → 8.2.4-1
  • ros-jazzy-tracetools-dbgsym: 8.2.3-1 → 8.2.4-1
  • ros-jazzy-tracetools-launch: 8.2.3-1 → 8.2.4-1
  • ros-jazzy-tracetools-read: 8.2.3-1 → 8.2.4-1
  • ros-jazzy-tracetools-test: 8.2.3-1 → 8.2.4-1
  • ros-jazzy-tracetools-trace: 8.2.3-1 → 8.2.4-1
  • ros-jazzy-transmission-interface: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-transmission-interface-dbgsym: 4.32.0-1 → 4.35.0-1
  • ros-jazzy-tricycle-controller: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-tricycle-controller-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-tricycle-steering-controller: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-tricycle-steering-controller-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-turtle-nest: 1.0.2-1 → 1.1.0-1
  • ros-jazzy-turtle-nest-dbgsym: 1.0.2-1 → 1.1.0-1
  • ros-jazzy-turtlebot3: 2.3.1-1 → 2.3.3-1
  • ros-jazzy-turtlebot3-bringup: 2.3.1-1 → 2.3.3-1
  • ros-jazzy-turtlebot3-cartographer: 2.3.1-1 → 2.3.3-1
  • ros-jazzy-turtlebot3-description: 2.3.1-1 → 2.3.3-1
  • ros-jazzy-turtlebot3-example: 2.3.1-1 → 2.3.3-1
  • ros-jazzy-turtlebot3-fake-node: 2.3.5-1 → 2.3.7-1
  • ros-jazzy-turtlebot3-fake-node-dbgsym: 2.3.5-1 → 2.3.7-1
  • ros-jazzy-turtlebot3-gazebo: 2.3.5-1 → 2.3.7-1
  • ros-jazzy-turtlebot3-gazebo-dbgsym: 2.3.5-1 → 2.3.7-1
  • ros-jazzy-turtlebot3-navigation2: 2.3.1-1 → 2.3.3-1
  • ros-jazzy-turtlebot3-node: 2.3.1-1 → 2.3.3-1
  • ros-jazzy-turtlebot3-node-dbgsym: 2.3.1-1 → 2.3.3-1
  • ros-jazzy-turtlebot3-simulations: 2.3.5-1 → 2.3.7-1
  • ros-jazzy-turtlebot3-teleop: 2.3.1-1 → 2.3.3-1
  • ros-jazzy-type-description-interfaces: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-type-description-interfaces-dbgsym: 2.0.2-2 → 2.0.3-1
  • ros-jazzy-ur-client-library: 2.1.0-1 → 2.2.0-1
  • ros-jazzy-ur-client-library-dbgsym: 2.1.0-1 → 2.2.0-1
  • ros-jazzy-ur-msgs: 2.2.0-1 → 2.3.0-1
  • ros-jazzy-ur-msgs-dbgsym: 2.2.0-1 → 2.3.0-1
  • ros-jazzy-velocity-controllers: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-velocity-controllers-dbgsym: 4.27.0-1 → 4.30.1-1
  • ros-jazzy-yasmin: 3.2.0-1 → 3.3.0-1
  • ros-jazzy-yasmin-demos: 3.2.0-1 → 3.3.0-1
  • ros-jazzy-yasmin-demos-dbgsym: 3.2.0-1 → 3.3.0-1
  • ros-jazzy-yasmin-msgs: 3.2.0-1 → 3.3.0-1
  • ros-jazzy-yasmin-msgs-dbgsym: 3.2.0-1 → 3.3.0-1
  • ros-jazzy-yasmin-ros: 3.2.0-1 → 3.3.0-1
  • ros-jazzy-yasmin-viewer: 3.2.0-1 → 3.3.0-1
  • ros-jazzy-zed-msgs: 5.0.1-1 → 5.0.1-2
  • ros-jazzy-zed-msgs-dbgsym: 5.0.1-1 → 5.0.1-2
  • ros-jazzy-zstd-image-transport: 4.0.4-1 → 4.0.5-1
  • ros-jazzy-zstd-image-transport-dbgsym: 4.0.4-1 → 4.0.5-1
  • ros-jazzy-zstd-vendor: 0.26.7-1 → 0.26.9-1

Removed Packages [1]:

  • ros-jazzy-test-ros-gz-bridge

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:

  • Aarav Gupta
  • Addisu Z. Taddese
  • Aditya Pande
  • Alejandro Hernandez Cordero
  • Anthony Cavin (@anthonycvn)
  • Anthony Welte
  • Audrow Nash
  • Automatika Robotics
  • Bence Magyar
  • Bernd Pfrommer
  • Brandon Ong
  • Chris Bollinger
  • Chris Iverach-Brereton
  • Chris Lalancette
  • Christophe Bedard
  • Davide Faconti
  • Dirk Thomas
  • Emerson Knapp
  • Enrique Fernandez
  • Felix Exner
  • Felix Ruess
  • Fictionlab
  • Foxglove
  • G.A. vd. Hoorn
  • Geoffrey Biggs
  • Hilary Luo
  • Husarion
  • Ivan Paunovic
  • Jacob Perron
  • Jafar Uruc
  • Janne Karttunen
  • Jean-Pierre Busch
  • Jon Binney
  • Jordan Palacios
  • Jose Luis Blanco-Claraco
  • Jose-Luis Blanco-Claraco
  • José Luis Blanco-Claraco
  • Kenji Brameld
  • Kevin Hallenbeck
  • LibRealSense ROS Team
  • Luca Della Vedova
  • Luis Camero
  • Markus Bader
  • Marq Rasmussen
  • Mathieu Labbe
  • Max Krogius
  • Michael Orlov
  • Miguel Company
  • Miguel Ángel González Santamarta
  • Pyo
  • ROS Security Working Group
  • ROS Tooling Working Group
  • Roni Kreinin
  • STEREOLABS
  • Severn Lortie
  • Shane Loretz
  • Southwest Research Institute
  • Stephen Williams
  • TRACLabs Robotics
  • Tarik Viehmann
  • Timo Röhling
  • Tom Moore
  • Tully Foote
  • Victor López
  • William Woodall
  • Wolfgang Hönig
  • geoff
  • miguel
  • pyo
  • ruess

4 posts - 4 participants

Read full topic

by marcogg on August 20, 2025 08:03 PM

Continuous Trajectory Recording and Replay for AgileX PIPER Robotic Arm

Hi ROS Community,

I’m excited to share details about implementing continuous trajectory recording and replay for the AgileX PIPER robotic arm. This solution leverages time-series data to accurately replicate complex motion trajectories, with full code, usage guides, and step-by-step demos included. It’s designed to support teaching demonstrations and automated operations, and I hope it brings value to your projects.

Abstract

This paper achieves continuous trajectory recording and replay based on the AgileX PIPER robotic arm. Through the recording and reproduction of time-series data, it achieves the perfect replication of the complex motion trajectories of the robotic arm. In this paper, we will analyze the code implementation and provide complete code, usage guidelines, and step-by-step demonstrations.

Keywords

Trajectory control; Continuous motion; Time series; Motion reproduction; AgileX PIPER

Code Repository

github link: https://github.com/agilexrobotics/Agilex-College.git

Function Demonstration

From Code → to Motion 🤖 The Magic of Robotic Arm

1. Preparation Before Use

1.1. Preparation Work

  • There are no obstacles in the workspace to provide sufficient movement space for the robotic arm.
  • Confirm that the power supply of the robotic arm is normal and all indicator lights are in a normal state.
  • The lighting conditions are good for the observation of the position and state of the robotic arm.
  • If equipped with a gripper, check whether the gripper actions are normal. The ground is stable to avoid vibration affecting the recording accuracy.
  • Verify that the teach button functions normally.

1.2. Environment Configuration

  • Operating system: Ubuntu (Ubuntu 18.04 or higher is recommended).
  • Python environment: Python 3.6 or higher.
  • Git code management tool: Used to clone remote code repositories.
    sudo apt install git
    
  • Pip package manager: Used to install Python dependency packages.
    sudo apt install python3-pip
    
  • Install CAN tools.
    sudo apt install can-utils ethtool
    
  • Install the official Python SDK package, among which 1_0_0_beta is the version with API.
    git clone -b 1_0_0_beta https://github.com/agilexrobotics/piper_sdk.git
    cd piper_sdk
    pip3 install .
    
  • Reference document: https://github.com/agilexrobotics/piper_sdk/blob/1_0_0_beta/README(ZH).MD

2. Operation Steps for Continuous Trajectory Recording and Replay Function

2.1. Operation Steps

  1. Power on the robotic arm and connect the USB-to-CAN module to the computer (ensure that only one CAN module is connected).

  2. Open the terminal and activate the CAN module.

    sudo ip link set can0 up type can bitrate 1000000
    
  3. Clone the remote code repository.

    git clone https://github.com/agilexrobotics/Agilex-College.git
    
  4. Switch to the recordAndPlayTraj directory.

    cd Agilex-College/piper/recordAndPlayTraj/
    
  5. Run the recording program.

    python3 recordTrajectory_en.py
    
  6. Short-press the teach button to enter the teaching mode.

  7. Set the initial position of the robotic arm. After pressing Enter in the terminal, drag the robotic arm to record the trajectory.

  8. After recording, short-press the teach button again to exit the teaching mode.

  9. Precautions before replay:
    When exiting the teaching mode for the first time, a specific initialization process is required to switch from the teaching mode to the CAN mode. Therefore, the replay program will automatically perform a reset operation to return joints 2, 3, and 5 to safe positions (zero points) to prevent the robotic arm from suddenly falling due to gravity and causing damage. In special cases, manual assistance may be needed to return joints 2, 3, and 5 to zero points.

  10. Run the replay program.

    python3 playTrajectory_en.py
    
  11. After successful enabling, press Enter in the terminal to play the trajectory.

2.2. Recording Techniques and Strategies

Motion Planning Strategies:

Before starting the recording, the trajectory to be recorded should be planned:

  1. Starting Position Selection:

    • Select a safe position of the robotic arm as the starting point.
    • Ensure that the starting position is convenient for initialization during subsequent replay.
    • Avoid choosing a position close to the joint limit.
  2. Trajectory Path Design:

    • Plan a smooth motion path to avoid sharp direction changes.
    • Consider the kinematic constraints of the robotic arm to avoid singular positions.
    • Reserve sufficient safety margins to prevent collisions.
  3. Speed Control:

    • Maintain a moderate movement speed to ensure both recording quality and avoid being too slow.
    • Appropriately slow down at key positions to improve accuracy.
    • Avoid sudden acceleration or deceleration.

3. Problems and Solutions

Problem 1: No Piper Class

image

Reason: The currently installed SDK is not the version with API.

Solution: Execute pip3 uninstall piper_sdk to uninstall the current SDK, and then install the 1_0_0_beta version of the SDK according to the method in 1.2. Environment Configuration.

Problem 2: The Robotic Arm Does Not Move, and the Terminal Outputs as Follows

Reason: The teach button was short-pressed during the program operation.

Solution: Check whether the indicator light of the teach button is off. If it is, re-run the program. If not, short-press the teach button to exit the teaching mode first and then run the program.

4. Implementation of Trajectory Recording Program

The trajectory recording program is the data collection module of the system, responsible for capturing the position information of the continuous joint movements of the robotic arm in the teaching mode.

4.1. Program Initialization and Configuration

4.1.1. Parameter Configuration Design

# Whether there is a gripper
have_gripper = True
# Maximum recording time in seconds (0 = unlimited, stop by terminating program)
record_time = 10.0
# Teach mode detection timeout in seconds
timeout = 10.0
# CSV file path for saving trajectory
CSV_path = os.path.join(os.path.dirname(__file__), "trajectory.csv")

Analysis of Configuration Parameters:

  • The have_gripper parameter is of boolean type, and True indicates the presence of a gripper.
  • The record_time parameter sets the maximum recording time. The default value is 10s, that is, it records a 10-second trajectory. When this parameter is set to 0, the system enters the infinite recording mode.
  • The timeout parameter sets the timeout for teaching mode detection. After starting the program, if the teaching mode is not entered within 10s, the program will exit.
  • The CSV_path parameter sets the save path of the trajectory file. By default, it is in the same path as the program, and the file name is trajectory.csv.

4.1.2. Robotic Arm Connection and Initialization

# Initialize and connect to robotic arm
piper = Piper("can0")
piper.connect()
interface = piper.init()
time.sleep(0.1)

Analysis of Connection Mechanism:

  • Piper() is the core class of the API, which simplifies some common methods based on the interface.
  • init() creates and returns an interface instance, which can be used to call some special methods of Piper.
  • connect() starts a thread to connect to the CAN port and process CAN data.
  • The addition of time.sleep(0.1) ensures that the connection is fully established. In embedded systems, hardware initialization usually takes a certain amount of time, and this short delay ensures the reliability of subsequent operations.

4.1.3. Position Acquisition and Data Storage

4.1.3.1. Position Acquisition Function
def get_pos():
    joint_state = piper.get_joint_states()[0]
    if have_gripper:
        '''Get current joint angles and gripper opening distance'''
        return joint_state + (piper.get_gripper_states()[0][0], )
    return joint_state
4.1.3.2. Position Change Detection
if current_pos != last_pos:  # Record only when position changes
    current_pos = get_pos()
    wait_time = round(time.time() - last_time, 4)
    print(f"INFO: Wait time: {wait_time:0.4f}s, current position: {current_pos}")
    last_pos = current_pos
    last_time = time.time()
    csv.write(f"{wait_time}," + ",".join(map(str, current_pos)) + "\n")

Position Processing:

  • current_pos != last_pos: When the robotic arm is stationary or the positions obtained in two consecutive times are the same, the position change processing can greatly reduce the recorded data.

Time Processing:

  • round(time.time() - last_time, 4):
    • A precision of 0.1 milliseconds is sufficient for robotic arm control.
    • Shortening the length of time can reduce the occupied storage space.

4.1.4. Mode Detection and Switching

print("step 1: Press teach button to enter teach mode")
while interface.GetArmStatus().arm_status.ctrl_mode != 2:
    over_time = time.time() + timeout
    if over_time < time.time():
        print("ERROR: Teach mode detection timeout. Please check if teach mode is enabled")
        exit()
    time.sleep(0.01)

Status Polling Strategy:
The program uses the polling method to detect the control mode. This method has the following characteristics:

  • Simple implementation and clear logic.
  • Low requirements for system resources.

Timeout Protection Mechanism:
The 10-second timeout setting takes into account the needs of actual operations:

  • Time for users to understand the prompt information.
  • Time to find and press the teach button.
  • Time for system response and state switching.
  • Fault-tolerance handling in abnormal situations.

Safety Features of Teaching Mode:

  • Joint torque is released, allowing manual operation.
  • Maintain position feedback and monitor position changes in real-time.

4.1.5. Data Storage

# ... Recording loop ...
csv.write(f"{wait_time}," + ",".join(map(str, current_pos)) + "\n")
# ... End of recording ...
csv = open(CSV_path, "w")
csv.close()

Data Integrity Guarantee:
After each recording, the data is immediately written to the file, and the buffer is refreshed to ensure that the data will not be lost due to abnormal program exit.

Data Format Selection:
Reasons for Choosing CSV Format for Data Storage:

  • High versatility. Almost all data processing tools support the CSV format.
  • Strong readability, facilitating debugging and verification.
  • Simple structure and high parsing efficiency.
  • Widely supported, facilitating integration with other tools.

Data Column Attributes:

  • Column 1: Time interval, unit: second.
  • Columns 2 - 7: Joint motor radians.
  • Column 8: Gripper opening distance, unit: m.

4.1.6. Recording Control Logic

over_time = last_time + record_time
while record_time == 0 or time.time() < over_time:
    csv = open(CSV_path, "w")
    input("step 2: Press Enter to start recording trajectory")
    last_pos = get_pos()
    last_time = time.time()
    # Recording logic
    time.sleep(0.01)
csv.close()

Time Control Strategy:
The system supports two recording modes:

  1. Timed recording: when record_time > 0, the recording stops automatically after the specified duration.
  2. Infinite recording: When record_time == 0, the program needs to be manually closed.

The flexibility of this design:

  • Adapting to the recording requirements of different-length trajectories.
  • Providing a safe automatic stop mechanism.
  • Supporting long-time continuous recording tasks.

4.1.7. Complete Code Implementation of Trajectory Recording Program

#!/usr/bin/env python3
# -*-coding:utf8-*-
# Record continuous trajectory
import os, time
from piper_sdk import *

if __name__ == "__main__":
    # Whether there is a gripper
    have_gripper = True
    # Maximum recording time in seconds (0 = unlimited, stop by terminating program)
    record_time = 10.0
    # Teach mode detection timeout in seconds
    timeout = 10.0
    # CSV file path for saving trajectory
    CSV_path = os.path.join(os.path.dirname(__file__), "trajectory.csv")

    # Initialize and connect to robotic arm
    piper = Piper("can0")
    interface = piper.init()
    piper.connect()
    time.sleep(0.1)

    def get_pos():
        joint_state = piper.get_joint_states()[0]
        if have_gripper:
            '''Get current joint angles and gripper opening distance'''
            return joint_state + (piper.get_gripper_states()[0][0], )
        return joint_state

    print("step 1: Press teach button to enter teach mode")
    over_time = time.time() + timeout
    while interface.GetArmStatus().arm_status.ctrl_mode != 2:
        if over_time < time.time():
            print("ERROR: Teach mode detection timeout. Please check if teach mode is enabled")
            exit()
        time.sleep(0.01)

    input("step 2: Press Enter to start recording trajectory")
    csv = open(CSV_path, "w")
    last_pos = get_pos()
    last_time = time.time()
    over_time = last_time + record_time

    while record_time == 0 or time.time() < over_time:
        current_pos = get_pos()
        if current_pos != last_pos:  # Record only when position changes
            wait_time = round(time.time() - last_time, 4)
            print(f"INFO: Wait time: {wait_time:0.4f}s, current position: {current_pos}")
            csv.write(f"{wait_time}," + ",".join(map(str, current_pos)) + "\n")
            last_pos = current_pos
            last_time = time.time()
        time.sleep(0.01)

    csv.close()
    print("INFO: Recording complete. Press teach button again to exit teach mode")

5. Implementation of Trajectory Replay Program

The trajectory replay program is the execution module of the system, responsible for reading recorded position data and controlling the robotic arm to reproduce these positions.

5.1. Parameter Configuration and Data Loading

Replay Parameter Configuration:

# replay times (0 means infinite loop)
play_times = 1
# replay interval in seconds
play_interval = 1.0
# Motion speed percentage (recommended range: 10-100)
move_spd_rate_ctrl = 100
# replay speed multiplier (recommended range: 0.1-2)
play_speed = 1.0

Play times control:
The play_times parameter supports three modes:

  • Single replay (play_times = 1): Suitable for demonstrations and testing.
  • Multiple replays (play_times > 1): Suitable for repetitive tasks.
  • Infinite loop (play_times = 0): Suitable for continuous production operations.

Dual Mechanism for Speed Control:
The system provides two speed control methods:

  1. move_spd_rate_ctrl: Controls the overall movement speed of the robotic arm.
  2. play_speed: Controls the time scaling of trajectory replay.

Advantages of this dual control:

  • Hardware-level speed control ensures safety.
  • Software-level time scaling provides flexibility.
  • The combination of both enables precise speed control.

Role of Play Interval:
The play_interval parameter plays an important role in continuous replay:

  • Provides recovery time for the system.
  • Facilitates observation and analysis of replay effects.
  • Can be used for rhythm control in production environments.

5.2. Data Loading: Reading Data Files

try:
    with open(CSV_path, 'r', encoding='utf-8') as f:
        track = list(csv.reader(f))
        if not track:
            print("ERROR: Trajectory file is empty")
            exit()
        track = [[float(j) for j in i] for i in track  # Convert to float lists
except FileNotFoundError:
    print("ERROR: Trajectory file not found")
    exit()

Exception Handling Strategy:
The program adopts a comprehensive exception handling mechanism to cover common file operation errors:

  • FileNotFoundError: Handles cases where the file does not exist.
  • Empty file check: Prevents reading empty data files.
  • Data format verification: Ensures data can be correctly converted to numerical types.

Data type conversion: The program uses list comprehensions to convert string data to floating-point numbers.

5.3. Safety Stop Function

def stop():
    '''Stop robotic arm; must call this function when first exiting teach mode before using CAN mode'''
    interface.EmergencyStop(0x01)
    time.sleep(1.0)
    limit_angle = [0.1745, 0.7854, 0.2094]  # Arm only restored when joints 2,3,5 are within safe range
    pos = get_pos()
    while not (abs(pos[1]) < limit_angle[0] and abs(pos[2]) < limit_angle[0] and pos[4] < limit_angle[1] and pos[4] > limit_angle[2]):
        # Restore arm
        piper.disable_arm()
        time.sleep(0.01)
        pos = get_pos()
    time.sleep(1.0)

Staged Stop Strategy:
The stop function adopts a phased safety stop strategy:

  1. Emergency stop phase: EmergencyStop(0x01) sends an emergency stop command to immediately halt all joint movements (joints with impedance).
  2. Safe position waiting: Waits for key joints (joints 2, 3, and 5) to move within the safe range.
  3. System recovery phase: Sends a recovery command to reactivate the control system.

Safety Range Design:
The program focuses on the positions of joints 2, 3, and 5 based on the mechanical structure characteristics of the PIPER robotic arm:

  • Joint 2 (shoulder joint): Controls the pitching movement of the upper arm, affecting overall stability.
  • Joint 3 (elbow joint): Controls the angle of the forearm, directly influencing the end position.
  • Joint 5 (wrist joint): Controls the end posture, affecting the gripper direction.

The safety angle ranges (10°, 45°, 12°) are set based on the following considerations:

  • Prevent the robotic arm from falling rapidly under gravity.
  • Ensure joints do not collide with mechanical limits.
  • Provide sufficient operating space for subsequent movements.

Real-time monitoring mechanism: The program uses real-time polling to monitor joint positions, ensuring the next operation is performed only when safety conditions are met.

5.4. System Enable Function

def enable():
    while not piper.enable_arm():
        time.sleep(0.01)
    if have_gripper:
        interface.ModeCtrl(0x01, 0x01, move_spd_rate_ctrl, 0x00)
        piper.enable_gripper()
        time.sleep(0.01)
    print("INFO: Enable successful")

Robotic Arm Enable: enable_arm()

Gripper Enable: enable_gripper()

Control Mode Settings:
Parameters for ModeCtrl(0x01, 0x01, move_spd_rate_ctrl, 0x00):

  • First parameter (0x01): Set to CAN command control mode.
  • Second parameter (0x01): Set to joint movement mode.
  • Third parameter (0 to 100): Set the movement speed percentage.
  • Fourth parameter (0x00): Set to position-speed mode.

5.5. Replay Control Logic

count = 0
while play_times == 0 or abs(play_times) != count:
    input("step 2: Press Enter to start trajectory replay")
    for n, pos in enumerate(track):
        piper.move_j(pos[1:-1], move_spd_rate_ctrl)
        if have_gripper and len(pos) == 8:
            piper.move_gripper(pos[-1], 1)
        print(f"INFO: replay #{count + 1}, wait time: {pos[0] / play_speed:0.4f}s, target position: {pos[1:]}")
        if n == len(track) - 1:
            time.sleep(play_interval)
        else:
            time.sleep(pos[0] / play_speed)
    count += 1

Joint Control: move_j()

  • First parameter: A tuple containing the radians of the six joint motors.
  • Second parameter: Movement speed percentage, ranging from 0 to 100.

Gripper Control: move_gripper()

  • First parameter: Gripper opening distance in meters.
  • Second parameter: Gripper torque in N/m.

Replay Speed Adjustment Mechanism:
pos[0] / play_speed enables dynamic adjustment of trajectory replay speed:

  • play_speed > 1.0: Accelerated replay with shortened time intervals.
  • play_speed < 1.0: Decelerated replay with extended time intervals.
  • play_speed = 1.0: Replay at original speed.

Advantages of this implementation:

  • Maintains the relative time relationship of the trajectory.
  • Provides simple and intuitive speed control.
  • Eliminates the need to recalculate the entire trajectory.

5.6. Complete Code of the Trajectory Replay Program

#!/usr/bin/env python3
# -*-coding:utf8-*-
# Play continuous trajectory
import os, time, csv
from piper_sdk import *

if __name__ == "__main__":
    # Whether there is a gripper
    have_gripper = True
    # replay times (0 means infinite loop)
    play_times = 1
    # replay interval in seconds
    play_interval = 1.0
    # Motion speed percentage (recommended range: 10-100)
    move_spd_rate_ctrl = 100
    # replay speed multiplier (recommended range: 0.1-2)
    play_speed = 1.0
    # CAN mode switch timeout in seconds
    timeout = 5.0
    # CSV file path for saved trajectory
    CSV_path = os.path.join(os.path.dirname(__file__), "trajectory.csv")

    # Read trajectory file
    try:
        with open(CSV_path, 'r', encoding='utf-8') as f:
            track = list(csv.reader(f))
            if not track:
                print("ERROR: Trajectory file is empty")
                exit()
            track = [[float(j) for j in i] for i in track  # Convert to float lists
    except FileNotFoundError:
        print("ERROR: Trajectory file not found")
        exit()

    # Initialize and connect to robotic arm
    piper = Piper("can0")
    interface = piper.init()
    piper.connect()
    time.sleep(0.1)

    def get_pos():
        joint_state = piper.get_joint_states()[0]
        if have_gripper:
            '''Get current joint angles and gripper opening distance'''
            return joint_state + (piper.get_gripper_states()[0][0], )
        return joint_state

    def stop():
        '''Stop robotic arm; must call this function when first exiting teach mode before using CAN mode'''
        interface.EmergencyStop(0x01)
        time.sleep(1.0)
        limit_angle = [0.1745, 0.7854, 0.2094]  # Arm only restored when joints 2,3,5 are within safe range
        pos = get_pos()
        while not (abs(pos[1]) < limit_angle[0] and abs(pos[2]) < limit_angle[0] and pos[4] < limit_angle[1] and pos[4] > limit_angle[2]):
            time.sleep(0.01)
            pos = get_pos()
        # Restore arm
        piper.disable_arm()
        time.sleep(1.0)

    def enable():
        while not piper.enable_arm():
            time.sleep(0.01)
        if have_gripper:
            interface.ModeCtrl(0x01, 0x01, move_spd_rate_ctrl, 0x00)
            piper.enable_gripper()
            time.sleep(0.01)
        print("INFO: Enable successful")

    print("step 1: Ensure robotic arm has exited teach mode before replay")
    if interface.GetArmStatus().arm_status.ctrl_mode != 1:
        over_time = time.time() + timeout
        stop()  # Required when first exiting teach mode
        while interface.GetArmStatus().arm_status.ctrl_mode != 1:
            if over_time < time.time():
                print("ERROR: CAN mode switch failed. Please confirm teach mode is exited")
                exit()
            interface.ModeCtrl(0x01, 0x01, move_spd_rate_ctrl, 0x00)
            time.sleep(0.01)
    enable()

    count = 0
    input("step 2: Press Enter to start trajectory replay")
    while play_times == 0 or abs(play_times) != count:
        for n, pos in enumerate(track):
            piper.move_j(pos[1:-1], move_spd_rate_ctrl)
            if have_gripper and len(pos) == 8:
                piper.move_gripper(pos[-1], 1)
            print(f"INFO: replay #{count + 1}, wait time: {pos[0] / play_speed:0.4f}s, target position: {pos[1:]}")
            if n == len(track) - 1:
                time.sleep(play_interval)  # Final point delay
            else:
                time.sleep(pos[0] / play_speed)  # Point-to-point delay
        count += 1

6. Summary

Based on the AgileX PIPER robotic arm, the above has realized the continuous trajectory recording and replay functions. Through the application of Python SDK, the recording and repeated execution of the robotic arm’s trajectory can be achieved, providing strong technical support for teaching demonstrations and automated operations.

If you have any questions or feedback about this implementation, feel free to share in the comments. Let’s discuss and improve it together! You can also contact us directly at support@agilex.ai for further assistance.

Thanks,
AgileX Robotics

2 posts - 2 participants

Read full topic

by Agilex_Robotics on August 20, 2025 07:07 AM

August 19, 2025
Looking for beta testers: Video Recorder – a black box for your robots

Ever had to review an incident that happened in the field but you weren’t recording a bagfile when it happened? Recording, uploading, and reviewing video and other data from your robot is surprisingly tricky. We wanted to make that easier.

Video Recorder (beta)

We’ve just released a new Video Recorder capability for Transitive in beta. It continuously records defined video tracks in a rolling buffer from ROS topics, USB cameras, RTSP feeds, or GStreamer pipelines, uploads them to the cloud in segments, and makes them playable on the web through a calendar and embeddable video player component.

How you can control it

On the robot you can control via a ROS API:

  • When (not to) upload segments, e.g., only while docked,
  • Which segments to upload (incl. anything from the last 24 hours),
  • Pause recording entirely during known downtimes, e.g., at night.

On the web frontend, use a simple JavaScript API to query available recordings by date/time—ideal for embedding in your dashboards.

We’re looking for feedback on:

  • Reliability of segment recording, upload behavior, and interactions with other processes,
  • Usability of the calendar and web player UI for reviewing recordings, and
  • Critical features missing from the APIs (robot-side and frontend).

Want to help?

If you’d like to try it out:

  • Sign up for Transitive Robotics (if not already)—you get a $100 starting credit valid for 30 days and if you need more time, please DM me and we’ll gladly extend your trial if you are actively testing.
  • Install the Transitive agent and the capability on your robot and start recording!
  • Reach out with what’s working, what’s confusing, or what’s missing, either here or on our Slack.

Your early feedback will shape how this tool becomes something that can really help startups with their robot operations.

Looking forward to your insights, questions, and suggestions!

2 posts - 2 participants

Read full topic

by chfritz on August 19, 2025 11:35 PM

August 18, 2025
📢 Announcing CRISP: Closing the Gap Between ROS 2 and Robot Learning

Hi everyone,

In our lab we’ve been working on robot learning, in particular with Vision-Language-Action models (VLAs). To make it easier for the community to experiment with these methods on real robots, we decided to open source our package: CRISP :tada:

Our main contributions are:

  • Robot-agnostic, torque/effort-based ros2_controllers for manipulators.
  • A simple Python + Gymnasium interface to collect manipulation data and deploy learned policies.

We also provide detailed documentation so that both novice ROS 2 users and researchers can get started quickly. Our hope is to lower the entry barrier to robot learning and accelerate research in this domain!

:hammer_and_wrench: Features and Notes

  • Controllers

    • Includes an operational space controller and a Cartesian impedance controller with additional useful features.
    • Uses Pinocchio for URDF parsing and all rigid-body dynamics computations.
    • We provide dockerized demos to show how to start the controllers.
  • Integration with LeRobot

    • LeRobot provides a fantastic platform for training VLAs, but it does not directly integrate with ROS 2 robots (and maybe it shouldn’t).
    • We provide a Python + Gym interface on top of our controllers, with scripts to:
      • Record data in the LeRobot format
      • Train policies using LeRobot
      • Deploy trained policies on real robots
    • Our Python and Gym interface are how
    • For the interfaces, we use pixi and robostack. This makes it easier to integrate
  • Why not MoveIt?

    • MoveIt is a powerful framework, but it has a higher entry barrier to simply get a robot moving.
    • For VLAs, which act more like path planners, all that’s needed is to stream a target pose from vision inputs. No perception or motion planning stack is strictly required for quick experimentation.
  • Limitations

    • So far we’ve mainly tested on real robots.
    • We do not provide controllers for position/velocity-based control. But cartesian controllers should be compatible with our python-gym interface so integrating them should not be a problem.

:raising_hands: How You Can Get Involved

  • Try out the controllers on your manipulator with an effort-based interface.
  • Share your feedback, ideas, or videos of your experiments!

We’d love to hear your thoughts, suggestions, and experiences.

Cheers,
Daniel San José Pro | Learning Systems and Robotics Lab @ TUM

1 post - 1 participant

Read full topic

by danielsanjosepro on August 18, 2025 04:22 PM

Logging & Observability Review | Cloud Robotics WG Meeting 2025-08-25

Please come and join us for this coming meeting at Mon, Aug 25, 2025 4:00 PM UTCMon, Aug 25, 2025 5:00 PM UTC, where the group plans to review all of the research performed so far into Logging & Observability. After hosting guest speakers from Roboto AI, Heex Technologies, and Bagel, the group will review their findings so far and consider what to look into next. The research is intended for a community guide on Logging & Observability, written by the group.

Last meeting, guest speakers Arun Venkatadri and Shouheng Yi came to present Bagel, a new open source project that lets you chat with your robotics data by using AI to search through recorded data. If you’d like to see the meeting, the recording is available on YouTube.

The meeting link for next meeting is here, and you can sign up to our calendar or our Google Group for meeting notifications or keep an eye on the Cloud Robotics Hub.

Hopefully we will see you there!

1 post - 1 participant

Read full topic

by mikelikesrobots on August 18, 2025 03:18 PM

August 15, 2025
New packages for Humble Hawksbill 2025-08-15

Package Updates for Humble

Added Packages [128]:

  • ros-humble-adi-iio: 1.0.1-3
  • ros-humble-adi-iio-dbgsym: 1.0.1-3
  • ros-humble-as2-behaviors-swarm-flocking: 1.1.3-1
  • ros-humble-as2-behaviors-swarm-flocking-dbgsym: 1.1.3-1
  • ros-humble-autoware-adapi-adaptors: 1.4.0-1
  • ros-humble-autoware-adapi-adaptors-dbgsym: 1.4.0-1
  • ros-humble-autoware-adapi-specs: 1.4.0-1
  • ros-humble-autoware-behavior-velocity-planner: 1.4.0-1
  • ros-humble-autoware-behavior-velocity-planner-common: 1.4.0-1
  • ros-humble-autoware-behavior-velocity-planner-common-dbgsym: 1.4.0-1
  • ros-humble-autoware-behavior-velocity-planner-dbgsym: 1.4.0-1
  • ros-humble-autoware-behavior-velocity-stop-line-module: 1.4.0-1
  • ros-humble-autoware-behavior-velocity-stop-line-module-dbgsym: 1.4.0-1
  • ros-humble-autoware-component-interface-specs: 1.4.0-1
  • ros-humble-autoware-core: 1.4.0-1
  • ros-humble-autoware-core-api: 1.4.0-1
  • ros-humble-autoware-core-control: 1.4.0-1
  • ros-humble-autoware-core-localization: 1.4.0-1
  • ros-humble-autoware-core-map: 1.4.0-1
  • ros-humble-autoware-core-perception: 1.4.0-1
  • ros-humble-autoware-core-planning: 1.4.0-1
  • ros-humble-autoware-core-sensing: 1.4.0-1
  • ros-humble-autoware-core-vehicle: 1.4.0-1
  • ros-humble-autoware-crop-box-filter: 1.4.0-1
  • ros-humble-autoware-crop-box-filter-dbgsym: 1.4.0-1
  • ros-humble-autoware-default-adapi: 1.4.0-1
  • ros-humble-autoware-default-adapi-dbgsym: 1.4.0-1
  • ros-humble-autoware-downsample-filters: 1.4.0-1
  • ros-humble-autoware-downsample-filters-dbgsym: 1.4.0-1
  • ros-humble-autoware-ekf-localizer: 1.4.0-1
  • ros-humble-autoware-ekf-localizer-dbgsym: 1.4.0-1
  • ros-humble-autoware-euclidean-cluster-object-detector: 1.4.0-1
  • ros-humble-autoware-euclidean-cluster-object-detector-dbgsym: 1.4.0-1
  • ros-humble-autoware-geography-utils: 1.4.0-1
  • ros-humble-autoware-geography-utils-dbgsym: 1.4.0-1
  • ros-humble-autoware-global-parameter-loader: 1.4.0-1
  • ros-humble-autoware-gnss-poser: 1.4.0-1
  • ros-humble-autoware-gnss-poser-dbgsym: 1.4.0-1
  • ros-humble-autoware-ground-filter: 1.4.0-1
  • ros-humble-autoware-ground-filter-dbgsym: 1.4.0-1
  • ros-humble-autoware-gyro-odometer: 1.4.0-1
  • ros-humble-autoware-gyro-odometer-dbgsym: 1.4.0-1
  • ros-humble-autoware-interpolation: 1.4.0-1
  • ros-humble-autoware-interpolation-dbgsym: 1.4.0-1
  • ros-humble-autoware-kalman-filter: 1.4.0-1
  • ros-humble-autoware-kalman-filter-dbgsym: 1.4.0-1
  • ros-humble-autoware-lanelet2-map-visualizer: 1.4.0-1
  • ros-humble-autoware-lanelet2-map-visualizer-dbgsym: 1.4.0-1
  • ros-humble-autoware-lanelet2-utils: 1.4.0-1
  • ros-humble-autoware-lanelet2-utils-dbgsym: 1.4.0-1
  • ros-humble-autoware-localization-util: 1.4.0-1
  • ros-humble-autoware-localization-util-dbgsym: 1.4.0-1
  • ros-humble-autoware-map-height-fitter: 1.4.0-1
  • ros-humble-autoware-map-height-fitter-dbgsym: 1.4.0-1
  • ros-humble-autoware-map-loader: 1.4.0-1
  • ros-humble-autoware-map-loader-dbgsym: 1.4.0-1
  • ros-humble-autoware-map-projection-loader: 1.4.0-1
  • ros-humble-autoware-map-projection-loader-dbgsym: 1.4.0-1
  • ros-humble-autoware-marker-utils: 1.4.0-1
  • ros-humble-autoware-marker-utils-dbgsym: 1.4.0-1
  • ros-humble-autoware-mission-planner: 1.4.0-1
  • ros-humble-autoware-mission-planner-dbgsym: 1.4.0-1
  • ros-humble-autoware-motion-utils: 1.4.0-1
  • ros-humble-autoware-motion-utils-dbgsym: 1.4.0-1
  • ros-humble-autoware-motion-velocity-obstacle-stop-module: 1.4.0-1
  • ros-humble-autoware-motion-velocity-obstacle-stop-module-dbgsym: 1.4.0-1
  • ros-humble-autoware-motion-velocity-planner: 1.4.0-1
  • ros-humble-autoware-motion-velocity-planner-common: 1.4.0-1
  • ros-humble-autoware-motion-velocity-planner-common-dbgsym: 1.4.0-1
  • ros-humble-autoware-motion-velocity-planner-dbgsym: 1.4.0-1
  • ros-humble-autoware-ndt-scan-matcher: 1.4.0-1
  • ros-humble-autoware-ndt-scan-matcher-dbgsym: 1.4.0-1
  • ros-humble-autoware-node: 1.4.0-1
  • ros-humble-autoware-node-dbgsym: 1.4.0-1
  • ros-humble-autoware-object-recognition-utils: 1.4.0-1
  • ros-humble-autoware-object-recognition-utils-dbgsym: 1.4.0-1
  • ros-humble-autoware-objects-of-interest-marker-interface: 1.4.0-1
  • ros-humble-autoware-objects-of-interest-marker-interface-dbgsym: 1.4.0-1
  • ros-humble-autoware-osqp-interface: 1.4.0-1
  • ros-humble-autoware-osqp-interface-dbgsym: 1.4.0-1
  • ros-humble-autoware-path-generator: 1.4.0-1
  • ros-humble-autoware-path-generator-dbgsym: 1.4.0-1
  • ros-humble-autoware-perception-objects-converter: 1.4.0-1
  • ros-humble-autoware-perception-objects-converter-dbgsym: 1.4.0-1
  • ros-humble-autoware-planning-factor-interface: 1.4.0-1
  • ros-humble-autoware-planning-factor-interface-dbgsym: 1.4.0-1
  • ros-humble-autoware-planning-test-manager: 1.4.0-1
  • ros-humble-autoware-planning-test-manager-dbgsym: 1.4.0-1
  • ros-humble-autoware-planning-topic-converter: 1.4.0-1
  • ros-humble-autoware-planning-topic-converter-dbgsym: 1.4.0-1
  • ros-humble-autoware-point-types: 1.4.0-1
  • ros-humble-autoware-pose-initializer: 1.4.0-1
  • ros-humble-autoware-pose-initializer-dbgsym: 1.4.0-1
  • ros-humble-autoware-pyplot: 1.4.0-1
  • ros-humble-autoware-qp-interface: 1.4.0-1
  • ros-humble-autoware-qp-interface-dbgsym: 1.4.0-1
  • ros-humble-autoware-route-handler: 1.4.0-1
  • ros-humble-autoware-route-handler-dbgsym: 1.4.0-1
  • ros-humble-autoware-signal-processing: 1.4.0-1
  • ros-humble-autoware-signal-processing-dbgsym: 1.4.0-1
  • ros-humble-autoware-simple-pure-pursuit: 1.4.0-1
  • ros-humble-autoware-simple-pure-pursuit-dbgsym: 1.4.0-1
  • ros-humble-autoware-stop-filter: 1.4.0-1
  • ros-humble-autoware-stop-filter-dbgsym: 1.4.0-1
  • ros-humble-autoware-test-node: 1.4.0-1
  • ros-humble-autoware-test-node-dbgsym: 1.4.0-1
  • ros-humble-autoware-test-utils: 1.4.0-1
  • ros-humble-autoware-test-utils-dbgsym: 1.4.0-1
  • ros-humble-autoware-testing: 1.4.0-1
  • ros-humble-autoware-trajectory: 1.4.0-1
  • ros-humble-autoware-trajectory-dbgsym: 1.4.0-1
  • ros-humble-autoware-twist2accel: 1.4.0-1
  • ros-humble-autoware-twist2accel-dbgsym: 1.4.0-1
  • ros-humble-autoware-vehicle-info-utils: 1.4.0-1
  • ros-humble-autoware-vehicle-info-utils-dbgsym: 1.4.0-1
  • ros-humble-autoware-vehicle-velocity-converter: 1.4.0-1
  • ros-humble-autoware-vehicle-velocity-converter-dbgsym: 1.4.0-1
  • ros-humble-autoware-velocity-smoother: 1.4.0-1
  • ros-humble-autoware-velocity-smoother-dbgsym: 1.4.0-1
  • ros-humble-husarion-components-description: 0.0.2-1
  • ros-humble-robotraconteur-companion: 0.4.2-1
  • ros-humble-robotraconteur-companion-dbgsym: 0.4.2-1
  • ros-humble-ros2-control-cmake: 0.2.1-1
  • ros-humble-turtlebot3-home-service-challenge: 1.0.5-1
  • ros-humble-turtlebot3-home-service-challenge-core: 1.0.5-1
  • ros-humble-turtlebot3-home-service-challenge-manipulator: 1.0.5-1
  • ros-humble-turtlebot3-home-service-challenge-manipulator-dbgsym: 1.0.5-1
  • ros-humble-turtlebot3-home-service-challenge-tools: 1.0.5-1

Updated Packages [309]:

  • ros-humble-ackermann-steering-controller: 2.48.0-1 → 2.49.1-1
  • ros-humble-ackermann-steering-controller-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-admittance-controller: 2.48.0-1 → 2.49.1-1
  • ros-humble-admittance-controller-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-aerostack2: 1.1.2-2 → 1.1.3-1
  • ros-humble-apriltag: 3.4.3-1 → 3.4.4-1
  • ros-humble-apriltag-dbgsym: 3.4.3-1 → 3.4.4-1
  • ros-humble-apriltag-detector: 3.0.2-1 → 3.0.3-1
  • ros-humble-apriltag-detector-dbgsym: 3.0.2-1 → 3.0.3-1
  • ros-humble-apriltag-detector-mit: 3.0.2-1 → 3.0.3-1
  • ros-humble-apriltag-detector-mit-dbgsym: 3.0.2-1 → 3.0.3-1
  • ros-humble-apriltag-detector-umich: 3.0.2-1 → 3.0.3-1
  • ros-humble-apriltag-detector-umich-dbgsym: 3.0.2-1 → 3.0.3-1
  • ros-humble-apriltag-draw: 3.0.2-1 → 3.0.3-1
  • ros-humble-apriltag-draw-dbgsym: 3.0.2-1 → 3.0.3-1
  • ros-humble-apriltag-tools: 3.0.2-1 → 3.0.3-1
  • ros-humble-apriltag-tools-dbgsym: 3.0.2-1 → 3.0.3-1
  • ros-humble-as2-alphanumeric-viewer: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-alphanumeric-viewer-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behavior: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behavior-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behavior-tree: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behavior-tree-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behaviors-motion: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behaviors-motion-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behaviors-path-planning: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behaviors-path-planning-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behaviors-perception: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behaviors-perception-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behaviors-platform: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behaviors-platform-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behaviors-trajectory-generation: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-behaviors-trajectory-generation-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-cli: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-core: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-core-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-external-object-to-tf: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-external-object-to-tf-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-gazebo-assets: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-gazebo-assets-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-geozones: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-geozones-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-keyboard-teleoperation: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-map-server: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-map-server-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-motion-controller: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-motion-controller-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-motion-reference-handlers: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-msgs: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-msgs-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-platform-gazebo: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-platform-gazebo-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-platform-multirotor-simulator: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-platform-multirotor-simulator-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-python-api: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-realsense-interface: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-realsense-interface-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-rviz-plugins: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-rviz-plugins-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-state-estimator: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-state-estimator-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-usb-camera-interface: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-usb-camera-interface-dbgsym: 1.1.2-2 → 1.1.3-1
  • ros-humble-as2-visualization: 1.1.2-2 → 1.1.3-1
  • ros-humble-autoware-adapi-v1-msgs: 1.3.0-1 → 1.9.0-1
  • ros-humble-autoware-adapi-v1-msgs-dbgsym: 1.3.0-1 → 1.9.0-1
  • ros-humble-autoware-adapi-version-msgs: 1.3.0-1 → 1.9.0-1
  • ros-humble-autoware-adapi-version-msgs-dbgsym: 1.3.0-1 → 1.9.0-1
  • ros-humble-autoware-internal-debug-msgs: 1.10.0-1 → 1.12.0-1
  • ros-humble-autoware-internal-debug-msgs-dbgsym: 1.10.0-1 → 1.12.0-1
  • ros-humble-autoware-internal-localization-msgs: 1.10.0-1 → 1.12.0-1
  • ros-humble-autoware-internal-localization-msgs-dbgsym: 1.10.0-1 → 1.12.0-1
  • ros-humble-autoware-internal-metric-msgs: 1.10.0-1 → 1.12.0-1
  • ros-humble-autoware-internal-metric-msgs-dbgsym: 1.10.0-1 → 1.12.0-1
  • ros-humble-autoware-internal-msgs: 1.10.0-1 → 1.12.0-1
  • ros-humble-autoware-internal-msgs-dbgsym: 1.10.0-1 → 1.12.0-1
  • ros-humble-autoware-internal-perception-msgs: 1.10.0-1 → 1.12.0-1
  • ros-humble-autoware-internal-perception-msgs-dbgsym: 1.10.0-1 → 1.12.0-1
  • ros-humble-autoware-internal-planning-msgs: 1.10.0-1 → 1.12.0-1
  • ros-humble-autoware-internal-planning-msgs-dbgsym: 1.10.0-1 → 1.12.0-1
  • ros-humble-autoware-lanelet2-extension: 0.7.2-1 → 0.8.0-1
  • ros-humble-autoware-lanelet2-extension-dbgsym: 0.7.2-1 → 0.8.0-1
  • ros-humble-autoware-lanelet2-extension-python: 0.7.2-1 → 0.8.0-1
  • ros-humble-autoware-lanelet2-extension-python-dbgsym: 0.7.2-1 → 0.8.0-1
  • ros-humble-axis-camera: 2.0.3-1 → 2.0.4-1
  • ros-humble-axis-description: 2.0.3-1 → 2.0.4-1
  • ros-humble-axis-msgs: 2.0.3-1 → 2.0.4-1
  • ros-humble-axis-msgs-dbgsym: 2.0.3-1 → 2.0.4-1
  • ros-humble-bicycle-steering-controller: 2.48.0-1 → 2.49.1-1
  • ros-humble-bicycle-steering-controller-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-clearpath-common: 1.3.3-1 → 1.3.5-1
  • ros-humble-clearpath-config: 1.3.1-1 → 1.3.2-1
  • ros-humble-clearpath-control: 1.3.3-1 → 1.3.5-1
  • ros-humble-clearpath-customization: 1.3.3-1 → 1.3.5-1
  • ros-humble-clearpath-description: 1.3.3-1 → 1.3.5-1
  • ros-humble-clearpath-generator-common: 1.3.3-1 → 1.3.5-1
  • ros-humble-clearpath-generator-common-dbgsym: 1.3.3-1 → 1.3.5-1
  • ros-humble-clearpath-manipulators: 1.3.3-1 → 1.3.5-1
  • ros-humble-clearpath-manipulators-description: 1.3.3-1 → 1.3.5-1
  • ros-humble-clearpath-mounts-description: 1.3.3-1 → 1.3.5-1
  • ros-humble-clearpath-platform-description: 1.3.3-1 → 1.3.5-1
  • ros-humble-clearpath-ros2-socketcan-interface: 1.0.2-1 → 1.0.3-1
  • ros-humble-clearpath-ros2-socketcan-interface-dbgsym: 1.0.2-1 → 1.0.3-1
  • ros-humble-clearpath-sensors-description: 1.3.3-1 → 1.3.5-1
  • ros-humble-diff-drive-controller: 2.48.0-1 → 2.49.1-1
  • ros-humble-diff-drive-controller-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-dynamixel-hardware-interface: 1.4.9-1 → 1.4.11-1
  • ros-humble-dynamixel-hardware-interface-dbgsym: 1.4.9-1 → 1.4.11-1
  • ros-humble-effort-controllers: 2.48.0-1 → 2.49.1-1
  • ros-humble-effort-controllers-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-etsi-its-cam-coding: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cam-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cam-conversion: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cam-msgs: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cam-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cam-ts-coding: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cam-ts-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cam-ts-conversion: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cam-ts-msgs: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cam-ts-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-coding: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-conversion: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-conversion-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cpm-ts-coding: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cpm-ts-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cpm-ts-conversion: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cpm-ts-msgs: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-cpm-ts-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-denm-coding: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-denm-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-denm-conversion: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-denm-msgs: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-denm-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-denm-ts-coding: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-denm-ts-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-denm-ts-conversion: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-denm-ts-msgs: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-denm-ts-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-mapem-ts-coding: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-mapem-ts-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-mapem-ts-conversion: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-mapem-ts-msgs: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-mapem-ts-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-mcm-uulm-coding: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-mcm-uulm-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-mcm-uulm-conversion: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-mcm-uulm-msgs: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-mcm-uulm-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-messages: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-msgs: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-msgs-utils: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-primitives-conversion: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-rviz-plugins: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-rviz-plugins-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-spatem-ts-coding: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-spatem-ts-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-spatem-ts-conversion: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-spatem-ts-msgs: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-spatem-ts-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-vam-ts-coding: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-vam-ts-coding-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-vam-ts-conversion: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-vam-ts-msgs: 3.2.1-1 → 3.3.0-1
  • ros-humble-etsi-its-vam-ts-msgs-dbgsym: 3.2.1-1 → 3.3.0-1
  • ros-humble-event-camera-renderer: 2.0.0-1 → 2.0.1-1
  • ros-humble-event-camera-renderer-dbgsym: 2.0.0-1 → 2.0.1-1
  • ros-humble-examples-tf2-py: 0.25.15-1 → 0.25.16-1
  • ros-humble-filters: 2.2.1-1 → 2.2.2-1
  • ros-humble-filters-dbgsym: 2.2.1-1 → 2.2.2-1
  • ros-humble-force-torque-sensor-broadcaster: 2.48.0-1 → 2.49.1-1
  • ros-humble-force-torque-sensor-broadcaster-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-forward-command-controller: 2.48.0-1 → 2.49.1-1
  • ros-humble-forward-command-controller-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-franka-inria-inverse-dynamics-solver: 1.0.0-1 → 1.0.1-1
  • ros-humble-franka-inria-inverse-dynamics-solver-dbgsym: 1.0.0-1 → 1.0.1-1
  • ros-humble-geometry2: 0.25.15-1 → 0.25.16-1
  • ros-humble-gpio-controllers: 2.48.0-1 → 2.49.1-1
  • ros-humble-gpio-controllers-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-gripper-controllers: 2.48.0-1 → 2.49.1-1
  • ros-humble-gripper-controllers-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-hebi-cpp-api: 3.12.3-1 → 3.13.0-1
  • ros-humble-hebi-cpp-api-dbgsym: 3.12.3-1 → 3.13.0-1
  • ros-humble-imu-sensor-broadcaster: 2.48.0-1 → 2.49.1-1
  • ros-humble-imu-sensor-broadcaster-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-inverse-dynamics-solver: 1.0.0-1 → 1.0.1-1
  • ros-humble-inverse-dynamics-solver-dbgsym: 1.0.0-1 → 1.0.1-1
  • ros-humble-joint-state-broadcaster: 2.48.0-1 → 2.49.1-1
  • ros-humble-joint-state-broadcaster-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-joint-trajectory-controller: 2.48.0-1 → 2.49.1-1
  • ros-humble-joint-trajectory-controller-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-kdl-inverse-dynamics-solver: 1.0.0-1 → 1.0.1-1
  • ros-humble-kdl-inverse-dynamics-solver-dbgsym: 1.0.0-1 → 1.0.1-1
  • ros-humble-libcaer-driver: 1.5.1-1 → 1.5.2-1
  • ros-humble-libcaer-driver-dbgsym: 1.5.1-1 → 1.5.2-1
  • ros-humble-librealsense2: 2.55.1-1 → 2.56.4-1
  • ros-humble-librealsense2-dbgsym: 2.55.1-1 → 2.56.4-1
  • ros-humble-mecanum-drive-controller: 2.48.0-1 → 2.49.1-1
  • ros-humble-mecanum-drive-controller-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-mola-test-datasets: 0.4.1-1 → 0.4.2-1
  • ros-humble-mrpt-map-server: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-map-server-dbgsym: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-msgs-bridge: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-nav-interfaces: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-nav-interfaces-dbgsym: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-navigation: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-path-planning: 0.2.1-1 → 0.2.2-1
  • ros-humble-mrpt-path-planning-dbgsym: 0.2.1-1 → 0.2.2-1
  • ros-humble-mrpt-pf-localization: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-pf-localization-dbgsym: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-pointcloud-pipeline: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-pointcloud-pipeline-dbgsym: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-rawlog: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-rawlog-dbgsym: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-reactivenav2d: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-reactivenav2d-dbgsym: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-tps-astar-planner: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-tps-astar-planner-dbgsym: 2.2.0-1 → 2.2.3-1
  • ros-humble-mrpt-tutorials: 2.2.0-1 → 2.2.3-1
  • ros-humble-ntrip-client-node: 0.5.7-1 → 0.6.1-1
  • ros-humble-ntrip-client-node-dbgsym: 0.5.7-1 → 0.6.1-1
  • ros-humble-pid-controller: 2.48.0-1 → 2.49.1-1
  • ros-humble-pid-controller-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-plotjuggler: 3.10.10-1 → 3.10.11-1
  • ros-humble-plotjuggler-dbgsym: 3.10.10-1 → 3.10.11-1
  • ros-humble-pose-broadcaster: 2.48.0-1 → 2.49.1-1
  • ros-humble-pose-broadcaster-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-position-controllers: 2.48.0-1 → 2.49.1-1
  • ros-humble-position-controllers-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-range-sensor-broadcaster: 2.48.0-1 → 2.49.1-1
  • ros-humble-range-sensor-broadcaster-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-rc-genicam-api: 2.6.5-1 → 2.8.1-1
  • ros-humble-rc-genicam-api-dbgsym: 2.6.5-1 → 2.8.1-1
  • ros-humble-rc-genicam-driver: 0.3.1-1 → 0.3.2-1
  • ros-humble-rc-genicam-driver-dbgsym: 0.3.1-1 → 0.3.2-1
  • ros-humble-rc-reason-clients: 0.4.0-2 → 0.5.0-1
  • ros-humble-rc-reason-msgs: 0.4.0-2 → 0.5.0-1
  • ros-humble-rc-reason-msgs-dbgsym: 0.4.0-2 → 0.5.0-1
  • ros-humble-realsense2-camera: 4.55.1-1 → 4.56.4-2
  • ros-humble-realsense2-camera-dbgsym: 4.55.1-1 → 4.56.4-2
  • ros-humble-realsense2-camera-msgs: 4.55.1-1 → 4.56.4-2
  • ros-humble-realsense2-camera-msgs-dbgsym: 4.55.1-1 → 4.56.4-2
  • ros-humble-realsense2-description: 4.55.1-1 → 4.56.4-2
  • ros-humble-robotraconteur: 1.2.2-1 → 1.2.5-1
  • ros-humble-robotraconteur-dbgsym: 1.2.2-1 → 1.2.5-1
  • ros-humble-ros2-controllers: 2.48.0-1 → 2.49.1-1
  • ros-humble-ros2-controllers-test-nodes: 2.48.0-1 → 2.49.1-1
  • ros-humble-rqt-joint-trajectory-controller: 2.48.0-1 → 2.49.1-1
  • ros-humble-rqt-robot-steering: 1.0.2-1 → 1.0.3-1
  • ros-humble-steering-controllers-library: 2.48.0-1 → 2.49.1-1
  • ros-humble-steering-controllers-library-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-swri-cli-tools: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-console-util: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-console-util-dbgsym: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-dbw-interface: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-geometry-util: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-geometry-util-dbgsym: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-image-util: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-image-util-dbgsym: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-math-util: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-math-util-dbgsym: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-opencv-util: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-opencv-util-dbgsym: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-roscpp: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-roscpp-dbgsym: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-route-util: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-route-util-dbgsym: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-serial-util: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-serial-util-dbgsym: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-transform-util: 3.8.5-1 → 3.8.7-1
  • ros-humble-swri-transform-util-dbgsym: 3.8.5-1 → 3.8.7-1
  • ros-humble-tf2: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-bullet: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-dbgsym: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-eigen: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-eigen-kdl: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-eigen-kdl-dbgsym: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-geometry-msgs: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-kdl: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-msgs: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-msgs-dbgsym: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-py: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-py-dbgsym: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-ros: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-ros-dbgsym: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-ros-py: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-sensor-msgs: 0.25.15-1 → 0.25.16-1
  • ros-humble-tf2-tools: 0.25.15-1 → 0.25.16-1
  • ros-humble-tricycle-controller: 2.48.0-1 → 2.49.1-1
  • ros-humble-tricycle-controller-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-tricycle-steering-controller: 2.48.0-1 → 2.49.1-1
  • ros-humble-tricycle-steering-controller-dbgsym: 2.48.0-1 → 2.49.1-1
  • ros-humble-turtlebot3-home-service-challenge-aruco: 1.0.4-1 → 1.0.5-1
  • ros-humble-ublox-dgnss: 0.5.7-1 → 0.6.1-1
  • ros-humble-ublox-dgnss-node: 0.5.7-1 → 0.6.1-1
  • ros-humble-ublox-dgnss-node-dbgsym: 0.5.7-1 → 0.6.1-1
  • ros-humble-ublox-nav-sat-fix-hp-node: 0.5.7-1 → 0.6.1-1
  • ros-humble-ublox-nav-sat-fix-hp-node-dbgsym: 0.5.7-1 → 0.6.1-1
  • ros-humble-ublox-ubx-interfaces: 0.5.7-1 → 0.6.1-1
  • ros-humble-ublox-ubx-interfaces-dbgsym: 0.5.7-1 → 0.6.1-1
  • ros-humble-ublox-ubx-msgs: 0.5.7-1 → 0.6.1-1
  • ros-humble-ublox-ubx-msgs-dbgsym: 0.5.7-1 → 0.6.1-1
  • ros-humble-ur-client-library: 2.1.0-1 → 2.2.0-1
  • ros-humble-ur-client-library-dbgsym: 2.1.0-1 → 2.2.0-1
  • ros-humble-ur-msgs: 2.2.0-1 → 2.3.0-1
  • ros-humble-ur-msgs-dbgsym: 2.2.0-1 → 2.3.0-1
  • ros-humble-ur10-inverse-dynamics-solver: 1.0.0-1 → 1.0.1-1
  • ros-humble-ur10-inverse-dynamics-solver-dbgsym: 1.0.0-1 → 1.0.1-1
  • ros-humble-velocity-controllers: 2.48.0-1 → 2.49.1-1
  • ros-humble-velocity-controllers-dbgsym: 2.48.0-1 → 2.49.1-1

Removed Packages [0]:

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:

  • Adam Dabrowski
  • Analog Devices
  • Autoware
  • Bence Magyar
  • Berkay Karaman
  • Bernd Pfrommer
  • CVAR-UPM
  • Chris Bollinger
  • Chris Iverach-Brereton
  • Chris Lalancette
  • David Wong
  • Davide Faconti
  • Dirk Thomas
  • Enrico Ferrentino
  • Felix Exner
  • Felix Ruess
  • Fumiya Watanabe
  • G.A. vd. Hoorn
  • Geoff Sokoll
  • Husarion
  • Jean-Pierre Busch
  • John Wason
  • José Luis Blanco-Claraco
  • Kosuke Takeuchi
  • Kyoichi Sugahara
  • LibRealSense ROS Team
  • Luis Camero
  • M. Fatih Cırıt
  • Mamoru Sobue
  • Markus Bader
  • Max Krogius
  • Maxime CLEMENT
  • Maxime Clement
  • Mete Fatih Cırıt
  • Nick Hortovanyi
  • Pyo
  • Ryohsuke Mitsudome
  • Ryu Yamamoto
  • Satoshi OTA
  • Satoshi Ota
  • Southwest Research Institute
  • Taiki Tanaka
  • Takagi, Isamu
  • Takamasa Horibe
  • Takayuki Murooka
  • Temkei Kem
  • Tomoya Kimura
  • Tully Foote
  • Xingang Liu
  • Yamato Ando
  • Yoshi Ri
  • Yuki Takagi
  • Yukihiro Saito
  • Yukinari Hisaki
  • amc-nu
  • mitsudome-r
  • pyo
  • ruess

1 post - 1 participant

Read full topic

by audrow on August 15, 2025 09:09 PM

UBLOX ZED-X20P Integration Complete - 25Hz NavSatFix

I’ve completed initial UBLOX ZED-X20P integration in the ublox_dgnss package with 25Hz NavSatFix output.

Quick Start

ros2 launch ublox_dgnss ublox_x20p_rover_hpposllh_navsatfix.launch.py -- device_family:=x20p

What’s New

  • 25Hz NavSatFix output - significant performance boost
  • Multi-device support - F9P/F9R/X20P automatic detection
  • USB architecture adaptation - handles X20P’s different interface structure
  • Backward compatible - existing F9P/F9R setups unchanged

Available Now

Available now on GitHub for local compilation:

Architecture Notes

X20P main interface (0x01ab) fully supported with F9P/F9R compatibility.

UART interfaces (0x050c/0x050d) under investigation - see X20P UART1/UART2 interfaces (0x050c/0x050d) not supported - use main interface (0x01ab) · Issue #48 · aussierobots/ublox_dgnss · GitHub.

Have an X20P?

If you want to test it out and give us feedback, it would be appreciated!

3 posts - 2 participants

Read full topic

by horto on August 15, 2025 07:19 AM

August 13, 2025
RMW-RMW bridge - is it possible, has anyone done it?

We’re more and more thinking that there should be a RMW-RMW bridge for ROS 2.

Our specific use-case is simple - a microcontroller with MicroROS (thus FastDDS) and the rest would be better with Zenoh RMW. But we can’t use Zenoh in the rest of the system because DDS and Zenoh don’t talk to each other.

I know (or guess) that between DDS-based RMWs, there is the possibility to interoperate on the DDS level (through it’s incomplete for some combinations AFAIU).

But if you need to connect a non-DDS RMW, there’s currently no option.

I haven’t dived into RMW details too much yet, but I guess in principle, creating such bridge at the RMW level should be possible, right?

Has anyone tried that? Is it achievable to create something that is “RMW-agnostic”, meaning one generic bridge for any pair (or n-tuple) of RMWs to connect?

Of course, such solution would hinder performance (all messages would have to be brokered by the bridge), but in our case, we only have a uC feeding one IMU stream, odometry, some state and diagnostics, and receieving only cmd_vel and a few other commands. So performance should not be a problem at least in these simpler cases.

6 posts - 5 participants

Read full topic

by peci1 on August 13, 2025 09:27 PM

Bagel's New Release -- Cursor Integration

We are thrilled to announce a new integration for our open-source tool, Bagel! Two weeks ago, we presented Bagel at the ROS/PX4 meetup in Los Angeles, and the community’s excitement was incredible. As promised, we’ve integrated Bagel with the Cursor IDE to make robotics development even easier.

You can find the full tutorial here: bagel/doc/tutorials/mcp/2_cursor_px4.ipynb at stage · Extelligence-ai/bagel · GitHub

What is Bagel?

If you’re new to Bagel, it’s a tool that lets you chat with your rosbags using natural language queries. This allows you to quickly get insights from your log files without writing code. For example, you can ask questions like:

  • “Is the front left camera calibrated?”

  • “Were there any hard decelerations detected in the IMU data?”

  • “Are there any errors or warnings in this log?”

Bagel currently was tested in:

  • Claude Code
  • Gemini CLI
  • Cursor
  • and more integrations to come…

How to Get Involved

Bagel is a community-driven project, and we’d love for you to be a part of it. Your contributions are what will make this tool truly great.

Here are a few ways you can help:

  • Star us on GitHub: Show your support and help us grow by giving us a star.

  • File a bug report: If you find an issue, let us know so we can fix it.

  • Pitch a feature request: Have an idea for a new feature? We’d love to hear it.

  • Join us on Discord: Hang out with the community and chat directly with the Bagel team.

Many people have done so! The community found two bugs and filed two feature requests already!

Thank you for your support!

1 post - 1 participant

Read full topic

by shouheng on August 13, 2025 06:09 PM

Localization of ROS 2 Documentation

Hello, Open Robotics Community,

I’m glad to announce that the :tada: ros2-docs-l10n :tada: project is published now:

The goal of this project is to translate the ROS 2 documentation into multiple languages. Translations are contributed via the Crowdin platform and automatically synchronized with the GitHub repository. Translations can be previewed on GitHub Pages.

22 posts - 5 participants

Read full topic

by hwhsu1231 on August 13, 2025 02:44 PM

Open-sourcing ROS 1 code from RUVU (AMCL reimplementation, planners, controllers and more)

Hey everyone,

As part of the acqui-hire of our startup RUVU, we’re open-sourcing a large portion of the ROS 1 code we’ve built over the years.

While it’s all written for ROS 1 so not immediately plug-and-play for ROS 2 users, we hope some of it might still be useful, inspirational, or a good starting point for your own projects.

Some highlights:

Everything is released under the MIT license, so feel free to fork, adapt, and use anything you find interesting.

We’re not planning on actively maintaining this code right now, but that could change if there’s enough community interest.

If you have questions, ideas, or want to discuss this code, you can reach me here or at my current role at Nobleo Technology.

— The (old) RUVU Team

1 post - 1 participant

Read full topic

by Rayman on August 13, 2025 12:30 PM

August 12, 2025
Fixed Position Recording and Replay for AgileX PIPER Robotic Arm

We recently implemented a fixed position recording and replay function for the AgileX PIPER robotic arm using the official Python SDK. This feature allows recording specific arm positions and replaying them repeatedly, which is useful for teaching demonstrations and automated operations.

In this post, I will share the detailed setup steps, code implementation, usage instructions, and a demonstration video to help you get started.

Tags

Position recording, Python SDK, teaching demonstration, position reproduction, AgileX PIPER

Code Repository

GitHub link: https://github.com/agilexrobotics/Agilex-College.git

Function Demonstration

PIPER Robotic Arm | Fixed Position Recording & Replay Demo

Preparation Before Use

Hardware Preparation for PIPER Robotic Arm

  • There are no obstacles in the workspace to provide sufficient movement space for the robotic arm.
  • Confirm that the power supply of the robotic arm is normal and all indicator lights are in the normal state.
  • The lighting conditions are good for observation of the position and state of the robotic arm.
  • If equipped with a gripper, check whether the gripper actions are normal.
  • The ground is stable to avoid vibration affecting recording accuracy.
  • The teach button functions normally.

Environment Configuration

  • Operating system: Ubuntu (Ubuntu 18.04 or higher is recommended)
  • Python environment: Python 3.6 or higher
  • git code management tool: used to clone remote code repositories
sudo apt install git
  • pip package manager: used to install Python dependency packages
sudo apt install python3-pip
  • Install CAN tools
sudo apt install can-utils ethtool
  • Install the official Python SDK package, among which1_0_0_betais the version with API
git clone -b 1_0_0_beta https://github.com/agilexrobotics/piper_sdk.git
cd piper_sdk
pip3 install .

Operation Steps for Fixed Position Recording and Replay Function

  1. Power on the robotic arm and connect the USB-to-CAN module to the computer (ensure that only one CAN module is connected)
  2. Open the terminal and activate the CAN module

sudo ip link set can0 up type can bitrate 1000000

  1. Clone the remote code repository

git clone https://github.com/agilexrobotics/Agilex-College.git

  1. Switch to therecordAndPlayPosdirectory

cd Agilex-College/piper/recordAndPlayPos/

  1. Run the recording program

python3 recordPos_en.py

  1. Short-press the teach button to enter the teaching mode

  2. Place the position of the robotic arm well, press Enter in the terminal to record the position, and input ‘q’ to end the recording.

  3. After recording, short-press the teach button again to exit the teaching mode

  1. Notes before replay: When exiting the teaching mode for the first time, a specific initialization process is required to switch from the teaching mode to the CAN mode. Therefore, the replay program will automatically perform a reset operation to return joints 2, 3, and 5 to safe positions (zero points) to prevent the robotic arm from suddenly falling due to gravity and causing damage. In special cases, manual assistance may be required to return joints 2, 3, and 5 to zero points.
  2. Run the replay program

python3 playPos_en.py

  1. After successful enabling, press Enter in the terminal to play the positions

Problems and Solutions

Problem 1: There is no Piper class.

image

Reason: The currently installed SDK is not the version with API.

Solution: Execute pip3 uninstall piper_sdkto uninstall the current SDK, then install the 1_0_0_beta version of the SDK according to the method in 1.2. Environment Configuration.

Problem 2: The robotic arm does not move, and the terminal outputs as follows.

Reason: The teach button was short-pressed during the operation of the program.

Solution: Check whether the indicator light of the teach button is off. If yes, re-run the program; if not, short-press the teach button to exit the teaching mode first and then run the program.

Code/Principle and Parameter Description

Implementation of Position Recording Program

The position recording program is the data collection module of the system, which is responsible for capturing the joint position information of the robotic arm in the teaching mode.

Program Initialization and Configuration

Parameter Configuration Design

#  Whether there is a gripper
have_gripper = True
# Timeout for teaching mode detection, unit: second
timeout = 10.0
# CSV file path for saving positions
CSV_path = os.path.join(os.path.dirname(__file__), "pos.csv")

Analysis of configuration parameters:

Thehave_gripperparameter is of boolean type, and True means there is a gripper.

Thetimeoutparameter sets the timeout for teaching mode detection. After starting the program, if the teaching mode is not entered within 10s, the program will exit.

TheCSV_pathparameter sets the save path of the trajectory file, which defaults to the same path as the program, and the file name is pos.csv

Robotic Arm Connection and Initialization

# Initialize and connect the robotic arm
piper = Piper("can0")
interface = piper.init()
piper.connect()
time.sleep(0.1)

Analysis of connection mechanism:

Piper()is the core class of the API, which simplifies some common methods on the basis of the interface.

init()will create and return an interface instance, which can be used to call some special methods of Piper.

connect()will start a thread to connect to the CAN port and process CAN data.

time.sleep(0.1)is added to ensure that the connection is fully established. In embedded systems, hardware initialization usually takes a certain amount of time, and this short delay ensures the reliability of subsequent operations.

Position Acquisition and Data Storage

Implementation of Position Acquisition Function

def get_pos():
    '''Get the current joint radians of the robotic arm and the gripper opening distance'''
    joint_state = piper.get_joint_states()[0]
    if have_gripper:
        return joint_state + (piper.get_gripper_states()[0][0], )
    return joint_state

Mode Detection and Switching

print("INFO: Please click the teach button to enter the teaching mode")
over_time = time.time() + timeout
while interface.GetArmStatus().arm_status.ctrl_mode != 2:
    if over_time < time.time():
        print("ERROR: Teaching mode detection timeout, please check whether the teaching mode is enabled")
        exit()
    time.sleep(0.01)

Status polling strategy
The program uses polling to detect the control mode, and this method has the following characteristics:

  • Simple implementation and clear logic
  • Low requirements on system resources

Timeout protection mechanism:
The 10-second timeout setting takes into account the needs of actual operations:

  • Time for users to understand prompt information
  • Time to find and press the teach button
  • Time for system response and state switching
  • Fault tolerance handling in abnormal situations

Safety features of teaching mode:

  • Joint torque is released, allowing manual operation
  • Maintain position feedback and monitor position changes in real time

Data Recording and Storage

count = 1
csv = open(CSV_path, "w")
while input("INPUT: Input q to exit, press Enter directly to record:") != "q":
    current_pos = get_pos()
    print(f"INFO: {count}th position, recorded position:  {current_pos}")
    csv.write(",".join(map(str, current_pos)) + "\n")
    count += 1
csv.close()
print("INFO: Recording ends, click the teach button again to exit the teaching mode")

Data integrity guarantee:
After each recording, the data is immediately written to the file and the buffer is refreshed to ensure that the data will not be lost due to abnormal exit of the program.

Data Format Selection
Reasons for choosing CSV format for data storage:

  • High versatility, almost all data processing tools support CSV format
  • Strong human readability, easy for debugging and verification
  • Simple structure and high parsing efficiency
  • Widely supported, easy to integrate with other tools

Data column attributes:

  • Columns 1-6: Joint motor radians
  • Column 7: Gripper opening distance, unit: m

Complete Code Implementation of Position Recording Program

#!/usr/bin/env python3
# -*-coding:utf8-*-
# Record positions
import os, time
from piper_sdk import *

if __name__ == "__main__":
    # Whether there is a gripper
    have_gripper = True
    # Timeout for teaching mode detection, unit: second
    timeout = 10.0
    # CSV file path for saving positions
    CSV_path = os.path.join(os.path.dirname(__file__), "pos.csv")
    # Initialize and connect the robotic arm
    piper = Piper("can0")
    interface = piper.init()
    piper.connect()
    time.sleep(0.1)

    def get_pos():
        '''Get the current joint radians of the robotic arm and the gripper opening distance'''
        joint_state = piper.get_joint_states()[0]
        if have_gripper:
            return joint_state + (piper.get_gripper_states()[0][0], )
        return joint_state
    
    print("INFO: Please click the teach button to enter the teaching mode")
    over_time = time.time() + timeout
    while interface.GetArmStatus().arm_status.ctrl_mode != 2:
        if over_time < time.time():
            print("ERROR:Teaching mode detection timeout, please check whether the teaching mode is enabled")
            exit()
        time.sleep(0.01)

    count = 1
    csv = open(CSV_path, "w")
    while input("INPUT: Enter q to exit, press Enter directly to record:  ") != "q":
        current_pos = get_pos()
        print(f"INFO:  {count}th position, recorded position: {current_pos}")
        csv.write(",".join(map(str, current_pos)) + "\n")
        count += 1
    csv.close()
    print("INFO: Recording ends, click the teach button again to exit the teaching mode")

Implementation of Position Replay Program

The position replay program is the execution module of the system, responsible for reading the recorded position data and controlling the robotic arm to reproduce these positions.

Parameter Configuration and Data Loading

replay Parameter Configuration

# Number of replays, 0 means infinite loop
play_times = 1
# replay interval, unit: second, negative value means manual key control
play_interval = 0
# Movement speed percentage, recommended range: 10-100
move_spd_rate_ctrl = 100

Analysis of parameter design:

Theplay_timesparameter supports three replay modes:

  • Single replay(play_times = 1):Suitable for demonstration and testing
  • Multiple replay (play_times > 1): Suitable for repetitive tasks
  • Infinite loop(play_times = 0): Suitable for continuous operations

The negative value design ofplay_intervalis an ingenious user interface design:

  • Positive value: Automatic replay mode, the system executes automatically at the set interval
  • Zero value: Continuous replay mode, no delay between positions
  • Negative value: Manual control mode, users control the replay rhythm through keys.

Themove_spd_rate_ctrlparameter provides a speed control function, which is very important for different application scenarios:

  • High-speed mode (80-100%): Suitable for no-load fast movement
  • Medium-speed mode (50-80%): Suitable for general operation tasks
  • Low-speed mode (10-50%): Suitable for precision operations and scenarios with high safety requirements

Data File Reading

try:
    with open(CSV_path, 'r', encoding='utf-8') as f:
        track = list(csv.reader(f))
        if not track:
            print("ERROR: The position file is empty")
            exit()
        track = [[float(j) for j in i] for i in track]    # Convert to a list of floating-point numbers
except FileNotFoundError:
    print("ERROR: The position file does not exist")
    exit()

Exception handling strategies:

  • FileNotFoundError:Handle the case where the file does not exist
  • Empty file check: Prevent reading empty data files
  • Data format verification: Ensure that the data can be correctly converted to numerical types

Data type conversion:
In the process of converting string data to floating-point numbers, the program uses list comprehensions.

Safety Stop Function

def stop():
    '''Stop the robotic arm; when exiting the teaching mode for the first time, this function must be called first to control the robotic arm in CAN mode'''
    interface.EmergencyStop(0x01)
    time.sleep(1.0)
    limit_angle = [0.1745, 0.7854, 0.2094]  # The robotic arm can be restored only when the angles of joints 2, 3, and 5 are within the limit range to prevent damage caused by falling from a large angle
    pos = get_pos()
    while not (abs(pos[1]) < limit_angle[0] and abs(pos[2]) < limit_angle[0] and pos[4] < limit_angle[1] and pos[4] > limit_angle[2]):
        time.sleep(0.01)
        pos = get_pos()
    # Restore the robotic arm
    piper.disable_arm()
    time.sleep(1.0)

Staged stop strategy:
The stop function adopts a staged safety stop strategy:

  1. Emergency stop stage: EmergencyStop(0x01) sends an emergency stop command to immediately stop all joint movements (joints with impedance)
  2. Safe position waiting: Wait for key joints (joints 2, 3, and 5) to move within the safe range
  3. System recovery stage: Send a recovery command to reactivate the control system

Safety range design:
The program pays special attention to the positions of joints 2, 3, and 5, which is based on the mechanical structure characteristics of the PIPER robotic arm:

  • Joint 2 (shoulder joint): Controls the pitching movement of the upper arm, affecting the overall stability
  • Joint 3 (elbow joint): Controls the angle of the forearm, directly affecting the end position
  • Joint 5 (wrist joint): Controls the end posture, affecting the direction of the gripper

The setting of the safe angle range (10°, 45°, 12°) is based on the following considerations:

  • Avoid the robotic arm from falling quickly under gravity
  • Ensure that the joints will not collide with mechanical limits
  • Provide sufficient operating space for subsequent movements

Real-time monitoring mechanism: The program uses real-time polling to monitor the joint positions to ensure that the next step is performed only when the safety conditions are met.

System Enable Function

def enable():
    '''Enable the robotic arm and gripper'''
    while not piper.enable_arm():
        time.sleep(0.01)
    if have_gripper:
        time.sleep(0.01)
        piper.enable_gripper()
    interface.ModeCtrl(0x01, 0x01, move_spd_rate_ctrl, 0x00)
    print("INFO: Enable successful")

Robotic arm enabling:enable_arm()

Gripper enabling:enable_gripper()

Control mode setting:
ModeCtrl(0x01, 0x01, move_spd_rate_ctrl, 0x00)Control mode parameters:

  • The first parameter (0x01): Set to CAN command control mode
  • The second parameter (0x01): Set to joint movement mode
  • The third parameter (0 to 100): Set the movement speed percentage
  • The fourth parameter (0x00): Set to position-speed mode

Replay Control Logic

count = 0
input("step 2: Press Enter to start playing positions")
while play_times == 0 or abs(play_times) != count:
    for n, pos in enumerate(track):
        while True:
            piper.move_j(pos[:-1], move_spd_rate_ctrl)
            time.sleep(0.01)
            current_pos = get_pos()
            print(f"INFO: {count + 1}th playback, {n + 1}th position, current position: {current_pos}, target position: {pos}")
            if all(abs(current_pos[i] - pos[i]) < 0.0698 for i in range(6)):
                break
        if have_gripper and len(pos) == 7:
            piper.move_gripper(pos[-1], 1)
            time.sleep(0.5)
        if play_interval < 0:
            if n != len(track) - 1 and input("Enter q to exit, press Enter directly to play:  ") == 'q':
                exit()
        else:
            time.sleep(play_interval)
    count += 1

Joint control: move_j()

  • The first parameter: A tuple containing the radians of the six joint motors
  • The second parameter: Movement speed percentage, range 0-100

Gripper control: move_gripper()

  • The first parameter: Gripper opening distance, unit: m
  • The second parameter: Gripper torque, unit: N/m

Position control closed-loop system:

  1. Target setting: Send target position commands to each joint through themove_j()function
  2. Status feedback: Obtain the current actual position through theget_pos()function
  3. Error calculation: Compare the difference between the target position and the actual position
  4. Convergence judgment: Consider reaching the target when the error is less than the threshold

Multi-joint coordinated control:
all(abs(current_pos[i] - pos[i]) < 0.0698 for i in range(6))ensures that the next step is performed only after all six joints reach the target position.

Gripper control strategy:
The gripper control adopts an independent control logic:

  • Execute gripper control only when the data contains gripper information
  • The gripper action is executed after the joint movement is completed to avoid interference
  • A 0.5-second delay ensures that the gripper action is fully completed

replay rhythm control:
The program supports three replay rhythms:

  • Automatic continuous replay: play_interval >= 0
  • Manual step-by-step replay: play_interval < 0
  • Real-time adjustment: Users can interrupt replay at any time

Complete Code Implementation of Position replay Program

#!/usr/bin/env python3
# -*-coding:utf8-*-
# Play positions
import os, time, csv
from piper_sdk import Piper

if __name__ == "__main__":
    # Whether there is a gripper
    have_gripper = True
    # Number of playbacks, 0 means infinite loop
    play_times = 1
    # Playback interval, unit: second; negative value means manual key control
    play_interval = 0
    # Movement speed percentage, recommended range: 10-100
    move_spd_rate_ctrl = 100
    # Timeout for switching to CAN mode, unit: second
    timeout = 5.0
    # CSV file path for saving positions
    CSV_path = os.path.join(os.path.dirname(__file__), "pos.csv")
    # Read the position file
    try:
        with open(CSV_path, 'r', encoding='utf-8') as f:
            track = list(csv.reader(f))
            if not track:
                print("ERROR: Position file is empty")
                exit()
            track = [[float(j) for j in i] for i in track]    # Convert to a list of floating-point numbers
    except FileNotFoundError:
        print("ERROR: Position file does not exist")
        exit()

    # Initialize and connect the robotic arm
    piper = Piper("can0")
    interface = piper.init()
    piper.connect()
    time.sleep(0.1)

    def get_pos():
        '''Get the current joint radians of the robotic arm and the gripper opening distance'''
        joint_state = piper.get_joint_states()[0]
        if have_gripper:
            return joint_state + (piper.get_gripper_states()[0][0], )
        return joint_state    

    def stop():
        '''Stop the robotic arm; this function must be called first when exiting the teaching mode for the first time to control the robotic arm in CAN mode'''
        interface.EmergencyStop(0x01)
        time.sleep(1.0)
        limit_angle = [0.1745, 0.7854, 0.2094]  # The robotic arm can be restored only when the radians of joints 2, 3, and 5 are within the limit range to prevent damage caused by falling from a large radian
        pos = get_pos()
        while not (abs(pos[1]) < limit_angle[0] and abs(pos[2]) < limit_angle[0] and pos[4] < limit_angle[1] and pos[4] > limit_angle[2]):
            time.sleep(0.01)
            pos = get_pos()
        # Restore the robotic arm
        piper.disable_arm()
        time.sleep(1.0)
    
    def enable():
        '''Enable the robotic arm and gripper'''
        while not piper.enable_arm():
            time.sleep(0.01)
        if have_gripper:
            time.sleep(0.01)
            piper.enable_gripper()
        interface.ModeCtrl(0x01, 0x01, move_spd_rate_ctrl, 0x00)
        print("INFO: Enable successful")

    print("step 1:  Please ensure the robotic arm has exited the teaching mode before playback")
    if interface.GetArmStatus().arm_status.ctrl_mode != 1:
        stop()  # This function must be called first when exiting the teaching mode for the first time to switch to CAN mode
    over_time = time.time() + timeout
    while interface.GetArmStatus().arm_status.ctrl_mode != 1:
        if over_time < time.time():
            print("ERROR: Failed to switch to CAN mode, please check if the teaching mode is exited")
            exit()
        interface.ModeCtrl(0x01, 0x01, move_spd_rate_ctrl, 0x00)
        time.sleep(0.01)
    
    enable()
    count = 0
    input("step 2: Press Enter to start playing positions")
    while play_times == 0 or abs(play_times) != count:
        for n, pos in enumerate(track):
            while True:
                piper.move_j(pos[:-1], move_spd_rate_ctrl)
                time.sleep(0.01)
                current_pos = get_pos()
                print(f"INFO: {count + 1}th playback, {n + 1}th position, current position: {current_pos}, target position: {pos}")
                if all(abs(current_pos[i] - pos[i]) < 0.0698 for i in range(6)):
                    break
            if have_gripper and len(pos) == 7:
                piper.move_gripper(pos[-1], 1)
                time.sleep(0.5)
            if play_interval < 0:
                if n != len(track) - 1 and input("INPUT: Enter 'q' to exit, press Enter directly to play:  ") == 'q':
                    exit()
            else:
                time.sleep(play_interval)
        count += 1

Summary

The above implements the fixed position recording and replay function based on the AgileX PIPER robotic arm. By applying the Python SDK, it is possible to record and repeatedly execute specific positions of the robotic arm, providing strong technical support for teaching demonstrations and automated operations.

If you have any questions regarding the use, please feel free to contact us at support@agilex.ai.

1 post - 1 participant

Read full topic

by Agilex_Robotics on August 12, 2025 05:58 AM

August 10, 2025
ROS Kerala | Building a Robotics Career in the USA | Robotics Talk | Jerin Peter | Lentin Joseph

:studio_microphone: ROS Kerala Presents: Robotic Talk Series Topic: Building a Robotics Career in the US – Myths, Challenges & Reality

Join Jerin Peter (Graduate Student – Robotics, UC Riverside) and Lentin Joseph (Senior ROS & AI Consultant, CTO & Co-Founder – RUNTIME Robotics) as they share real-world insights on launching and growing a career in robotics in the United States.

From higher education choices and visa hurdles to mastering ROS and cracking robotics interviews, this talk covers it all. Whether you’re a student, a robotics enthusiast, or a professional looking to go abroad, you’ll find valuable tips and lessons here.

Building a Robotics Career in the USA | Robotics Talk | Jerin Peter | Lentin Joseph

1 post - 1 participant

Read full topic

by lentinjoseph on August 10, 2025 01:42 PM

August 08, 2025
Native rcl::tensor type

We propose introducing the concept of a tensor as a natively supported type in ROS 2 Lyrical Luth. Below is a sketch of how this would work for initial feedback before we write a proper REP for review.

Abstract

Tensors are a fundamental data structure often used to represent multi-modal information for deep neural networks (DNNs) at the core of policy-driven robots. We introduce rcl::tensor as a native type in rcl, as a container for memory that can be optionally externally managed. This type would be supported through all client libraries (rclcpp, rclpy, …) the ROS IDL rosidl, and all RMW implementations. This enables tensor_msgs ROS messages based on sensor_msgs which use tensor instead of uint8[]. The default implementation of rcl::tensor operations for creation/destruction and manipulation will be available on all tiers of supported platforms.. With the presence of an optional package and an environment variable, a platform-optimized implementation for rcl::tensor operations can then be swapped in at runtime to take advantage of accelerator-managed memory/compute. Through adoption of rcl::tensor in developer code and ROS messages, we can enable seamless platform-specific acceleration determined at runtime without any recompilation or deployment.

Motivation

ROS 2 should be accelerator-aware but accelerator-agnostic like other popular frameworks such as PyTorch or NumPy. This enables package developers that conform to ROS 2 standards to gain platform-specific optimizations for free (“optimal where possible, compatible where necessary”).

Background

AI robots and policy-driven physical agents rely on accelerated deep neural network (DNN) model inference through tensors. Tensors are a fundamental data structure to represent multi-dimensional data from scalar (rank 0), vectors (rank 1), and matrices (rank 2) to batches of multi-channel matrices (rank 4). These can be used to encode all data flowing through such graphs including images, text, joint positions, poses, trajectories, IMU readings, and more.

Performing inference on these DNN model policies requires these tensors to reside in accelerator memory. ROS messages, however, expect their payloads to reside in main memory with field types such as uint8[] or multi-dimensional arrays. This requires these payloads to be copied from main memory to accelerator memory and then copied back to main memory after processing in order to populate a new ROS message to publish. This quickly becomes the primary bottleneck for policy inference. Type adaptation in rclcpp provides a solution for this, but it requires all participating packages to have accelerator-specific dependencies and only applies within the client library, so RMW implementations cannot apply optimized-for-accelerator memory, for example.

Additionally, without a canonical tensor type in ROS 2, a patchwork of different tensor libraries across various ROS packages is causing impedance mismatches with popular deep learning frameworks including PyTorch.

Requirements

  • Provide a native way to represent tensors across all interfaces from client libraries through RMW implementations.
  • Make available a set of common operations on tensors that can be used by all interfaces.
  • Enable accelerated implementations of common tensor operations when available at runtime.
  • Enable accelerator memory management backing these tensors when available at runtime.
  • Optimize flow of tensors for deep neural network (DNN) model inference to avoid unnecessary memory copies.
  • Allow for backwards compatibility with all non-accelerated platforms.

Rough Sketch

struct rcl::tensor
{
    std::vector<size_t> shape; // shape of the tensor
    std::vector<size_t> strides; // strides of the tensor
    size_t rank; // number of dimensions

    union {
        void* data; // pointer to the data in memory handle
        size_t handle; // token stored by rcl::tensor for externally managed memory
    }
    size_t byte_size; // size of the data

    data_type_enum type; // the data type
}

Core Tensor APIs

Inline APIs available on all platforms in core ROS 2 rcl.

Creation

Create a new tensor from main memory.

  • rcl_tensor_create_copy_from_bytes(const void *data_ptr, size_t byte_size, data_type_enum type)
  • rcl_tensor_wrap_bytes(void *data_ptr, size_t size, data_type_enum type)
  • rcl_tensor_create_copy_from(const struct rcl::tensor & tensor)

Common operations

Manipulations performed on tensors that can be optionally accelerated. The more complete these APIs are, the less fragmented the ecosystem will be but the higher the burden on implementers. These should be modeled after PyTorch tensor API and existing C tensor libraries such as libXM or C++ libraries like xtensor.

  • reshape()
  • squeeze()
  • normalize()
  • fill()
  • zero()

Managed access

Provide a way to access elements individually in parallel.

  • rcl_tensor_apply(<functor on each element with index>)

Direct access

Retrieve the underlying data in main memory but may involve movement of data.

  • void* rcl_tensor_materialized_data()

Other Conveniences

  1. rcl functions to check which tensor implementation is active.
  2. tensor_msgs::Image to mirror sensor_msgs::Image to enable smooth migration to using tensor type in common ROS messages. Alternative is to add a “union” field in sensor_msgs::Image with the uint8[] data field.
  3. cv_bridge API to convert between cv::Mat and tensor_msgs::Image.

Platform-specific tensor implementation

Without loss of generality, suppose we have an implementation of tensor that uses an accelerated library, such as rcl_tensor_cuda for CUDA. This package provides shared libraries that implement all of the core tensor APIs. An environment variable for RCL_TENSOR_IMPLEMENTATION = rcl_tensor_cuda enables the loading of rcl_tensor_cuda at runtime without rebuilding any other packages. Unlike the native implementation, rcl_tensor_cuda copies the input buffer into a CUDA buffer and uses CUDA to perform operations on that CUDA buffer.

It also provides new APIs for creating a tensor from a CUDA buffer, for checking whether the rcl_tensor_cuda implementation is active, and for accessing the CUDA buffer from a tensor available for any other package libraries the link to rcl_tensor_cuda directly. An RMW implementation linked against rcl_tensor_cuda would query the CUDA buffer backing a tensor and use optimized transport paths to handle it, while a general RMW implementation could just call rcl_tensor_materialize_bytes and transport the main memory payload as normal.

Simple Examples

Example #1: rcl::tensor with “accelerator-aware” subscriber

Node A publishes a ROS message with rcl::tensor from main memory bytes and sends it to a topic Node B subscribes to. Node B happens to be written to first check whether the rcl::tensor is backed by externally managed memory AND checks that rcl_tensor_cuda is active (indicates this is backed by CUDA). Node B has a direct dependency on rcl_tensor_cuda in order to perform this check.

Alternatively, Node B could have also been written with no dependency on any rcl::tensor implementation to simply retrieve the bytes from the rcl::tensor and ignore the externally managed memory flag altogether, which would have forced a copy back from accelerator memory in Scenario 2.

MyMsg.msg
—--------
std_msgs/Header header
tensor payload

Scenario 1: RCL_TENSOR_IMPLEMENTATION = <none>
----------------------------------------------

┌─────────────────┐    ROS Message    ┌─────────────────┐
│   Node A        │ ────────────────► │   Node B        │
│                 │                   │                 │
│ ┌─────────────┐ │                   │ ┌─────────────┐ │
│ │Create Tensor│ │                   │ │Receive MyMsg│ │
│ │in MyMsg     │ │                   │ │             │ │
│ └─────────────┘ │                   │ └─────────────┘ │
│         │       │                   │         │       │
│         ▼       │                   │         ▼       │
│ ┌─────────────┐ │                   │ ┌─────────────┐ │
│ │Publish      │ │                   │ │Check if     │ │
│ │MyMsg        │ │                   │ │Externally   │ │
│ └─────────────┘ │                   │ │Managed      │ │
└─────────────────┘                   │ └─────────────┘ │
                                      │         │       │
                                      │         ▼       │
                                      │ ┌─────────────┐ │
                                      │ │Copy         │ │
                                      │ │to Accel Mem │ │
                                      │ └─────────────┘ │
                                      │          │       │
                                      │         ▼       │
                                      │ ┌─────────────┐ │
                                      │ │Process on   │ │
                                      │ │Accelerator  │ │
                                      │ └─────────────┘ │
                                      └─────────────────┘

Scenario 2: RCL_TENSOR_IMPLEMENTATION = rcl_tensor_cuda
--------------------------------------------------------

┌─────────────────┐    ROS Message    ┌─────────────────┐
│   Node A        │ ────────────────► │   Node B        │
│                 │                   │                 │
│ ┌─────────────┐ │                   │ ┌─────────────┐ │
│ │Create Tensor│ │                   │ │Receive MyMsg│ │
│ │in MyMsg     │ │                   │ │             │ │
│ └─────────────┘ │                   │ └─────────────┘ │
│         │       │                   │         │       │
│         ▼       │                   │         ▼       │
│ ┌─────────────┐ │                   │ ┌─────────────┐ │
│ │Publish MyMsg│ │                   │ │Check if     │ │
│ └─────────────┘ │                   │ │Externally   │ │
└─────────────────┘                   │ │Managed      │ │
                                      │ └─────────────┘ │
                                      │         │       │
                                      │         ▼       │
                                      │ ┌─────────────┐ │
                                      │ │Process on   │ │
                                      │ │Accelerator  │ │
                                      │ └─────────────┘ │
                                      └─────────────────┘

In Scenario 2, the same tensor function call in Node A creates a tensor backed by accelerator memory instead. This allows Node B, which was checking for a rcl_tensor_cuda-managed tensor to skip the extra copy.

Example #2: CPU versus accelerated implementations

SCENARIO 1: RCL_TENSOR_IMPLEMENTATION = <none> (CPU/Main Memory Path)
========================================================================

┌─────────────────────────────────────────────────────────────────────────────┐
│                              CPU/Main Memory Path                           │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   Create    │    │  Normalize  │    │   Reshape   │    │ Materialize │
│   Tensor    │───▶│  Operation  │───▶│  Operation  │───▶│    Bytes    │
│  [CPU Mem]  │    │   [CPU]     │    │   [CPU]     │    │  [CPU Mem]  │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
        │                   │                   │                   │
        ▼                   ▼                   ▼                   ▼
┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│ Allocate    │    │ CPU-based   │    │ CPU-based   │    │ Return      │
│ main memory │    │ normalize   │    │ reshape     │    │ pointer to  │
│ for tensor  │    │ computation │    │ computation │    │ byte array  │
│ data        │    │ on CPU      │    │ on CPU      │    │ in main mem │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘

Memory Layout:
┌─────────────────────────────────────────────────────────────────────────────┐
│                              Main Memory                                    │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │   Tensor    │  │  Normalized │  │  Reshaped   │  │ Materialized│         │
│  │   Data      │  │   Tensor    │  │   Tensor    │  │    Bytes    │         │
│  │  [CPU]      │  │   [CPU]     │  │   [CPU]     │  │   [CPU]     │         │
│  └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘         │
└─────────────────────────────────────────────────────────────────────────────┘

SCENARIO 2: RCL_TENSOR_IMPLEMENTATION = rcl_tensor_cuda (GPU/CUDA Path)
=======================================================================

┌─────────────────────────────────────────────────────────────────────────────┐
│                              GPU/CUDA Path                                  │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   Create    │    │  Normalize  │    │   Reshape   │    │ Materialize │
│   Tensor    │───▶│  Operation  │───▶│  Operation  │───▶│    Bytes    │
│  [GPU Mem]  │    │   [CUDA]    │    │   [CUDA]    │    │  [CPU Mem]  │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
        │                   │                   │                   │
        ▼                   ▼                   ▼                   ▼
┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│ Allocate    │    │ CUDA kernel │    │ CUDA kernel │    │ Copy from   │
│ GPU memory  │    │ for normalize│   │ for reshape │    │ GPU to CPU  │
│ for tensor  │    │ computation │    │ computation │    │ memory      │
│ data        │    │ on GPU      │    │ on GPU      │    │ (cudaMemcpy)│
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘

Memory Layout:
┌─────────────────────────────────────────────────────────────────────────────┐
│                              GPU Memory                                     │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐                          │
│  │   Tensor    │  │  Normalized │  │  Reshaped   │                          │
│  │   Data      │  │   Tensor    │  │   Tensor    │                          │
│  │  [GPU]      │  │   [GPU]     │  │   [GPU]     │                          │
│  └─────────────┘  └─────────────┘  └─────────────┘                          │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                              Main Memory                                    │
│                                                                             │
│                                                                             │
│  ┌─────────────┐                                                            │
│  │ Materialized│                                                            │
│  │    Bytes    │                                                            │
│  │   [CPU]     │                                                            │
│  └─────────────┘                                                            │
└─────────────────────────────────────────────────────────────────────────────┘

IMPLEMENTATION NOTES
===================

• Environment variable RCL_TENSOR_IMPLEMENTATION controls which path is taken
• Same API calls work in both scenarios (transparent to user code)
• GPU path requires CUDA runtime and rcl_tensor_cuda package
• Memory management handled automatically by implementation
• Backward compatibility maintained for CPU-only systems

Discussion Questions

  1. Should we constrain tensor creation functions to using memory allocators instead? rcl::tensor implementations would need to provide custom memory allocators for externally managed memory, for example.

  2. Do we allow for mixed runtimes of cpu-backed/external memory managed tensors in one runtime? What creation pattern would allow for precompiled packages to “pick up” accelerated memory dynamically at runtime by default but also explicitly opt-out from it for specific tensors as well?

  3. Do we need to expose the concept of “streams” and “devices” through the rcl::tensor API or can that be kept under the abstraction layer? They are generic concepts but may too strongly proscribe the underlying implementation. However, exposing them would let developers provide stronger intent on how they want their code to be executed in an accelerator-agnostic manner.

  4. What common tensor operations should we keep as supported? The more we choose, the higher the burden on the rcl::tensor implementations, but the more standardized and less fragmented our ROS 2 developer base. For example, we do not want fragmentation where packages begin to depend on rcl_tensor_cuda and thus fallback only to CPU for rcl_tensor_opencl (wlog).

  5. Should tensors have a multi-block interfaces from the get-go? Assuming one memory address seems problematic for rank 4 tensors, for example (e.g., sets of images from multiple cameras).

  6. Should the ROS 2 canonical implementation of rcl::tensor be inline or based on an existing, open source library? If so, which one?

Summary

  • tensor as a native type in rcl and made available through all client libraries, ROS IDL, and all RMW implementations, like string array or uint8[].
    • tensor_msgs::Image is sensor_msgs::Image but with tensor payload instead of uint8[].
    • Add cv_bridge functions to create tensor_msgs::Image from cv2::Mat to spur adoption.
  • Implementations for tensor lifecycle and manipulation can be dynamically swapped at runtime with a package and an environment variable.
    • Data for tensors can then be optionally stored in externally managed memory, eliminating need for type adaptation in rclcpp.
    • Operations on tensors can then be optionally implemented with accelerated libraries.

8 posts - 7 participants

Read full topic

by HemalShahNV on August 08, 2025 11:41 PM

ROS 2 Performance Benchmark - Code Release

In our ROS 2 Performance Benchmark tests, we had interesting findings demonstrating potential bottlenecks for message transport in ROS 2(rolling). Now, we’re excited to release the code which can be used to reproduce our results. Check it out here!

1 post - 1 participant

Read full topic

by MihirRaoNV on August 08, 2025 11:25 PM

ROS 2 Rust Meeting: August 2025

The next ROS 2 Rust Meeting will be Mon, Aug 11, 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!

With the recent announcement about OSRF funding for adding Cargo dependency management to the buildfarm, and a few people having questions on that, I would like to reiterate that this meeting is open to everyone - working group member or not. If you want to learn what we’re trying to accomplish, please drop by! We’d love to have you!

1 post - 1 participant

Read full topic

by jhdcs on August 08, 2025 11:45 AM


Powered by the awesome: Planet