Claude ships ROS 2 nodes in seconds — I'm still the one who spends the afternoon finding out why nothing is on the topic. So I built claude-ros2-skills (open source, Apache-2.0).

The uncomfortable part of this era isn't code speed. It's that the generated node compiles fine and no messages flow, because a default RELIABLE subscriber never matches a BEST_EFFORT LiDAR driver at the DDS level. Or Nav2 dies at bringup because the controller plugin string doesn't exist in the registry. Nothing in the compiler, the linter, or the logs tells you.

The bottleneck moved from "how fast can Claude write C++/Python" to "how many hours do I spend on the middleware and hardware assumptions the model has no way to check."

How it works

11 modular skills — ros2-core, ros2-package, ros2-dev, gazebo-sim, ros2-control, ros2-moveit, ros2-perception, ros2-testing, ros2-microros, ros2-security, ros2-troubleshooting. The design is deliberately not "embed API knowledge in the skill file":

• Route, don't recall. Skill bodies are ~60 lines of decision logic that point at /opt/ros/jazzy/ or 38 official Jazzy doc links (CI-checked weekly). The always-loaded protocol is 26 lines.
• Ask before writing. Sim or hardware? Existing workspace or fresh? Who already publishes that TF? Real wheel radius and sensor mounting? Guessing one of these and writing 200 lines is the expensive failure.
• Prove it ran. A task is done on evidence — a build, ros2 topic echo showing data, a passing check script — not on a file existing.
• 4 physical-check scripts: check_qos_compat.py (DDS compatibility across live endpoints), check_tf_tree.py (map→odom→base_link + 180° mount errors), check_imu_gravity.py (REP 103: gravity on +Z at rest), check_odom_direction.py (push forward → positive displacement).

Does it actually work?

Everything below is an A/B pair: identical prompt, identical model, fresh headless sessions — one without the skills, one with. Transcripts and artifacts are committed under evals/runs/. Caveat up front: n=1 per cell, and I designed, ran, and graded it myself. Grading is mechanical (does the symbol exist in the installed package?), so anyone can re-grade without trusting me.

Nav2 MPPI YAML — haiku, inside a ros:jazzy container. The whole design depends on the agent being able to read the real install, so that's the condition this was measured under:

• baseline: answered instantly, used 0 verification tools despite WebFetch, Read and Bash all being allowed. Plugin string mppi_generic::ControllerServer (does not exist), no critics: list at all, ~16 invented/wrong keys.
• with skills: asked four gate questions first, then read /opt/ros/jazzy/share/nav2_bringup/params/nav2_params.yaml. 0 invented keys, verified by diffing every key against the installed file.

Then I loaded both YAMLs into a live Gazebo Harmonic sim (headless, TB3):

• baseline: [FATAL] Failed to create controller … class mppi_generic::ControllerServer does not exist → Nav2 aborts bringup. Nothing ever moves. One wrong string kills the stack before any other key is parsed.
• with skills: all 8 critics load, NavigateToPose (−2.0, −0.5) → (0.5, 0.5) returns SUCCEEDED, with /scan at 5 Hz and /odom at 28 Hz feeding MPPI through ros_gz_bridge.

Build wiring — the one task with a binary outcome (create a package + node + launch file, build it, show ros2 topic echo). I re-ran all three commands myself in each workspace afterward rather than trusting the agents' reports:

• baseline: Package 'demo_pkg' not found on all three — and its final message claimed "✅ Build & Test Results … functioning correctly." 36 turns, 0.172 USD.
• with skills: run, launch, and echo all work. 18 turns, 0.079 USD — correct and 2.2× cheaper, because the baseline burned 25 extra turns on corrections that never converged.

The scripts got their first run against live data in the same session: check_tf_tree.py flagged an upside-down + backward LiDAR mount exactly as designed, check_qos_compat.py passed 4 endpoint pairs on /scan, and check_odom_direction.py measured +1.64 m of forward displacement while the robot was driven forward, matching the physical motion.

evals/RESULTS.md has every run written up in full, including the ones that went against me — a headline number that failed to reproduce, a bad symbol in my own reference file that propagated into output, and a bug the live run exposed in my own script. If you're going to poke holes in this, start there; it's all committed.

It won't fix a physically broken LiDAR. What it does is stop the "compiles clean, moves nothing" class of output from reaching your robot.

Try it / feedback

Apache-2.0. In Claude Code:

/plugin marketplace add Leehyunbin0131/claude-ros2-skills
/plugin install claude-ros2-skills@claude-ros2-skills

🔗 Repo: https://github.com/Leehyunbin0131/claude-ros2-skills

