I'm abandoning Micro ROS
36 views
Skip to first unread message
Michael Wimble
Jun 9, 2025, 12:50:09 PMJun 9
to hbrob...@googlegroups.com
I’m finally giving up on Micro ROS, I think. It offers a solution to a problem I don’t have at a complexity I don’t need.
It took a fair amount of learning to create the Micro ROS environment for my Teensy 4.2 components with custom configuration, as I needed bigger message packets, more publishers and subscribers, and custom messages. Maintaining time synchronization adds too much overhead. But the kicker was that somewhere along the line of accepting changes to the brittle Linux ecosystem over the last few days has caused hash value warnings to crop up in topic communication — my Micro ROS was originally created under Humble and worked fine with Jazzy until something broke recently.
This caused me to rethink why I went down this road anyway. I was seduced into thinking that I needed the advantages that DDS supposedly brings, that I needed to deal with communication errors, checks for versions of messages (hence the hash value errors that just came up), serialization of actual ROS message formats, and a couple of other issues. And none of that ended up being true.
USB communication between the Teensy and my PC is reliable and very fast. It doesn’t matter what serial speed you think you’re assigning to the serial-over-USB channel, as it’s a virtual channel and operates near the maximum USB speed. USB already is a reliable communication channel. If I need to deal with reliability beyond that, such as handling cable disconnects, fractured wires, etc., I can add a simple CRC check and an ACK/NAK handshake. I don’t need to pass real ROS messages over the wires; I pass human-readable ASCII text in abbreviated form. I don’t have timers going off to deal with executors—I’ve simply built a state machine with counters and use the millis() and micros() functions to determine if it’s time to do the next time-based action in my loop. I have a TModule class that allows all of my functionality to be broken up into segments, each with its own setup() and loop() methods, and TModule gathers performance stats so I can see what kind of execution variance I’m getting when dealing with sensors. I have a class that manages the SD card so I can write a lot of log data quickly and not tie up the USB channel. When things go wrong, I pull out the SD card and see what happened.
I wrote a simple C++ program that runs on the PC and interacts with my Teensy using a single serial, USB connection, where messages are simply multiplexed in the stream.
It’s simple, reliable, and fast. In ROS, fast frame rates and low latency is critical. I’m still tweaking it, but I believe I can increase my sensor frame rate from 30 or so frames per second up to more like 1 or 2 hundred frames per second, though I’ll probably add more messaging and add more sensors if I have headroom. I probably want about 50 frames per second for the stuff the Teensy is controlling.
I have two Teensy 4.2 devices in my computer at the moment.
One manages:
* All the cmd_vel message handling. That is, cmd_vel x and z data (only) is sent to the Teensy. It turns that into motor commands for the RoboClaw. Those commands do ramp up/ramp down acceleration of the commanded velocity and include a safety feature where the motors will simply come to a stop if the Teensy fails or the nav system fails to send commands fast enough. There is also a safety layer that checks the motor currents and will shut down the system if it detects a motor stall condition. The safety layer also checks the wheel encoders and detects when the PID loop is failing because the motors are in a runaway situation. It also checks motor temperatures and motor controller temperature and will shut down the system if anything overheats. Finally, it computes odometry and passes it up to the PC.
* Battery management. For now, that simply involves checking that the battery isn’t discharging below a safe limit and shutting off the motor system if it is. Later, it will signal all the other computers to shut down as well and send some alert to my phone. I used to use Twilio to send SMS messages to me.
* It has code, currently disabled, to manage 4 SONAR and 8 time of flight sensors to enforce a final ring of protection against collision.
* It has code, currently disabled, to manage a touch screen to display all the sensor data and allow manual power on/off and system reset of all the components.
The other Teensy manages the gripper system with one stepper to move an elevator, another stepper to move the horizontal extender arm. This includes enforcing movement physical limits and velocity limits. There is plenty of overhead in this second system to add a lot more sensors.
The new code is still being tweaked. I’m taking the opportunity to redesign systems and refactor systems while I’m at it.
Micro ROS is dead. I’ve used it for three years and I won’t miss its passing. Long live tricky, efficient code.
It took a fair amount of learning to create the Micro ROS environment for my Teensy 4.2 components with custom configuration, as I needed bigger message packets, more publishers and subscribers, and custom messages. Maintaining time synchronization adds too much overhead. But the kicker was that somewhere along the line of accepting changes to the brittle Linux ecosystem over the last few days has caused hash value warnings to crop up in topic communication — my Micro ROS was originally created under Humble and worked fine with Jazzy until something broke recently.
This caused me to rethink why I went down this road anyway. I was seduced into thinking that I needed the advantages that DDS supposedly brings, that I needed to deal with communication errors, checks for versions of messages (hence the hash value errors that just came up), serialization of actual ROS message formats, and a couple of other issues. And none of that ended up being true.
USB communication between the Teensy and my PC is reliable and very fast. It doesn’t matter what serial speed you think you’re assigning to the serial-over-USB channel, as it’s a virtual channel and operates near the maximum USB speed. USB already is a reliable communication channel. If I need to deal with reliability beyond that, such as handling cable disconnects, fractured wires, etc., I can add a simple CRC check and an ACK/NAK handshake. I don’t need to pass real ROS messages over the wires; I pass human-readable ASCII text in abbreviated form. I don’t have timers going off to deal with executors—I’ve simply built a state machine with counters and use the millis() and micros() functions to determine if it’s time to do the next time-based action in my loop. I have a TModule class that allows all of my functionality to be broken up into segments, each with its own setup() and loop() methods, and TModule gathers performance stats so I can see what kind of execution variance I’m getting when dealing with sensors. I have a class that manages the SD card so I can write a lot of log data quickly and not tie up the USB channel. When things go wrong, I pull out the SD card and see what happened.
I wrote a simple C++ program that runs on the PC and interacts with my Teensy using a single serial, USB connection, where messages are simply multiplexed in the stream.
It’s simple, reliable, and fast. In ROS, fast frame rates and low latency is critical. I’m still tweaking it, but I believe I can increase my sensor frame rate from 30 or so frames per second up to more like 1 or 2 hundred frames per second, though I’ll probably add more messaging and add more sensors if I have headroom. I probably want about 50 frames per second for the stuff the Teensy is controlling.
I have two Teensy 4.2 devices in my computer at the moment.
One manages:
* All the cmd_vel message handling. That is, cmd_vel x and z data (only) is sent to the Teensy. It turns that into motor commands for the RoboClaw. Those commands do ramp up/ramp down acceleration of the commanded velocity and include a safety feature where the motors will simply come to a stop if the Teensy fails or the nav system fails to send commands fast enough. There is also a safety layer that checks the motor currents and will shut down the system if it detects a motor stall condition. The safety layer also checks the wheel encoders and detects when the PID loop is failing because the motors are in a runaway situation. It also checks motor temperatures and motor controller temperature and will shut down the system if anything overheats. Finally, it computes odometry and passes it up to the PC.
* Battery management. For now, that simply involves checking that the battery isn’t discharging below a safe limit and shutting off the motor system if it is. Later, it will signal all the other computers to shut down as well and send some alert to my phone. I used to use Twilio to send SMS messages to me.
* It has code, currently disabled, to manage 4 SONAR and 8 time of flight sensors to enforce a final ring of protection against collision.
* It has code, currently disabled, to manage a touch screen to display all the sensor data and allow manual power on/off and system reset of all the components.
The other Teensy manages the gripper system with one stepper to move an elevator, another stepper to move the horizontal extender arm. This includes enforcing movement physical limits and velocity limits. There is plenty of overhead in this second system to add a lot more sensors.
The new code is still being tweaked. I’m taking the opportunity to redesign systems and refactor systems while I’m at it.
Micro ROS is dead. I’ve used it for three years and I won’t miss its passing. Long live tricky, efficient code.
Pito Salas
Jun 9, 2025, 2:42:51 PMJun 9
to hbrob...@googlegroups.com
Michael,
That’s pretty impressive! Great analysis and interesting essay.
As I understand it, you would need to have the teensy both send info the the pi (e.g. Odom - or decoder tics) and receive info from the pi (i.e. Cmd_vel etc.). Without an OS on the teensy are you essentially writing a simple OS to handle that?
Other than motors and encoders what else is connected to the teensy?
Would you be willing to show us the code?
Pito
> --
> 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/AF023293-ABEE-44CC-A21F-2A8FC79F9EBB%40gmail.com.
That’s pretty impressive! Great analysis and interesting essay.
As I understand it, you would need to have the teensy both send info the the pi (e.g. Odom - or decoder tics) and receive info from the pi (i.e. Cmd_vel etc.). Without an OS on the teensy are you essentially writing a simple OS to handle that?
Other than motors and encoders what else is connected to the teensy?
Would you be willing to show us the code?
Pito
> 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/AF023293-ABEE-44CC-A21F-2A8FC79F9EBB%40gmail.com.
Michael Wimble
Jun 10, 2025, 2:22:49 AMJun 10
to hbrob...@googlegroups.com
Of course, most of my development eventually ends up somewhere in my GitHub.
 | |
