August 04, 2026
Last day to purchase regular price ROSCon Global tickets is Monday, August 24th

Hi Everyone,

Quick reminder, the last day to purchase regular price tickets for ROSCon Global in Toronto is Tue, Aug 25, 2026 6:59 AM UTC.

1 post - 1 participant

Read full topic

by Katherine_Scott on August 04, 2026 09:59 PM

Announcing protoros2: use protobuf in ros2 without compromise

Hi ROS Community! :waving_hand:

For years, there has been a strong and consistent demand for seamless Protobuf serialization in ROS/ROS 2. While there are excellent existing tools in the community, integrating them cleanly into a high-performance, production-ready pipeline often comes with friction.

Today, we’re excited to introduce protoros2 — a middleware wrapper and orchestration engine designed to provide zero-intrusive protobuf support for ROS 2. ZhenshengLee/protoros2: use protobuf in ros2 without compromise

(The name is heavily inspired by the awesome flatros2 GitHub - Ekumen-OS/flatros2 · GitHub project!)

:rocket: What does protoros2 do?

protoros2 does not reinvent the wheel. Instead, it acts as a non-intrusive “Tri-State Orchestration Engine” that elegantly binds third-party Open-Source foundations into a unified architecture. It allows you to use Protobuf in your stack without compromise.

It provides an out-of-the-box EnterpriseNode wrapper that offers multi-channel communication:

• Proto Channel (Zero-Intrusive Fast-Path): Transparently inspects the underlying RMW serialization format at runtime. If the RMW supports Protobuf natively, it routes messages directly via rclcpp::SerializedMessage. If not, it gracefully falls back to standard CDR via rclcpp::TypeAdapter.
• Flat Channel (Performance Bonus): An optional bypass channel optimized for ultra-low latency IPC (powered by Iceoryx shared memory), fully adapted to the ROS 2 executor ecosystem.

:sparkles: Key Features & Use Cases

We designed protoros2 to be flexible enough to accommodate different team workflows, supporting multiple “Single Source of Truth” (SSOT) architectures seamlessly:

• Use Case A: Standard ROS 2 .msg as SSOT
Write your standard .msg files as usual. protoros2 works seamlessly with standard RMWs (CDR only) or native Protobuf RMWs without altering your application logic. In fallback modes, it can even handle simultaneous CDR and Protobuf topic ecosystems flawlessly.
• Use Case B: AI/Robotics .proto as SSOT
For AI-first teams, define your data structures natively in .proto. protoros2 can either co-exist with a generated mirror IDL or operate purely on .proto, bypassing .msg entirely for a direct, zero-overhead binding.
• Native ROS 2 Executor Support:
Whether you prefer standard Callback Push, WaitSets, CallbackGroups (Mutually Exclusive/Reentrant), Polling Subscribers, or Intra-Process Comm—protoros2 natively integrates these paradigms out of the box.
• MLOps Ecosystem Ready:
Full compatibility with mcap format and rosbag2 plugins. Data scientists can consume protobuf bags directly with native python bindings.

:shield: Enterprise Security Built-in

To ensure consistency in large-scale deployments, protoros2 utilizes strict C++ access controls to safely encapsulate the raw rclcpp::Node. It intercepts and disables risky dynamic ROS 2 configurations (like parameter services and QoS overriding) at compile time, guaranteeing predictable behavior on the vehicle edge without sacrificing the standard ROS 2 developer experience.

:folded_hands: Acknowledgement

This work stands on the shoulders of giants. We want to express our deepest gratitude to the following incredible projects and their contributors, without which protoros2 would not have been possible:

• rosidl_typesupport_protobuf https://github.com/eclipse-ecal/rosidl_typesupport_protobuf: For providing the robust C++ TypeSupport handle and TypeAdapter generation engine.
• proto2ros https://github.com/rai-opensource/proto2ros: For the brilliant AST parser bridging .proto definitions to synthetic IDL .msg.
• ros-central-registry https://github.com/intrinsic-opensource/ros-central-registry/blob/main/examples: For the excellent Bazel + ROS 2 integration examples and Protobuf C++ references.

1 post - 1 participant

Read full topic

by ZhenshengLee on August 04, 2026 07:11 AM

Boston Robot Hackers announces August Monthly Meeting

Boston Robot Hackers is pleased share info about our August meeting:

Topic: Forward & Inverse Kinematics: The Math: From joint angles to end-effector poses"
Speaker: Shivam Chopra, PhD
Date: August 6 2026
Time: 7:00pm to 9:00pm
Location: Artisans Asylum, Alston, Boston

Shivam will introduce the concepts of Forward and Inverse Kinematics, explain where it fits into robotics (and how important it is!) and get into technical details of how to apply it and how the math works.

Also featured two lighting talks

PLEASE REGISER! brh.eventbrite.com

1 post - 1 participant

Read full topic

by pitosalas on August 04, 2026 12:49 AM

August 02, 2026
ROS 2 Realtime Support Package

We have been working on adding real-time functionality to rcl and rclcpp since 2022.
In response to this proposal, we have created a new package that provides real-time functionality without changing the existing packages.

esol-community/ros2_realtime_support

Background

The previous discussion is as follows: ROS lacks a unified mechanism to formally support real-time functionality, and we have tried to achieve this by adding functionality to rcl and rclcpp.

On the other hand, it has been pointed out in past PTCs that it makes it difficult to check at release time and to support the OS.
Since CallbackIsolatedExecutor was announced around the same time, we have also changed our policy to provide functionality in separate packages.

Update REP-2017 prototype and executor using OS native threads - ROS/ROS General - Open Robotics Discourse

How to use

For now, we provide rclcpp-friendly classes. There are four things to do:

  1. Add package description to CMakeLists.txt and package.xml
  2. Add a configuration file in YAML format
  3. Change the main routine in the source file
    • Change rclcpp::init, rclcpp::shutdown to the rclcpp_realtime namespace
    • Change executors to be able to apply thread attributes provided by rclcpp_realtime

This allows thread attribute settings to be applied to executors by specifying an environment variable or a configuration file with --ros-args.
See the README below for details.

ros2_realtime_support/examples_rclcpp_realtime/README.md at rolling · esol-community/ros2_realtime_support

Discussion & Future Work

Despite the name, real-time support, not much has been done.
The thread attributes can be managed through the extended rcl interfaces; APIs for thread operations, abstracted by these attributes, are provided, and executors that use the attributes have been added.

In the future, we will change the mutexes and condition variables used in rclcpp_realtime on an RTOS to call OS-native APIs.
Another challenge is to make intra-process communication real-time, so we can guarantee real-time performance in robot systems that run on a single PC.

1 post - 1 participant

Read full topic

by k-yokoyama-esol on August 02, 2026 01:21 PM

Uv on ROS 2: a field report on workspace-level virtual environments — five failure modes and minimal colcon/ament proposals

TL;DR: A workspace-level uv-managed venv works on stock apt-installed ROS 2 — including a PyTorch+CUDA node — but we hit five reproducible failure modes on the way (verified on Jazzy; none of the mechanisms are Jazzy-specific). Key measurement: the known shebang workaround ([build_scripts] executable = /usr/bin/env python3) does not cover --symlink-install, so when colcon is launched from the system Python there is currently no complete workaround. Below are four minimal change proposals for colcon/ament — all opt-in, none fixing the venv’s location or name, with no behavior change for workspaces that do not use a venv.

Background

PEP 668 disabled pip install into the system Python on Ubuntu 24.04, and deep-learning robotics often needs exact version pins and custom package indexes (e.g. torch==2.6.0+cu124) that package.xml/rosdep currently has no way to declare. A per-workspace virtual environment with pyproject.toml and a lockfile — managed here with uv — is one practical answer. In Letting Python Be Python, the idea that workspaces could become venvs was raised, along with the question of what it would take to get there; Status of Colcon building “standards-based” Python packages covers the related build-tool work. This post adds empirical data to that discussion: we migrated a real robot stack to uv while keeping colcon, ros2 run, and ros2 launch in use, and recorded what broke and why.

What works and what breaks

