I'll use ros2_control. If I have to. I guess.

[Michael Wimble]

Well, Sergei has prodded me to spend more of my mortality to use ros2_control in my code. I used ros_control back in the ROS (1) days, but when I converted everything to ROS 2, ros2_control wasn’t there. Then it was there but not ready for primetime. But I had gone ahead and programmed without the library.

So why change now? Well, normally I probably wouldn’t go back and change my code because I never seem to get further on into the really fun part of my code. Sure, I’ve started projects to do localization by just using my LIDAR data and recognizing the shape of rooms in my house and computing the pose of the robot from that, and I did all that stuff to map the Wi-Fi signal strength throughout my house to help me place repeaters, and I’ve got my robot patrolling throughout the house, but I still haven’t got to the point where any beer cans are in danger of being fetched.

So, I could just keep my non-ros2_control code for now and get on with the fun stuff. Except for one thing that is pretty important for me. I spent a huge chunk of my mortality working on safety systems for my robot. My code checks for the effects of broken connections in the wheel encoders which would cause high-speed runaway of the robot, and it checks for motor overcurrent which would melt the motor windings almost immediately, and it checks for motors overheating, and power supply voltages and currents out of range, and a few other safety systems. I have hooks in place to implement rings of safety for collision avoidance, where if the robot is moving too fast to stop before it could run into something, or if the control loop runs too slow, or any of a few other things that would result in the robot getting too close to expensive objects in my house; in any of those cases, the robot needs to signal emergency stop to the motors and, when safety is restored, remove the emergency stop signal.

But all of that requires testing of the safety systems. Applying a blow torch to the motor housings to check not only for absolute temperature values but the slope of temperature ramps is not something I really want to try. Pulling out my DC-DC brick converters and replacing them with programmable, high-current power supplies is not ideal — my robot is not designed for changing power sources just to test the safety system.

But there is a way I can test the code correctness of my safety system—by simulating all of the interesting state. And that’s where ros2_control comes into play.

I’ve spent all day with my favorite set of AI buddies writing a small test robot simulation that not only exposes the read-only values of my current, voltage, temperature, and distance sensors, but allows me to inject values into the sensors. I can run my house patrolling code in Gazebo and have a node that ramps up the motor housing temperature over time and see if the safety system responds as expected. I can simulate the PC drawing too much 12-volt current and make sure that the appropriate Teensy board detects the condition and writes the fault log to the SD card that logs state that would be lost if the PC shuts down.

It’s just a sample piece of code right now. I haven’t found any open source code so far that deals with using ros2_control to deal with read-only sensors and also allows me to write desired values to the sensors when in simulation mode. It’s kind of a bitch because you have to deal with the fact that there really can only be one controller manager running, and your ros2 control classes have to derive from one parent class if you want to simulate a sensor and derive from a completely different class if you’re plugging in real sensors. That took me a long time to get working.

If I have time, though, I’ll flesh this out more and see if I can’t prove that this works switching between real hardware and simulation. If I can do so in the next few days, I’ll outline it all during the next ROS2 SIG meeting during our usual Tuesday night knife fights, er, discussions. And then I’ll write another chapter or 3 for my book, “ROS 2 for Mere Mortals”.

It’s all fun until the robot explodes and melts your polyester pants.

Have I mentioned lately that everything about robots is hard?

[Jeremy Williams]

Thank you for that!

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/6B376620-C049-493B-B9A0-03B32C2F7645%40gmail.com.

[Sergei Grichine]

Welcome to the bright side, Michael! ros2_control is the shortest path to world domination, and we’ll all earn extra citizen credits for advocating it when the Overlords finally take over.

I must confess — my basement and lawn are completely free of glass doors or anything expensive, so my only real concern right now is robot self-mutilation. I can claim one burned 350 W motor (the robot lost a contest with a tree), but my solution was simply to replace it with high ratio 350 W gearmotors. Now the tree is the one trembling when Dragger drives by... slowly.

I’ve also noticed that a well-tuned nav2_params.yaml is surprisingly effective at keeping my bots safe around anything the lidar can see.

And yes — I absolutely love the idea of SIM-first and “trouble injection.” That’s first-class engineering in my book.

Now, I have to dig really deep to find something to “disagree” with… so let’s talk safety systems.

We can roughly split them into two categories:

1. Things the onboard computer can handle on its own:

• Monitoring voltage and current and adjusting behavior accordingly
• Additional safety loops for collision avoidance
• Watching internal loop frequencies, CPU load, WiFi quality, delays, etc.

2. Things that happen when the onboard computer goes completely bananas or dies, and a watchdogwolf must take over:

• Driving straight toward an obstacle and refusing to stop
• Anything overheating, smoking, or catching fire
• Main current draw going way too high

For the first case, you seem to be making good progress. But what about the second case? I'd guess you have enough Teensies to put that logic there? What about sharing sensors between the main computer and the Watchdog? Having some switches controlled by the watchdog? Does the "keep it simple" principle, when applied to the watchdog, conflict with the complexity of your Teensy hardware and software?

BTW, ROS2 Control Manager discovers Ubuntu Real Time kernel and will adjust its scheduling to run at higher priority. 

It will fail in subtle ways if not allowed to do so. One more reason to use RT kernel, and to use it properly: https://github.com/slgrobotics/robots_bringup/blob/main/Docs/Ubuntu-RPi/UbuntuRealTime.md

P.S. - in our last Tuesday meeting I was distracted, trying to find the map offset parameter, and might have missed the important points you were making about the dynamic TF (for the moving lidar?) If, by any chance, there's a solution of further considerations - I am all ears.

Best Regards,

-- Sergei

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CAJHxCZGgopLSnbK3BqOO6LPY5NDE-HpjznXjzE9rOKbadcrP4w%40mail.gmail.com.

[Alan Timm]

heh, when the smart people talk I tend to listen, so I'm adding ros2_control onto the list of things to explore as I move forward with alfie.  Among other things, I guess that will make it easier to retarget between simulation and the live robot.  :-)

I plugged a bunch of sources into NotebookLM to get a handle on the subject.

https://notebooklm.google.com/notebook/de95b7c4-1395-4b82-9ca8-7813c9addf98

[agmiller]

Michael and Sergei,

I'm very interested in how you have implemented the watchdog and safety loops in ROS, and hope you can walk us through during the ROS SIG meeting.

Specifically, I looking into ways the hardware interface can implement safety functions outside of ROS, to compliment/enable safety loops running inside of ROS. 

Thanks,

- A - 

On Sunday, November 30, 2025 at 4:20:25 PM UTC-8 Sergei Grichine wrote: