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.

Raise your hand if this sounds familiar:

1. You just want better latency or higher throughput for your ROS2 app — but DDS throws hundreds of parameters at you and you have no idea where to start.
2. So you end up spending hours (or days) manually tweaking, re-running benchmarks, and tweaking again… only to end up with “good enough” instead of actually good.

If that’s you, I have something that might help: GitHub - qualcomm-qrb-ros/ROS2-DDSConfig-Optimizer: An AI-driven tool that automatically tunes DDS configuration for ROS2 applications. · GitHub

It’s an AI-driven tool that automatically tunes FastDDS configuration for your ROS 2 application. All you need to provide is:

1. Your performance targets — latency, throughput, reliability, CPU/memory limits, whatever matters to you — in a simple XML file
2. An initial DDS config as the baseline

That’s it. You’ll get back the best DDS configuration tailored to your application.

Would love to hear your feedback, bug reports, or feature ideas — issues and PRs are very welcome!

1 post - 1 participant

Read full topic

https://play.google.com/store/apps/details?id=com.jax.roscontroller

My app was finally approved on the play store. I have been using this app to control my quadruped running ROS2 on a Pi. This release has the fundamentals working. I will be adding additional features soon.

2 posts - 2 participants

Read full topic

Improvements:

1. Reforged Explode View tool and now it support robot links position states (with memory), explode offset slider.

Features:

1. New AI Tool - “Generate primitive robot by text”.
   Creates robot from primitives by your description. Supports various LLM providers.

2. New Tool “Manage Link Display”.
   Toggles display of Visual, Collision, Real elements of robot links. It has “Set Placement Mode” for fast activate visibility of Real and disable others.

Added Sponsorship Block to Settings Window. There is can be your company or ads.

Explode View tool

AI Generator of Primitive Robots tool

Sponsorship Block

1 post - 1 participant

Read full topic

As part of an OSRA-led clarification of governance boundaries within the ROS ecosystem, the public infrastructure of micro-ROS is transitioning to the Vulcanexus ecosystem.

This change is limited to public infrastructure and hosting. The micro-ROS project itself, its goals, roadmap, APIs, and technical direction remain unchanged. micro-ROS continues to be fully aligned with ROS 2 and supports standard ROS 2 workflows.

The new canonical website for micro-ROS is:
https://micro.vulcanexus.org

During the transition period, micro.ros.org will display a notice page indicating the new location of the project and guiding users to update bookmarks and references.

We recommend updating any existing links, documentation, or automation to point to the new domain.

Further updates will be shared as the transition progresses.

1 post - 1 participant

Read full topic

Do you have opinions on the available ROS tooling? Are you using AI in your ROS development workflow? Or maybe you refuse to use AI and want to tell us why?

We want to hear from you!

We are a group of software engineering researchers at Carnegie Mellon University, VORTEX Collab, and the University of Lisbon investigating how ROS developers find and use information, what tools they rely on across different development tasks, and how AI-powered tools fit into the development workflow.

We are conducting a research survey to better understand the information needs, tooling gaps, and the role of AI in the ROS development process. This survey is estimated to take ~20 minutes to complete.

The research survey is open to ROS developers who are at least 18 years old and with at least one year of experience. If you are interested in sharing your experiences, please visit the SURVEY LINK to complete the survey.

Responses are anonymous and will be used solely for research purposes. This research survey is part of a study (STUDY2026_00000158) conducted by Claire Le Goues and Christopher Timperley at Carnegie Mellon University. If you have any questions about the study, please contact Andrea Miller (PhD student) at andreami@andrew.cmu.edu.

1 post - 1 participant

Read full topic

Please come and join us for this coming meeting at Mon, May 4, 2026 4:00 PM UTC→Mon, May 4, 2026 5:00 PM UTC, where we plan to continue our Transitive Robotics tryout by trying one of the more advanced features: writing and deploying a custom capability. This feature allows customers to write their own custom code and deploy it to their robots alongside the features available directly from Transitive Robotics.