Look at sigyn_to_teensy for the PC-side code that sends ROS messages as ASCII to the Teensy and reads ASCII messages from the Teensy and turns them into ROS messages. It’s a trivial program.
And teensy_to_sigyn is the Teensy side program. It’s not complete yet and only deals with the battery monitor and cmd_vel stuff. It isn’t tuned yet but it’s small now and easy to see how it all works.
The package teensy_monitor/tm5 is the older, Micro ROS code with more functionality.
teensy_monitor/oldCode has the Teensy stuff with time-of-flight and SONAR tricky code to deal with lots of sensors efficiently to keep up high frame rates. It also has the old touch screen monitor code.
For those interested in what I did today, I took the old, ROS1 package for teleop_twist_keyboard and had AI rewrite it for ROS2 with some redesign and improvements. Importantly, it supports command-line options for default linear.x and angular.z values so you don’t have to always pound the keyboard a bunch of times to get to the rates you want. It supports a limit on speed and turn values. You can decide if you want stamped cmd_vel or unstamped cmd_vel. You can set the frame_id. You can decide the repeat rate. And when you stop pressing a key it stops sending cmd_vel messages.
Other interesting packages include:
* bluetooth_joystick — pairs with my Nimbus Steele Series joystick (from my Mac) to send cmd_vel messages, implement a deadman switch, operate my elevator and horizontal gripper, and open and close the testicle twister on my gripper.
* gripper — this is the Micro ROS Teensy side package to operate the elevator and horizontal extender.
* sgyn_behavior_trees — the beginning of my special code and custom behavior trees for my robot. Currently, it’s mostly a demo of how to extend and customize ROS2 behavior trees. I’ll fill in more later.
There is more, but I’m not going to describe it all here.
Other interesting repositories include:
* sigyn_testicle_twister - code that runs on a Pi 5 and subscribes to a cmd_vel topic and operates the opening and closing of the end-effect gripper. Also includes code to control a servo by hardware PWM on a Pi 4 (not a Pi 5 running Ubuntu), software PWM, and using a PCA9685 dongle.
* sigyn_video_server — shows the video stream from my v3 wide-angle Pi camera on a web page and includes a button to capture a frame as a JPG to a directory. Those images will later be used to train my object recognition AI.
* wifi_logger_visualizer — captures Wi-Fi data and communication speed from the robot to the desktop and saves it into a database for display as an RVIZ overlay. It also can generate a standalone heat map of the Wi-Fi data, showing you how well Wi-Fi is working throughout your house.
* min_max_curr_rviz_overlay — takes the Wi-Fi logger data and shows it as a costmap overlay in RVIZ so I can see how well the Wi-Fi performs on my robot throughout the house. It also has a widget for responding to some critical action, like a battery getting ready to fail.
* ros2_roboclaw_driver — a recent rewrite of a driver for the RoboClaw. Works on a PC and has special instructions for use on Raspberry Pis.
* laser_lines — looks at laser scans and detects lines, such as might be walls or edges of tables. Will be used to do localization by recognizing the shapes of each room of my house and figuring out where the robot is in the room.
Michael Wimble
Jun 10, 2025, 2:23:37 AMJun 10
to hbrob...@googlegroups.com
Of course, most of my development eventually ends up somewhere in my GitHub.
 | |
