[Documentation] [TitleIndex] [WordIndex] 

Planet ROS

Planet ROS - http://planet.ros.org

Planet ROS - http://planet.ros.org[WWW] http://planet.ros.org

ROS Discourse General: Upcoming breaking changes in ros2_control: deprecated Handle / export APIs removed

Quick heads-up for anyone maintaining hardware components or controllers on Rolling or Lyrical: ros2_control 6.12.0 removes the API that has been deprecated since Jazzy. It has been released into Lyrical and Rolling and will reach users with the next sync. We’ve patched most simulators and many public drivers already.

If your package currently builds with deprecation warnings from hardware_interface or controller_interface, it will very likely fail to build after the sync.

Jazzy and Kilted are not affected. The deprecated API remains there for backward compatibility.

Migration notes

We had migration notes for this available for some time but today I made some updates too on this PR, should it be still in flight when you are reading this.

What’s being removed

Affected packages are hardware_interface and controller_interface from this PR ros2_control#3610.

  1. Raw-pointer handles. You can no longer construct a StateInterface/CommandInterface from a double* that points into your own member variables. Handles now own their data, and you access it through shared pointers and the getter/setter API.
  2. Legacy hardware component exports. export_state_interfaces() and export_command_interfaces(), which return interfaces by value, are removed.
  3. Legacy chainable controller exports. The old by-value export methods on ChainableControllerInterface are removed in favour of the shared-pointer on_export_*_interfaces_list() callbacks.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/upcoming-breaking-changes-in-ros2-control-deprecated-handle-export-apis-removed/58708

ROS Discourse General: Rokoko ROS 2 bridge for Smartgloves II is released

We’ve released an open-source ROS 2 bridge for the Rokoko Device SDK. It takes solved hand data from Smartgloves II and publishes it natively into ROS 2.

1791280376688

What’s included:

Requirements: ROS 2 Lyrical Luth and Rokoko Device SDK 0.10.0 or newer.

Licensed under Apache 2.0.

Docs: ROS 2 bridge | ROKOKO Device SDK

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/rokoko-ros-2-bridge-for-smartgloves-ii-is-released/58658

ROS Discourse General: University of Waterloo user study on understanding CMake changes

Hi everyone,

I’m Mattie Nejati, a Ph.D. candidate at the University of Waterloo. I’m recruiting participants for a user study on understanding the impact of changes to CMake build specifications.

Since CMake is widely used in the ROS ecosystem, I thought developers in this community might be particularly interested in participating.

We are evaluating a new approach that aims to help developers identify how a modification to a CMake build specification affects the resulting build configuration.

The study is conducted entirely online, takes about one hour, and involves inspecting changes to CMake build specifications and identifying their impact.

You can participate if you:

You do not need to be a CMake expert. We are interested in participants with different levels of experience.

You will need a computer with internet access and approximately 4 GB of free space to download the files required for the tasks.

We will not collect your name. We will ask for your email address only for study follow-up. It will be stored separately from your study data using a randomly assigned ID, and your name or email will not appear in any dataset or publication.