With a venv created by uv venv --system-site-packages from the distro interpreter, and python-preference = "only-system" set in the [tool.uv] section of pyproject.toml, everything builds and a torch+CUDA inference node runs on the venv’s Python, with lockfile reproducibility and custom wheel indexes.

Setup: Ubuntu 24.04 / apt Jazzy / Python 3.12.3 / setuptools 68.1.2 / uv 0.11.28, and pyproject.toml (click for more details)

Along the way we hit five reproducible failure modes. All of them can be worked around, but the workarounds are not covered by official documentation, so they are easy to rediscover independently:

# Failure mode Cause Current workaround
1 Every shell needs two setup steps (source install/setup.bash and venv activation), in order The ROS environment and the venv have no knowledge of each other Hand-written shell setup per project
2 colcon treats directories inside the venv as packages during discovery Package discovery descends into every subdirectory touch .venv/COLCON_IGNORE (documented)
3 ros2 run executes ament_python nodes with the system interpreter even while a venv is active colcon runs setup.py with its own sys.executable; setuptools writes that interpreter into console-script shebangs Incomplete — see next section (ros2/ros2#1094, open since 2021)
4 numpy 2.x in the venv breaks apt-built extensions (cv_bridge) at import Jazzy binaries are built against numpy 1.26’s C ABI Pin numpy<2 in the workspace
5 uv provisions its own standalone CPython, which mismatches distro-built C extensions uv’s default python-preference python-preference = "only-system" in pyproject.toml ([tool.uv])

The remaining gap

Four of the five have complete workarounds; #3 does not. A known mitigation is [build_scripts] executable = /usr/bin/env python3 in setup.cfg (mechanism related to colcon-core#183, reported in ros2/ros2#1094). We measured it on Jazzy:

  • Regular colcon build: works — scripts get env shebangs and resolve to the active venv.
  • colcon build --symlink-install: not applied — the develop/editable code path keeps #!/usr/bin/python3, so the mode commonly used during development is not covered.
  • Launching colcon from the venv itself — .venv/bin/python -m colcon build — covers both modes (with --system-site-packages, the apt-installed colcon is importable from the venv, so nothing extra needs to be installed). The limitation: the venv’s absolute path is written into the generated shebangs, so the result does not survive venv recreation and install/ is not relocatable.

Bottom line: when colcon is launched from the system Python — the common configuration in tutorials and CI — there is currently no complete workaround.

Proposed changes

One design principle for all four: opt-in, no fixed venv location or name, and no behavior change for workspaces that do not involve a venv.

  • P1 — discovery: skip any directory containing pyvenv.cfg (the PEP 405 marker every venv has) during package discovery — an automatic COLCON_IGNORE for venvs of any name, in any location.
  • P2 — shebangs: an option to emit #!/usr/bin/env python3 shebangs on both the install and the develop (--symlink-install) code paths. The setup.cfg mitigation covers only the install path and has to be repeated in every package; an option at the build-tool level would cover a whole workspace at once. Where no venv is active, env python3 resolves to /usr/bin/python3 as before.
  • P3 — activation: record the path of the interpreter colcon built with under install/, and let setup.bash read it and, if that interpreter belongs to a venv, activate it (with an opt-out environment variable). This is a minimal mechanism for the “workspaces as venvs” idea from the threads above, and it leaves the venv’s location entirely up to the user.

Relation to existing work

  • colcon-uv manages Python dependencies per package, installed during colcon build. This post focuses on one environment and one lockfile per workspace; the two granularities address different needs (per-package isolation vs. one shared environment for a whole launch graph) and can coexist.
  • Pixi as a co-official installation method concerns how ROS itself is installed. The scope here is different and does not compete with it: keeping the standard apt installation and making the Python layer of one workspace reproducible.
  • ros-python-wheels distributes ROS client libraries as pip-installable wheels. The direction here is complementary: using pip/uv-managed dependencies inside a standard, apt-based ROS workspace.
  • A similar uv setup (--system-site-packages + lockfile) has been shared in Status of Colcon building “standards-based” Python packages, with nodes started directly through python. The measurements above cover the case where colcon, ros2 run, and ros2 launch stay in use.

Open questions

  1. For P1: would a package-identification extension in colcon-core, modeled on the existing COLCON_IGNORE one, be an acceptable shape — or would this fit better as a separately distributed extension package?
  2. For P2, which layer would be better suited to handle the develop-path shebang — colcon-core, or the setuptools develop machinery?
  3. For those running workspace-level venvs with colcon in CI or on production robots: which failure modes are missing from the list above (overlays, cross-compilation, non-Ubuntu platforms)?

3 posts - 2 participants

Read full topic

by Decwest on August 02, 2026 09:48 AM

July 31, 2026
VectorField Planner: 7 µs global path queries with strict optimality — REST API for occupancy grids, Nav2 plugin on roadmap

Hi all,

I’ve been working on a global planning engine aimed at warehouse/fleet
deployments, and I just opened a free API tier. I’d love feedback from people
running real Nav2 fleets.

What it does

You upload an occupancy grid once. It solves a field for your goal (charging
station, pick station, dock), and from then on every path query — from any
start cell — returns a strictly optimal path in microseconds, without
re-searching the map.

The pitch for fleet operators: the cost of global planning stops scaling with
the number of robots.

Measured numbers (C++ core, single thread, low-end 2-core CPU)

1M-cell 3D warehouse map (100³, mezzanine floors + rack walls):

Metric VectorField A* (C++, typical)
One-time solve per goal 47 ms
Query, any start pose 7 µs ~5 ms, every query
Optimality 1.0000 (BFS-verified) optimal
Peak memory 5 MB
10,000 simultaneous queries 70 ms total ~50 s

Dynamic sites: obstacle removal (cleared shelves, opened gates) is patched
exactly, 5.9× faster than a rebuild, zero error. Every solve is a fixed,
bounded number of identical array operations, so worst-case latency is known
in advance — relevant if you need timing guarantees for certification.

Where this fits in a ROS stack

  • Input: an occupancy grid (the same data you already publish on /map or
    keep in a costmap_2d layer)
  • Output: an optimal cell path per query
  • Today: plain REST API, so anything that can HTTP can plan. A native Nav2
    global-planner plugin (drop-in replacement for Navfn) is on the roadmap

    the field-reuse model maps nicely onto multi-goal / fleet planners, which is
    exactly where Navfn recomputes the most.

Typical integration I’m picturing: your fleet manager uploads the map once per
shift (or per layout change), then every robot’s global plan request is a
~7 µs lookup instead of a Navfn re-search.

Honest limitations

  • Built for structured, mostly-static environments — warehouses, factories,
    indoor drones. Not for highly dynamic unstructured spaces.
  • Obstacle insertion currently uses a repair fallback; exact fast insertion is
    roadmap work.
  • It’s a hosted API (with an on-prem license option), not an open-source
    package. Free tier is genuinely free: 100³ maps, 1,000 solves + 100K
    queries/month.

Links

Questions I’d especially love feedback on:

  1. For those running multi-robot fleets: how do you handle global replanning
    cost today? Is 5 ms/query/robot actually hurting you, or is local planning
    the real bottleneck?
  2. What would a Nav2 plugin need to do for you to consider it (topic/action
    interface, costmap update cadence, multi-goal support)?
  3. Any interest in an on-prem / offline deployment for sites without
    connectivity?

5 posts - 3 participants

Read full topic

by ShiyanPeng on July 31, 2026 05:02 PM

A new tool to create ros2 package with executables, c++ and Python node in one package

site: GitHub - yjphhw/ros2_pkg_create: A utility script for generating ROS 2 package templates that support both C++ and Python nodes, simplifying mixed-language development within a single package. · GitHub

useage is very easy, just download the ros2_pkg_create.py and put in a workspace(direction),

and run :slight_smile:

python3 ros2_pkg_create <package_name>

such as create demo_pkg:

python3 ros2_pkg_create demo_pkg

output is :

:rocket: 正在生成混合功能包: my_pkg
:white_check_mark: 已创建: src/my_pkg/CMakeLists.txt
:white_check_mark: 已创建: src/my_pkg/package.xml
:white_check_mark: 已创建: src/my_pkg/setup.cfg
:white_check_mark: 已创建: src/my_pkg/LICENSE
:white_check_mark: 已创建: src/my_pkg/src/hello_world.cpp
:white_check_mark: 已创建目录: src/my_pkg/include/my_pkg/
:white_check_mark: 已创建: src/my_pkg/src/script_node.py
:white_check_mark: 已创建: src/my_pkg/my_pkg/init.py
:white_check_mark: 已创建: src/my_pkg/my_pkg/py_node.py

:tada: 功能包 [my_pkg] 生成完毕!
:light_bulb: 提示: 记得在 CMakeLists.txt 中根据需要补充依赖项。

按照以下步骤进行下一步操作:
:light_bulb: 1.编译功能包: colcon build --symlink-install --packages-select my_pkg
:light_bulb: 2.安装功能包: source install/setup.bash
:rocket: 3.测试可执行程序: hello_world
:rocket: 4.测试 C++节点: ros2 run my_pkg hello_world
:rocket: 5.测试 Python 节点: ros2 run my_pkg script_node
:rocket: 6.测试 Python 模块: ros2 run my_pkg my_py_node

follow the instructions in output, you can build and run package in one minute.

you will get a ros2 pkg template, you can easily add C++ , Python and normal executable.

welcom to Star the project: GitHub - yjphhw/ros2_pkg_create: A utility script for generating ROS 2 package templates that support both C++ and Python nodes, simplifying mixed-language development within a single package. · GitHub

1 post - 1 participant

Read full topic

by yjphhw on July 31, 2026 01:29 PM

July 30, 2026
How do you understand the architecture of a large ROS 2 workspace?

Hi everyone,

I’m curious about how other ROS 2 developers approach understanding a large or unfamiliar workspace.

When joining an existing project or reviewing a large codebase, I often find myself asking questions like:

  • Which packages depend on each other?
  • Which nodes communicate together?
  • What topics, services, and actions are used?
  • Are there isolated nodes or communication issues?
  • Does the implementation still match the intended architecture?
  • How do you quickly get a high-level understanding before running the system?

I’m interested in learning about your workflow.

For example:

  • Which tools do you use?
  • Do you rely mostly on runtime tools such as rqt_graph, Foxglove, or RViz?
  • Do you have internal scripts or documentation that help?
  • Do you manually inspect the source code?
  • Do you perform any kind of static analysis before launching the system?
  • How do you review architectural changes in CI?

I’m particularly interested in workflows for medium-to-large industrial projects where a workspace may contain dozens (or even hundreds) of packages.

Looking forward to hearing how everyone approaches this problem and what has worked well in practice.

7 posts - 5 participants

Read full topic

by aminebensaid66 on July 30, 2026 04:51 PM

Jenkins version upgrade of build.ros2.org [Scheduled Buildfarm Downtime]

Hello ROS Community,

The OSRF Infrastructure Project is planning to update the Jenkins version of https://build.ros2.org as part of our ongoing efforts to maintain and improve the ROS buildfarm infrastructure. To facilitate this migration, the following services will experience downtime during the maintenance window:

The migration is scheduled to begin on Monday Mon, Aug 3, 2026 11:30 AM UTC (11:30 UTC) and is expected to last for 4 hours. During this time, the buildfarm will be offline, and all queued jobs will need to complete before Jenkins is taken offline.

Once the upgrade is complete, I’ll update this thread to confirm that services are back online. I’ll also be monitoring for any issues that may arise as a result of the upgrade.

Thank you for your patience as we work to improve the ROS buildfarm infrastructure. If you have any questions or concerns, please feel free to reach out in this thread.

Att,

Cristóbal

4 posts - 2 participants

Read full topic

by Crola1702 on July 30, 2026 04:37 PM

July 29, 2026
Chinese legged/humanoids banned in USA, what are the alternatives?

Just saw that newly imported Chinese legged and humanoid robots are now banned in USA, what other alternatives are there? I know Unitree had ROS interface in both Go2 dog and G1 humanoid (and you could jailbreak cheap base version instead of expensive research one).

What other alternatives are there?
Will this spur open source/open hardware design?

Again, I’m adding poll of what legged/humanoid robots have you used/planned to use :down_arrow:

What legged/humanoid robots have you used/will use?
  • Chinese( Unitree Go2, G1, etc)
  • Boston Dynamics (Spot, Atlas, etc)
  • Musk(Optimus)
  • Figure
  • Anybotics
  • Open source/ Open Hardware
  • Other

Click to view the poll.

4 posts - 2 participants

Read full topic

by martincerven on July 29, 2026 08:24 AM

July 28, 2026
Learning Zenoh: A New Communication Layer for ROS 2

Hi everyone,

Recently, I’ve been learning more about Zenoh and its role in the ROS 2 ecosystem. Since most ROS 2 applications rely on DDS for communication, I was curious about how Zenoh approaches the same problem and where it can provide advantages.

From what I’ve learned so far, Zenoh offers a lightweight communication layer that aims to reduce latency, minimize bandwidth usage, and simplify communication across distributed systems. These characteristics make it particularly interesting for robots running on resource-constrained hardware such as the Raspberry Pi or for systems that need to communicate across different networks.

I’m currently developing a mobile robot called Pavlov Mini Wheel, based on ROS 2 Humble, and I’m planning to experiment with Zenoh for communication between the onboard Raspberry Pi and an external laptop running perception and navigation workloads. It seem like an interesting opportunity to compare its behavior with the default DDS-based setup.

This post is the first step in my exploraiton of Zenoh. Over the next few weeks, I plan to document:

  • Installing Zenoh with ROS 2 Humble
  • Integrating Zenoh into a existing ROS 2 project
  • Comparing DDS and Zenoh in practical robotics scenarios
  • Sharing performance observation from a real robot

If you’ve already used Zenoh in your projects, I’d be happy to hear about your experences, recommendations, or challenges you’ve encountered.

My article on the relevant topic:
Medium: https://medium.com/@bengokaysaglam/beyond-dds-introducing-zenoh-for-modern-ros-2-systems-1cacbfcc21f3

Looking forward to learning from the community!

3 posts - 2 participants

Read full topic

by bengokaysaglam on July 28, 2026 12:08 PM

July 27, 2026
YERP + rosbag2 snapshot: can we capture why a ROS perception latency spike happened?

[Update] Thanks to the great feedback in the comments regarding rosbag2 snapshot, I have updated the original post to clarify how YERP and rosbag2 snapshot work perfectly together as a trigger-and-capture pair!

Hi everyone, Recently I have been thinking about a very practical debugging problem in ROS / ROS2 perception pipelines, especially for AMRs and mobile robots. When a robot behaves strangely in the field, the usual workflow is often:

  1. rosbag record everything.
  2. Bring the massive data back.
  3. Replay it and try to find what happened.

Of course, rosbag2 is powerful. I am also aware of rosbag2 snapshot mode, which can keep recent messages in memory and dump a raw topic window when triggered. That is actually very close to the architecture I have in mind. I do not want to replace rosbag2 or its snapshot mode. Instead, I want to explore a lightweight layer above it: an event-triggered Runtime Evidence Layer for ROS perception pipelines.

I call the current prototype YERP — originally “YOLO Edge Runtime Profiler”.(Project repo: https://github.com/ZC502/yolo-edge-runtime-profiler)*

The core idea

In my view, the layering could be:

  • rosbag2 snapshot: captures the raw ROS topic window.

  • YERP / EvidenceFlow: decides when the snapshot is worth triggering, records why it was triggered, and adds structured perception-runtime evidence.

So the question is not: Can YERP replace rosbag2? The question is: Can YERP act as the lightweight anomaly detector / evidence sidecar layer that triggers rosbag2 snapshot at the exact right moment?

For example, a robot may run normally most of the time, but occasionally:

  • average FPS looks fine, but p95 / p99 latency spikes
  • the local planner receives perception results too late
  • a detection frame creates too many candidates
  • postprocess suddenly dominates runtime
  • the issue is hard to reproduce later

In that case, raw topic replay is useful, but we also need to know:

  • Why was this moment captured?
  • Which frame was involved?
  • Which perception stage became slow? (preprocess, inference, postprocess, callback delay, queue delay, or message age?)
  • Did output pressure increase? Was there a box-count or candidate-count spike?

That is the role I am exploring for YERP.

Current prototype status

The current YERP Vision prototype has already been tested in a standalone YOLO / edge CV pipeline. It can monitor fields such as preprocess_ms, inference_ms, postprocess_ms, p50/p95/p99 latency, box count, and confidence entropy.

When a runtime pressure event is triggered, it saves local evidence (image.jpg, metadata.json, etc.).

In one test case, a normal-looking YOLO frame was captured not because it was manually labeled as a “[bad frame] ”, but because the runtime trace showed pressure:

{
  "state": "RED",
  "dominant_cause": "POSTPROCESS_DOMINANT",
  "selection_reason": "runtime_pressure",
  "metrics": {
    "box_count": 18,
    "class_count": 4,
    "confidence_entropy": 2.51,
    "preprocess_ms": 1.20,
    "inference_ms": 3.95,
    "postprocess_ms": 2.02,
    "postprocess_ratio": "28.15%"
  }
}

The important point is not that the image “looks abnormal”. The important point is: this input frame created measurable runtime pressure, so it became worth saving as evidence.

Community Momentum

This concept is already gaining cross-community traction:

  • I have introduced this EvidenceFlow approach in the Ultralytics GitHub Discussions, where the team is currently gathering feedback.

  • I’ve also initiated an open co-testing discussion within the MindSpore Lite community, and developers there are exploring collaboration for edge NPU inference.

Now, I want to bring this discussion to the ROS ecosystem, which is arguably where field debugging is the most painful.

EvidenceFlow Schema v0.1 Draft

Instead of exposing all internal YERP logic, I am thinking about a simple structured sidecar format. A ROS / ROS2 runtime pressure event could look like this:

{
  "schema_version": "0.1",
  "record_type": "runtime_pressure_event",

  "sample": {
    "sample_id": "frame_1048",
    "input_ref": "/camera/front/image_raw",
    "timestamp": "2026-07-27T19:32:18.104Z"
  },

  "environment": {
    "runtime": "ros2",
    "backend": "yolo_edge_runtime",
    "mode": "event_only",
    "device": "amr_edge_board"
  },

  "trigger": {
    "state": "RED",
    "reason": "latency_p99_spike",
    "observed_ms": 51.7,
    "threshold_ms": 30.0,
    "dominant_cause": "POSTPROCESS_DOMINANT"
  },

  "stage_ms": {
    "preprocess": 2.1,
    "inference": 15.4,
    "postprocess": 34.2,
    "total": 51.7
  },

  "ros_metadata": {
    "topic": "/camera/front/image_raw",
    "node": "/perception/yolo_detector",
    "callback_delay_ms": null,
    "queue_delay_ms": null,
    "message_age_ms": null,
    "dropped_messages": null
  },

  "output_metadata": {
    "box_count": 145,
    "candidate_count": 312,
    "confidence_entropy": 2.8,
    "class_entropy": 1.4
  },

  "hardware_metadata": {
    "cpu_usage": null,
    "gpu_usage": null,
    "npu_usage": null,
    "memory_spike_mb": 12,
    "temperature_c": null
  },

  "snapshot": {
    "rosbag2_snapshot_triggered": true,
    "window_sec": 5
  },

  "privacy": {
    "local_first": true,
    "image_saved": true,
    "upload_performed": false
  }
}

The goal is not to force every ROS project to use these exact fields, but to discuss what a useful runtime evidence record should contain.

Runtime Overhead

A natural concern is: Will such a probe slow down the robot?
Absolutely valid. A probe should not become the new bottleneck. The design separates the workload:

  • Fast path (Main inference loop): read existing timestamps, update a fixed-size rolling window, check trigger conditions. No file IO, no large tensor copies, no image saving.

  • Slow path (Background worker): after a trigger, write JSON / image in a background worker, and optionally call rosbag2 snapshot service. Uses a bounded queue and drops evidence if full to avoid blocking inference.

For production ROS / ROS2 systems, the default modes would likely be shadow_mode (observe only) or (write only when triggered).

How I imagine the rosbag2 integration

  1. Observe: YERP observes perception timing and output metadata.

  2. Detect: YERP detects a runtime pressure event (p99 spike, queue delay, output pressure, etc.).

  3. Log: YERP writes a small EvidenceFlow JSON sidecar.

  4. Trigger: If raw replay is needed, YERP calls rosbag2 snapshot service.

  5. Result: raw bag window + structured reason for capture + perception-stage timing + output metadata.

In short: rosbag2 snapshot tells us what raw ROS messages were around the event. YERP / EvidenceFlow tells us why this event was worth capturing.

Questions for the ROS community

I would really appreciate feedback from people who debug ROS / ROS2 robots in the field.

  1. Does this EvidenceFlow schema cover the information you would want when debugging ROS perception latency?

  2. For ROS2, should such an adapter start at the image topic level, diagnostics level, or executor / callback timing level?

  3. For AMR / mobile robot scenarios, which fields matter most? (frame latency, message age, queue delay, callback delay, TF wait time, etc.)

  4. How do you currently trigger rosbag2 snapshots in real robots? (Manual trigger? Diagnostics threshold? Topic frequency monitoring? Custom anomaly detector? Lifecycle event? Nav2 state?)

  5. Would a small structured JSON sidecar make snapshot bags easier to triage later?

Boundary

To avoid misunderstanding:

  • YERP is not a replacement for rosbag2.

  • YERP is not a replacement for tracing or profilers.

  • YERP does not identify the final root cause by itself.

  • YERP tries to capture the input frame and runtime metadata that make a case worth investigating.

My current goal is to turn field debugging from “record everything and search later” into “capture structured evidence when runtime pressure actually happens”.

I am sharing this as an early prototype and schema draft. Comments, criticism, field stories, and suggestions are very welcome!

If you find this “Runtime Evidence Layer” concept valuable for your edge AI ROS deployments, or if you are interested in co-designing the ROS2 adapter together, feel free to drop a comment below, open an issue on GitHub, or reach out to me directly!

3 posts - 2 participants

Read full topic

by zc_Liu on July 27, 2026 12:44 PM

July 26, 2026
[Release] Gazebo ROS Text-to-Speech (TTS) Plugin – From Gazebo Classic to Gazebo Harmonic

Hello ROS & Gazebo Community,

We’re excited to announce the release of gz_ros_tts, an open-source ROS 2 Text-to-Speech (TTS) Plugin for the latest Gazebo Harmonic.

This release is the Gazebo Classic and Gazebo harmonic ROS TTS Plugin, bringing the same idea to the modern Gazebo ecosystem with ROS 2.

# Project Evolution

## Version 1 — Gazebo Classic ROS TTS Plugin

The first version of the plugin introduced Text-to-Speech support for robots running in Gazebo Classic through ROS.

### Supported

- Gazebo Classic

- ROS 2 Humble

GitHub:

-–

## Version 2 — gz_ros_tts for Gazebo Harmonic

To support the modern Gazebo ecosystem, the plugin has been redesigned and released as **gz_ros_tts** for Gazebo Harmonic.

### Supported

- Gazebo Harmonic

- ROS 2 Humble

- ROS 2 Jazzy

### Successfully Tested On

- Heinz H1 Humanoid Robot

- Gazebo Harmonic

- ROS 2 Humble

- ROS 2 Jazzy

GitHub:

LinkedIn Release:

Demo Video: classic

Gazebo audio plugin demonstration

Demo video - harmonic

Announcements of gazebo text to speech plugin in gazebo harmonic version

1 post - 1 participant

Read full topic

by Rahul1 on July 26, 2026 07:46 PM

July 25, 2026
What should go in the tag?

I’ve always put just “BSD” in the package.xml of our projects, mostly because it is the exact value mentioned in https://www.ros.org/reps/rep-0149.html#license-multiple-but-at-least-one . However, this value is not SPDX.

What’s the current best practice? Should we start putting SPDX identifiers into the license tag? Would it deserve a small update of REP 149?

11 posts - 5 participants

Read full topic

by peci1 on July 25, 2026 09:37 AM

July 24, 2026
A New Chapter for ROS-Industrial Americas

Over the past few months, I've had the privilege of stepping into the role of leading ROS-Industrial Americas. I'm grateful to Matt Robinson for his years of leadership and the strong community he helped build. At our 2026 Annual Meeting, I had the opportunity to share my first impressions and my vision for where we can go next.

I've reproduced that welcome letter below, because it captures the direction I hope we'll pursue together.

This is my first annual meeting as program director for ROS-Industrial Americas, and one thing has become clear very quickly: the strength of ROS-Industrial has never been a single individual or organization. It's the community itself.

Since we announced the leadership transition, I've heard from dozens of members offering encouragement, advice, questions, and ideas.

You made it immediately obvious that you participate in ROS-Industrial not because of a logo or affiliation, but because you genuinely care about advancing industrial robotics. That commitment matters especially now.

It feels like a lot has changed since our last meeting a year ago. Large language models have rapidly evolved from impressive demonstrations into practical tools used daily by engineers around the world. Those same advances are now beginning to reshape robotics as well.

Major technological shifts create uncertainty, but they also create opportunity. One of the reasons ROS-Industrial exists is to help practitioners evaluate emerging technologies, separate signal from noise, and move useful ideas from research into real-world deployment.

For fourteen years now, ROS-I has helped industrial robotics practitioners advance, adopt, and apply technologies that were once difficult to deploy reliably in industrial contexts. Today, we're seeing another transition. Robotic foundation models, LLMs, Physical AI, synthetic data generation, and learning-enabled systems are creating capabilities that seemed impractical not many years ago.

The question for us is no longer whether these technologies will influence industrial robotics. As we will hear from several speakers, they already have. The question is how we incorporate them responsibly, effectively, openly, and practically into real systems.

As I step into this role, I see part of my responsibility as helping this community ask those questions clearly and answer them together.

ROS-Industrial's mission remains the same: enabling innovation in industrial robotics through collaboration, open-source technology, applied research, and education. New technologies will continue to emerge, and our responsibility is to understand them, evaluate them, and make them useful to industrial practitioners. Today, that includes AI. Tomorrow, it will include technologies not yet imagined.

I am grateful to inherit that mission, and I am committed to stewarding it with diligence, openness, and practical focus.

At this year's meeting, our speakers will introduce new open-source robotics software, explore novel applications of AI, discuss new opportunities for open-source automation, and share real-world experience deploying these solutions in specific contexts. Our workshops will give you a focused opportunity to direct the consortium over the coming years.

But the future of ROS-Industrial will not be determined by keynote speakers, steering committees, or roadmap documents alone. It will be shaped by practitioners who bring real problems, real deployments, real successes, and even real failures back to the community.

I offer my sincere thanks to every one of you and your colleagues who have fed this community over the last year: contributing code, sharing lessons learned, participating in projects, mentoring newcomers, and helping move open-source robotics technology from research into production.

I'm excited about this meeting, but I'm more excited about what we'll all do together in the year ahead.

Sincerely,
Jerry Towler
Program Director, ROS-Industrial Americas

by Jerry Towler on July 24, 2026 05:34 PM

Do warehouse AMR operators actually monitor their fleets for security in production?

Hi all — I’m a security engineer researching runtime security for autonomous mobile robot fleets (warehouse/3PL AMRs on ROS 2). I keep hitting one question I can’t answer from the outside, and I’d value the perspective of people who actually run or build these fleets:

  1. For fleets already deployed in production — is anyone doing continuous security monitoring (detecting anomalous behaviour at runtime), or is security still mostly design-time hardening (SROS 2, DDS security) and then hands-off?
  2. When an operator worries about a robot being compromised, is that framed as a cybersecurity problem or purely as a safety/uptime problem? Who owns it internally?

Not selling anything — genuinely trying to understand the current state before assuming a gap exists. Grateful for any real-world experience.

2 posts - 2 participants

Read full topic

by RoboticsTehnologis on July 24, 2026 04:41 PM

July 23, 2026
Convert in the terminal

Would you use a free CLI tool to convert CAD assemblies to URDF?

No CAD plugins.

Just one command from your terminal to work in Ros directly.

I’m thinking about open-sourcing the core of a tool I’ve been building over the past few months, and I’d love to validate the idea before releasing it.

Would you use something like this?

Or do you prefer the existing CAD add-ins?

If not, what’s the biggest reason?

1 post - 1 participant

Read full topic

by Sleem45 on July 23, 2026 05:04 PM

Logging and Observability Guide Review Part 2 | Cloud Robotics WG Meeting 2026-08-24

The group is skipping two meetings (2026-07-27, 2026-08-10) due to lack of available members!

The next meeting of the CRWG will be at Mon, Aug 24, 2026 4:00 PM UTC→Mon, Aug 24, 2026 5:00 PM UTC, where we will continue editing the first draft of the Logging and Observability guide. We also worked on this last session, but decided not to record as it would make for pretty dry video content!

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 July 23, 2026 03:19 PM

July 22, 2026
Seeking advice on reaching ROS 2 developers

I’ve spent the last few months building ������� to automate one of the most repetitive parts of robotics development. Instead of manually converting CAD assemblies, configuring joints, generating robot descriptions, and debugging the first setup, the goal is a verified, ready-to-use robotics workspace automatically in ������ and ����.

But now I’m at a point where the technical part feels solid. The new challenge is figuring out how to reach the right users for such a ��������� �������.

If you’ve built developer tools or engineering software, how did you get your first 10 to 50 users? What channels actually worked? What wasted effort would you skip if you started again?

1 post - 1 participant

Read full topic

by Sleem45 on July 22, 2026 05:45 PM

July 21, 2026
Community event calendar; Get updates to only the selected events

On the community event calendar (introduced in discourse.openrobotics.org#48220), is there a way to 1) select only the events of my interest, 2) receive updates if such event gets updated (time change etc.)?

  • Each event seems to offer “Copy to my calendar”, which does copy a particular event on to my calendar, but the event doesn’t seem to get updates from the original event entity. Also even if the original event is recurring, the copied event seems to be one-time.
  • Choosing “Add to Google Calendar” option adds this entire community event calendar to my calendar, which shows all events, not just the ones of my interest.
    • The idea of aggregating the community events at a single location is great!!! It’s just on my personal calendar, having all events would be simply too much, so would like to be selective.

Thank you.

3 posts - 2 participants

Read full topic

by 130s on July 21, 2026 04:18 PM

Nvidia Jetson price increase by up to 100%, what other boards are you using to run ROS?

As avid Jetson user, I just saw there has been 50-100% price increases across all Nvidia Jetson kit/module lineup, what other boards/SoCs/PCs are you using for running ROS on real world robots? I saw recent posts by @smac with AMD Strix, Intel also made some robotics computers recently, there’s also upcoming Qualcomm’s Arduino HW, but that’s more on EDU/DIY side…

Jetsons seemed to me to have the most mature ecosystem, but some of those price increases surely puts them away from reach of students/hobbyists, and can have also impacts on larger fleet deployments.

EDIT: Added voting poll! :down_arrow:

  • NVIDIA Jetson
  • AMD SoC
  • Intel SoC
  • Raspberry Pi
  • Arudino/Qualcomm - Mobile SoC
  • Chinese alternatives (Rockchip etc.)
  • Other

Click to view the poll.

8 posts - 6 participants

Read full topic

by martincerven on July 21, 2026 03:29 PM

July 20, 2026
PyZeROS: a Python-first alternative to `rclpy` over Zenoh

Hi everyone,

I am releasing PyZeROS, an experimental alternative to rclpy for communicating with ROS from Python. This is not a Python wheel packaging rclpy: I bit the bullet and wrote a client from scratch in pure Python.

You can install PyZeROS like a standard python package:

pip install pyzeros

It does not require a ROS installation, colcon workspace, message compilation, or a ROS executor. It communicates with ROS 2 through Zenoh and interoperates with standard ROS 2 nodes using rmw_zenoh_cpp.

The main features are:

  • Interoperability with Jazzy and Lyrical
  • Designed for asyncio and asynchronous Python
  • Topics, services, and QoS
  • Custom ROS messages defined directly with Python classes
  • Installation through pip with minimal dependencies

A subscriber looks like this:

import asyncio

import asyncio_for_robotics as afor
import pyzeros
from ros2_pyterfaces.cyclone.all_msgs import String


async def main():
    sub = pyzeros.Sub(String, "chatter")
    async for msg in sub.listen_reliable():
        print(msg.data)


with pyzeros.auto_context(node="listener", namespace="/demo"):
    asyncio.run(main())

Why another ROS 2 client?

You’ll find that Rust has many independent ROS 2 client implementations, all with interesting designs and trade-offs. In Python, however, we have only rclpy, and RoboStack+Pixi as (fantastic) alternative installation method.

I made PyZeROS as a Python-native option built around standard Python tooling and asyncio. It’s not a repackaging of rclpy or rcl and is widely different from it. The goal is to communicate with a ROS network from python, not to integrate with the whole ROS ecosystem.

Main differences are:

  • PyZeROS installs through pip, so it should work easily with standard isolated-environment tooling like venv, uv, pipx, uvx, pixi.
  • It is primarily coded in python so no additional colcon build to compile a message types. And Python developers can dive into the source code.
  • It uses standard Python tools and small dependencies. It should run mostly anywhere.
  • PyZeROS deliberately does not aim to support every ROS feature. The Python ecosystem is prioritized: argparse for configuration, subprocess for launching processes, and importlib.resources for shared package data.
  • asyncio is the primary executor.

Why asyncio?

Robots are asynchronous systems, so they need an execution model. Python already has one: asyncio, so I use it.

Using callbacks directly is possible, but it can quickly lead to shared-state issues, locks, and complicated lifecycle management. After using asyncio in robot applications for several years, I find async/await much easier to reason about, and the python community has many tools for it. In my benchmarks, PyZeROS is also significantly faster than rclpy’s callback-and-executor model, so there does not appear to be a large performance hit from asyncio.

Custom messages

This is essential to ROS, and making them easy to define was especially important to me. In PyZeROS, you can define them directly as Python dataclasses and interoperate with standard ROS 2 messages:

from dataclasses import dataclass, field

import pyzeros
from ros2_pyterfaces.cyclone import all_msgs, idl


@dataclass
class Sphere(
    idl.IdlStruct,
    typename="tutorial_interfaces/msg/Sphere",
):
    center: all_msgs.Point = field(default_factory=all_msgs.Point)
    radius: idl.types.float64 = 0.0


pub = pyzeros.Pub(Sphere, "sphere")
pub.publish(Sphere(radius=42.0))

There is no .msg file, CMake configuration, or colcon build required on the PyZeROS side. For interoperability, the type name, field names, and field types must match the message definition used by the other ROS 2 nodes.

Performance

I also measured PyZeROS against rclpy for round-trip latency:

  • PyZeROS: ~13 µs
  • rclpy with SingleThreadedExecutor: ~70 µs

This is about 5.5× faster in this microbenchmark.

The benchmark sends sensor_msgs/msg/JointState messages continuously inside one node using two publisher/subscriber pairs. Keeping everything local minimizes transport latency, so the benchmark primarily measures executor and message serialization/deserialization overhead.

The benchmark code and complete results are available here: GitHub - 2lian/afor_benchmarks · GitHub

I also tested PyZeROS in a more realistic stress test with 100 nodes publishing mostly JointState messages at around 10 Hz. This uses my own ROS nodes for controlling a robot swarm that I have been working on for several years. In that application, the PyZeROS version used roughly one-quarter of the CPU used by the rclpy version.

Related libraries I created for PyZeROS

ros2-pyterfaces is how I define messages in Python. It provides XCDR1 serialization and ROS RIHS01 type hashes. It can serialize using cyclone_idl (tweaked by me) or cydr (created by me), with cydr being faster than rclpy to ser/de messages. It is a standalone low-level library, so it can also be used independently to send ROS messages over DDS or another RMW:

asyncio-for-robotics (afor) is the asynchronous model that I’ve been using on my robot software for a while now. It already supports ROS (rclpy) and other systems, and it now supports Lyrical and its new AsyncNode:

Feedback, testing, issues, and contributions are very welcome. I am sure there are still some rough edges, but I cannot wait indefinitely for perfection before releasing it. Reaching this point took a long time. ROS is a large ecosystem, and I am already very happy to have topics and services working

9 posts - 3 participants

Read full topic

by 2lian on July 20, 2026 07:03 PM

OnSLAM: Run LiDAR-inertial mapping on ROS1 bags directly from Windows

Hi everyone,

I recently released OnSLAM, an open-source Windows application for running LiDAR-inertial odometry and mapping on ROS1 bag files.

It automatically detects compatible LiDAR and IMU topics, runs the mapping pipeline locally, visualizes the trajectory and point-cloud map in the browser, and exports PLY and PCD files.

The main goal is to make it easier to inspect datasets, demonstrate LIO mapping, and generate maps without rebuilding a complete Linux and ROS environment.

The project is still early, and I am looking for users willing to test it with different sensors and datasets.

GitHub: GitHub - musabali314/OnSLAM: A Windows app for local LiDAR-inertial mapping of ROS1 bag files with live point-cloud visualization and PLY/PCD export. · GitHub

Demo: https://youtu.be/VGmrXOI95Uo?si=oqzMvNMH3C0D9Zje

I would especially appreciate feedback from anyone using Livox, Ouster, Velodyne, or Hesai data.

1 post - 1 participant

Read full topic

by musabali314 on July 20, 2026 04:04 PM

July 17, 2026
AgileX NERO Robotic Arm Control with OpenClaw

1.Introduction

The recent popularity of OpenClaw has sparked a wave of enthusiasm for building personal robotic assistants. In this tutorial, we’ll demonstrate how to write an OpenClaw Skill that enables simple control of the AgileX NERO robotic arm.

Before proceeding, make sure you have already installed and configured the OpenClaw environment. Please refer to the official OpenClaw documentation for installation instructions.

2. Writing an OpenClaw Skill

Inside your OpenClaw agent workspace, create the following files under the skills directory:

.
├── config
│   └── hands_ctrl.yaml
├── scripts
│   └── hands_ctrl.py
└── SKILL.md

In this example, we are using the Three Provinces and Six Ministries multi-agent architecture, so the skill is placed inside the workspace of the Crown Prince agent, as shown below.

Don’t worry if you are not using this multi-agent architecture. The following implementation works equally well for a standard OpenClaw workspace.

2.1 SKILL.md

The contents of SKILL.md are shown below:

---
name: hands_ctrl
description: Use when the user wants OpenClaw to perform physical hand gestures like shaking hands or waving, or to recover/reset the hardware task. Executes the corresponding Python script based on user intent and securely interrupts any ongoing gesture before starting a new one.
---

# Gesture Control for OpenClaw

Use this skill when the user wants OpenClaw to act as a gesture controller for the hardware or robotic system.

## Inputs

Accept natural language commands or explicit action requests, such as:

- "握手", "shake hands", "let's shake"
- "挥手", "wave at me", "say hello"
- "恢复", "恢复任务", "recover", "reset"

Derive the intended action (`shake`, `wave`, or `recove`) from the user's input before execution.

## Interruption Handling (Ctrl + C)

Hardware can only perform one gesture safely at a time to prevent motor conflicts. 
If the user requests a new gesture or a recovery command while a previous `hands_ctrl.py` process is still executing, you MUST interrupt the active process first. Send a `Ctrl + C` (SIGINT) to the running process to safely cancel the current hardware action before executing the new command. Ensure no orphaned background processes are left behind.

## Modes

### Handshake

Use when the user issues a handshake command.

Produce the following execution:

~~~bash
python3 skills/scripts/hands_ctrl.py --action shake
~~~

Implement this execution with:
- strict passing of the `--action shake` argument.
- capturing of standard output to confirm the hardware received the command.

### Wave

Use when the user issues a wave command.

Produce the following execution:

~~~bash
python3 skills/scripts/hands_ctrl.py --action wave
~~~

Implement this execution with:
- strict passing of the `--action wave` argument.
- capturing of standard output to confirm the hardware received the command.

### Recover

Use when the user issues a command to recover or reset the task.

Produce the following execution:

~~~bash
python3 skills/scripts/hands_ctrl.py --action recove
~~~

Implement this execution with:
- strict passing of the `--action recove` argument.
- capturing of standard output to confirm the hardware received the command.

## Backend Rules

Prefer executing the provided script over reimplementing the logic. Use `skills/scripts/hands_ctrl.py` as the sole backend interface for these gestures. Do not attempt to modify or rewrite the hardware control logic within the script unless explicitly asked to do so. Ensure process termination (SIGINT / Ctrl + C) is handled gracefully by the system.

## Packaging Rules

- The execution context must be at the root of the workspace so that the relative path `skills/scripts/hands_ctrl.py` is valid.
- Ensure the Python environment has the necessary dependencies installed to run the script.

## Workflow

1. Acquire and parse the user's intent from the prompt.
2. Analyze whether the intent maps to the Handshake, Wave, or Recover mode.
3. Check if there is an active `hands_ctrl.py` process currently running.
4. If a process is running, send a `Ctrl + C` (SIGINT) to terminate it and wait for it to stop completely.
5. Verify the existence of the `skills/scripts/hands_ctrl.py` file locally.
6. Execute the command corresponding to the matched mode.
7. Capture execution logs (`stdout` and `stderr`).
8. Update the user on the success or failure of the hardware action, clearly stating if a previous action was interrupted via Ctrl + C.

## Output Expectations

When reporting progress or final results, include:

- detected gesture intent (shake, wave, or recove)
- whether a previous process was interrupted via Ctrl + C
- the exact script command executed
- validation of execution (e.g., success message or error trace)
- open risks or hardware backend limitations

2.2 How the Skill Works

This Skill simply maps natural-language commands to different execution modes.

  • When the user says “shake hands”, OpenClaw executes:
python3 skills/scripts/hands_ctrl.py --action shake

  • When the user says “wave”, it executes:
python3 skills/scripts/hands_ctrl.py --action wave

  • When the user requests “recover” or “reset”, it executes:
python3 skills/scripts/hands_ctrl.py --action recove

All three commands invoke the same backend script : hands_ctrl.py. The actual hardware control logic is implemented inside this Python script. The Skill itself is responsible only for invoking the script with the appropriate command-line argument.

2.3 hands_ctrl.py

The implementation of hands_ctrl.py is shown below.

import time
import argparse
import yaml
from pyAgxArm import create_agx_arm_config, AgxArmFactory


def wait_motion_done(robot, timeout: float = 5.0, poll_interval: float = 0.1) -> bool:
    """Wait until the robotic arm reaches the target position or the operation times out."""
    time.sleep(0.5)
    start_t = time.monotonic()

    while True:
        status = robot.get_arm_status()

        if status is not None and getattr(status.msg, "motion_status", None) == 0:
            return True

        if time.monotonic() - start_t > timeout:
            print(f"Timed out waiting for motion completion ({timeout:.1f}s)")
            return False

        time.sleep(poll_interval)


# Set the following three parameters to None by default so that the
# "recove" action can be executed independently without requiring them.
def main(action_name, pose_prepare=None, pose_left=None, pose_right=None):

    # Create the robotic arm configuration and establish the connection
    cfg = create_agx_arm_config(robot="nero", comm="can", channel="can0")
    robot = AgxArmFactory.create_arm(cfg)
    robot.connect()

    # Switch to Normal Mode and enable CAN communication
    print("Switching to Normal Mode and enabling CAN communication...")
    robot.set_normal_mode()
    time.sleep(1)

    # Enable the robotic arm
    print("Enabling the robotic arm...")
    while not robot.enable():
        time.sleep(0.01)

    print("Robotic arm enabled successfully.")

    # Set the motion speed percentage
    robot.set_speed_percent(80)

    # Center (safe) pose of the robotic arm
    pose_center = [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

    if action_name == "recove":
        print("\nExecuting recovery action: moving the robotic arm to the safe position...")
        robot.move_j(pose_center)
        wait_motion_done(robot, timeout=8.0)
        time.sleep(1)
        print("The robotic arm has returned to the safe position. Program finished.")
        return

    print(f"Executing action: {action_name}")
    print(
        f"Motion parameters:\n"
        f"Preparation pose: {pose_prepare}\n"
        f"Left pose: {pose_left}\n"
        f"Right pose: {pose_right}"
    )

    try:
        print("Moving to the center pose...")
        robot.move_j(pose_center)
        wait_motion_done(robot, timeout=8.0)

        print("Moving to the preparation pose...")
        robot.move_j(pose_prepare)
        wait_motion_done(robot, timeout=8.0)

        print(f"Starting continuous '{action_name}' motion (Press Ctrl+C to stop)...")

        cycle_count = 0

        while True:
            cycle_count += 1

            print(f"Cycle {cycle_count} - Pose 1")
            robot.move_j(pose_left)
            wait_motion_done(robot)

            print(f"Cycle {cycle_count} - Pose 2")
            robot.move_j(pose_right)
            wait_motion_done(robot)

    except KeyboardInterrupt:
        print("\nMotion interrupted by the user. Returning to the center pose...")
        robot.move_j(pose_center)
        wait_motion_done(robot)

    finally:
        time.sleep(1)
        print("Program finished.")


if __name__ == "__main__":

    parser = argparse.ArgumentParser(
        description="Control the AgileX NERO robotic arm using predefined motions loaded from a YAML configuration file."
    )

    # Path to the YAML configuration file
    parser.add_argument(
        "--config",
        type=str,
        default="skills/config/hands_ctrl.yaml",
        help="Path to the YAML configuration file (default: skills/config/hands_ctrl.yaml)",
    )

    # Action to execute
    parser.add_argument(
        "--action",
        type=str,
        choices=["wave", "shake", "recove"],
        default="wave",
        help='Name of the action to execute. It must match a key in the YAML file. '
             'The "recove" action is built-in and does not require YAML parameters '
             "(default: wave).",
    )

    args = parser.parse_args()

    if args.action == "recove":
        main(args.action)
        exit(0)

    try:
        with open(args.config, "r", encoding="utf-8") as f:
            config_data = yaml.safe_load(f)

    except FileNotFoundError:
        print(f"Error: Configuration file '{args.config}' not found.")
        exit(1)

    except yaml.YAMLError as e:
        print(f"Error parsing the YAML configuration file: {e}")
        exit(1)

    # Retrieve the parameters for the selected action
    actions_dict = config_data.get("actions", {})

    if args.action not in actions_dict:
        print(f"Error: Action '{args.action}' was not found in the configuration file.")
        exit(1)

    selected_action = actions_dict[args.action]

    pose_prepare = selected_action.get("pose_prepare")
    pose_left = selected_action.get("pose_left")
    pose_right = selected_action.get("pose_right")

    if not all([pose_prepare, pose_left, pose_right]):
        print(
            f"Error: The action '{args.action}' is missing required parameters "
            "(pose_prepare, pose_left, pose_right)."
        )
        exit(1)

    main(args.action, pose_prepare, pose_left, pose_right)

3. Script Overview

This script controls the AgileX NERO robotic arm using predefined motion parameters stored in a YAML configuration file.

The YAML file defines each motion sequence using three joint-space poses:

  • Preparation pose
  • Left pose
  • Right pose

When the program starts, it performs the following steps:

  1. Creates the robotic arm configuration and establishes the connection.
  2. Switches the robot into normal operating mode.
  3. Enables CAN communication.
  4. Enables the robotic arm.
  5. Sets the motion speed.
  6. Executes the requested action based on the command-line argument.

Three actions are currently supported:

  • Wave
  • Shake Hands
  • Recover

For both the wave and shake actions, the robot first moves to a preparation pose and then continuously alternates between the left and right poses until the user interrupts the program with Ctrl+C.

When interrupted, the script automatically returns the robotic arm to its center (safe) position before exiting.

The recover action is a built-in recovery command that immediately moves the robotic arm back to its predefined safe position.

4.YAML Configuration

The motion parameters are stored in hands_ctrl.yaml.

actions:
  wave:
    pose_prepare: [0.8, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
    pose_left: [0.8, 0.0, 0.0, 0.6, -0.6, 0.0, 0.0]
    pose_right: [0.8, 0.0, 0.0, -0.6, -0.6, 0.0, 0.0]

  shake:
    pose_prepare: [0.0, 0.6, 0.0, 1.0, 1.57, 0.0, 0.0]
    pose_left: [0.0, 0.6, 0.0, 1.0, 1.57, 0.0, 0.0]
    pose_right: [0.0, 0.6, 0.0, 0.6, 1.57, 0.0, 0.0]

Each action consists of three joint-space poses:

  • pose_prepare – The initial pose before starting the motion.
  • pose_left – The first motion pose.
  • pose_right – The second motion pose.

The Python script loads these poses at runtime and executes the corresponding motion sequence according to the selected action.

5.Demo

After completing the configuration above, you can control your OpenClaw-powered robotic assistant using natural language and command the AgileX NERO robotic arm to perform simple gestures such as waving, shaking hands, and recovering to a safe position.

The demonstration is shown below.
2026-03-27-16-20-40 (1)

FAQ

Q1:Can OpenClaw Control Real Robots?

Yes. OpenClaw is responsible for task understanding and Skill execution. Through Skills, it can connect to external programs and hardware devices, enabling control of real robots.

Q2:What Is an OpenClaw Skill?

An OpenClaw Skill is a modular extension that expands the capabilities of an AI Agent. Developers can define trigger conditions and execution logic in a SKILL.md file, allowing the Agent to invoke the appropriate scripts based on natural language instructions.

Q3: How Do You Use OpenClaw to Control the NERO 7-DoF Robotic Arm?

The control workflow includes the following steps:

  1. Install and configure the OpenClaw environment.
  2. Create a robot control Skill.
  3. Develop a Python script for hardware control.
  4. Configure robot motion parameters using a YAML file.
  5. Trigger robotic arm actions through natural language commands.

Q4: Why Use a YAML Configuration File?

A YAML file stores the motion parameters of the robotic arm, separating motion data from the control logic. This design allows developers to create or modify robot actions simply by updating the pose parameters in the YAML file, without changing the underlying Python control code.

Q5:Is Controlling a Robot with OpenClaw Considered Embodied AI?

The combination of OpenClaw and physical robot hardware represents a practical approach to enabling AI Agents to interact with the physical world. It is one of the promising directions being explored in the field of Embodied AI.

:speech_balloon: Have Question?

If you encounter any issues with environment installation, parameter configuration, or RL training, feel free to leave your questions for further discussion.

1 post - 1 participant

Read full topic

by Agilex_Robotics on July 17, 2026 10:09 AM

July 15, 2026
Opportunity for ROS Developers: AMD AI DevMaster Hackathon Physical AI Track

AMD AI DevMaster Hackathon

Official Registration: AMD AI DevMaster Hackathon · Luma

Overview

​Join developers, researchers, students, AI practitioners, and open-source contributors worldwide to build innovative AI applications on AMD Radeon™ GPUs and the ROCm™ software stack. The AMD AI DevMaster Hackathon is a fully online global competition featuring three innovation tracks: Agentic AI, Multimodal AI, and Physical AI. Participants can build individually or in teams of up to three members and compete for a share of USD $30,000 prize pool. Registered participants may also receive access to AMD GPU resources during the hackathon period.

:trophy: $30,000 USD Prize Pool

:laptop: Free AMD Radeon GPU Access

:globe_showing_europe_africa: Attend Online & Submit Online

:rocket: Three AI Innovation Tracks

:busts_in_silhouette: Individuals or Teams (up to 3 members)

:white_check_mark: Registration

​To be eligible for judging, awards, and prize payments, participants must:

​Register as a member of the AMD AI Developer Program before joining this virtual event

​Global developers: AMD AI Developer Program

​Only for developers in Mainland China: AMD Developer Program China

​Meet all eligibility requirements outlined in the official Rules & Conditions document

:police_car_light: Prize Eligibility Notice: Participants who are not registered members of the AMD AI Developer Program will not be eligible to receive prize money, even if their submission is selected as a winning project.

:date:Hackathon Schedule

Registration Opens

Beijing/Singapore (UTC+8): July 10, 2026, 12:00 AM

Europe (CEST): July 9, 2026, 6:00 PM

US Pacific (PDT): July 9, 2026, 9:00 AM

Submission Opens

Beijing/Singapore (UTC+8): July 15, 2026, 12:00 AM

Europe (CEST): July 14, 2026, 6:00 PM

US Pacific (PDT): July 14, 2026, 9:00 AM

Hackathon Ends / Final Submission Deadline

Beijing/Singapore (UTC+8): August 6, 2026, 11:59 PM

Europe (CEST): August 6, 2026, 5:59 PM

US Pacific (PDT): August 6, 2026, 8:59 AM

:bullseye: Choose Your Track

​Choose one of three innovation tracks designed to showcase practical AI applications accelerated by AMD Radeon GPUs and ROCm.

:robot: Track 1: Multimodal AI

​Create next-generation AI experiences that combine text, images, video, audio, and visual generation technologies. Examples include text-to-image systems, image editing applications, image-to-video workflows, content creation studios, style transfer tools, digital media enhancement solutions, and creator-focused applications. Participants are encouraged to demonstrate efficient deployment and acceleration using Radeon GPUs.

Judging Criteria (100 points):
• Functional completeness, practical value, and innovation: 80 points
• Operational performance on AMD Radeon GPUs: 20 points.

:artist_palette: Track 2: Agentic AI

​Build intelligent AI agents capable of reasoning, planning, tool use, memory management, and task execution. Example applications include personal productivity assistants, enterprise copilots, workflow automation agents, local knowledge assistants using RAG, developer productivity agents, and multi-agent systems. Projects should demonstrate local inference on AMD Radeon GPUs and showcase practical problem-solving capabilities.

Judging Criteria (100 points):
• Functional completeness and application value: 60 points
• Scenario innovation and user experience: included within functional evaluation
• AMD Radeon GPU and ROCm optimization: 40 points, including local inference execution and inference-speed optimization.

:mechanical_arm: Track 3: Physical AI

​Develop robotics and embodied AI solutions powered by AMD Radeon GPUs. Projects may focus on robotic manipulation, humanoid robotics, quadruped locomotion, autonomous navigation, robotics simulation, autonomous driving simulation, multi-agent robotics, or embodied AI research. Participants may leverage simulation environments such as Genesis, MuJoCo, or other open-source frameworks and demonstrate how GPU acceleration supports training, simulation, and inference.

Judging Criteria (100 points):
• Robot capability performance: 30 points
• AMD Radeon GPU and ROCm adoption: 20 points
• Innovation and originality: 20 points
• Real-world application value: 20 points
• Contributions to upstream open-source projects: 10 points.

:trophy:Total Prize Pool: $30,000 USD

Each track offers:

:1st_place_medal: 1st Place: $5,000 USD

:2nd_place_medal: 2nd Place: $3,500 USD

:3rd_place_medal: 3rd Place: $1,500 USD

:laptop: Free AMD Radeon GPU Access

​Eligible participants may receive access to AMD Radeon GPU development resources during the competition period for model development, optimization, testing, benchmarking, and final project preparation.

:globe_showing_americas:Developer Community and Technical Support

​Participants are not expected to work alone. Dedicated community channels will be available throughout the hackathon.

Discord Channel: [ AMD Developer Community ]

WeChat Group:

User Uploaded Image
​For questions, please send us email via: ai_dev_contests@amd.com

:books: Rules and Conditions

​The attached Rules and Conditions document serves as the governing document for eligibility, judging methodology, submission requirements, code of conduct, intellectual property provisions, payments, and legal requirements. Participants are responsible for reviewing the complete document before submitting a project.

1 post - 1 participant

Read full topic

by Ranjun_Hua on July 15, 2026 03:01 PM


Powered by the awesome: Planet