We did attempt this tryout last session (hence why the title might be familiar!), but as I used an unsupported system for setting up the development environment, most of the session was spent on the initial setup. Hence, we’re repeating the session using a supported operating system. If you’re interested in watching the meeting anyway, it is available on YouTube.

The meeting link for next meeting is here, and you can sign up to our calendar or our Google Group for meeting notifications or keep an eye on the Cloud Robotics Hub.

Hopefully we will see you there!

2 posts - 2 participants

Read full topic

Do you use a Spacemouse to control your robot? Then you might depend on `pyspacemouse`. If so, please check test this merge request and let me know if it has any effect on your usage!

1 post - 1 participant

Read full topic

I am delighted to share that our manuscript, “��� � �� � ��������: � ������,� has been officially �������� ��� ����������� in ��� ��������� ������� — one of the leading journals for high-impact review articles in computer science.

With an ������ ������ �� ��.�, and ������ #� ��� �� ��� �������� �� �������� ������� ������ & �������, this journal is recognized among the most prestigious venues for high-impact survey research.

This work is the result of a valuable collaboration between researchers from the RIOTU Lab at Prince Sultan University and the AlfaisalX Center at Alfaisal University.
Co-authors: ����������� �. ��-������, ���� ������, ������ ����, ������� ����������, ��� ����� �������� for more than 2 years of consistent work

Our paper presents one of the most comprehensive and systematic reviews of ROS 2, covering its architecture, ecosystem, advances, challenges, and future directions in modern robotics.

Survey Highlights
8,033 papers surveyed
960 ROS 2 publications analyzed
176 community packages reviewed
2009–2025 research timeline covered

The survey explores:
Evolution from ROS 1 to ROS 2
Middleware architecture and DDS
Real-time systems and hardware acceleration
Security and safety
Multi-robot and distributed robotics
Simulators, frameworks, and open-source ecosystems
Applications in autonomous vehicles, healthcare, aerospace, logistics, agriculture, and public safety

Companion website and open-access database:

We also provide an open-access companion database for the ROS research community.

I sincerely thank my co-authors and, in particular, ����������� �. ��-������ for his perseverance, editors, and reviewers for their valuable feedback and support throughout this journey.

Excited to see this contribution help researchers, students, and engineers advance the future of robotics.

1 post - 1 participant

Read full topic

My Raspberry Pi 5 powered TurtleBot4 (clone) TB5-WaLI has been “alive” for 11108 hours since January 9, 2025.

It has undocked, navigated around my home 6226 meters (almost 4 miles), and redocked by itself 2137 times (well I did have to help it 5 times after safety shutdowns).

It has built a good map of the house, and with LIDAR seems to never lose localization anywhere in the map.

I have found a set of Turtlebot4_navigation parameters that will give 90% reliable navigation to 10 carefully chose goals in my home, but don’t try to check the battery_state from the command line, or write a node that subscribes to BT Log Events to collect statistics, and don’t expect reliable navigation in complex, tight areas of the house (even when it appears there is a very clear path available).

My “Raspberry Pi home/educational robot” philosophy has always been, “I’m not in a hurry, so my robot should be able to do anything (that fits in 8GB of memory), albeit the bot may need to go very slow or think for a while before acting or answering.”

My hope for ROS TurtleBot4_navigation has been along this same line - WaLI may need to go slow, or even stop to rethink a plan, but nothing short of a localization failure should prevent him from navigating.

I understand there are several path planners, several plan critics, and several recovery planners, each with a bevy of parameters to tweak, but for the life of me I cannot find a set that provide robust, reliable navigation in my home.

From the start my hope was that there are some nav2 parameters that would make nav2 robust and reliable.

Many times navigation decides to fail because WaLI happens to be in a tight spot, and it seems like it doesn’t wait for recoveries. I see “spin failed” but the bot never rotated. Or “Spin 1.57” which is way too much more than needed.

