ROS and safety requirements
ROS and safety requirements
Posted Oct 24, 2025 8:38 UTC (Fri) by massimiliano (subscriber, #3048)Parent article: A look at the Robot Operating System
To give you an idea of the kind of robots I build, this is a video of a small autonomous racing car competing on a "folkrace" track:
https://youtu.be/w5mThCTlCn8
BTW, the firmware for that robot is developed entirely using async Rust with Embassy, with independent tasks communicating over channels, on a dual-core RP2040.
The modularity and cleanness of this kind of environment are amazing.
All the robots I develop run on one or two microcontrollers, typically a RP2040/2350 or some kind of ESP32 (currently either C6 or S3).
And ROS cannot run there.
That said, I have looked deeply into ROS, and I cannot understand how it can possibly work when there are strict safety and/or real-time requirements.
Which, for me, means "all robots that matter".
About safety, using a TCP network introduces so many possible failure points that I would not know how to handle them.
And, in fact, I think that getting the generic software stack "Ubuntu over a TCP network" certified for safety-critical operations is not possible.
About real-time, the big problem I see is the kernel scheduler.
I mean, even using a single (possibly multicore) CPU, and a message broker like iceoryx2 (https://ekxide.github.io/iceoryx2-book/main/), each node would run in its own process, and response time deadlines would depend on the kernel scheduler.
This can be ok for soft real-time, but again, I do not think it can be certified for hard real-time requirements.
The way I see it, ROS is amazing as a prototyping tool, to get a robot running quickly, to reuse existing nodes, and to have infrastructure like a physical simulator and event inspection and analysis working out of the box.
I do see its value in this context.
But how are the two issues of safety and real-time requirements handled?
Am I missing something fundamental?
Posted Oct 25, 2025 12:33 UTC (Sat)
by TheLittleLance (subscriber, #35074)
[Link] (1 responses)
That isn't strictly true. The main ROS libraries are indeed too heavyweight for microcontrollers, but there is a related project called micro-ROS (https://micro.ros.org/) which puts ROS-compatible libraries on microcontrollers.
> That said, I have looked deeply into ROS, and I cannot understand how it can possibly work when there are strict safety and/or real-time requirements.
You are right that if you are doing safety or controls, you need real-time. That doesn't rule out using ROS or Linux though; there are the real-time kernels (including ones you can install directly from the Ubuntu repositories), and there is a project called ros2_control (https://control.ros.org/rolling/index.html) which takes advantage of that and real-time scheduling to be able to do controls.
However, real-time controls isn't all, or (depending on how you count), most, of robotics. Large sections of robotics deal with things that don't need to be realtime, like doing object detection from cameras, looking at the world through LIDAR, planning paths through space, etc. These things don't need to run in real-time; they typically compute what they need to at the speed they can, and then provide their results to the layers that do real-time. It is a very common arrangement in robotics to have at least 2 processors on-board; a microcontroller doing real-time things for movement through the world, and a microprocessor looking at most of the sensors, learning about the world through it, and making decisions. These lines can blur; often the microcontroller needs some access to sensors as well, for emergency situations.
The whole premise of ROS is that it makes development on these microprocessors easy, and easy to debug. And that seems to be borne out by the results; there are literally millions of robots in the world that run ROS in the arrangement that I describe above.
I hope that answers your question and gives some additional context.
Posted Oct 30, 2025 8:10 UTC (Thu)
by massimiliano (subscriber, #3048)
[Link]
I will surely look into micro-ROS as soon as I have a chance; it's a shame I was not aware of it.
Maybe I could give it a try at porting one of my robots to ROS and see how it goes.
The real potential I see is in having a clean "host" simulation environment where I can run components in isolation, and also test partial or even full integrations (those would require a simulator).
Currently, I don't feel the pressure to go for it because a channel-based Rust environment based on Embassy tasks offers most of the same advantages (on the microcontroller side).
However, I see the advantages of tapping into a larger ecosystem, so thank you again for your reply. I will do experiments and see where this goes!
ROS and safety requirements
> And ROS cannot run there.
> Which, for me, means "all robots that matter".
ROS and safety requirements