Planet ROS

ROS Discourse General: Launching the VLAs on the Humanoid robot(G1, T800) for continues tasks

Thu, 13 Aug 2026 12:16:47 +0000

So, current issue of the launching VLAs on the Humanoids, like G1 Unitree\EngineAI T800\another,

is the realsense pack of cams. F.e., for the unifolm vla (GitHub - unitreerobotics/unifolm-vla · GitHub), you need 2 on wrists + 2 on shoulders, so its kinda there is no another way without realsense?

Currently kinda stuck on this type of the issue, maybe someone know the solution?

1 post - 1 participant

Read full topic

ROS Discourse General: Want to get involved with ROS 2? Come to Waffle

Thu, 13 Aug 2026 01:39:23 +0000

One of the most common questions we get is some version of “how do I start contributing?”
Here is a concrete answer: join us for Waffle, Thursdays, 30 minutes.

What it is

Waffle is a weekly triage meeting. We go through the issues and pull requests coming into the ROS 2 repositories that nobody has picked up yet, and we quickly discuss, triage, and assign them.

It moves fast. Most items get a minute or two: what is this, is it valid, who should look at it. We assign things live in the meeting rather than writing them down for later. In half an hour we get through a lot.

Why it’s a good on-ramp

(via easily digestible bullets!)

No preparation. Show up, look at the queue with us.
No commitment. Come once, come when you can, leave early if you need to.
You don’t need to be a committer. Anyone is welcome.
You’ll see how the project actually works. Half an hour of watching maintainers make real decisions about real code teaches you more about the project than a lot of reading.
It’s a good way to find something to work on. Plenty of what crosses the queue is well-scoped and looking for someone. That someone could be you.

If you already know one corner of the stack well, you are especially useful. Being able to glance at an incoming PR and say “this looks fine” or “this will break X” is exactly the thing we never have enough of.

One thing it isn’t

Waffle is not the place to bring your own issue or pull request. We work through the queue in order, and carving out time for individual requests is what turns a 30 minute meeting into a 90 minute one. If you need eyes on something specific, Discourse or Zulip is the right venue.

Details

When: Thursdays, 30 minutes, Thu, Aug 13, 2026 4:30 PM UTC
Where: Google Meet
The Board: The Baffle Board

Just turn up. We’re glad to have you.

_{Why “Waffle”? The meeting is named after waffle.io, the GitHub-backed kanban board we used to run triage on years ago. The service is long dead, the name stuck. The board we use now is generated by Baffle Maker, built by @andrew_symington, which is a Bazel waffle board, and also a baffle is the partition you put in a duct to control the flow of what’s coming through it. Make of that what you will. It is a large part of why this meeting runs as well as it does now.}

1 post - 1 participant

Read full topic

ROS Discourse General: Analyzing rosbags with LLMs and SQL + queryable Nav2 behavior trees

Wed, 12 Aug 2026 09:28:35 +0000

A few weeks ago @jopequ shared mcp-rosbags + mcp-lab ( Another MCP Server to analyze your rosbags with LLMs + a UI to benchmark it against different LLM providers ) — an MCP server with purpose-built analysis tools (trajectories, laser scans, tf, plotting) and a neat UI for benchmarking providers on it. We’ve been working on the same problem at Pixel Robotics (AMRs for pallet transport) and just wrote up our approach, which lands on a different point in the design space, so I thought a comparison might be useful to the community:

we use mcap-mcp-server, that uses a database under the hood. This allows complex queries / joins to the rosbag for fast analysis. This also means that no specific tools are needed, the LLM already knows how to use SQL
by extending nav2 BT logging, we can query the behavior tree log efficiently
we share an agent skill that sets up everything to get started

More details, an example walk through and a video in the blog post! How we analyze robot behavior with LLMs — rosbags as SQL

1 post - 1 participant

Read full topic

ROS Discourse General: Properly close windows processes, discussion about implementation

Tue, 11 Aug 2026 12:00:47 +0000

So I went into a bit of a rabbit whole last week! CI on windows kept on getting this particular error:

2: [WARNING] [python.exe-2]: 'SIGINT' sent to process[python.exe-2] not supported on Windows, escalating to 'SIGTERM'

Apparently, windows does not have a proper way to handle SIGINT, which means that it always straight goes to the ungraceful shutdown of SIGTERM.

So I thought “oh! is that perhaps the reason why we keep getting all of the unhandy access violation ( 3221225477) that we see ever since we went switched ci to server-2025?”

The answer is… it’s not that simple…

I tried these two repositories on CI where I tried to have the testing use the proper CTRL_C_EVENT, CTRL_BREAK_EVENT signals and such:

GitHub - knmcguire/osrf_pycommon at new-sigterm-win · GitHub (I had to remove osrf_pycommon from pixi.toml)
(Renamed from ros2/launch) GitHub - knmcguire/ros2_launch at new-sigterm-win · GitHub

… which resulted in this CI run with even more failures than before: https://ci.ros2.org/job/ci_windows/28952/