A simple DDS discovery server query can cause turtlebot_navigation to fail. Shouldn’t such “resource starvation” events be possible to handle by stopping the bot, or pausing the planning?

Introducing anything external that monitors the navigation BT Events, or my node collecting statistics during the navigation should not kill everything. If the control loops are only able to run at 10Hz, can’t all the nodes slow their expectations, can’t the bot crawl slowly enough or stop while it is thinking?

For all the flexibility of Nav2 and the infinite parameterization, suite of planners and critics, and adaptable sensor inputs, TurtleBot4_navigation just seems to be a “house of cards” for me.

ROS 2 Jazzy, Turtlebot_navigation (Derivative of Nav2), Raspberry Pi 5 8GB, Ubuntu 24.04
(No temp or voltage throttling ever, Idle CPU 35%, navigating CPU 75%)

1 post - 1 participant

Read full topic

Saw this post recently, debating that Docker is not the right tool for robotics. It sparked a good discussion and got me thinking.

I am curious to know what people are actually using in real world deployments and over-the-air updates. Docker, Podman, Snap, Yocto, something else entirely? And does it change between dev and production?

There is a nice blog on this as well: https://blog.robotair.io/best-way-to-ship-your-ros-app-a53927186c35

But still forming my own view on this, would really like to know what people are using.

11 posts - 7 participants

Read full topic

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

• URDF passed structural validation (100+ joints, consistent hierarchy)

• Kinematic analysis produced expected:

  • DOF (~74, computed from non-fixed joints)

  • chain depth (~19)

  • multiple end effectors (hands, fingers, sensors)

• Tree reconstruction yielded a valid single-root structure (no cycles/orphans)

• Browser preview correctly reflects:

  • joint origins (xyz / rpy)

  • parent-child relationships

  • joint axis orientation

Pipeline

Upload → Validate → Analyze → Preview

• No ROS environment required

• No RViz

• Validation on server (file deleted after response)

• 3D is client-side only

Motivation

Most URDF tooling focuses on XML/schema validation.

In practice, failures appear later in:

• TF tree inconsistencies

• Incorrect joint transforms

• Misconfigured DOF

• Broken kinematic chains

This tool aims to surface those earlier via:

• structural validation

• kinematic introspection

• immediate visual feedback

Live demo

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

Feedback request

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

• additional validation rules worth enforcing

• kinematic analysis gaps

• CI/CD use cases (pre-merge URDF checks, regression detection)

Live test Screen Shots Below,

1 post - 1 participant

Read full topic

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:

• Humble → Jazzy

• Jazzy → Lyrical

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:

• Upgrade analysis tooling

• Automated migration suggestions

• Compatibility validation

• Package dependency checking

• Launch file migration assistance

• Nav2-specific upgrade support

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

3 posts - 2 participants

Read full topic

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.

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:

• If FusionCore sees N consecutive GPS rejections, it increases the position process noise (Q)

• That causes the covariance (P) to grow

• As P grows, the Mahalanobis gate naturally becomes less strict

• Eventually, incoming GPS measurements are no longer “too far” and get accepted again

• Once GPS is accepted, Q resets back to normal

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

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!

6 posts - 3 participants

Read full topic

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.

• Ardent Apalone
• Bouncy Bolson
• Crystal Clemmys
• Dashing Diademata
• Eloquent Elusor
• Foxy Fitzroy
• Galactic Geochelone
• Humble Hawksbill
• Iron Irwini
• Jazzy Jalisco
• Kilted Kaiju
• Lyrical Luth

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

• Boxturtle
• C Turtle
• Diamondback
• Electric Emys
• Fuerte
• Groovy Galapagos
• Hydro Medusa
• Indigo Igloo
• Jade Turtle
• Kinetic Kame
• Lunar Loggerhead
• Melodic Morenia
• Noetic Ninjemys

Here are the usual lists to help your namestorming.

• A list of adjectives that start with M
• More adjectives that start with M
• Yet more adjectives starting with M!
• A “complete” list of all turtle species
• Some more turtles!
• Turtle genera
• Prehistoric turtle genera

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!

