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

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

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

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

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

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

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

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

1 post - 1 participant

Read full topic

does anyone know of like an nvidia jetson debloating guide that exists?

I was just updating my jetson to the latest jetpack release and wanted to take a go at removing some of the massive amounts of bloat that nvidia ships with jetpack. I looked around and couldn’t find really many good guides on getting rid of some of the garbage they leave laying around

if no such guide exists, I was pretty comprehensive in documenting the steps that I took to clean things up. would anyone be interested in me writing it up into a guide and publishing it? (I’m not talking about smth paid, I mean like a free blog post)

8 posts - 4 participants

Read full topic

I have an Ouster OS0-128 with an ethernet connectivity fault, and I want to remove the connector cap on the base to inspect the sensor-side connector pins and internal ethernet wiring.

1. Symptom and what I’ve ruled out:

• I had lidar and interface box, I tried connecting different ouster with existing interface box, I got data, it’s working.
• But issue is my existing OS0-128 not connecting, only inside laser light comming, but no data, As i tried with different interface box also.

This points to the sensor-side connector, hence wanting to open the connector cap.

Questions:

1. For anyone who has opened an OS0/OS1 connector cap: what is the exact fastener type and size?
2. Is the connector behind the cap a standard panel-mount part or Ouster-proprietary?
3. Any precautions when refitting — gasket orientation, torque, pin alignment?

I’m aware this likely voids the warranty; Asking here first because Ouster doesn’t publish service documentation.

4 posts - 3 participants

Read full topic

Hello ROS 2 and robotics simulation community,

I would like to introduce FastSwarmSim, an open-source, lightweight multi-UAV simulator for PX4-compatible vehicles:

• GitHub: GitHub - shupx/FastSwarmSim: lightweight multi-drone simulator · GitHub
• Documentation: FastSwarmSim Documentation

FastSwarmSim is designed for multi-robot algorithm development and repeatable simulation-time experiments. It combines a trimmed PX4 runtime, MAVROS-compatible ROS interfaces, RViz visualization, local LiDAR point-cloud rendering, and a conservative lock-step simulation clock.

A key feature: lock-step simulation time

FastSwarmSim publishes simulation time through ROS 2 /clock and advances the simulation in lock-step. This makes simulation progress explicit and reproducible instead of being tied directly to wall-clock speed.

With a small adaptation, a ROS node can participate in this timing model: use ROS time, respond to /clock, and advance its algorithm or publish outputs according to the simulation-time cycle. This allows existing ROS nodes to be integrated into lock-step experiments without redesigning the whole system. Nodes that are not adapted can still run normally, but they will not provide the same deterministic lock-step behavior.

The practical result is that the same experiment can be run faster than real time when the workload allows it, while retaining a consistent simulation-time reference across PX4, ROS 2 nodes, sensors, and controllers. This is useful for high-volume algorithm testing, repeatable multi-UAV experiments, accelerated parameter sweeps, and timing-sensitive coordination studies.

Current capabilities

• PX4-compatible multi-rotor simulation;
• single- and multi-vehicle launch workflows;
• ROS 2 and MAVROS-compatible interfaces;
• namespace-based multi-vehicle operation;
• RViz visualization;
• local LiDAR point-cloud simulation;
• ROS 2 command-line tools, including map generation;
• keyboard control for interactive vehicle operation;
• documentation hosted with GitHub Pages.

On a desktop-class computer, the documentation reports operation up to approximately 100x real time for a single vehicle with LiDAR simulation disabled, with lower but still accelerated rates as the vehicle count increases.

The project is still evolving, and feedback, use cases, and contributions are welcome.

Best regards,
Peixuan Shu, Beihang University, China

Email: shupeixuan@qq.com

1 post - 1 participant

Read full topic

Now Open Source! HM-LD1 3D dToF Lidar Officially Supports ROS1 & ROS2

Robot developers, this one’s for you — we’ve released the official ROS1 Noetic + ROS2 Humble/Lyrical dual driver for the HM-LD1 depth camera. The open-source repository is now live:

myrobotproject/HM-LD1-ROS1-ROS2-driver: ROS1 Noetic & ROS2 Humble/Lyrical driver for HM-LD1 dToF Lidar depth sensor module. Serial / UDP / UVC transports, depth + point cloud , auto-reconnect.

Why choose HM-LD1?

Outstanding outdoor performance under strong light
Still reaches a stable 8 meters even under 80 klux sunlight — something many dToF sensors struggle with.

Wide ranging distance
Indoor: 0.2 – 25 m
Outdoor (strong light): up to 8 m

Flexible interfaces
Supports UVC / UDP / UART, making it easy to connect with different controllers.

Excellent platform compatibility
Verified on Raspberry Pi and Jetson Nano, and supports Windows / Linux / ARM.

Robot developers can now quickly integrate depth images, point clouds, and diagnostics via ROS, significantly lowering the development barrier.

Feel free to star, fork, or open issues — we’ll keep maintaining and improving it!

Interested in the product or potential collaboration? Drop a comment or send a DM!

2 posts - 1 participant

Read full topic

For anyone running ROS across more than a single machine or LAN, how are you handling networking today?

I’m particularly curious about setups where you need remote access to robots, ROS 1/ROS 2 communication across sites or subnets, or connectivity between robots and backend/fleet systems.

What do you use?

• OpenVPN / traditional VPN
• Tailscale
• ZeroTier
• Self-managed WireGuard
• Other
• No VPN

Click to view the poll.

Would be great to hear in the comments what your setup looks like, especially for ROS 2/DDS discovery and multi-machine communication, and whether networking constraints influenced your choice.

2 posts - 2 participants

Read full topic

Hello all,

I’ve built a working runtime (I call it xZane) that sits between an AI model and physical actuation. The model proposes intents; a deterministic layer validates each one against the device’s declared capabilities before anything reaches the hardware, and the device’s own safety function runs underneath, independent of the model.

I’ve been running it across three quite different devices with the same four to five models (Claude, GPT and Gemini in the cloud; Mistral and Qwen locally): a ROS 2 mobile robot (Yahboom Rosmaster M1, Jetson Orin Nano), an LG webOS TV, and a robot vacuum. Same runtime, same models, one validation gate… the per-device specifics come from a schema rather than a code change.

A few short clips, because they show it better than I can describe it:

• validator refusing an out-of-bounds / undeclared command — nothing moves
• a valid command executing, then a physical trigger driving an independent stop
• the same models driving the TV and the vacuum

On where this sits: I’m aware of the recent related work: ROSClaw and URML both put a validation layer between a model and a robot, and both validate the command or program before execution. xZane differs in that it isn’t only a pre-execution check. The safety enforcement runs as an independent layer alongside execution, and it’s built to integrate a device’s existing safety function (the certified e-stop or safety-rated behavior) beneath the AI rather than replace it (or you can author your own), so the model is never in the safety-critical path. I mention them to place this clearly, not to relitigate their designs.

What I’d like to find out from people running real robots, industrial cells, or other machine-control setups: does this approach fit a use case you actually have? I’ve validated it on my own hardware and the useful next step is other people’s different devices, different transports. If that’s interesting to you, or if it looks worth collaborating on, I’d like to hear from you! And I’m equally interested in where you think this breaks.

Happy to go deeper on how the schema and the runtime are structured.

Thanks for your time and support!

Julio.

1 post - 1 participant

Read full topic

Quick reminder that regular price ROSCon Global ticket sales end Monday, Mon, Aug 24, 2026 12:00 AM UTC!

Later next week, we are planning to release a complete list of after-hours ROSCon Global events. This includes an OSRF hackathon at the fancy new Google office in Toronto, a bus tour of the Waterloo robotics ecosystem with stops at Otto Motors, Clearpath Robotics, and the University of Waterloo’s Robohub, multiple after-parties sponsored by friends and colleagues at Autoware and Rootly, and ROSCon reception details.

