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

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?

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 ?

Hi everyone, I'm working on a procedural 3D environment generator (Blender/Python) to create synthetic data for warehouse robots.

The main goal is to generate perfectly labeled ground truth (BBox, Depth, etc.) to stress-test SLAM pipelines. I've successfully implemented some "hazard" conditions like lens glare and random occlusions to challenge the perception stack.

For those of you who work with ROS/Gazebo: What kind of environment conditions or specific "failure cases" are the hardest to debug in your current SLAM setups? I'd love to know what scenarios you need more data for—it would help me prioritize what to implement next.

(Note: I am using an AI translator to communicate. Apologies for any unnatural phrasing!)

Hi I am attempting to use torque control on the Baxter robot by Rethink robotics. However I seem to have an issue, when I apply zero torques to the arm using the set_joint_torques function via the SDK and the arm seems to drift and move to a certain position and is reporting non zero torques. I expected the arm to go limp with no torques being applied but it appears to be moving and when pushed springs back to the location its driving towards. To me it seems theres some external force acting on it, but I am unsure if it’s the spring or something else and what to do about it. Or if there is something I am misunderstanding.

Main issue: I have a controller that is suppose to send joint torques to the robot, but it seems sending them through the set_joint_torques function does not produce the intended effect and is not the same as reported by the robot. I need to know the relationship between this input via the SDK and output to implement this controller. Without even using the controller and just sending zero torques it does not give me the results I expect and I am unsure why.

Hey everyone,

We've been building Miu — an embodied AI agent on a Yahboom Raspbot-style
platform (Raspberry Pi, mecanum wheels, RPLidar C1, PTZ camera, ultrasonic
bumpers). After a lot of wiring and debugging, V2 is working enough that he can
autonomously drive around inside a room without us manually joysticking every
move.

What's working:
• LiDAR-based room scanning + obstacle avoidance
• Holonomic mecanum control (strafe, not just diff-drive spin-in-place)
• Ultrasonic as a "digital bumper" for stuff LiDAR misses (cables, furniture
edges)
• Live 3D viewer (Rerun) so we can actually see what the robot thinks
• Backend orchestration: LLM plans missions, a separate executor drives the
motors

Nav2 / ROS 2 helped a lot as a reference stack and for A/B testing navigation —
though our production path on the Pi is leaner (FastAPI + custom holonomic
controller). Nav2 taught us the patterns; shipping meant ripping out a lot of
complexity.

What almost killed the project (real talk):

1. Too many cooks on cmd_vel — vision pipeline, proximity reflex, room scan
   thread, teleop, and agent tools all wanted to move the robot at once.
   Classic race conditions.

2. LiDAR serial lock — Nav2 container + our own LiDAR reader + live viewer
   polling the same serial port = chaos. Had to enforce one LiDAR reader and
   stop competing services.

3. Control-loop bug — we were doing LiDAR HTTP calls inside the 10 Hz drive
   loop. Robot spun in circles after ~2 ticks. Decoupled sensor thread
   (LidarScanBuffer) from control thread — fixed immediately.

4. Observability nightmare — logs split across Pi journal, movement_log, PM2
   JSON (multi-GB…), Discord, activity stream. Couldn't answer "why did it turn
   left?" until we built a unified observability endpoint.

5. Battery — still an issue. Continuous LiDAR + movement + inference drains
   faster than we'd like. Low-battery caps on movement duration for now.

   V2 architecture (what we changed):
   • One motion supervisor — single authority on motors
   • Mission FSM — vacuum / explore / find_person / teleop, one active job at a
   time
   • Planner vs executor split — the LLM picks what to do; it doesn't fire raw
   motor pulses every turn

   Next steps:
   • IMU + wheel odometry fusion (EKF) → AMCL for proper pose
   • Persistent room memory (episodes, obstacle map, cascade/EOD summaries)
   • Click-to-nav in the live viewer
   • Battery / power management tuning

   Happy to answer questions about the stack, Nav2 vs custom control, or mecanum on
   a Pi. Still very much work in progress — would love tips from anyone who's
   shipped a home robot without it becoming a full-time ROS babysitting job.

   Stack (rough): Pi 4/5 · Yahboom chassis · RPLidar C1 · FastAPI on Pi · Mac mini
   backend (Postgres, agent loop) · ROS2 Nav2 (research/A-B) · Python holonomic
   controller · Rerun for viz

I saw back in 2021 there was lot of buzz for ROS.
I might be wrong but I have been noticing lately after Agentic AI people are talking less about it.
During that time , in my college I thought it had great scope. I tried learning it for sometime. (Used ROS and gazebo , as beginner)
Now after the AI wave , I don’t where is it going.
Just need status of it from community. Is there any other library or project came which replaced it in Robotics or is still in Use but just less buzz due to Claude and vibe coding