48 posts - 41 participants

Read full topic

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

• rotor mass
• strain wave gear input side mass
• strain wave gear output side mass
• stator mass

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

ROS 2 Lyrical Luth Testing Kicks Off on April 30th

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:

• Thu, Apr 30, 2026 4:00 PM UTC Tutorial & Testing Party begins
• Thu, May 14, 2026 7:00 AM UTC Tutorial & Testing Party ends
• Fri, May 22, 2026 7:00 AM UTC ROS 2 Lyrical Luth released

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!

3 posts - 2 participants

Read full topic

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

• FusionCore: 5.5 m

• robot_localization EKF: 23.4 m: 4.2× worse

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!

6 posts - 3 participants

Read full topic

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:

• Mode-based config for standalone / rover (NTRIP or radio) / moving base / moving-base-rover / static base setups — no need to hand-edit UBX CFG-VAL keys.
• Integrated NTRIP client (including VRS via GGA uplink).
• Optional safety integrity monitoring: protection levels (NAV-PL), jamming/spoofing detection (SEC-SIG), antenna status, etc., aggregated into a ~/integrity topic and a simple ~/operational go/no-go Bool.
• CI against Humble / Jazzy / Kilted on amd64 and arm64.
• Includes a small admin CLI (oxide_gnss_assign_serial) for setting the F9P USB device serial string (useful when operating in moving base + rover mode).

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:

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

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

1 post - 1 participant

Read full topic

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

• Validates URDF structure and semantics

• Detects broken links, joints, and invalid references

• Flags issues seen in real robot models

• Supports .xacro (with guided upgrade hints)

Proof (real-world failures)

• Valkyrie: leftover xacro artifacts → correctly flagged

• Fetch: invalid XML prefix → caught immediately

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

• Files are not stored

• No training on user data

• Stateless validation

Extras

• Clear upgrade hints for .xacro

• Human-readable error explanations (not just parser output)

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

1 post - 1 participant

Read full topic

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

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

• Online asynchronous competition (from April 15th to April 30th)
• Python language
• Robot programming from your web browser
• Free, just for fun
• Based on ROS, on Gazebo simulator and Unibotics web platform

The 2026 April challenge is to program a Formula1 car to follow the red line drawn in the floor along several race circuits . 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!

JoseMaria

1 post - 1 participant

Read full topic

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

• QUIC multistream — one QUIC stream per Zenoh priority level,
  eliminating head-of-line blocking in mixed-priority traffic.
• QUIC mixed reliability — reliable streams and best-effort datagrams
  on a single connection.
• Reliable UDP — unsecure QUIC for trusted environments where TLS
  overhead matters.
• Zenoh-Go — official, idiomatic Go binding with full API coverage
  from day one (sponsored by SoftBank Corp.). Useful for fleet-side
  tooling and cloud bridges written in Go.
• Zenoh-Pico async executor — single-threaded task execution bringing
  advanced pub/sub, connectivity events, auto-reconnection, and
  peer-to-peer mode to microcontroller deployments.
• Nuze 0.3.0 — native Zenoh message decoding in the Nu-powered CLI.

Resources

• Release blog
• Protocol Spec (first draft)
• New Wireshark plugin with heuristic decoding, ID-based filtering, key-expr
  reconstruction.

– Happy Hacking

1 post - 1 participant

Read full topic

Hi ROS community,

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

• Root element must be
• At least one exists
• No duplicate link/joint names
• All joint parent/child refs valid
• Valid joint types (revolute, continuous, prismatic, fixed, floating, planar)
• revolute/prismatic joints include
• Exactly one root link (no cycles, no orphans)

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

• Python SDK: pip install roboinfra-sdk
• GitHub Action for PR validation: uses: roboinfra/validate-urdf-action@v1
• Kinematic analysis (DOF, end effectors, chain depth)
• 3D model conversion (STL/OBJ/FBX/GLB/DAE)

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

1 post - 1 participant

Read full topic

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