You will need to be registered for ROSCon Global to sign up for the events, and space will be limited, so please do not delay!

1 post - 1 participant

Read full topic

I’d like to share VirtuLayer, a web-based GUI I developed to simplify the configuration and usage of my Virtual Layer Plugin for Nav2.

The Virtual Layer Plugin can be used to add virtual geometries to the Nav2 costmap. VirtuLayer provides a visual interface for creating these geometries on a map and generating the configuration required by the plugin.

The idea is to avoid manually defining the geometries and configuration, and instead provide a simple visual workflow for creating and experimenting with virtual layers.

GitHub:

Live Demo:

The Virtual Layer Plugin is available in the Nav2 Plugins documentation under Virtual Layer:

I’d be interested to hear feedback .

3 posts - 2 participants

Read full topic

Hi everyone,

I’ve been working on an open-source project called ROS 2 Inspector, aimed at making it easier to understand the architecture of an unfamiliar or large ROS 2 workspace before running it.

The idea came from a problem I’ve repeatedly found interesting in ROS 2 projects:

When documentation is incomplete or outdated, understanding a workspace often means combining source-code inspection, launch-file analysis, grep/search, runtime tools such as rqt_graph, and a lot of manual exploration.

ROS 2 Inspector tries to automate part of that first architectural pass.

For example:

ros2inspector scan .

This scans the workspace from source and produces a compact summary of the discovered ROS 2 packages together with health signals that can help identify areas worth reviewing more closely.

The output can be exported as:

• table
• JSON
• YAML

For a more visual exploration:

ros2inspector viz

This generates a self-contained interactive visualization of the discovered ROS 2 architecture, allowing you to explore nodes, topics, services, actions, and their relationships.

There are also commands for inspecting nodes and connections, generating dependency and communication graphs, auditing connectivity, and validating architectural policies.

Some examples:

ros2inspector nodes --show-connections

ros2inspector graph comms --format mermaid

ros2inspector audit

ros2inspector validate --policy ros2inspector_policy.yaml

The analyzer currently handles supported patterns in Python, C++, ROS interfaces, and launch files.

One important point: ROS 2 Inspector is based on static analysis.

It is not intended to replace runtime tools.

Dynamic names, plugins, conditional behavior, runtime remappings, DDS/network behavior, and other aspects of the effective ROS 2 topology can only be fully understood with runtime evidence.

I see the two approaches as complementary:

Static analysis:
What architecture can we infer from the workspace before launching it?

Runtime inspection:
What architecture actually exists when the system is running?

The project is still in its early releases, so there is a lot of room for improvement, optimization, and broader ROS 2 pattern support.

That is also why I’d really like feedback from people working with real ROS 2 systems.

In particular:

What information would you want to see when opening an unfamiliar ROS 2 workspace for the first time?

And for the visualization:

What would make an architecture graph genuinely useful on a large ROS 2 system rather than just becoming another unreadable graph?

If you have a non-confidential ROS 2 workspace, I’d also be very interested in cases where the analyzer misses something, interprets something incorrectly, or where you think runtime/static information should be connected differently.

GitHub:

Website / documentation:

LinkedIn post:

Thanks, and I’d be very interested to hear how others approach this problem.

5 posts - 3 participants

Read full topic

Hi!

At Foxglove, we announced quite a few new features today and wanted to share them with the community. Here is what we’ve been cooking:

Search Experience

You can query all your recordings in Foxglove and quickly get to the data you need. The example query I always demo is: `/mti/imu/linear_acceleration.x > 11`. It gets more exciting as of Today, because you can combine the topic search with semantic search, and for example run the following query: `visual("stairs") AND (/anymal/imu/linear_acceleration.x > 4 OR /anymal/imu/linear_acceleration.x < -4)` gets me a good set of instances of my robot walking on stairs to work with:

And, of course, if you click any of these results, you’ll see the exact moment and can start working with the data immediately.

Learn more

A/B Comparison

