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.

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!😁

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.

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/

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

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

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.

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

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

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?

Background: I studied EECS and I'm now getting into robotics, mostly working through the simulation side of things. While digging into the sim pipeline I came across this repo: https://github.com/AlexKaravaev/world-creator

It's a CLI that generates Gazebo and Mujoco simulation worlds from a text prompt. You type something like "warehouse with shelves and some obstacles for navigation testing" and it picks models from the Gazebo model database and places them for you. I think it's genuinely a great idea and ahead of its time. It's from ~2023, so it predates all the recent LLM progress, and the author was upfront that the model hallucinated a lot back then. With today's models this approach could work way better.

Curious about a few things:

1. Has anyone here used this or something like it in real work?
2. Is prompt-to-world something you'd actually want, or is scene setup not painful enough to matter? From what I've seen so far, people complain way more about getting the robot itself into sim (URDF, meshes, inertia values) than the environment around it. Is that right?
3. If someone built an upgraded version of this, what would the use cases be for you? Randomized scenes for RL training? Test scenarios in CI? Quick demos?

I'm exploring building in this space, so honest "nobody needs this" takes are just as useful as feature wishlists.

Best method to create URDF from CAD software which is also campatible with gazebo sim?

I'm working on a school project using a Yahboom Transbot (Jetson Nano, ROS1). We're using Cartographer for mapping and AMCL + DWA for navigation.

I'm trying to save a pose in front of a wall and have the robot autonomously return to that exact position.

My current results:

• xy_goal_tolerance = 0.03 m
• yaw_goal_tolerance = 0.14 rad (~8°)
• Best run: 3.7 cm position error and 11.6° yaw error
• AMCL covariance at the goal is roughly 4 cm (x/y) and 3° yaw.

The main issue is that move_base reports "Goal reached" while the robot is still about 11° off and never performs a final in-place rotation.

I'm also seeing occasional "DWA could not find a path" errors even in open space, although retrying usually works.

Are these errors in position and yaw typical for a low-cost differential-drive platform, or do they suggest a localization or DWA tuning issue? Any pointers on where I should start troubleshooting would be appreciated.

Hi, i m pretty new to all of this and would like to know what software to use to simulate an environnement like you guys show, my project is to simulate a drone, which could map an appartement by himself with a lidar and camera, thanks you !

I have been thinking of building a project where a robotic arm is controlled by a local VLM model. In my understanding I feed the VLM a 2D image of the object infront of the robot and query the vlm task like "grab the hammer" and VLM provides the 2D co-ordinates and then it goes to moveit and moveit plans the mission.

I'm still at the vague idea state, any kind of input or reference or guide will be appreciated!

Thank you in advance!!

I've been curious about how different robotics teams handle failures during simulation, especially for robots using AI / learned policies.

When something fails because of a small sensor delay, contact issue, friction change, payload variation, or another unexpected condition, what does your debugging process actually look like?

A few things I'm curious about..
> How do you usually discover these failures in the first place?
> How much time do you spend figuring out why they happened?
> What's the most frustrating part of that workflow?
> Are there particular failure modes that keep coming back?
> What tools do you wish existed but don't?

I'd love to hear from people working with Isaac Sim, Gazebo, MuJoCo, or similar simulators..

Just trying to understand how people actually approach this problem and is there real bottleneck in identifying failures and evaluating the AI policy against the standards is painful ?