Look at sigyn_to_teensy for the PC-side code that sends ROS messages as ASCII to the Teensy and reads ASCII messages from the Teensy and turns them into ROS messages. It’s a trivial program.
And teensy_to_sigyn is the Teensy side program. It’s not complete yet and only deals with the battery monitor and cmd_vel stuff. It isn’t tuned yet but it’s small now and easy to see how it all works.
The package teensy_monitor/tm5 is the older, Micro ROS code with more functionality.
teensy_monitor/oldCode has the Teensy stuff with time-of-flight and SONAR tricky code to deal with lots of sensors efficiently to keep up high frame rates. It also has the old touch screen monitor code.
For those interested in what I did today, I took the old, ROS1 package for teleop_twist_keyboard and had AI rewrite it for ROS2 with some redesign and improvements. Importantly, it supports command-line options for default linear.x and angular.z values so you don’t have to always pound the keyboard a bunch of times to get to the rates you want. It supports a limit on speed and turn values. You can decide if you want stamped cmd_vel or unstamped cmd_vel. You can set the frame_id. You can decide the repeat rate. And when you stop pressing a key it stops sending cmd_vel messages.
Other interesting packages include:
* bluetooth_joystick — pairs with my Nimbus Steele Series joystick (from my Mac) to send cmd_vel messages, implement a deadman switch, operate my elevator and horizontal gripper, and open and close the testicle twister on my gripper.
* gripper — this is the Micro ROS Teensy side package to operate the elevator and horizontal extender.
* sgyn_behavior_trees — the beginning of my special code and custom behavior trees for my robot. Currently, it’s mostly a demo of how to extend and customize ROS2 behavior trees. I’ll fill in more later.
There is more, but I’m not going to describe it all here.
Other interesting repositories include:
* sigyn_testicle_twister - code that runs on a Pi 5 and subscribes to a cmd_vel topic and operates the opening and closing of the end-effect gripper. Also includes code to control a servo by hardware PWM on a Pi 4 (not a Pi 5 running Ubuntu), software PWM, and using a PCA9685 dongle.
* sigyn_video_server — shows the video stream from my v3 wide-angle Pi camera on a web page and includes a button to capture a frame as a JPG to a directory. Those images will later be used to train my object recognition AI.
* wifi_logger_visualizer — captures Wi-Fi data and communication speed from the robot to the desktop and saves it into a database for display as an RVIZ overlay. It also can generate a standalone heat map of the Wi-Fi data, showing you how well Wi-Fi is working throughout your house.
* min_max_curr_rviz_overlay — takes the Wi-Fi logger data and shows it as a costmap overlay in RVIZ so I can see how well the Wi-Fi performs on my robot throughout the house. It also has a widget for responding to some critical action, like a battery getting ready to fail.
* ros2_roboclaw_driver — a recent rewrite of a driver for the RoboClaw. Works on a PC and has special instructions for use on Raspberry Pis.
* laser_lines — looks at laser scans and detects lines, such as might be walls or edges of tables. Will be used to do localization by recognizing the shapes of each room of my house and figuring out where the robot is in the room.
On Jun 9, 2025, at 11:42 AM, Pito Salas <pito...@gmail.com> wrote:
Reply all
Reply to author
Forward
0 new messages