So this went a little too deep then I was comfortable with, but I at least tried to implement some of the suggestions given in these issues and old and closed PR

github.com/ros2/launch

Use signal.CTRL_C_EVENT on windows instead of signal.SIGINT (#306)

master ← ivanpauno/use-ctrl-c-event-on-windows

opened 09:30PM - 14 Aug 19 UTC

ivanpauno

+1 -5

We were using `signal.SIGTERM` on windows instead of `signal.SIGINT`. I think t…hat `signal.CTRL_C_EVENT` is the correct signal to be send in replacement of `signal.SIGINT`, which is not supported in [SubprocessTransport.send_signal](https://docs.python.org/3/library/subprocess.html#subprocess.Popen.send_signal). Related with https://github.com/ros2/ros2cli/pull/315. See https://github.com/pypa/setuptools/issues/1818.

Anyway! I failed in this but perhaps someone interested to give more ideas and thoughts, and perhaps want to have a go? It would be nice to actually terminate windows nodes properly this time, and might also fix some other things in the process as well. In general there have been many complaints of ghost processes still hanging after termination, not only on Windows.

This is a list of intersting issues and PRs I saw open during my research, as it might be handy for others as well:

Windows Signal Handling Issue · GitHub
Hang after repeated ctrl+c on Windows Hang after repeated ctrl+c on Windows · Issue #310 · ros2/launch_ros · GitHub
Tests on Windows falsely positive reporting passed due to SIGINT handling Tests on Windows falsely positive reporting passed due to SIGINT handling · Issue #767 · ros2/launch · GitHub
incorrect signal handling: Incorrect signal handling · Issue #666 · ros2/launch · GitHub
Kill dangling subprocesses https://github.com/ros2/launch/pull/632
Ivanpauno/kill dangling subprocesses
Ivanpauno/kill dangling subprocesses by anton-matosov · Pull Request #936 · ros2/launch · GitHub
Gracefully handle CTRL+C and CTR+Break events on Windows Issue · GitHub
Gracefully handle CTRL+C and CTR+Break events on Windows Gracefully handle CTRL+C and CTR+Break events on Windows by MichaelOrlov · Pull Request #1342 · ros2/rosbag2 · GitHub
Gracefully handle SIGINT and SIGTERM in rosbag2 recorder https://github.com/ros2/rosbag2/pull/1301
Use signal.CTRL_C_EVENT on windows instead of signal.SIGINT Use signal.CTRL_C_EVENT on windows instead of signal.SIGINT by ivanpauno · Pull Request #306 · ros2/launch · GitHub

Love to hear your thoughts!

3 posts - 2 participants

Read full topic

ROS Discourse General: Exploring a human-reviewed ROS 2 agentic pipeline generator

Sun, 09 Aug 2026 23:58:56 +0000

I am prototyping **EdgeAI Forge**, a local-first engineering architecture intended to help generate, test, benchmark, and document ROS 2 and machine-vision pipelines.

The initial target workflow is a ROS 2 vision pipeline generator. Given a requirement such as:

> Read frames from a USB camera, run object detection, publish detections, expose health status, benchmark performance, and prepare deployment to Jetson.

the system should eventually produce reviewed artifacts including:

- package manifests and directory structure;

- Python or C++ nodes;

- topics, messages, services, and actions;

- parameters and launch files;

- unit, integration, and launch tests;

- simulation or recorded-data validation;

- Docker/Jetson packaging;

- FPS and latency benchmarks; and

- assumptions, limitations, and operating documentation.

The current proof of concept contains Planner, Vision, and ROS prompt agents backed by a local Ollama endpoint. It generates design output, not production-ready ROS packages. A broader scaffold contains API, dashboard, infrastructure, and observability components.

The safety boundary is important: generated robot-motion or production-deployment artifacts should never run automatically. The intended sequence includes simulation, test evidence, human review, explicit approval, logging, and rollback.

I would appreciate feedback from the ROS community on:

1. Which package archetype would make the best first supported template?

2. How should generated packages be evaluated beyond compilation and linting?

3. Which launch_testing, rosbag, Gazebo, or other simulation patterns should be mandatory?

4. How should the generator encode QoS, lifecycle nodes, diagnostics, and hardware assumptions?

5. What safeguards would make this useful without encouraging unsafe deployment practices?

Project: GitHub - afridali123/EdgeAI_Forge · GitHub

Background: EdgeAI Forge: My Journey Toward a Local Agentic AI Platform for Industrial Automation

The project is early, and I am sharing it to collect design criticism before implementing the deeper ROS workflow.

1 post - 1 participant

Read full topic

ROS Discourse General: Some Knowledge about ros

Sun, 09 Aug 2026 23:58:45 +0000

Hi everyone!

I’m a 2nd-year Mechanical Engineering student at NIT Jalandhar, currently exploring Robotics and Automation.

I’m starting my journey with C++/Python, electronics, CAD and eventually ROS 2. My long-term goal is to work on real robotics projects and eventually pursue research/internship opportunities in robotics.

I’m looking to connect with:
• Students who are also learning Robotics/ROS 2
• People working on interesting robotics projects
• Researchers/engineers who are open to collaboration or guidance
• Students who have previously pursued robotics research internships

If you’re on a similar journey, I’d love to connect and learn together.

Also, if there are any beginner-friendly open-source robotics projects where a student can contribute, I’d really appreciate suggestions.

Thanks!

1 post - 1 participant

Read full topic

ROS Discourse General: Robotics Student - Perception Systems Question

Sun, 09 Aug 2026 23:58:07 +0000

Hi all, I’m an MEng Robotics & AI student at UCL working on perception/tracking pipelines (recently built a person re-ID and tracking evaluation pipeline, and a Gaussian-splat reconstruction quality evaluator). I’m trying to understand a specific problem better: how do teams currently notice when a perception or sensor-fusion stack has silently degraded in production, before it causes a visible failure? Do you rely on manual spot-checks, logging + alerts, a formal calibration schedule, or something else? Genuinely trying to learn what’s actually painful here vs. what’s already a solved problem, not selling anything. Would appreciate any war stories, even short ones.

2 posts - 2 participants

Read full topic

ROS Discourse General: Advice on breaking into US robotics/embedded industry as a US citizen with no US history

Sun, 09 Aug 2026 23:57:52 +0000

I’m a 4th-year Computer Engineering student in Palestine (Birzeit University, graduating 2027). I focus on embedded systems and robotics. I have US citizenship, but I never lived or worked in the US. There’s no embedded or robotics industry here at all, so I can’t really build experience or a network locally. I’m trying to move to the US, but I’m not sure where to start.

My background: ROS2 control software for a multi-agent robotics platform, FreeRTOS firmware on custom boards, and a competition robot (WRO Future Engineers) that I built from the PCB up to the low level firmware. I’m fine with relocating, that’s not a problem for me.

I’m not sure what the right next step is. Should I look for a job directly, try to get into a US grad program first, or something else? If you work in robotics or made a similar move yourself, what would you do in my place?

2 posts - 2 participants

Read full topic

ROS Discourse General: ROS2 Dev Container Feature + Workspace Update

Sat, 08 Aug 2026 16:26:29 +0000

I’ve been working on a ROS2 Dev Container Feature and just updated my VSCode ROS2 Workspace Template to use it instead of my pre-built ROS Docker images.

The feature is here:

Source:

The main thing I wanted was to select the ROS distro once in devcontainer.json and have both local development and CI use that same configuration.

" Package devcontainers/ros2 · GitHub ": {

“distro”: “lyrical”,

“package”: “desktop”

}

I also cleaned up a bunch of the old X11/WSLg configuration. WSL2 GUI support now works through the normal VS Code Dev Container setup, and native Linux X11 support is available as a separate opt-in feature.

If you’re using ROS2 with Dev Containers, I’d be interested to hear how it works for your setup!

1 post - 1 participant

Read full topic

ROS Discourse General: Has a CPU shared-memory backend for rosidl::Buffer been explored?

Sat, 08 Aug 2026 14:30:45 +0000

I have been looking into rosidl::Buffer and the current buffer backend support, particularly for large variable-length payloads such as images and point clouds.

One idea I am interested in is a CPU shared-memory backend for rosidl::Buffer.

I realize that this overlaps to some extent with functionality that already exists at lower layers. For example, some middleware / RMW implementations already provide shared-memory transport or other zero-copy optimizations. Depending on the implementation, moving data through shared memory may therefore already be possible without introducing a dedicated Buffer backend.

What I am trying to understand is whether there is still a useful role for shared memory at the rosidl::Buffer layer.

My interest is specifically in large variable-length fields where avoiding copies of the payload itself is useful. Rather than treating shared memory only as a transport optimization for a serialized message, a Buffer backend could potentially make the payload storage itself shared and let a buffer-aware RMW transport a descriptor or reference when appropriate.

Conceptually:

ROS message
  metadata
  rosidl::Buffer<uint8_t>
          |
          +-- CPU shared-memory backend
                  |
                  +-- shared payload storage

This seems potentially complementary to transport-level shared memory rather than necessarily a replacement for it. On the other hand, I can also imagine that the overlap with middleware-native SHM mechanisms may be a reason why such a backend has not been pursued.

In particular, I would be interested in hearing:

Has anyone already explored a CPU shared-memory backend for rosidl::Buffer?
Is sharing the backing storage of large variable-length payloads considered an intended use of the Buffer backend abstraction?

Before prototyping something in this direction, I wanted to check whether there is already related work or design discussion that I have missed. I previously explored a similar problem for CUDA IPC in this discussion, so I would especially like to avoid independently reimplementing something that is already being worked on elsewhere.

ROS Discourse General: Experimental order-sensitive consistency residual for Odometry/TF streams — minimal C++ reproducer

Sat, 08 Aug 2026 00:56:00 +0000

I briefly mentioned an order-sensitive state diagnostic in another thread, but that was the wrong place for it. Posting it separately here with an executable reproducer.

The idea is simple: three consecutive pose samples in, one scalar residual out. It quantifies how much the result shifts when you change the nesting order of state composition.

Synthetic test results:

Smooth linear motion: 4.9848e-08
Abrupt pose/orientation jump: 0.000881456

This is absolutely not a validated anomaly detector yet. Normalization, frame conventions and real-world thresholds all need work.

No ROS, Eigen, or external dependencies required to run the reproducer.

#include <cmath>
#include <iostream>

struct Q { double w,x,y,z; };
Q qc(Q q){ return {q.w,-q.x,-q.y,-q.z}; }
Q qm(Q a,Q b){ return {
  a.w*b.w-a.x*b.x-a.y*b.y-a.z*b.z,
  a.w*b.x+a.x*b.w+a.y*b.z-a.z*b.y,
  a.w*b.y-a.x*b.z+a.y*b.w+a.z*b.x,
  a.w*b.z+a.x*b.y-a.y*b.x+a.z*b.w}; }
Q add(Q a,Q b){ return {a.w+b.w,a.x+b.x,a.y+b.y,a.z+b.z}; }
Q sub(Q a,Q b){ return {a.w-b.w,a.x-b.x,a.y-b.y,a.z-b.z}; }

struct State8 { Q a,b; };
State8 compose(State8 x, State8 y) {
  return {sub(qm(x.a,y.a), qm(qc(y.b),x.b)),
          add(qm(y.b,x.a), qm(x.b,qc(y.a)))};
}

struct Pose { double x,y,z,qw,qx,qy,qz; };
State8 encode(Pose p) {
  return {{p.qw,p.qx,p.qy,p.qz},{p.x,p.y,p.z,0.0}};
}

double order_sensitive_residual(Pose A,Pose B,Pose C) {
  State8 x=compose(compose(encode(A),encode(B)),encode(C));
  State8 y=compose(encode(A),compose(encode(B),encode(C)));
  double d[8]={x.a.w-y.a.w,x.a.x-y.a.x,x.a.y-y.a.y,x.a.z-y.a.z,
               x.b.w-y.b.w,x.b.x-y.b.x,x.b.y-y.b.y,x.b.z-y.b.z};
  double s=0; for(double v:d) s+=v*v;
  return std::sqrt(s);
}

int main() {
  Pose a{.1,.001,0,.99875026,0,0,.04997917};
  Pose b{.2,.004,0,.99500417,0,0,.09983342};
  Pose c{.3,.009,0,.98877108,0,0,.14943813};

  std::cout << "smooth: " << order_sensitive_residual(a,b,c) << '\n';

  c.z=2.0; c.qw=.92106099; c.qx=.38941834; c.qy=c.qz=0;
  std::cout << "jump:   " << order_sensitive_residual(a,b,c) << '\n';
}

1 post - 1 participant

Read full topic

ROS Discourse General: [GSoC 2026] ROS 2 Client Library Performance Monitoring: Midterm Progress Update

Thu, 06 Aug 2026 20:16:21 +0000

Organization: OSRF
Contributor: Ammaar Ahmed (GitHub, LinkedIn)
Mentors: Kimberly McGuire (GitHub) and Skyler Medeiros (GitHub)
GSoC project: ROS 2 Client Library Performance Monitoring
Repository: ros2-performance-monitoring
Live dashboard: performance.ammaar.lol

Hello everyone,

I am Ammaar Ahmed. I am pursuing a bachelor’s degree in Robotics and Automation Engineering at FAST NUCES Islamabad, Pakistan. My interest in ROS began about a year and a half ago, when I started building robots with ROS running on raspberry pi.

This summer I have been working on ROS 2 client library performance monitoring with OSRF, with guidance from Kimberly McGuire and Skyler Medeiros. The project is still in progress, but its main workflow now works from benchmark execution to a public dashboard. I wanted to share what it does, what has been completed, and what I plan to improve during the rest of the GSoC period.

Why this project exists

ROS 2 gives developers several choices for how an application communicates and runs. These include different client libraries, middleware implementations, executors, communication modes, and process layouts. These choices are useful because robots have different needs, but they also make performance difficult to compare.

A change that works well for small messages may behave differently with large messages. Results can also change when nodes move from one process to several processes. Looking at one number without knowing how it was produced can therefore give the wrong impression.

ROS 2 benchmark tools already produce detailed measurements, but their output is spread across many files and test scenarios. Reading those files by hand makes it difficult to answer common questions:

Did this ROS 2 version become faster or slower?
Is a slowdown widespread, or limited to one demanding test?
Did latency improve at the cost of CPU or memory?
Were both runs produced by the same workload?

This project connects benchmark execution, result processing, and visualization. Its purpose is to make the results easier to reproduce, compare, and understand.

Current Status and Workflow

The project provides a CLI workflow for running a reduced rclcpp benchmark matrix. It covers publish/subscribe communication, client/service calls, multiple message sizes, middleware implementations, communication modes, and both single-process and multi-process layouts.

The ros2-performance-monitoring run command executes the supported benchmark suite and converts the raw benchmark outputs into a consistent JSONL format. The dashboard up command launches local Prometheus and Grafana services for interactive analysis. Docker and the Docker Compose plugin are required. The project also supports container and image reuse, CPU pinning, alternative ROS distributions, separate Pub/Sub or service suites, and additional configuration options described in the README.md.

The workflow is:

Run a ROS 2 benchmark

        ↓

Collect benchmark results

        ↓

Normalize measurements

        ↓

Compare runs in the dashboard

The dashboard helps answer both what changed and why it changed . The default view compares two benchmark runs, summarizes the overall result, and highlights the metrics that deserve attention. The manual explorer lets you compare one exact workload by matching the same topology, middleware, communication mode, payload size, and process layout on both sides. A coverage view checks whether two runs contain the same tests before comparing them.

The dashboard displays latency, throughput, CPU usage, memory usage, and message reliability where available. It also preserves benchmark metadata including the ROS distribution, middleware, executor, benchmark commit, client library source, hardware platform, payload size, and process layout.

Default comparison view

Figure X. Default dashboard comparing the median Jazzy and median Lyrical benchmark runs.

Manual explorer

Figure Y. Manual explorer showing matching benchmark configurations for detailed investigation.

The public dashboard currently contains five Jazzy runs, five Lyrical runs, and one median summary for each distribution. Every benchmark in the supported matrix runs for 60 seconds. Containers are pinned to the same physical performance cores, and the Jazzy and Lyrical run order is alternated to reduce scheduling and thermal bias. The median summaries provide the primary comparison, while the individual runs remain available to inspect run-to-run variation. Results are published only after the full dataset has been validated.

The complete workflow from running benchmarks to exploring comparisons is working locally, and the dashboard is publicly available at performance.ammaar.lol. Current work focuses on improving repeated run summaries and handling incomplete upstream benchmark data.

I would like to thank Kimberly McGuire and Skyler Medeiros for their guidance, careful reviews, and feedback throughout the project. I am also grateful to OSRF, the ROS community, and everyone who answered questions and made me feel welcome in the community.

Work completed so far

Built a single CLI workflow that prepares the benchmark project, runs it in Docker, and saves the results.
Added a consistent result format so measurements from many benchmark files can be searched and compared together.
Covered publish and subscribe tests as well as client and service tests, from 10-byte messages through 4 MiB messages.
Added support for Fast DDS, Cyclone DDS, and the available Zenoh configurations.
Recorded the context needed for fair comparisons, including ROS version, middleware, executor, process layout, communication mode, source revisions, and machine platform.
Added checks that reject missing or incompatible result files instead of silently presenting partial data as complete.
Built guided, detailed, and manual Grafana views for comparing latency, throughput, CPU, memory, reliability, and test coverage.
Replaced the confusing headline percentages with a plain language comparison result, a reason, and a suggested next action.
Added safe container reuse and image reuse so repeated benchmarks do not rebuild large Docker images unnecessarily.
Added optional CPU pinning to reduce interference on machines with different types of CPU cores.
Added tests and documentation throughout the benchmark, parsing, exporting, and dashboard workflow.
Deployed a public read only dashboard and documented how its code, data, archives, and services are maintained.

Work remaining

There is still time left in the GSoC period. The main remaining work is:

Turn repeated run aggregation into a supported command that validates matching runs, excludes warm ups, records its sources, produces median results, and communicates variability clearly.
Handle incomplete upstream output, including non finite values, missing latency files, unreliable message counters, multi-process synchronization, and pinned submodule revisions.
Make result activation and archiving safer, and move duplicated knowledge about benchmark directory layouts into shared metadata.
Fix Kilted support, improve setup documentation, and test the complete workflow on clean machines.

Support for rclpy, hosted automation, CI benchmarking, hosting under performance.ros2.org and a small local graphical launcher are possible stretch or post GSoC efforts. The CLI workflow would remain the main implementation so the project stays scriptable and reproducible.

I would value your feedback

If you work with ROS 2 performance, maintain a client library or middleware implementation, or are simply curious about how two ROS versions compare, please try the public dashboard. I would especially like to know whether the overall result makes sense without prior benchmark knowledge, whether you can find the scenario behind a warning, and what information would help you trust or question a comparison.

Feedback from both experienced ROS developers and people seeing these measurements for the first time would be very useful and appreciated from the depths of my heart. Thanks for reading.

3 posts - 2 participants

Read full topic

ROS Industrial: From URDF to SimReady: What a Robotiq Gripper Taught Us About Simulation Assets

Wed, 05 Aug 2026 21:02:52 +0000

For industrial robotics teams, simulation is useful only when the important parts of the simulated system behave enough like the real system to support better engineering decisions. A robot arm that looks right but reaches to the wrong pose is an obvious problem. A gripper that looks right but responds differently during contact can be harder to notice, and in manipulation work it may matter even more.

At Southwest Research Institute, we have been developing and evaluating Physical AI approaches for high-mix manipulation. The broader effort combines teach-through-demonstration with simulation, with the goal of supplementing demonstrations through reinforcement learning. Our lab setup includes Universal Robots UR5e arms and Robotiq 2F-85 grippers. The full workcell matters, but the gripper became the clearest example of a practical problem many robotics teams are beginning to face: the asset that is available is rarely the same thing as the asset that is ready for production-oriented simulation.

Isaac Sim representation of the lab system

Photograph of the lab setup

The first problem: available assets are not automatically usable assets

A common starting point in a simulation project is to use the assets that are already available in the simulator or in the ROS ecosystem. That was our starting point as well. Isaac Sim includes Robotiq gripper assets, and there are public Robotiq-related resources in the ROS and ROS 2 ecosystem. Those resources are valuable, but in our testing they did not immediately give us the behavior we needed.

The issues were not cosmetic. We encountered practical asset-structure and behavior problems, including difficulty restructuring an articulation root, gripper assets that were not instanceable, and contact behavior that failed when a mimic joint encountered an object asymmetrically at one finger pad. Each of those issues matters in a production-oriented simulation workflow.

For readers who do not spend their day in USD internals, an “instanceable” asset is one that can be referenced and reused cleanly rather than copied and manually modified each time. That matters when a simulated workcell becomes more complex or when the same asset must appear in many scenes. A “mimic joint” is a joint whose motion follows another joint. For a mechanically coupled gripper, mimic behavior can be the right abstraction because the physical hardware is not simply two independent fingers driven by unrelated commands.

That distinction is central to the Robotiq 2F-85.

Why the Robotiq 2F-85 is a useful test case

The Robotiq 2F-85 is a parallel gripper, but its mechanism is not as simple as two independent pads moving toward each other. It includes closed-loop mechanical behavior, which creates challenges for simulation asset authoring. The practical modeling decision becomes: should the gripper be represented with one driven joint and mimic behavior, or should both sides be driven independently?

A single driven joint with mimic behavior is attractive because it better reflects how the gripper is normally commanded. Driving both sides independently can make an asset move in simulation, but it introduces extra controller and joint-state complexity and moves the simulation farther away from the real gripper abstraction. We evaluated that path by importing a URDF into USD and adding drives to both sides. For our purposes, that direction created more complexity than value, and it likely would still have required mimic behavior to represent the coupled mechanism faithfully.

NVIDIA’s Isaac Sim documentation includes a tutorial on rigging closed-loop structures using a Robotiq 2F-85 gripper, and that tutorial points to a workflow that starts from a CAD/Onshape representation and then adds the physics, joint, and drive configuration needed to make the asset functional in Isaac Sim. That detail is important: import is only the beginning. A realistic gripper asset still needs careful authoring and validation.

What we tried from the ROS ecosystem

After our initial asset testing, we reviewed several public resources related to Robotiq grippers, including the older ROS-Industrial Robotiq repository, PickNik’s ros2_robotiq_gripper, and UW-Lab resources and assets. It’s worth noting that Robotiq does not currently provide first-party assets for its grippers; all of the resources we tested are community-maintained.

The best-performing candidate in our lab testing was the UW-Lab calibrated USD asset for the Robotiq 2F-85. That asset appears to follow the same general pattern as the Isaac Sim closed-loop structure workflow, with additional modifications. Out of the box, it behaved better than the other candidates we tested. Even though it uses mimic behavior, it did not break when an object contacted one finger before the other, and we did not observe the unexpected mesh behavior we saw elsewhere when larger forces were applied.

Simulated Robotiq 2F-85 mounted on the UR arm

That made the UW-Lab asset a much better starting point. It did not make the problem disappear.

The remaining fidelity gap

The physical Robotiq 2F-85 still exhibited behavior that the simulation did not capture. In the real gripper, when an object is grasped near the base-side region of the finger pads, the pads can angle inward slightly. When the object is grasped farther out on the pads, the pads remain parallel.

In our simulation, that behavior was not represented. The simulated kinematics and physics did not capture the same pad motion we observed on the physical gripper.

Physical Robotiq 2F-85 on the lab robot

That may sound like a small difference. In manipulation, small differences at the contact interface can become large differences in outcome. A grasping policy trained or validated in simulation is sensitive to contact geometry, friction, compliance, joint coupling, and failure modes. A gripper asset that works for visualization may still be insufficient for reinforcement learning, synthetic data generation, or pre-deployment validation.

The broader lesson: conversion is not fidelity

ROS users tend to start with URDF, and for good reason. URDF is familiar, widely supported, and often the most available robot description format for ROS-based systems. SDF is also common in simulation workflows. USD and OpenUSD offer a powerful scene representation for modern simulation and digital-twin workflows. But moving from URDF or SDF to USD does not automatically create the physical and behavioral information needed for high-fidelity simulation.

A converter can translate what is present. It cannot reliably invent what is missing.

That is where the SimReady idea is useful. NVIDIA describes SimReady as more than placing simulation data into a USD file. The goal is to represent simulation-ready content through named, typed, validated properties that tools can interpret, validate, and use. In NVIDIA’s broader description, SimReady assets include physics properties, semantic labels, material attributes, and, where needed, behavioral or articulation data.

For robotics teams, that framing exposes the real gap. A useful production asset is not merely a mesh. It is not merely a URDF. It is not merely a USD file. It is a validated representation of geometry, kinematics, dynamics, contacts, materials, semantics, and control-relevant behavior at the level required by the task.

Practical takeaways for robotics teams

First, validate assets against the behavior that matters for the application. Loading the asset, moving the joints, and rendering the workcell are necessary checks, but they are not enough. For manipulation, validation should include contact cases, asymmetric grasps, edge grasps, expected failure modes, verification of the mesh geometries, and comparisons against the physical hardware.

Second, choose the simulated command abstraction deliberately. For a mechanically coupled gripper, independent finger drives may be convenient during asset authoring, but they may also create a mismatch with the real system. If the physical gripper is commanded as a coupled mechanism, the simulation should preserve that abstraction unless there is a clear reason to do otherwise.

Third, track asset provenance and simulator version. Isaac Sim documentation, import workflows, asset structure, and tuning parameters can vary between versions. A gripper that behaves acceptably in one workflow may require different configuration in another. Asset source, simulator version, import method, and post-import modifications should be captured as part of the engineering record.

Fourth, treat conversion as the start of an asset-authoring workflow rather than the end. URDF-to-USD or SDF-to-USD conversion is valuable, but high-fidelity simulation still requires authoring, tuning, and validation. The missing information often lives with the equipment manufacturer or must be measured experimentally.

Finally, involve equipment manufacturers where possible. Manufacturers are often best positioned to provide richer kinematic, dynamic, material, and behavioral information about their products. The robotics community would benefit from a more standard way to move that information from manufacturer data into ROS-compatible descriptions, USD-based simulation assets, and validation tests.

Toward a better ROS-to-SimReady workflow

The Robotiq 2F-85 experience points to a larger opportunity for the ROS-Industrial, open-source robotics, simulation, AI, and equipment-manufacturer communities. We need workflows that preserve what ROS users already rely on while adding the physical and behavioral fidelity required by modern high-fidelity simulation.

A practical workflow could look something like this:

Manufacturers provide CAD, URDF or SDF descriptions, kinematic details, material properties, actuator behavior, and validation data;
ROS and open-source tools support accessible robot descriptions and integration;
USD-based simulation workflows support composition, reuse, and high-quality scene representation; and
SimReady-style validation defines whether an asset is ready for the intended class of simulation tasks.

The important point is that “simulation ready” should become an engineering claim that can be tested, not a label applied because an asset loads in a simulator.

There are signs this is starting to happen. When we contacted Robotiq prior to publication, they indicated that “an official C++ SDK, ROS 2 driver, URDF and updated Isaac Sim assets are in active development.”

Conclusion

Our experience with the Robotiq 2F-85 was a reminder that the hard part of simulation is not always the robot arm, the environment, or the renderer. Sometimes the hard part is the contact behavior of a gripper pad at the exact point where the simulated world meets the physical one.

URDF, SDF, USD, and SimReady all have roles to play, but no single file format solves the fidelity problem by itself. For production robotics, a simulation asset earns trust only when it reproduces the behaviors that affect the task. The closer the ROS, simulation, AI, and equipment communities can align around that standard, the less time teams will spend rebuilding the same assets and the more confidence they can place in simulation before deploying to real hardware.

ROS Discourse General: Last day to purchase regular price ROSCon Global tickets is Monday, August 24th

Tue, 04 Aug 2026 21:59:52 +0000

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

ROS Discourse General: Announcing protoros2: use protobuf in ros2 without compromise

Tue, 04 Aug 2026 07:11:37 +0000

Hi ROS Community!

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!)

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.

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.

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.

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.

5 posts - 3 participants

Read full topic

ROS Discourse General: Boston Robot Hackers announces August Monthly Meeting

Tue, 04 Aug 2026 00:49:02 +0000

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

The Pupper Project team will give an update of their progress and hopefully show off their puppy
The Beaver Works Summer Institute will present highlights of this summerâ€™s program

PLEASE REGISER! brh.eventbrite.com

1 post - 1 participant

Read full topic

ROS Discourse General: ADEL 2.0 – C++/Rust Deterministic Execution Layer for Microsecond Edge Compute & Robotics

Mon, 03 Aug 2026 16:08:07 +0000

Hi ROS Community!

We are opening early-access evaluations for ADEL 2.0 (Autonomous Deterministic Executive Layer), a bare-metal C++/Rust execution engine built for ultra-low latency, zero-jitter control loops.

While designed for microsecond satellite maneuver planning under severe compute bounds, ADEL 2.0 provides immediate utility for terrestrial robotics, BVLOS drone flight controllers, and autonomous hardware running ROS/ROS2 node topologies.

Key Highlights:

Microsecond-latency spatial trajectory recalculation.
Deterministic, zero-jitter C++/Rust core execution loop.
Lightweight memory footprint suitable for embedded edge targets.

Interactive Monitor & Visualizer:

We are actively scheduling 15-day to 30-day Hardware-in-the-Loop (HIL) benchmarking pilots with robotics hardware teams and autonomous system integrators.

Feel free to test the live monitor above or reach out at annesham649@gmail.com if youâ€™d like to benchmark ADEL 2.0 against your current ROS control stack!

1 post - 2 participants

Read full topic

ROS Discourse General: ROS 2 Realtime Support Package

Sun, 02 Aug 2026 13:21:09 +0000

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:

Add package description to CMakeLists.txt and package.xml
Add a configuration file in YAML format
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

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

Sun, 02 Aug 2026 09:48:52 +0000

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

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?
For P2, which layer would be better suited to handle the develop-path shebang — colcon-core, or the setuptools develop machinery?
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)?