You can now easily compare two or more runs in Foxglove. Load the bag files, align the time offsets, and visualize the two runs on the same timeline. Here is one example of running a UMBMark test and visualizing odometry before and after calibration:

Video of the example above: https://youtu.be/wdSkFHLtZwU

Learn more

Agent Sidebar

We have an agent sidebar now. You can ask the agent to create layouts for you, help you triage issues, write userscripts, create events, and more.

We also have an MCP in the desktop app, so you can connect your agent of choice to Foxglove and ask it to do things for you. My favorite prompt so far was asking it to triage an issue and create a PDF report for my boss.

Learn more

Remote Access and BYOS

This and the next feature are not agent-related, but I thought I would mention them since I have your attention. With Bring Your Own Server (BYOS), you use your own storage bucket with Foxglove (no longer need to keep two separate copies of your data).

Remote Access enables a connection to your robot through an optimized WebRTC stream, where we optimize stream quality based on the available bandwidth.
Read more:

• Remote Access blog post

• BYOS blog post

If you have any questions or feedback, don’t hesitate to let me know! If you happen to be at Actuate today or tomorrow, let me know, and let’s try to catch up!

4 posts - 3 participants

Read full topic

The OSRA, in collaboration with our new Special Interest Group on Physical AI (SIG PAI), just published a blog post that details their recent efforts, thought processes, and roadmap for the future of Physical AI and ROS. We would love it if you took a look and shared it with your friends and colleagues!

As AI rapidly reshapes robotics, software tools specialized for Physical AI are appearing at a rapid pace. This has led the community to ask questions about the future of existing tools designed for more traditional robotics applications, including ROS.

In the post, we discuss why we believe the most effective path forward is to leverage the strengths of ROS along with those of complementary tools designed for Physical AI. The SIG PAI present their findings, ongoing work, and long-term roadmap to achieve this. They also share ways for you to get involved in these efforts.

Feel free to share your thoughts below!

1 post - 1 participant

Read full topic

A little over a year ago @shouheng and I launched Bagel here.

We’ll we’re back with Bagel 2.0 ! And we’d love this community’s eyes on it.

For those of you that are unfamilar:

Bagel lets you talk to your robotics data instead of writing one-off scripts. Point Claude (or any MCP client, including fully local models via Ollama) at a bag and ask: “what was the peak z-deceleration?”, “summarize this bag”, "find every hard brake and cut ±10s snippets.

Answers are not LLM guesses. Bagel writes your topic messages to Arrow and runs DuckDB SQL over them, and it shows you the query so you can audit it. In testing we tried to bait it into confirming a pothole that wasn’t in the data. It checked the z-axis, told us the data was flat, and explained why. A tool that says no when the answer is no was a hard requirement for us.

As for what’s new:

The part I’m most excited about is the data reduction pipeline. One sentence (“keep 10 seconds around every deceleration below −10 m/s²”) becomes a detector. It previews exactly what it would keep before writing a byte, then runs on one bag, across a fleet, or standing on the robot so only event windows are ever written. Verified down to the message level: kept windows are byte-identical to the source, nothing outside them survives.

We also made it a point to integrate with tools in the ecosystem in this release and will make this an ongoing focus

Formats: ROS 1/2 bags, MCAP (any profile), ROS text logs, PX4, ArduPilot, Betaflight, CAN/MF4, live MQTT, and Copper (copper-rs) logs via their MCAP export. Exports to Rerun, Lichtblick, PlotJuggler, and LeRobot datasets.

Everything runs in Docker locally. No cloud, no telemetry. Apache-2.0.

Give us a star, file an issue, or fork it and go on your own journey and we’ll support you the best we can.

Repo: GitHub - Extelligence-ai/bagel: Query robotics, drone, and IoT data in plain English through an MCP server, with an intelligent edge data reduction pipeline that keeps only the data that matters. · GitHub

Would love feedback, especially on what formats or workflows you’d want next. As always we appreciate your support and feedback!

1 post - 1 participant

Read full topic

Hi ROS community!

