[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: URDF Validation + Kinematic Analysis API with Browser-Based Preview (Tested on Robonaut 2)

I’ve been working on a developer-focused URDF validation and analysis API and recently added a browser-based 3D preview layer.

To stress test the pipeline, I used the NASA Robonaut 2 (R2) URDF:

URDF: https://github.com/gkjohnson/nasa-urdf-robots/blob/master/r2_description/robots/r2c6.urdf

Observations

Pipeline

Upload → Validate → Analyze → Preview

Motivation

Most URDF tooling focuses on XML/schema validation.

In practice, failures appear later in:

This tool aims to surface those earlier via:

Live demo

https://roboinfra-dashboard.azurewebsites.net/validator

Feedback request

Would appreciate input from others working with URDF pipelines, especially around:

Live test Screen Shots Below,

r2_preview

image

image

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/urdf-validation-kinematic-analysis-api-with-browser-based-preview-tested-on-robonaut-2/54298

ROS Discourse General: I’ve been building a developer-focused URDF validation + analysis API and recently added browser-based 3D preview

(topic deleted by author)

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/i-ve-been-building-a-developer-focused-urdf-validation-analysis-api-and-recently-added-browser-based-3d-preview/54296

ROS Discourse General: Community Group Proposal: Automated ROS Upgrade Assistant

Hello everyone,

I would like to start a community discussion around building an AI-assisted ROS migration and upgrade tool focused on ROS 2 LTS transitions such as:

As ROS 2 adoption grows, many developers face challenges upgrading between releases due to API changes, deprecated interfaces, package compatibility issues, launch system updates, Nav2 migration challenges, QoS behavior differences, build system adaptations, and CI/CD validation changes.

The goal is not only syntax conversion, but practical engineering support for production migrations.

I would like to explore:

I am looking for contributors interested in ROS core development, Nav2, tooling, developer experience, and AI-assisted code migration.

If there is enough interest, we can organize a community group discussion and eventually work toward a formal proposal.

I would especially appreciate feedback from @smac , @mjcarroll, and @katherine_Scott, along with others working on ROS 2 migration workflows and developer tooling.

Would love to hear thoughts from the community.

Best,
Darshil

2 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/community-group-proposal-automated-ros-upgrade-assistant/54293

ROS Discourse General: Analysis on FusionCore vs robot_localization

A few days ago I shared a benchmark where FusionCore beat robot_localization EKF on a single NCLT sequence. Fair enough… people called out that one sequence can easily be cherry-picked. Someone also mentioned that the particular sequence I used is known to be rough for GPS-based filters. Others asked if RL was just badly tuned, or how FusionCore could outperform it that much if both are just nonlinear Kalman filters… etc

All good questions.

So I went back and ran six sequences across different weather conditions. Same config for everything. No parameter tweaks between runs. The config is in fusioncore_datasets/config/nclt_fusioncore.yaml, committed along with the results so anyone can check.

fig1

image

FusionCore wins 5 of 6. RL-UKF diverged with NaN on all six.

Now, the obvious question: what happened with November 2012? That’s the one where RL wins.

That sequence has sustained GPS degradation… this isn’t just occasional noise. The NCLT authors themselves mention elevated GPS noise in that session. Both filters are seeing the exact same data, so the difference really comes down to how they handle it.

Here’s what’s going on:

FusionCore has a gating mechanism. When GPS looks bad, it rejects those measurements. That’s usually a good thing… but in this case, the degradation is continuous. So, Fusioncore rejects a few GPS fixes → the state drifts → the next GPS measurement looks even worse relative to that drifted state → it gets rejected again → and this repeats. It kind of traps itself rejecting the very data it needs to recover.

RL, on the other hand, just accepts every GPS update. No gating, no rejection. That means it gets pulled around by noisy GPS, but it also re-anchors itself as soon as the signal improves. So in this specific case, that “always accept” behavior actually helps.

After discussing this with some hardware folks here in Kingston, we decided to add something we’re calling an inertial coast mode. The idea is simple:

Basically, instead of getting stuck rejecting everything, the filter “loosens up” over time and lets itself recover.

image

On the November 2012 sequence, this drops the error from 61.4 m → 28.7 m. RL still wins, but the gap is much smaller now, and everything is documented in the repo.

If your robot drives through tunnels, underpasses, agricultural land, and/or urban canyons with brief GPS dropouts, FC’s gate is a strength… it doesn’t get corrupted by the bad fixes during the outage. If you have GPS that is consistently mediocre (cheap receiver, cheap module, always noisy but never totally wrong), RL’s accept-everything approach is probably safer at least until coast mode gets smarter?

If you’ve got ideas on improving this… especially around re-acquisition or better fallback behavior… I’m all ears. Suggestions, config tweaks, PRs… all welcome.

Reproducing a run is straightforward

git clone https://github.com/manankharwar/fusioncore.git
# Download NCLT sequence from http://robots.engin.umich.edu/nclt/
ros2 launch fusioncore_datasets nclt_benchmark.launch.py \
  data_dir:=/path/to/nclt/2012-01-08 \
  output_bag:=./bag
python3 tools/evaluate.py --gt ground_truth.tum \
  --fusioncore fusioncore.tum --rl rl_ekf.tum \
  --sequence 2012-01-08

Full pipeline in benchmarks/README.md. Results per sequence under benchmarks/nclt/*/results/BENCHMARK.md.

November 2012 is an open problem. Coast mode cuts the error by 53% but RL’s no-gate approach still wins under sustained GPS degradation. Fully closing the gap requires either a smarter re-acquisition strategy or a tunable fallback threshold. Pull requests are welcome.

If you’ve got a dataset you want me to try, just send it over (or drop a link), and I’ll run it and share the results.

FusionCore accepts nav_msgs/Odometry from any source including slam_toolbox, MOLA, ORB-SLAM3, and even VINS-Mono. Same interface as wheel odometry.

-> GitHub - manankharwar/fusioncore: ROS 2 sensor fusion SDK: UKF, 3D native, proper GNSS, zero manual tuning. Apache 2.0. · GitHub

Happy Building!

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/analysis-on-fusioncore-vs-robot-localization/54287

ROS Discourse General: ROS (2) M Name Brainstorming

With ROS Lyrical Luth branching off Rolling this week, it’s an excellent time to start thinking about where we’ll be a year from now: in the midst of preparing the ROS M release! To get there, the first thing we need to do is pick a name.

Following tradition, the next ROS release name will be an adjective starting with M followed by a turtle-related word or name, also starting with M.

Here are the existing ROS 2 names.

ROS 1 used the following names, which means they cannot be reused.

Here are the usual lists to help your namestorming.

For a blast from the mailing list past, here is the namestorming thread for ROS Melodic Morenia.

Please share your suggestions and comments. There are no rules to this part of the process so be creative!

38 posts - 33 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/ros-2-m-name-brainstorming/54225

ROS Discourse General: How to generate a perfect URDF for a cobot (Robotic Arm) for ros2 using Solid works for gravity compensation mode with cyclic syncronous torque mode?

We have a cobot. We are making URDF for ROS2 and for real hardware for gravity compensation mode and CST Cyclic Synchronous Torque Mode with EtherCAT. Links and Joints are such that if Link X has motor, motor is all inside this link joint, and its output rotating side is attached with the flange (half inside link X and half inside Link Y)

Flange is attached fixed to Link Y via screws so it rotates with Link Y Flange other face is attached to output (rototaing part of Link X)

The Motor has Strain Wave Gear (harmonic Drive) attached to its rotor.

Problem: Now, I want to know what Part of Motor should be taken along with Link X, Like in tag as part of the link and same for Link Y.

Because we are going to put these masses separately in soldiworks and then generate its URDF.
So, what things belong to what part. Like do we add stator in link X as fixed in solidworks so its Center of Mass is calculated with it for tag? or what

Please Someone guide me how to achieve this in industrial way and correct way. Also how much error in mass is okay?

2 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/how-to-generate-a-perfect-urdf-for-a-cobot-robotic-arm-for-ros2-using-solid-works-for-gravity-compensation-mode-with-cyclic-syncronous-torque-mode/54202

ROS Discourse General: :guitar: ROS 2 Lyrical Luth Testing Kicks Off on April 30th

:guitar: ROS 2 Lyrical Luth Testing Kicks Off on April 30th

LyricLuth (2)

As many of you are already aware, the ROS 2 Lyrical Luth release is just around the corner: Friday, May 22nd, to be exact (World Turtle Day falls on a Saturday this year)! We want this to be our best ROS 2 release yet, and to get there we need to make sure that we thoroughly test Lyrical Luth before it is released to the general public. We also want to make sure that the ROS documentation on docs.ros.org continues to be clear, concise, and correct. That’s where we need your help! We’re looking for community volunteers to join us for our Lyrical Luth Testing and Tutorial Party. If you are looking to start dipping your toes into contributing to the ROS project, this is a great place to start.

So, what is a Testing and Tutorial Party, you may ask? Well, it is a chance for the community to meet with our core team, systematically review all of the current ROS tutorials, and test the latest ROS release. Right now our ROS Boss @sloretz, is working to generate early release binary and source packages for ROS 2 Lyrical Luth. On April 30th, we’ll release those binaries to the public and start the process of systematically testing them.

During the Testing and Tutorial Party, we’ll provide a GitHub repository with a long list of tests we would like to run on the Lyrical Luth beta. These tests will first ask developers to pick a particular release setup, and then run either the test suite along with one or more of the existing ROS 2 tutorials on docs.ros.org. When we say setup, we mean a specific combination of RMW vendor (Zenoh / FastDDS / Cyclone DDS / Connext DDS), build type (binary / debian / source), host operating system (Ubuntu / RHEL / Windows / MacOS), and chip architecture (amd64 / aarch64). For each setup, we’ll perform a number of tests to validate our tutorials, core ROS functionality, and new features. With dozens of possible setup configurations, testing each and every one internally isn’t feasible, which is why we need your help!

During the tutorial party, participants will be asked to sign up for particular tests and report back the results. If you happen to find an issue or bug while participating, you’ll need to report it to us so it can get corrected before the Lyrical release.

We are planning to kick off the tutorial party with a virtual kickoff meeting on Thu, Apr 30, 2026 4:00 PM UTC. During this kickoff meeting, we’ll explain the whole Testing and Tutorial Party process. We’ll record the meeting and post instructions on Open Robotics Discourse for those who can’t make it. To help motivate participants, we’ll be giving away ROS Lyrical Luth swag to the testers who complete the most tests during the event. The testers with the most closed issues will receive a credit to our Fourth Wall shop to pick out some Lyrical swag.

Here are the key dates you’ll want to remember:

We’ll add these events to the official ROS events calendar, but the big one that you won’t want to miss is the kickoff event on Thu, Apr 30, 2026 4:00 PM UTC. In the meantime, we would like your help spreading the word about the Testing and Tutorial Party.

Finally, if you can’t make it to the T&T Party but would like to help support the next ROS release, consider making a donation via their DonorBox account or joining the OSRA. Our open source contributors, OSRF donors, and OSRA members are the people making our ROS ecosystem possible! :heart:

3 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/ros-2-lyrical-luth-testing-kicks-off-on-april-30th/54184

ROS Discourse General: I benchmarked my ROS 2 localization filter (FusionCore) against robot_localization on real-world data. Here's what happened

trajectory

I ran FusionCore head-to-head against robot_localization (the standard ROS sensor fusion package) on the NCLT dataset from the University of Michigan… a real robot driving around a campus for 10 minutes. Mixed urban/suburban environment with tree cover, buildings, and open quads: the kind of GPS conditions where multipath is real, not a lab with clear sky view. Ground truth is RTK GPS, sub-10cm accuracy.

Equal comparison, no tricks: same raw IMU + wheel odometry + GPS fed to every filter simultaneously. No tuning advantage. This is strictly equal-config performance on identical sensor data.

The dashed line is RTK GPS ground truth. That’s where the robot actually was.

Left: robot_localization EKF. Right: FusionCore.

Accuracy over 600s (Absolute Trajectory Error (ATE) RMSE: lower is better):

The difference comes down to one thing: robot_localization trusts every GPS fix equally and uses fixed noise values you set manually in a config file. FusionCore continuously estimates IMU bias and adapts its noise model in real time… so it knows when a measurement doesn’t fit and how much to trust it.

FusionCore tracks position, velocity, orientation, plus gyro bias and accelerometer bias as live states. RL-EKF has no bias estimation; gyro drift compounds silently into heading error.

I also ran robot_localization’s UKF mode. It diverged numerically at t=31 seconds: covariance matrix hit NaN, every output invalid for the remaining 9 minutes. FusionCore ran stably for the full 600 seconds on the same data. Fusioncore turns out is numerically stable even at high IMU rates. This is why RL-UKF hit NaN at 100Hz and FusionCore didn’t.

Dataset: NCLT (University of Michigan).

GitHub repo: https://github.com/manankharwar/fusioncore

ROS Discourse: https://discourse.ros.org/t/fusioncore-which-is-a-ros-2-jazzy-sensor-fusion-package-robot-localization-replacement

Currently testing on physical hardware. If you’d like to try it, the repo is open… raise an issue, open a PR, or just DM me. Happy to answer any questions… I respond to everything within 24 hours. Happy building!

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/i-benchmarked-my-ros-2-localization-filter-fusioncore-against-robot-localization-on-real-world-data-heres-what-happened/54174

ROS Discourse General: Oxide GNSS — a Rust-based ROS 2 driver for u-blox ZED-F9P with NTRIP and integrity monitoring

Hi everyone,

I’d like to announce the first release of “oxide_gnss”, a ROS 2 driver for u-blox ZED-F9P receivers.

Its focus is on providing a clean, simple way to get GNSS position, velocity and optional heading data from an F9P device with minimal effort, while also providing some safety integrity monitoring.

Built on ros2-rust (rclrs). MIT licensed.

Repo: GitHub - greenforge-labs/oxide_gnss: A Rust-based ROS2 GNSS driver for u-blox ZED-F9P devices with integrated NTRIP client · GitHub

Highlights:

A minimal rover with NTRIP config looks like:

mode: rover_ntrip

features:
  high_precision: true
  integrity: true

device:
  port: "/dev/gnss_f9p_rover"
  baud_rate: 460800
  frame: ENU
  navigation:
    rate_hz: 5

ntrip:
  host: "ntrip.data.gnss.ga.gov.au"
  port: 2101
  mountpoint: "SFLD00AUS0"
  username: "${NTRIP_USERNAME}"
  password: "${NTRIP_PASSWORD}"
  send_gga: true

Launch and you should see something like:

Startup output (click for more details)

Released as-is from internal automation use — plans for continued feature development are limited, but bug-fix PRs and forks are welcome.

Feedback / issues / PRs: Issues · greenforge-labs/oxide_gnss · GitHub

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/oxide-gnss-a-rust-based-ros-2-driver-for-u-blox-zed-f9p-with-ntrip-and-integrity-monitoring/54169

ROS Discourse General: Colorful ROS2 Command Line!

Hi everyone,

I am adding color support for ros2cli. Currently it is optional and controlled via ROS_COLORIZED_OUTPUT=1. Do you like it?

GitHub PR: https://github.com/ros2/ros2cli/pull/1223

ros2color

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/colorful-ros2-command-line/54165

ROS Discourse General: URDF Validator (catches real robot failures, privacy-first, with xacro support)

Hi all,

I built a URDF validator aimed at catching real-world issues in robot descriptions not just syntax errors.

Why these matters

Many URDF tools will accept files that still fail later in simulation, motion planning, or TF. The goal here is to catch those problems before runtime.

What it does

Proof (real-world failures)

These are real bugs in widely used robot models — not synthetic test cases.

Quick check (no login required)

Free URDF Validator RoboInfra

API example

curl -X POST "https://roboinfra-api.azurewebsites.net/api/urdf/validate?include_urdf=true" \
  -H "x-api-key: YOUR_KEY" \
  -F "file=@robot.urdf"

Privacy-first

Extras

I’d really appreciate feedback especially edge cases or robot models that break it.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/urdf-validator-catches-real-robot-failures-privacy-first-with-xacro-support/54157

ROS Discourse General: Upcoming Lyrical Feature Freeze

Hi all,

On Tue, Apr 21, 2026 6:59 AM UTC, we will freeze all core ROS 2 packages to prepare for the upcoming Lyrical Luth release on Fri, May 22, 2026 7:00 AM UTC.

Once this freeze takes effect, we will not accept new features to the core packages until Lyrical branches from ROS Rolling. This restriction applies to the packages and vendor packages appearing in the ros2.repos file: ros2/ros2.repos at rolling · ros2/ros2 · GitHub

We still welcome bug fixes after the freeze date.

Find more information on the Lyrical Luth release timeline here: ROS 2 Lyrical Luth (codename ‘lyrical’; May, 2026).

2 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/upcoming-lyrical-feature-freeze/54152

ROS Discourse General: Unibotics Robot Programming Challenge, April 2026

After checking the interest in the robot programming tournament we at JdeRobot org are launching the Unibotics Robot Programming Challenge :pushpin:

The 2026 April challenge is to program a Formula1 car to follow the red line drawn in the floor along several race circuits :racing_car: . The car is endowed with a front camera, a steering wheel (W) and an accelerator pedal (V). You can use both: the available SimpleAPI or directly the ROS topics for camera images and robot control. The car has Ackermann dynamics and Montmeló is the test circuit, although your solution should also work fine in other circuits such as Montreal or SimpleCircuit.

[Unibotics] RoboticsAcademy - Follow Line

The “rules” are available at here. All the interactions will be held at the Unibotics forum

Cheers and good luck! :slight_smile:

JoseMaria

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/unibotics-robot-programming-challenge-april-2026/54139

ROS Discourse General: Eclipse Zenoh 1.9.0 "Longwang" released — Regions, QUIC multistream, Go binding (RMW Zenoh impact inside)

Eclipse Zenoh 1.9.0 “Longwang” was released yesterday. There’s a fair bit
that’s directly relevant to ROS 2 / RMW Zenoh deployments, so I wanted to
flag it here for the community.

Full release notes: Zenoh 1.9.x: Longwang · Zenoh

Regions

Regions extends the old fixed router/peer/client hierarchy with
arbitrarily deep trees of topologies (clique / mesh / star) and
configurable gateway relationships between them.

For RMW Zenoh, this means that you can scale to much larger systems
than ever before, dramatically cutting the compute and network overhead
of multi-site fleet deployments.

Other Features Shipping with 1.9.0

Resources

– Happy Hacking

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/eclipse-zenoh-1-9-0-longwang-released-regions-quic-multistream-go-binding-rmw-zenoh-impact-inside/54135

ROS Discourse General: Free online URDF validator no ROS install, instant 9-check validation (also supports xacro)

Hi ROS community,

ChatGPT Image Apr 18, 2026, 12_37_08 AM

I built a free online URDF validator because I kept running into the same
problem: testing URDF files required a full ROS install just to catch basic
structural errors.

Live tool (no signup): RoboInfra Dashboard

What it checks (9 structural checks):

Also supports .xacro files (server-side preprocessing via the official
xacro Python package no ROS install needed on your side).

Why I’m sharing:
I built this as a solo developer and want feedback from actual ROS users.
Is the validation useful? What other checks would help? Does xacro support
cover your real-world files?

Other things available (optional, paid plans):

Free tier: 50 validations/month access on signup.
Happy to answer any questions.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/free-online-urdf-validator-no-ros-install-instant-9-check-validation-also-supports-xacro/54126

ROS Industrial: Tesseract & ROS-I Developer Monthly Meeting Revisit

ROS-I Developer Meeting

This was the second quarter ROSI Developer Meeting Americas, led by Matt Robinson, focusing on recent GitHub repository updates and documentation improvements. Matt presented new documentation pages for the Scan and Plan Workshop and Noether repositories, showcasing enhanced architecture diagrams and status information.

Michael discussed updates to Python bindings for Tesseract using NanoBind, noting improvements over the previous Swig implementation and plans for code reorganization. The team also discussed upcoming events including a July training session and Automate 2026 exhibition in Chicago, where they will host an open source meetup and ROS Industrial Consortium gathering.

Matt shared updates on OSRA's technical strategy development and concerns about ROS-2 release processes affecting industrial users, particularly regarding RMW and version compatibility issues. The conversation ended with Michael announcing plans to update all repositories to support Ubuntu 20.04 LTS, including necessary changes for QT5 to QT6 transition.

Tesseract Monthly Check-In

The meeting focused on discussing OMPL 2.0's new VAMP (Vectorized Antipodal Motion Planning) integration and Tesseract's 1.0 release updates.

The team explored how VAMP's SIMD acceleration and parallel collision checking capabilities could be integrated into Tesseract, with Levi and Michael explaining that VAMP uses fine-grained parallelism to process thousands of states simultaneously rather than checking single states sequentially.

Roelof provided an update on the Cole continuous collision checking implementation, reporting significant performance improvements of 20-30% and noting that the implementation now matches Bullet's approach using convex hulls.

The team also discussed ongoing work on replacing string-based data structures with hash-based ones to improve performance, and Levi mentioned plans to implement schema validation tools for easier YAML file management in Tesseract.

Information on ROS-I Developer Meetings may be found here: https://rosindustrial.org/developers-meeting

Info on the Tesseract Monthly Check-In may be found here: https://rosindustrial.org/tesseract-robotics

[WWW] https://rosindustrial.org/news/2026/4/17/tesseract-amp-ros-i-developer-monthly-meeting-revisit

ROS Discourse General: How to use fastdds_monitor on ROS2 Humble

I tried following some online tutorials ( 3. Example of usage - 4.0.0 , https://www.youtube.com/watch?v=OYibnUnMIlc, …) but cannot get any statistics. I can see my topics, just not statistics. I made sure to set FASTDDS_STATISTICS and even tried rebuilding my WS with --cmak-args -DFASTDDS_STATISTICS=ON but I’m quite sure that did nothing. I then run the AppImage (~/Apps/eProsima_Fast-DDS-Monitor-v3.2.0-Linux.AppImage) but no luck.

Screenshot from 2026-04-17 15-00-52

Screenshot from 2026-04-17 15-00-48

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/how-to-use-fastdds-monitor-on-ros2-humble/54114

ROS Discourse General: Baxter robot's RSDK GUI not booting

Hi everyone,

I’m currently working with a Baxter robot system and ran into an issue after recovering access to the internal PC. I’d really appreciate any guidance from those who have dealt with similar setups.

Background

The robot had been unused for several years. Initially:

I managed to:

Current Status

Problem

The RSDK GUI does not start automatically on boot.

Instead of the normal Baxter interface, the system:

What I’ve tried

However:

Questions

  1. What is responsible for transitioning from the Gentoo layer into the RSDK (Ubuntu) environment?

  2. What service or script launches the Baxter GUI on boot?

  3. Is there a manual way to trigger the RSDK environment from the Gentoo console?

  4. Could this be a broken startup script, service, boot configuration, or a corrupted drive?

  5. Is there a known way to restore the original Baxter startup behaviour without reinstalling the system?

  6. If there are no way to restore it then is there an image of the system available? I tried checking in with Cothinks Robotics (The ones who took over the license and manufacturing from Rethinks Robotics.) with no response.

Additional Notes

Goal

Restore normal behaviour where:

Any help or pointers (especially from others maintaining older Baxter systems) would be greatly appreciated.

Thanks in advance.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/baxter-robots-rsdk-gui-not-booting/54090

ROS Discourse General: Writing ROS2 nodes using modern python tooling with ros-z

Hi,

I recently found ZettaScaleLabs/ros-z, a work-in-progress Rust reimplementation of ROS2 by some of the people behind Zenoh. This project is still young and does not seem to have been discussed here yet, however they have already developped a very interesting feature: ros-z provides python bindings with no dependency on ROS.

Concretely, this means it is possible to create ROS2 nodes from a pyproject.toml-based python project. AFAIK, this is not possible with the standard ROS tooling.

I think many people (including myself) avoid using ROS in python projects (and python in ROS project) because modern python tooling is not supported. Could ros-z be python’s big comeback in ROS? What do you think?

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/writing-ros2-nodes-using-modern-python-tooling-with-ros-z/54073

ROS Discourse General: Real-Time Face Tracking in ROS 2 & OpenCV

Hi everyone,

I recently developed a zero-latency face tracking node using ROS 2 and OpenCV, designed as a foundation for responsive human-machine interaction, and was encouraged to share it with the community here!

The Challenge: Middleware Overhead

During development, I encountered severe frame-rate drops (sub-1 FPS). This was due to the heavy network serialization overhead of translating image matrices across standard ROS middleware.

The Solution: Edge Processing & Optimization

To solve this, I completely re-architected the pipeline:

• Bypassing Drivers: By bypassing the standard camera drivers and processing the hardware stream directly at the edge, I eliminated the latency loop entirely.

• Algorithm Optimization: The optimized system utilizes Haar cascades paired with dynamic contrast adjustment (CLAHE).

• Result: Smooth, real-time bounding box tracking executed entirely on local hardware.

image

image

GitHub repository link:GitHub - abinaabey2006/ros2-opencv-face-tracker: A zero-latency, real-time face tracking node for ROS 2 using OpenCV and Haar Cascade · GitHub

LinkedIn post link: #ros2 #ros2 #computervision #opencv #roboticsengineering #python | Abina Abey | 22 comments

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/real-time-face-tracking-in-ros-2-opencv/54068

ROS Discourse General: Session Postponed to 2026-04-20 | Cloud Robotics Working Group

We planned a session for the 13th - more information here:

The session will instead run on Mon, Apr 20, 2026 4:00 PM UTC→Mon, Apr 20, 2026 5:00 PM UTC. The meeting link for is here, and you can sign up to our calendar or our Google Group for meeting notifications or keep an eye on the Cloud Robotics Hub.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/session-postponed-to-2026-04-20-cloud-robotics-working-group/54054

ROS Discourse General: ROSCon Global 2026 Talk Proposals Due April 26th

Quick reminder, presentation proposals for ROSCon Global 2026 in Toronto are due by Sun, Apr 26, 2026 12:00 AM UTC. Please submit your proposals via HotCRP.

Additional details are available on the ROSCon Global 2026 website.

3 posts - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/roscon-global-2026-talk-proposals-due-april-26th/54026

ROS Discourse General: ROS jazzy driver for lego mindstroms Robot inventor

Hello everyone,

I have ported a ROS driver for Lego Mindstroms Robot inventor to ROS jazzy. Here is the link: GitHub - pem120/lego_ri_ros: ROS packages for Lego Mindstorms Robot Inventor · GitHub

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/ros-jazzy-driver-for-lego-mindstroms-robot-inventor/54003

ROS Discourse General: What's new in Transitive 2.0: ClickHouse DB storage, Grafana visualizations, Alerting

Transitive 2.0 cloud architecture

Transitive 2.0 is here!

We are thrilled to announce a new major version of Transitive, the open-source framework for full-stack robotics. Version 2.0 adds significant new integrations and features: storage of historic and time-series data in ClickHouse, visualization in Grafana, and custom alerting via Alertmanager. Some of our capabilities, like the free Health Monitoring capability, already use these features, providing significant added value to robotics companies with growing fleets.

Fleet Operation at Scale

Until now Transitive has been very much focused on transactional features needed for the operation of robot fleets. This includes our most popular capabilities: WebRTC Video streaming, Remote Teleop, and ROS Tool. These capabilities are particularly empowering to robotics companies that have not yet deployed more than 50 robots. Transitive’s open-source MQTTSync data protocol, its realization of full-stack packages, and the built-in fine-grained authentication and authorization features provided a solid foundation for us to build such transactional capabilities efficiently and reliably.

But as fleets grow so do the challenges in monitoring and operating. This means that companies need tools that go beyond the direct form of one operator working on one robot at a time, but provide both longitudinal as well as historic views of the fleet. Similarly, passive monitoring and alerting need to gradually replace active monitoring by (remote) operators. Supporting robotics companies in this second chapter of growth was our goal in this new major release, while still staying true to our philosophy of embeddability, ease of use, and fine-grained, namespaced access control.

Read more about the added features and how to try them out here:

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/whats-new-in-transitive-2-0-clickhouse-db-storage-grafana-visualizations-alerting/53995

ROS Discourse General: RobotCAD 10.5.0 adapted to FreeCAD 1.1 AppImage

Let you introduce RobotCAD adaption to FreeCAD 1.1 AppImage.
Enjoy new FreeCAD 1.1 functionality.

RobotCAD is a FreeCAD workbench to generate robot description packages for ROS2 (URDF) with launchers to Gazebo and RViz. Includes controllers based on ros2_controllers and sensors based on Gazebo. With integrated models library and a lot of other tools. In other words CAD → ROS2.

How to run RobotCAD - fast install and run with FreeCAD 1.1 AppImage

I did not post long time releases info, there are a lot of bug fixes and new functionality in previous versions.

robotcad_10_5_0

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/robotcad-10-5-0-adapted-to-freecad-1-1-appimage/53994

2026-04-25 12:18