17 posts - 6 participants

Read full topic

ROS Discourse General: VectorField Planner: 7 µs global path queries with strict optimality — REST API for occupancy grids, Nav2 plugin on roadmap

Fri, 31 Jul 2026 17:02:06 +0000

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.

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

Fri, 31 Jul 2026 13:29:54 +0000

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

python3 ros2_pkg_create <package_name>

such as create demo_pkg:

python3 ros2_pkg_create demo_pkg

output is :

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

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

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

ROS Discourse General: How do you understand the architecture of a large ROS 2 workspace?

Thu, 30 Jul 2026 16:51:41 +0000

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

ROS Discourse General: Jenkins version upgrade of build.ros2.org [Scheduled Buildfarm Downtime]

Thu, 30 Jul 2026 16:37:57 +0000

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:

https://build.ros2.org (Jenkins) will be temporarily unavailable or in shutdown mode (not running jobs).

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

ROS Discourse General: Chinese legged/humanoids banned in USA, what are the alternatives?

Wed, 29 Jul 2026 08:24:43 +0000

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

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

ROS Discourse General: Learning Zenoh: A New Communication Layer for ROS 2

Tue, 28 Jul 2026 12:08:33 +0000

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

Planet ROS

ROS Discourse General: Launching the VLAs on the Humanoid robot(G1, T800) for continues tasks