Have you ever debugged a problem on Humble or Jazzy for hours… only to discover the fix already existed on rolling, but was never backported? You’re not alone — and I’d like to fix this systematically.

The pain

In principle, all bug fixes should be backported to the supported downstream distributions — precisely because they are fixes. Today, however, this depends entirely on the maintainer’s manual effort and judgment, so backports happen on a need-to-do or requested basis rather than automatically and systematically.
One of the key blockers: it’s not always easy to tell whether a fix is ABI compatible with released distributions just by looking at the source code. This depends on developer skill and experience.
And too often, community developers hit a bug on a released distro, dig all the way down to the root cause, and only then find the fix was already merged to rolling — so they have to request the backport themselves. That’s wasted effort for everyone.

Making this automatic would save significant time for maintainers, developers, and users alike. Original discussion: ros2/rclcpp#2555

The prototype (working today!)

I built this as two GitHub Actions:

libabigail-action — generic, repo-agnostic. Diffs two shared libraries with libabigail’s abidiff. Useful for any C/C++ project, not just ROS!

ros2-abi-action — the ROS-aware layer. For every PR it:

• builds the package twice (target branch + PR head) in the matching distro container
• runs the binary ABI diff
• applies REP-0009 policy automatically: strict for released distros, advisory for rolling
• surfaces results as a sticky PR comment, ABI compatible / ABI break labels, and a pass/fail check

Maintainers can decide on backports at a glance. And the per-repo integration is a ~10-line workflow file, so rclcpp, rcl, rcutils, rmw and friends can all share the same setup.

Small print: an ABI compatible label is information, not an obligation to backport — behavioral changes can still surprise users even when ABI is intact. And this is binary ABI only; header templates/inlines still need human eyes.

I’d love your feedback

1. Does this approach make sense for ROS 2 core repos? Concerns about CI cost or noise?
2. Tooling: libabigail vs. the older abi-compliance-checker (used by industrial_ci / auto-abi-checker) — experiences?
3. Should we go further and wire the ABI compatible label into the Mergify backport flow?
4. Would community packages benefit from this as a shared reusable workflow too?

Comments, use cases, and contributions all very welcome!

Tomoya

8 posts - 5 participants

Read full topic

Hi ROS Community,

Benji from Roboto here. At ROSCon in October last year, we previewed an early experiment: could an AI agent investigate robotics data and help find the cause of a failure? As it turns out, the answer was yes.

After extensive testing with several robotics teams, last month we released Roboto Agents. Describe what you need in plain language, and Agents can now work across bags, video, and source code to help with tasks like:

• Triage: an Agent automatically reviews every new bag, checks it for failure modes, tags it, and can open a labeled, evidence-backed ticket in Linear, GitLab, or Jira.

• Root cause analysis: trace robot failures into your codebase and draft a fix.

• Data curation: “find stair traversals from the last two months” becomes a Collection of matching examples from across your bags, exportable to ML-ready formats like LeRobot.

• Data analysis: ask “Why did this drone flight crash?” and the visualizer opens with the data behind the answer: relevant plots, imagery, and key moments highlighted as Events.

Most bags are write-once, read-never. They sit in storage (or get deleted) until something breaks in the field, and then teams go digging. With Roboto Agents, every log gets triaged, your questions get answered with clear evidence, failures get traced into code fixes, and the moments worth learning from become training data. Every robot run improves the next one.

Any feedback is welcome! We’ll be at ROSCon in Toronto next month - sponsoring for our 4th year in a row! Hope to see you there.

2 posts - 2 participants

Read full topic

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

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.}

3 posts - 2 participants

Read full topic

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

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

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

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

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

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

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

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

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.

Related links

• ROS PMC minutes for July 21, 2026
• • “Qualcomm is working on a buffer implementation, which would be the first non-NVIDIA one”
• ros2_cuda_ipc: Zero-copy GPU data sharing between ROS 2 processes - #9 by ZhenshengLee

11 posts - 4 participants

Read full topic