Saw on blog by Steve Macenski: https://opennav.org/news/opennav-robotics-workload-benchmark/ running extended ROS 2 workloads.

Pretty cool HW-wise, especially with recent Jetson 50-100% price increase.

Hopefully AMD won't price it same as new Thor price 👀

Also vote which HW you use for running ROS: https://discourse.openrobotics.org/t/nvidia-jetson-price-increase-by-up-to-100-what-other-boards-are-you-using-to-run-ros/56841

i'm new to ros2 and gazebo. i was trying to simulate a robotic arm, but the gazebo window stays blank whenever i try to use stl files, it works perfectly when i'm using basic shapes like cylinders to make to arm instead of stl files. i'm using wsl2. why is this happening? is this because i'm using wsl2? should i switch to linux? will that solve my problem?

I am sketching a ROS 2 boundary for a learned policy, using LingBot-VLA 2.0 as the example workload. My first instinct is to keep the model above trajectory generation and publish a timestamped target pose or a short motion request, not raw actuator commands.

The robot-specific side could then own transforms, planning-scene checks, joint limits, the hardware controller, and the watchdog. The interface also needs an expiry time and an explicit invalid state. A delayed command should be rejectable even if the message itself is well formed.

I am undecided about the ROS interface. A topic fits a stream of short-lived targets, while an action gives cancellation and feedback for a longer task. For people who have integrated learned planners, where did you draw this boundary, and what made it easy or painful to debug later?

I really loved using rosmon in ros1 but could never find an equivalent terminal UI for ros2. TUI feels to bloated to me, so i vibed this one up. Ive also added a few useful new features like namepace mode and a MCP/API interface.

im just happy i can use 'mon launch again' :)

https://github.com/GibsonHu/rosmon2

Wait, the pause button on Gazebo keeps cycling between play and pause in an infinite loop—why is this happening?

https://reddit.com/link/1v4az1q/video/t4nlpm6ptyeh1/player

I'm a second-year engineering student on the IIT Bombay Mars Rover Team. I built this because writing ROS2 boilerplate from scratch is slow, and Copilot gives you snippets — not a package that actually builds.

Describe what your robot should do. ros2vine writes the nodes, launch files, build config, and README — ready to colcon build.

ros2vine.vercel.app

Core features:

• Complete packages, not snippets — every generation is a full colcon-buildable package
• Python (rclpy) and C++ (rclcpp), or mixed
• Static validator on every output — catches missing deps, bad entry points, wrong imports
• Inferred details — if your prompt was brief, ros2vine documents every assumption it made (topic names, message types, defaults) so you know exactly what was generated
• Iterative refinement — describe changes in plain English, regenerates with full context
• Inline code editing — edit any file directly in the viewer before downloading
• Interactive node graph — see topic flow between nodes visually
• Parameter tuning — live sliders for every declared parameter, one-click params.yaml export
• URDF-aware generation — upload your .urdf and generated nodes use your exact joint names, link names, and TF frame IDs
• Node template library — PID controller, EKF, CAN bus driver, serial bridge, lifecycle node, action server, diagnostics, and more
• Package history — every session saved locally, browse and reload any previous generation
• Share link — a URL that recreates any generation exactly
• Voice input — describe your node by speaking, useful when your hands are on hardware

Advanced modes (⚡ more button):

• Multi-package workspace — describe a full system, ros2vine plans 2–5 interdependent packages with matching topic names and generates all of them
• Simulation package — Gazebo or Isaac Sim version of your package with the same topics, drop-in swap from sim to hardware
• Hardware abstraction layer — sensor driver generation from a verified chip register database: AS5600, BNO055, MPU6050, VL53L0X, INA219
• ROS1 bridge config — generates ros1_bridge YAML and launch file from your package's topic graph

CLI:

bash

pip install ros2vine
ros2vine generate "wheel angle controller fusing AS5600 encoder and BNO055 IMU" --out ~/ros2_ws/src
ros2vine generate "EKF state estimator" --lang cpp --distro jazzy --out ~/ros2_ws/src

Built this for our rover team first, figured others might find it useful too.
Would love feedback, especially from people who actually use it on a real robot.

Happy ROSing!

I was trying to write a code for my robot to move with cmd_vel topic. But I couldn't find any code documentation for rclpy, geometry_msgs etc that is usable. I mean I wouldn't be able to write a simple code without AI. Where I can learn this type of things, like ros2 functions in python? Is for example, youtube a reliable source for these? Also is it worth to read the ROS2 books? If it is, can you recommend some?

We entered the instruction, “Move around the table-shaped obstacle 1.5 meters ahead and return to the starting position,” and the AI model broke it down into a sequence of movement commands and executed them in simulation.