ROS Discourse General: Want to get involved with ROS 2? Come to Waffle

What it is

Why it’s a good on-ramp

One thing it isn’t

Details

ROS Discourse General: Analyzing rosbags with LLMs and SQL + queryable Nav2 behavior trees

ROS Discourse General: Properly close windows processes, discussion about implementation

ROS Discourse General: Exploring a human-reviewed ROS 2 agentic pipeline generator

ROS Discourse General: Some Knowledge about ros

ROS Discourse General: Robotics Student - Perception Systems Question

ROS Discourse General: Advice on breaking into US robotics/embedded industry as a US citizen with no US history

ROS Discourse General: ROS2 Dev Container Feature + Workspace Update

ROS Discourse General: Has a CPU shared-memory backend for rosidl::Buffer been explored?

Related links

ROS Discourse General: Experimental order-sensitive consistency residual for Odometry/TF streams — minimal C++ reproducer

ROS Discourse General: [GSoC 2026] ROS 2 Client Library Performance Monitoring: Midterm Progress Update

Why this project exists

Current Status and Workflow

Work remaining

I would value your feedback

ROS Industrial: From URDF to SimReady: What a Robotiq Gripper Taught Us About Simulation Assets

The first problem: available assets are not automatically usable assets

Why the Robotiq 2F-85 is a useful test case