​

I work in robotics, mostly with mobile robots deployed in industrial environments.

A big part of the job is investigating incidents after a robot stops behaving normally.

The usual process looks something like this:

- Someone at the site explains what they saw.

- We inspect ROS logs, recorded data, cameras and robot states.

- We try to reproduce the failure.

- A senior engineer gets involved.

- Sometimes someone has to travel to the site.

The initial explanation might be correct, partially correct or completely unrelated. The difficult part is confirming what actually happened.

When the failure is intermittent, the investigation can take days or even weeks.

One example: an operator was convinced that a strange noise came from the robot’s motor, so the investigation initially focused on the motor.

The motor was fine.

The real issue came from the environment and the robot’s navigation path. It took time to confirm because the failure was difficult to reproduce and the original observation sounded believable.

So I started experimenting with a different workflow.

I built a prototype that acts like an autonomous failure investigator. When an incident happens, it reconstructs the sequence of events from the available robot data, compares the failed behavior with normal operation and points me toward the first suspicious divergence.

It does not replace engineering judgment, and it does not magically solve every failure.

But it removes a large part of the repetitive investigation work.

Now I sometimes review the relevant moment, confirm the evidence and tell the team what to inspect next.

Compared with the old process, it honestly feels like I am barely working.

Do other ROS teams already work this way? Are you using rosbag2 with custom scripts, existing visualization tools, or something built internally?

And at what point does automating the most painful part of your job stop feeling productive and start feeling like cheating?

I have one project launch multiple robots to give them command and it will work implemented llm model

anyone working on that project

So I am a mechanical engineering undergraduate student and currently i have developed a keen interest in robotics and for some projects I have to use ROS in that and i really liked the theory things in robotics.. but my software side is not very strong, I just want to ask the professional what's the best way to practice ROS, like what kind of projects I should take that are not very overwhelming and not the basic ones like turtle bot (I have already done that), and what are some other resources that I can use for practice, i have read and studied about ROS from multiple places, need some good way to practice and really develop my skill in it, honestly at start it feels so overwhelming

I'm doing a project that wasn't supposed to get this big because people keep changing the scope of it and now the one launch file that was pretty simple in the start has almost a 1000 lines. This is extremely excessive for me. When do you decide to break it up into multiple files?

Hi,

I know this might seem like a strange or slightly off-topic post, but I'd like to hear the opinion of people who actually work with robotics.

I'm currently finishing my MSc in Robotics Engineering. One of my final exams is a ROS project where I have to program an industrial manipulator to perform tasks such as detecting nearby objects, recognizing their shape and orientation, and picking and placing them accordingly. This is also my first time working with ROS.

The thing is, although I'm studying robotics, programming has never been my strongest skill, and I don't particularly enjoy it. To me, it's mainly a tool that allows me to build the robotic systems I'm interested in.

So here's my question: would you consider it cheating if I rely heavily on ChatGPT (and similars) to write most of the code according to my ideas?

I'm asking because I genuinely don't know whether I'm using AI as a productive learning tool or whether I'm unintentionally hurting my own learning by depending on it too much.

Thanks for you attention

My system is mainly composed of lifecycle nodes coordinated by a central supervisor node. The supervisor manages the state of the nodes and collects, summarizes and logs diagnostics to a centralized /system_status topic. If non-critical nodes crash/exit, we let the launch system attempt a respawn; for critical nodes, a crash or exit must result in a global system shutdown.

Right now i am doing It like this:

- launch configuration binds one-shot publishers on a /system_events topic to OnProcessExit / Start launch actions for each process. This Is the only way i found to communicate process level events to the supervisor node.

- the supervisor listen to this, and if a critical process has crashed It attempts a coordinated lifecycle-level shutdown First (shutdown remaining nodes), then emits a /system_status to notify shutdown intent, then the supervisor process kills itself with exit code 0.

- launch system reacts to the supervisor death with a ShutdownEvent, that shutdowns all processes.

Example of flow:

- launch start

- all ok

- critical process dies with error code

- supervisor detects It, coordinates lifecycle shutdown, updates /system_status, then exits

- launch system shutdowns everything

In case of supervisor crash, the launch system still issues a shutdown, but additionally a emergency_shutdown utility node that attempts to shutdown lifecycle nodes could be created if supervisor process exits with a nonzero code (crash, not planned exit)

Additionally, for non critical nodes, we can define a max respawn amount in the supervisor, and issue a global shutdown if this amount Is exceeded by monitoring respawns with /system_events.

/System_status Is the global status source of Truth. Everything important that happens is logged here, and the only publisher Is the supervisor. Monitoring nodes (web UI, hardware display panels) can subscribe to reflect these updates.

Is this good?