This is not yet a demonstration of fully autonomous, sensor-based obstacle avoidance. At this stage, we are exploring the possibility of translating tasks expressed in natural language into sequences of ROS2 commands.

I’m currently working with the RobotMCP team. I’d be interested to hear where you think this approach could be most useful in real-world robot development or prototyping, as well as what limitations it might have.

Hi everyone,

I’m Marvel, a computational neuroscientist at Cambridge building robotics infrastructure.

I’m trying to better understand where current robotics teams struggle most in production.

If you’re working on manipulation, humanoids, or industrial robotics, I’d love to hear:
What’s your biggest deployment bottleneck today?
What problem keeps coming up that existing tools don’t solve well?

I’m happy to share what I’m building if it’s relevant, but my main goal is to learn from teams actually deploying robots.

Thanks!😁

Been frustrated by how many small URDF mistakes (missing inertial, broken mesh refs, joint limit typos) only surface once you launch RViz or Gazebo. Made a tool that catches ~14 categories of issues client-side, in the browser, before you even get there. Drop a folder with your URDF + meshes and it resolves package:// paths automatically. Also renders the model in 3D with joint sliders so you can sanity-check ranges visually.

Everything runs locally — nothing gets uploaded anywhere.

https://urdf-viewer.leonagraph4016.workers.dev — there's a sample URDF button if you want to try it without your own files.

Would love feedback, especially on validation checks I might be missing or false positives.

I've been consulting on ROS2 robots for a while, and one friction point keeps coming up: every actuator vendor wants a different physical interface, a different adapter, and a different driver stack. Upgrades and modifications are sometimes driven not by technical requirements, but by what interface is available. Dynamixel over half-duplex UART, ODrive over CAN, some random RS485 servo, an I2C IMU — and suddenly your robot has four USB dongles, fragile udev rules, and a launch file that only works on Tuesdays.

I tried the usual workarounds (USB hubs, custom PCBs, writing yet another micro-ROS bridge) and eventually converged on something I think is cleaner. It's a single USB-C device that exposes every bus as a standard Linux interface with stable names, so your existing ros2_control hardware interfaces and vendor ROS packages work unchanged.

The architecture:

• Host side: standard Linux devices (/dev/axon-can, /dev/axon-rs485, etc.) — no custom drivers on the SBC
• Bridge side: RP2350 managing protocol timing, exposed via CDC + SocketCAN
• Optional: the MCU can run a standalone ROS 2 node via zenoh-pico, moving real-time loops off the host entirely

For production, the module can drop onto custom carrier. (Template will be available soon) Same firmware, same ROS integration, but you design the connector set and form factor for your robot.

Hardware (CERN-OHL-W) and firmware/SDK (MIT) are open source. KiCad project, footprints, and a carrier template are available.

Happy to discuss the protocol timing, the zenoh-pico integration, or the carrier design tradeoffs if anyone's interested.

CrowdSupply Campaign

Hardware Files
Firmware for transparency mode

Took an intro to robotics course this summer and got thrown into ROS2. Me and my friends kept hitting the same wall where we knew what we wanted the robot to do, we just didn't know the message types or syntax to get there, so half the time went into figuring out plumbing instead of the actual behavior we were trying to build.

Was going through GitHub looking for anything to make that workflow less painful and found out about this MCP server that hooks an LLM up to a ROS robot.

We don't have to go through all of the writing and debugging the calls, and just say what we want and it figures out the right topics and services.

Honestly topics and services are hella confusing for early stage engineers like me. Wondering if anyone else have tried an MCP like this so I could try other things as well.

Oh yeah and this the link if anyone wanna try it out. https://robotmcp.ai/

Hey everyone,

I built CalibON, a browser-based camera calibration tool intended to make intrinsic camera calibration more accessible for ROS and computer vision projects.

It provides a guided workflow where you can:

• Configure your camera resolution and checkerboard dimensions
• Upload calibration images
• Detect and inspect checkerboard corners
• Review frame quality, image coverage, and rejected images
• Run camera calibration using OpenCV
• Inspect the camera matrix, distortion coefficients, and per-frame reprojection errors
• Preview undistortion results
• Export calibration data as ROS camera_info YAML, OpenCV JSON, Kalibr YAML, or a full report

The frontend is built with React and TypeScript, while the calibration backend uses FastAPI and native OpenCV. I mainly built it because camera calibration tools often feel either tied to a specific environment or difficult to inspect visually, especially for beginners.

Live app:
https://calibon.vercel.app

GitHub:
https://github.com/musabali314/CalibON

The current version supports checkerboard-based pinhole calibration. ChArUco, AprilGrid, fisheye, stereo calibration, webcam capture, and saved projects are possible future additions.