What we tried from the ROS ecosystem

The remaining fidelity gap

The broader lesson: conversion is not fidelity

Practical takeaways for robotics teams

Toward a better ROS-to-SimReady workflow

Conclusion

ROS Discourse General: Last day to purchase regular price ROSCon Global tickets is Monday, August 24th

ROS Discourse General: Announcing protoros2: use protobuf in ros2 without compromise

What does protoros2 do?

Key Features & Use Cases

Enterprise Security Built-in

Acknowledgement

ROS Discourse General: Boston Robot Hackers announces August Monthly Meeting

PLEASE REGISER! brh.eventbrite.com

ROS Discourse General: ADEL 2.0 – C++/Rust Deterministic Execution Layer for Microsecond Edge Compute & Robotics

ROS Discourse General: ROS 2 Realtime Support Package

Background

How to use

Discussion & Future Work

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

Background

What works and what breaks

The remaining gap

Proposed changes

Relation to existing work

Open questions

ROS Discourse General: VectorField Planner: 7 µs global path queries with strict optimality — REST API for occupancy grids, Nav2 plugin on roadmap

What it does

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

Where this fits in a ROS stack

Honest limitations

Links

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

ROS Discourse General: How do you understand the architecture of a large ROS 2 workspace?

ROS Discourse General: Jenkins version upgrade of build.ros2.org [Scheduled Buildfarm Downtime]

ROS Discourse General: Chinese legged/humanoids banned in USA, what are the alternatives?

ROS Discourse General: Learning Zenoh: A New Communication Layer for ROS 2