The study has received clearance from the University of Waterloo Research Ethics Board (REB #46621).

If you’re interested, you can find the consent form, screening questionnaire, and study here:

Thank you very much for considering participating! I’d also really appreciate it if you shared the study with others who might be interested.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/university-of-waterloo-user-study-on-understanding-cmake-changes/58616

ROS Discourse General: Tuning StereoSGBM on PS5 Camera (ROS 2 Galactic) for Dense Depth Maps

Hi everyone,

I’m working on setting up a stereo camera PS5 HD Camera in ROS 2 Galactic for stereo depth estimation using stereo_image_proc (DisparityNode), with the end goal of feeding the depth data into RTAB-Map for 3D reconstruction.

I transitioned from StereoBM to StereoSGBM (stereo_algorithm: 1) to handle the wide-angle camera setup better, but I’m having trouble finding the optimal combination of parameters which result in a dense point cloud with smooth surfaces. My depth output keeps swinging between two extremes:

  1. Extremely sparse/empty with huge black gaps on uniform surfaces (e.g., walls, desks, pillows).

  2. Overly noisy with heavy color “speckle” artifacts across the scene.

What I’ve configured/tried so far:

Despite these adjustments, large homogeneous surfaces still disintegrate or become heavily fragmented unless I push the correlation window size to absurdly high values (which causes blocky, stepped artifacts).

Here is the code of my DisparityNode in the launch file:

ComposableNode(
                    package='stereo_image_proc',
                    plugin='stereo_image_proc::DisparityNode',
                    name='disparity_node',
                    namespace='',
                    parameters=[{
                        'stereo_algorithm': 1,          # 0 = StereoBM (30 FPS), 1 = StereoSGBM
                        'approximate_sync': True,
                        'queue_size': 2,
                        'correlation_window_size': 13,
                        'min_disparity': 0,
                        'disparity_range': 128,
                        'uniqueness_ratio': 5.0,
                        'P1': 1350.0,                         # 8 * 1 * 9^2 (for smoothing boundaries)
                        'P2': 4000.0,                        # 32 * 1 * 9^2 (for smooth surfaces)
                        'speckle_size': 150,
                        'speckle_range': 4,
                        'full_dp': False,
                    }]
                ),

Here I attach the results I got so far.

1ks7j200s3th1

2u6jvrjko3th1

Questions:

  1. Are there specific pre-filtering parameters (prefilter_cap, prefilter_size) or SGBM settings I’m overlooking for this specific camera lens/sensor?

  2. Could this be a rectification/calibration alignment issue rather than pure SGBM parameter tuning?

Any advice or working configuration examples for similar stereo setups in ROS 2 would be greatly appreciated!

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/tuning-stereosgbm-on-ps5-camera-ros-2-galactic-for-dense-depth-maps/58568

ROS Discourse General: RobotCAD v12.10.0 is released!

It’s been a long time since I posted any news. Many new features and fixes have been released.

Here is a list of some of them that have appeared in recent versions.

Added RobotCAD MCP server for agentic robot assembling.

mcp

mcp1

Updated Models Library. More models (219 now) and faster import. Added xacro and mjcf models import from Models Library.

Снимок экрана_2026-10-02_23-57-28

Снимок экрана_2026-10-02_23-19-09

Снимок экрана_2026-10-02_23-18-26

Снимок экрана_2026-10-02_23-16-42

Снимок экрана_2026-10-02_23-16-11

Снимок экрана_2026-10-02_23-15-42

Снимок экрана_2026-10-02_23-14-47

Снимок экрана_2026-10-02_23-13-52

Снимок экрана_2026-10-02_23-12-25

models_library

Added sensors field of view with reacting to sensor parameters.

sensors_field_of_view

Other features and fixes:

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/robotcad-v12-10-0-is-released/58566

ROS Discourse General: Has anyone found a reliable way to validate a hand eye calibration result?

I have been trying to work out how a hand eye calibration should be validated and I have not found any complete answer yet

There are some tools I looked at (MoveIt Calibration, easy_handeye, Kalibr) that just print reprojection error or transform, but I could not find a clear way to decide from that whether the result can be trusted or not. I read some of their GitHub issues and many people seem to end up in the same place “result looks off” and the only way to find out why is to ask someone more experienced.

Checking by eye on one robot and looking at each result in RViz is one thing and it’s fine. But that shouldn’t be the proper way to do it, especially at scale right?

So I would really like to know how people handle it in practice. What do you run after a calibration to decide it is good? Validation motion, touching a known point, comparing against a measured pose and does any of it work without someone experienced doing the judging?

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/has-anyone-found-a-reliable-way-to-validate-a-hand-eye-calibration-result/58556

ROS Discourse General: ROS2 Parameter Value Querying

I need a much better way of grabbing the current value of every parameter of every node running on my system. Not just the dynamic ones, but the defaults and overrides from the launch system. From an experiment documentation standpoint, this is extremely important to understanding exactly how things are configured when producing data and later if data is changing figuring if one of these changed. Sure some nodes may be less important and their parameters not matter much, but there would remain many that are important, so I just want to query all of them. Unfortunately in ROS2 this is extremely disruptive to the node graph and it causes data I’m recording to have gaps. I’ve already played around with QoS to make this a little better, but the entire problem is so frustrating regardless. It was so much better in ROS1. Does anyone have a low impact method to achieve this? Or are there plans to make the parameter system smarter in the future? Is there perhaps an easy way behind the scenes to mod source code and do something like write the parameters values to a field/database on startup?

4 posts - 4 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/ros2-parameter-value-querying/58542

ROS Discourse General: MoveIt 2 Setup Assistant Tutorial: Custom 3-Joint Arm Troubleshooting Guide (ROS 2 Jazzy)

Hello ROS Community,

I want to share a comprehensive step-by-step video tutorial on configuring MoveIt 2 from scratch for a custom robotic manipulator on ROS 2 Jazzy and Ubuntu 24.04.

While most official tutorials use high-DOF industrial manipulators (like the Franka Emika Panda), building configurations for smaller or custom arms often introduces unique glitches that standard guides don’t cover (0:33). In this video, I take a 3-joint printed arm model (arduinobot) with a gripper (0:17), walk through the MoveIt Setup Assistant, generate the config package, and explicitly show how to fix the common runtime errors that pop up (18:28).

:television: Watch the Full Tutorial here: https://youtu.be/eWbAi8HUdE8
Environment & Setup

What This Video Covers (And the Errors Fixed)

Instead of just showing a flawless run, this video acts as a practical troubleshooting handbook. Here are the 5 major roadblocks we encounter and solve live:

  1. move_group Crash (Joint Limits Type Error): Fixing the expected double, got integer error inside joint_limits.yaml by ensuring type consistency and manually initializing acceleration properties (21:47).
  2. Action Execution Failure: Resolving trajectory failures by explicitly mapping the action_ns: follow_joint_trajectory namespace inside moveit_controllers.yaml (26:44).
  3. Start Point Deviation Abort: How to correctly configure and command execution directly from the current robot state to avoid state deviations (25:59).
  4. Broken Interactive Markers (3-DOF Limitation) (31:48): Standard KDL kinematics solver fails to compute position and orientation together for a 3-joint setup (0:43). We resolve this by forcing position_only_ik: true inside kinematics.yaml to unlock full marker functionality (34:23).

Pilz Industrial Motion Planner Acceleration Violations: Setting up the OMPL and Pilz planners (LIN, PTP, CIRC) (37:29). We fix joint acceleration violations under linear paths by dialing down the Acceleration Scaling factor to 0.3 (39:09).

:open_book: Video Timeline & Highlights

If you are currently struggling to port a low-degree-of-freedom manipulator or custom URDF into MoveIt 2 on Jazzy, I hope this deep dive saves you hours of debugging (0:33)!

I would love to hear feedback from the community regarding your experiences with Position-Only IK behaviors or configuring custom industrial motion planners on Jazzy!

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/moveit-2-setup-assistant-tutorial-custom-3-joint-arm-troubleshooting-guide-ros-2-jazzy/58541

ROS Discourse General: Introducing NoDL: the Node Definition Language (ROSCon recap)

TLDR: come work on NoDL in the rosgraph-wg. Join the mailing list for automatic calendar invites to meetings: https://groups.google.com/u/1/g/rosgraph-wg

Hi everyone!

@emersonknapp and I presented “The Legible Node” at ROSCon last week. We talked about two things:

  1. Thin nodes - your node is an interface adapter, it should not contain robot logic
  2. NoDL - the node definition language that allows you to statically declare your node interfaces

If you didnt catch it, here are the slides (the_legible_node_slides.pdf) (5.4 MB) - go check out the recording once its up. Working example code here too.

We had a great response from everyone at the conference, and we’re really excited to keep building NoDL with the community.

NoDL Recap

A NoDL document looks like this:

nodl_version: 2
description: Drives a differential-base robot along a sequence of waypoints.

include:
  - ref: nodl://rclcpp/node

parameters:
  max_linear_speed:
    type: double
    default_value: 0.8
    description: Upper bound on commanded forward speed, in m/s.

publishers:
  - name: ~/status
    type: std_msgs/msg/String
    qos: {history: KEEP_LAST, depth: 1, reliability: RELIABLE}
    description: Human-readable status of the waypoint follower.

subscriptions:
  - name: odom
    type: nav_msgs/msg/Odometry
    qos: {history: KEEP_LAST, depth: 10, reliability: BEST_EFFORT}
    description: Wheel/inertial odometry used to track pose.

service_servers:
  - name: ~/cancel
    type: std_srvs/srv/Trigger
    description: Drops any queued waypoints and stops the robot.

service_clients:
  - name: /global_costmap/clear_entirely
    type: std_srvs/srv/Trigger
    description: Asks the costmap server to clear itself before a retry.

action_servers:
  - name: ~/follow_waypoints
    type: nav2_msgs/action/FollowWaypoints
    description: Follows an ordered list of waypoints to completion.

action_clients:
  - name: /navigate_to_pose
    type: nav2_msgs/action/NavigateToPose
    description: Delegates single-goal navigation to the planner stack.

You write this as part of your source code to declare the interface of your node (pub, sub, service, action, clients, params).

You can manually write a nodl document, or you can scrape an existing interface from a running node, using ros2 nodl describe <node_name>.

Once you have a nodl document you can:

All of these concepts are covered in our documentation here: https://nodl.readthedocs.io - go read it

Come work with us

We are building NoDL in the ROSGraph Working Group (link). Currently, its @emersonknapp, Luke Sy and myself - we would love more friends!

You can check out what we’re working on in our current milestone. Exciting ones:

We meet fornightly, next meeting is Tue, Oct 13, 2026 8:00 PM UTC→Tue, Oct 13, 2026 9:00 PM UTC The meeting link is open to anyone: Google Meet meeting

How to get involved

LINKS

4 posts - 3 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/introducing-nodl-the-node-definition-language-roscon-recap/58501

ROS Discourse General: Question on local vs. remote inference placement for perception tasks

Hey all! ECE undergrad here, exploring an inference-routing idea for robots (deciding at runtime whether a perception or higher-level AI task runs onboard, on a nearby edge server, or in the cloud, based on deadlines, network conditions, and local compute load) and trying to validate the problem before building anything.

For those running real robots: is your local/remote split for perception or AI tasks fixed, or does it ever change dynamically? Has latency or local compute contention ever actually caused a problem, what happened, and how did you fix it (changed placement, went async, added local compute, something else)? And has anyone tried offloading inference and then walked it back. What made it not worth it?

Not asking about anything safety-critical (e-stops, motor control), just perception/AI tasks. Production, lab, or abandoned-experiment stories all welcome, just mention which is which. Thanks!

2 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/question-on-local-vs-remote-inference-placement-for-perception-tasks/58394

ROS Discourse General: Ros2_unbag is now available via the ROS 2 buildfarm 📦

Hi everyone,

A small-but-important update for ros2_unbag

badge (1)

Starting with v1.3.0, ros2_unbag is now released through the official ROS 2 buildfarm.

That means installation is now as simple as:

sudo apt install ros-<distro>-unbag

and then:

ros2 unbag

No separate pip install, no cloning, no building from source — just a regular ROS package.

For anyone who hasn’t come across ros2_unbag yet:

Your robot packs the bags; ros2_unbag brings them to your room, unpacks them, and sorts out the mess. No lost luggage included.

It supports exporting data to, among others:

It also provides parallelized extraction, topic filtering, organized output structures, and both CLI and GUI workflows.

Getting ros2_unbag into the ROS buildfarm was something I had wanted to do for a while, so I’m very happy that installation is now much more in line with the usual ROS 2 workflow.

GitHub: GitHub - ika-rwth-aachen/ros2_unbag: A ROS 2 tool for exporting bags to human readable files. Supports pluggable export routines to handle any message type. · GitHub

As always, feedback, feature requests, bug reports, and contributions are very welcome!

Happy unbagging :package:

2 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/ros2-unbag-is-now-available-via-the-ros-2-buildfarm/58367

ROS Discourse General: ROSCon Toronto FollowUp: Kubernetes/KubeEdge with ROS 2

Hi All

those who joined the k8s/kubeedge with ROS 2 meetup at ROSCon Toronto, here is the thread that we follow up more information.
please subscribe this thread so that you will not miss the notification.

as we mentioned, let’s follow up more details about this topic after ROSCon.
i will send the online meeting once i get back to Tokyo, probably in Oct we can have the follow up online meeting.

thanks,
Tomoya

5 posts - 3 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/roscon-toronto-followup-kubernetes-kubeedge-with-ros-2/58350

ROS Discourse General: Fifteen Years of MoveIt, and the Next Fifteen

Today we announced that PickNik Inc. and Qualcomm Technologies, Inc. are joining forces. Before I go into that, I want to talk about MoveIt, because MoveIt is the reason any of this happened.

If you have learned about robotic arm manipulation in the past decade and a half, or been involved in manipulation R&D, there’s a good chance you’ve used MoveIt. More than 560 people have contributed code across the MoveIt project, which today spans 40 repositories, 6,700 GitHub stars, and 4,400 forks. The two main MoveIt papers have been cited more than 1,700 times between them. More than a million people have visited MoveIt’s websites and documentation over the years. Thousands of robot models have been made to work with it, in labs and companies I have never heard of, which is the point.

Where MoveIt came from

MoveIt started at Willow Garage, and the earliest and largest debts are owed to Ioan-Alex Șucan, Sachin Chitta, E. Gil Jones, and Acorn Pooley, who wrote the first version of what became the standard way to move an arm in ROS. I got my start in this world as a motion planning intern at Willow Garage in the summer of 2012, and benefited tremendously from their mentorship. I really loved ROS’s mission.

But then Willow Garage shut down in 2014, and a lot of software from the Willow days did not survive. MoveIt did, however, because Michael Ferguson, Robert Haschke, Michael Görner, and I decided it was worth keeping alive. Back in grad school, I spent way too much time working on MoveIt rather than publishing research, but it turned out to be the most useful thing I could have been doing anyway, which is a thing I got lucky about.

I started PickNik in 2015 when companies were asking for help using MoveIt. I started it as a software consulting shop, but then we received funding to begin the development of MoveIt 2 from a number of sources, including the EU’s ROSin and the US’s SBIR programs, as well as Acutronic Robotics. Many others got involved over time, including Mark Moll, Nathan Brooks, Sebastian Castro, Henning Kayser, Jafar Uruç, Andy Zelenak, Felix von Drigalski, and Tyler Weaver. The kind of maintenance required to keep a big project like MoveIt going can be unglamorous, so thank you to everyone on the complete list of contributors.

Going forward

For most of MoveIt’s history, the easy problems in the industry were solved with hard-coded waypoints, but the MoveIt community instead used geometric and model-based dynamic motion planning to achieve more reactivity. This included inverse kinematics, collision checking, and probabilistic sampling-based motion planning. Everything looked great in simulation, but the biggest struggle was always making it work on a real-time controller, reliably, in a production system.

Learned models are now really changing our field. VLAs, VLMs, and WAMs are becoming a bigger part of the robotic system in ways I could not have imagined previously. Things we used to use heuristics for are now shifting to AI-based task planning. But I don’t think planning goes away. At PickNik, we’ve been betting on hybrid AI systems over the past few years, combining the power of AI models with the determinism, safety, and validity of the traditional MoveIt approaches. This hybrid AI approach is where the interesting architecture work is now: how to get advanced motion planning deployed in production environments today, at the level of reliability that our customers demand.

MoveIt is already running in production in incredible places: NASA missions, surgical robots, warehouse logistics, 3D bioprinting, cell therapy manufacturing, sanitation in food processing, strawberry picking, airport baggage handling, bathroom cleaning, and car washes. These are real deployments running on ROS 2 and MoveIt.

Making AI models work reliably in all of those places is a different engineering problem than the last decade was. It needs different expertise and a different kind of investment.

Why is Qualcomm Technologies acquiring PickNik?

Back to the acquisition announcement. “Why Qualcomm?” A key insight about the future of robotics is that these powerful AI models need to run on the robot in real time, within a power budget, not in a data center or over a network. With that realization comes a fundamental shift: many of the toughest AI challenges are no longer purely software problems, but joint software and hardware design challenges. A good way to address those problems is to be close to the people designing the compute, instead of integrating with it after it’s already designed. Powerful heterogeneous compute and advanced processors are enabling techniques we could only dream of 15 years ago, and that means paying more attention to the hardware layer is not optional.

I will admit that when this started I thought of Qualcomm as the company powering my 5G Android phone. I have spent the last several months learning how wrong I was: Qualcomm is a full-stack physical AI company, combining industry-leading compute with software and AI that are increasingly enabling the next generation of intelligent robots with its Qualcomm Dragonwing platforms. I’m excited about how heavily Qualcomm is now betting on physical AI.

I’m also comforted knowing that they have made some big plays in open source recently, including acquiring Arduino, Modular, Edge Impulse, and Foundries.io. Qualcomm and Arduino bring scale to developer communities, and I look forward to seeing open-source MoveIt and the ROS interoperability layer go further into the mainstream with

The part that mattered most to me personally: we are both founding members of the Open Source Robotics Alliance, and Qualcomm will continue investing in ROS and MoveIt.

What is not changing

● MoveIt 1 and 2 stays open source under its existing license, with community-driven roadmaps.

● MoveIt stays hardware agnostic.

● PickNik customers will continue to receive support from the team.

● We will continue to support the open source development of MoveIt and ROS.

My promise

I am going to keep being an advocate for MoveIt, for ROS, and for open source, from inside a company considerably larger than the one I started. That is my commitment to you and the entire MoveIt community.

This week I am at ROSCon in Toronto, at the PickNik booth, number 7. Please stop by and see me. Thank you for fifteen years of groundbreaking work in robotics. Let’s go do the next fifteen and beyond.

4 posts - 4 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/fifteen-years-of-moveit-and-the-next-fifteen/58349

ROS Discourse General: Announcement: rclrs 0.8.0 Release

We’re happy to announce the release of rclrs v0.8.0!

Continuing our proud tradition of Conference-Driven Development (CDD), this release arrives just in time for ROSCon Global 2026 in Toronto.

If you are at ROSCon, do not miss Michael Grey’s talk on composable actions concurrency with rclrs.

What’s New

ROS 2 Lyrical Support

rclrs now supports ROS 2 Lyrical Luth. Bindings have been regenerated for Humble, Jazzy, Kilted, Lyrical, and Rolling.

ros-env Message Access

ROS message packages are now accessed through ros-env. This keeps rclrs, applications, and generated messages on the same message definitions.

Applications using generated messages should import them with:

use ros_env::*;

Actions and Parameters

Topic Endpoint QoS

TopicEndpointInfo now exposes its QoS profile, improving graph inspection and diagnostics.

Performance and Reliability

This release includes performance improvements and fixes across action handling, dynamic-message introspection, sequence resizing, and rosout initialization.

Breaking Changes

See the changelog ( ros2_rust/rclrs/CHANGELOG.md at main · ros2-rust/ros2_rust · GitHub ) for the complete list of changes.

Contributors

A huge thank you to everyone who contributed to this release!

Links

As always, we welcome feedback and contributions.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/announcement-rclrs-0-8-0-release/58347

ROS Discourse General: ROSCon Global 2026 Live Stream

ROSCon Global 2026 live from Toronto! :canada:

be10b549a9310e5a4b89a2fcf40f7e4bcdb74b5f_2_1035x475

3 posts - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/roscon-global-2026-live-stream/58340

ROS Discourse General: From CT Scan to Robotic Surgery Prototype: Kidney Stone Detection & PCNL Planning in ROS 2

Hi all,
I’d like to share a research prototype that connects medical CT imaging to ROS 2 visualization and robot simulation.
The pipeline starts from a DICOM / NIfTI CT scan, segments kidneys and nearby organs, finds stone candidates, builds 3D meshes, ranks PCNL (percutaneous nephrolithotomy) access corridors, then visualizes the anatomy in RViz and Gazebo. A Franka FR3 with a surgical needle can replay the selected path in simulation.
This is not a clinical tool and not medical advice. It is a learning / research MVP: geometric planning + kinematic replay, not a validated surgical system.

You can watch the project’s video LinkedIn Video or Youtube Video.

pcnl_pipeline_grid_1920x1080(1)

What actually do in the app

There is one window. Buttons on top, the CT slice on the left, a log and a stone table on the right.

  1. Load the scan

    Click Open NIfTI… or Open DICOM folder…. The CT appears as a slice you can scroll through, like flipping pages of the body.

  2. Find the kidneys

    Segment kidneys paints the left and right kidney (and nearby organs) on the scan. Extract kidney ROIs zooms in so you are not searching the whole abdomen.

  3. Find the stones

    Detect stones (HU) looks for bright spots inside the kidney — stones are denser than soft tissue. A table lists each candidate: left or right, volume, diameter, and how bright it is.

  4. See it in 3D

    Export STL saves kidney and stone shapes as 3D files. Show 3D meshes opens them in the app. Open RViz shows the same models in ROS, with the planned needle line drawn on top.

  5. Plan the needle path

    Pick a stone in the table, then click Plan PCNL. The program tries many directions from the back, avoids organs where it can, and ranks safer / shorter routes. You can switch between the best path and the backups.

  6. Watch the robot

    Simüle et (FR3) opens a simulated operating room: the patient model on a table, and a Franka robot with a needle. The arm lines up with the path, goes in to the stone, and İğneyi çıkar pulls it back out.

ROS is used for the part it is good at: showing 3D models and moving a robot. The heavy image work stays in a normal desktop app, then hands over files. That split kept the demo understandable and let one window drive the whole story: scan → stone → path → robot.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/from-ct-scan-to-robotic-surgery-prototype-kidney-stone-detection-pcnl-planning-in-ros-2/58308

ROS Discourse General: Oh noes! What's going on with Anubis?

Lately I’ve been intermittently but often getting this message when trying to access ROS documentation (like c++ API etc). Am I the only one running into this? I definitely have browser cookies enabled, and I’m not going through a VPN. The below messages was obtained by browsing to this location.

oh_noes

14 posts - 7 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/oh-noes-whats-going-on-with-anubis/58302

ROS Discourse General: D-Robotics at ROSCon Global 2026 — Let’s Connect in Toronto

Hi everyone! :waving_hand:

Here’s from the D-Robotics team. We’re excited to share that our team will be at ROSCon Global 2026 in Toronto, September 22–24. We’re looking forward to meeting fellow ROS developers and robotics folks in person.

For D-Robotics, ROS 2 is not an add-on — it is a core part of the RDK robotics development experience. Across the RDK platform, we support multiple ROS 2 distributions, while TogetheROS.Bot builds on ROS 2 with hardware-accelerated capabilities tailored for robotics.

If you’re attending too, come find us at the conference. You can meet the D-Robotics team at the AgileX Robotics booth (#48), where our engineers will be around throughout the event. We’ll be showcasing an RDK X5 × Piper demo, showing how on-device perception and AI inference can connect with physical robotic action.

You can also find us at the LooperRobotics booth, where their Insight series integrates D-Robotics RDK X5 modules for spatial AI applications.

We’d love to show you what we’ve been building, but even more, we’d like to hear what you’re working on. Come by to exchange ideas around ROS 2, robotics development, edge AI, and embodied AI, or just stop by and say hi.

See you in Toronto!

2 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/d-robotics-at-roscon-global-2026-let-s-connect-in-toronto/58247

ROS Discourse General: New SMACC demo in Gazebo using the PX4 flight stack

This demo uses the new SMACC PX4 Client Library to autonomously control the following drone in a Gazebo environment.

SMACC and PX4 flight stack simulation in the Strait of Hormuz

As always, here’s the source code: SMACC2/smacc2_sm_reference_library/sm_cl_px4_mr_test_4 at jazzy · robosoft-ai/SMACC2 · GitHub

The readme for this application lays out the steps of how to use it.

And here’s a link to the original linkedin post: #ros2 #px4 #smacc2 #physicalai #gazebo #qgroundcontrol #nav2 | Brett Aldrich

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/new-smacc-demo-in-gazebo-using-the-px4-flight-stack/58232

ROS Discourse General: Native ROS 2 on Zephyr with Cyclone DDS

Hi,

I have been experimenting with native DDS for ROS 2 on Zephyr and recently got the standard ROS 2 C client stack running on an ESP32-S3 over Wi-Fi.

The current stack is:

rclc -> rcl -> rmw_cyclonedds_c -> Cyclone DDS -> Zephyr

The board joins the DDS/RTPS network directly, without a Micro XRCE-DDS Agent.

The work is split into two repositories:

I tested an ESP32-S3 against stock ROS 2 Lyrical with rmw_cyclonedds_cpp, in both publisher and subscriber directions. The current implementation supports fixed-size messages and best-effort QoS.

I have also been working on Zephyr support for Micro XRCE-DDS and rmw_zenoh_pico, with the longer-term goal of comparing these embedded RMW paths on the same hardware.

I wrote a short note with more details and measurements here:

I will keep extending the native DDS path with Reliable QoS, Transient Local, ROS graph support and eventually DDS Security.

Feedback is very welcome.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/native-ros-2-on-zephyr-with-cyclone-dds/58222

ROS Discourse General: ROS medical community updates

Ahead of ROSCon, anyone using ROS in a medical context is welcome to update the community here with a quick status update. I’ll go first on behalf of Vexev!

Ps if you haven’t seen, there will be a Birds of a Feather session at ROSCon Toronto! 9am Tuesday. Followed by a community meeting online in October.

Context:

We use ROS in our 8dof ultrasound imaging robot. We’re a startup, pre regulatory submission. Full context in the 2024 ROSCon Keynote: Keynote: Saving lives sooner: leveraging ROS 2 for end-stage kidney disease with Deanna Hood

Updates:

  1. Successful results from our last clinical trial have been published! Vexev's VxWave System Successfully Meets Clinical Endpoints in Landmark Study Evaluating Robotic Ultrasound Scanning for Mapping Vascular Access at U.S. Renal Care Dialysis Clinics - Vexev
  2. The safety of our hardware has been beefed up following strategies I described in this talk: https://www.youtube.com/watch?v=DrJPVY4B1Yc
  3. V&V, cybersecurity and FDA trial are all on our radar! :rocket: still with no plans to remove ROS :grin:

Please keep an eye out for:

  1. Sydney-based technologists for our open roles: Work with us - Vexev

  2. People looking to join the community. (Sign up to this mailing list https://groups.google.com/g/ros-medical-community-group-invites )

  3. Speakers for sessions on:
    * V&V and what changes when SOUP is involved vs not (incl ROS)

    * cybersecurity and implications of including ROS in the SBOM

    * what OTA updates look like for medical devices and how that contrasts with packaging practices in ROS community

Share your updates whether you will be at ROSCon or not - the objective is to help each other find what we’re looking for, to move faster.

Context: (what you’re working on)
Updates: (news/where you’re at)
Please keep an eye out for: (how others can support)

3 posts - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/ros-medical-community-updates/58184

ROS Discourse General: CRA reporting starts tomorrow. How do you tell an exploited vulnerability from a normal robot failure inside 24 hours?

The EU Cyber Resilience Act reporting obligation for manufacturers starts on 11 September 2026: early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, and full notification within 72 hours, through the ENISA Single Reporting Platform. Open-source stewards are covered from 11 December 2027 under Article 24(3). Source: Cyber Resilience Act - Reporting obligations | Shaping Europe’s digital future

I am not posting this as a compliance warning. Most of us here are not manufacturers placing a product on the EU market, and nothing changes for an open-source stack tomorrow.

The engineering question underneath it is the one I would like to ask this group, because it applies whether or not the regulation touches you.

When a fielded robot does something wrong, how do you currently decide, quickly, whether that was an induced failure or the system’s own baseline failure rate showing up?

On my own bench, I can only answer it because I keep a clean control run at the same task and seed. Without that, a single bad rollout is uninterpretable in either direction: I cannot call it an attack, and I cannot call it noise.

What do people do in the field, where you do not get to re-run the same seed? Is there prior practice in the ROS world for baseline-rate logging that I should be reading instead of inventing?

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/cra-reporting-starts-tomorrow-how-do-you-tell-an-exploited-vulnerability-from-a-normal-robot-failure-inside-24-hours/58097

ROS Discourse General: Debug, Visualize and Teleoperate anything ROS2 with Phantom Bridge

If you haven’t tried Phantom Bridge yet, I recommend you do. I’ll be in Toronto next week for the ROSCon 2026, if anyone feels like talking about where this is headed or what features you’re missing.

Debug, Visualize and Teleoperate any ROS2 Robot with Phantom Bridge

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/debug-visualize-and-teleoperate-anything-ros2-with-phantom-bridge/58088

ROS Discourse General: Ros2-apt-source bumped to v 1.3.0

I’ve just noticed the ros2-apt-source package has been bumped to v1.3.0. Nothing special was added, just Fedora support. If you have v1.2.0 hardcoded to your deploy scripts, it’s time to switch to 1.3.0 :wink: (for those who have already this package installed, it will auto-update, so no worries there).

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/ros2-apt-source-bumped-to-v-1-3-0/58084

ROS Discourse General: Has anyone written a custom I²C transport for micro-ROS (or any MCU ROS stack)?

Small embedded team at a startup, weighing an idea before we commit to it. As far as I can tell, none of the MCU ROS stacks support I²C out of the box — micro-ROS does UART/UDP/CAN-FD, zenoh-pico does serial/UDP/TCP, Cyphal does CAN/serial. I²C isn’t on any of those lists. So if we want a board to be a ROS node talking over I²C, it looks like we’d have to write that transport layer ourselves. micro-ROS at least exposes a custom-transport API (the open/close/write/read hooks + set_custom_transport), so in principle an I²C transport is writable. My question is whether anyone actually has.

Context for why I²C at all: our STM32 boards sit behind a GMSL camera link, which tunnels an I²C channel through to the host side. The wire is already there, so an I²C transport would cost us no extra wiring — that’s the whole appeal.

So: Has anyone implemented a custom micro-ROS transport over I²C, or pushed zenoh-pico / Pico-ROS down onto an I²C link? How did it go — did the request/response and discovery patterns map onto a master-driven bus okay, or did that mismatch (the host has to poll, the MCU can’t initiate) become the whole problem? And if you tried and bailed — what made you bail? Rather hear where it broke now than find out the hard way later. (Not asking whether I²C is a “real” bus for this — I know it’s unusual. Asking specifically whether anyone’s made a ROS middleware transport work on top of it.)

3 posts - 3 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/has-anyone-written-a-custom-i-c-transport-for-micro-ros-or-any-mcu-ros-stack/58035

2026-10-10 12:18