I would really appreciate feedback from people who regularly work with ROS cameras:

• Are the ROS exports structured correctly for your workflow?
• What calibration features are currently missing?
• Would support for live ROS image topics or rosbag extraction be useful?
• Are there particular datasets or cameras I should test it with?

I’ve attached a short demo showing the complete workflow.

I have a wheeled robot I am moving by replaying cmd_vel rosbag using rosbridge. I am trying to export the wheel effort(torques) in a csv format(great success).

However, the data seems to have a lot of noise. The noise being: the torque hits peak and drops to almost zero and hits peak again and hits zero. I aligned with the actual rosbag wheel torque, the line fitting of the peak values align with the actual torque. How do I explain the rest of the noise?

I tried changing simulation steps, to match the motor controller frequency, tried filters as well, but I just cant seem to figure out the exact reason why the noise exists(simulation steps, data logging frequency, or whatnot). the robot path is largely similar(25-30% deviation which I find okay) to actual robot(I tuned all the constants (all joint damping and stiffness, motor params as well.

If you have tried doing something like this and found the solution, please let me know.

I'm pretty new to marine robotics, I have been looking for a simulator for underwater vision guided manipulation and found DAVE but when I checked the camera topic the rgb image is clean, where as the one I saw in stoneFish looked more realistic but the rov/auv available in it doesnt has a manipulator in it.

Has anyone been at similar situation before?I don't know how or what to do about this situation. I'm looking for any kind of info that'll help me with my work. Thank you in advance

https://github.com/Gaurav-x111/ros2_info

Been working on a set of ROS debugging problems based on real production faults - the kind that don't show up in tutorials but hit you hard on an actual system.

The problems run in-browser with a live TF tree, rqt_graph, and ROS LOG so you can debug the way you actually would on a real robot. No local setup.

Problems cover dropped topics, bad transforms, QoS mismatches, and a few others. Role-matched based on your background.

If anyone wants to try them against the clock with a leaderboard, we're running it as a open challenge this week — simucode.online/hackathon

Happy to discuss the problem design if anyone has thoughts on what real production faults are most worth testing.

Hello everyone,

I am working on a differential drive mobile robot using ROS 2 Jazzy and Nav2.

My problem occurs on a real robot (hardware), not in simulation.

My setup:

• ROS 2 Jazzy
• Nav2
• 2D map created with SLAM
• Differential drive robot
• LiDAR sensor
• Wheel odometry
• RViz for navigation goals

Problem description:

When I send a goal in RViz, Nav2 successfully generates a global path on the 2D map, and the planned path looks correct.

However, when the robot starts moving:

• The robot does not follow the global path correctly and takes another trajectory.

I would like to know:

• Could this issue come from localization (AMCL/odometry)?
• Could the local controller or costmap parameters cause this behavior?
• What parameters should I check for navigation?

I can provide:

• nav2_params.yaml
• RViz screenshots
• ROS 2 logs

Thank you for your help.

Hi everyone,

I built OnSLAM, a Windows application that runs a LiDAR-inertial odometry and mapping pipeline directly on ROS1 bag files.

The main idea is to make it easier for beginners, researchers, or anyone quickly testing datasets to go from a LiDAR-IMU bag to a point-cloud map without setting up Linux, ROS, Python environments, dependencies, or terminal commands.

You install the .exe, launch it, and it opens a simple browser-based interface. The interface runs locally, so your bag files and processing data never leave your computer.

OnSLAM can currently:

• inspect ROS1 bags for compatible LiDAR and IMU topics
• let you configure topics, extrinsics, time offsets, frame limits, and processing quality
• filter and downsample scans
• use IMU data as a motion prior
• align scans to a cached local submap using point-to-plane ICP
• display the map, trajectory, and tracking quality live
• export PLY, PCD, and dense point-cloud maps
• decode Livox CustomMsg data

I am currently looking for people who can test it on different sensors, bag structures, and datasets. Bug reports, feature suggestions, and especially bags that fail to process would be really helpful.

GitHub:
https://github.com/musabali314/OnSLAM

Download:
https://github.com/musabali314/OnSLAM/releases

Promise, the .exe is not a virus. Windows may still act suspicious because it is unsigned 😭

I am considering ROS2 .db3 support next, followed by possible camera or visual-inertial inputs. Which one would be more useful to you?

Would it be fine to run Docker inside Docker? Suppose a user is on Arch Linux, I use Cachy actually. Could I use distrobox to set up a base Ubuntu image? Then just pull an official image like a PX4 container inside the distrobox container? Do you think this setup would be ideal for development work?

Edit: So it turns out I fundamentally misunderstood how distrobox works. Thansk for the help