How Fast Can I Go, a thought piece

[Michael Wimble]

This is a draft of an article I’m thinking of completing. The data at the end about the history of Sigyn is somewhat fabricated. I used Claude Sonnet 4.5 to help me go from concept to research to data gathering to draft. A lot of the words are Claude’s for this draft, but the research, data measurement, concept, and several drafts leading to the final document are mine. Still, keep in mind that this is a draft, not a final article. And, as explained in the article, some of the data is measured by me, some of it is a ballpark that I haven’t verified, like Linux scheduling jitter on a Raspberry Pi 4.

The conclusions I think are right, in my experience. I think the speeds you should limit your robot to given the various assumptions seem about right. I think the order of concerns you should address seems about right.

So, for your amusement, and note that you accept all risks if you use this advice, here is a draft article about how fast you should expect your hobby robot to go. Constructive criticism and discussion is encouraged.

[Sergei Grichine]

This is really a must-read for any of us. And look—this is what happens to readability and language skills when Claude brings you coffee in the morning and wishes you good night… an easy, enjoyable read, too!

That said, here are my “fresh eye” notes as I was reading it.

Linux R/T Kernel on Raspberry Pi (working with ros2_control):
Robots that are not based on ros2_control don’t really benefit from an R/T kernel, do they?

Motor controller delay:
I’m not sure where the 50 ms figure comes from (although I don’t disagree with accounting for it, or with the ballpark). But - why is RoboClaw assumed to be ~20 ms while an MC+H-bridge is ~50 ms?

RPi 4 realistic speed ≈ 1 mph:
Very true in my experience. In practice, though, this is mostly limited by Nav2’s ability to navigate reliably, not collision safety.

Communication latency:
It can be far more unpredictable than simply dividing packet length by bitrate—but overall, it should indeed be low. Also, isn’t “230400 baud” kind of a myth? Does USB-to-serial really honor bitrate settings? There’s a lot of buffering going on there.

WiFi speed might contribute to delays, especially when you are monitoring the robot using RViz etc.

Here’s what I’ve got working very well for Seggy (indoors, RPi 5, BLDC wheel motors, Arduino motor controller over USB-to-serial):

    https://github.com/slgrobotics/articubot_one/blob/main/robots/seggy/config/nav2_params.yaml

      controller_frequency: 5.0 # For sim must be 5.0 to match or exceed simulation's time step. Works for real robots too.
      ax_max: 1.0  # max forward acceleration
      ax_min: -1.0 # max reverse acceleration
      vx_max: 0.3  # max forward speed            <== exactly how Michael estimated it. Did you look over my shoulder? ;-)
      vx_min: -0.2 # max reverse speed
      wz_max: 0.1  # max turning speed (less aggressive)
      #robot_radius: 0.30  # actual robot radius plus small safety margin      <== not used, as footprint is defined
      footprint: "[[ 0.280,  0.000],
                  ...
      inflation_radius: 0.36  # Default: 0.55. Should be larger than robot footprint. 0.3549 computed bubble.  <== squeezing through doorways

..._costmap:
      update_frequency: 6.0 # Default: 5.0 Matches Laser scan frequency
      publish_frequency: 6.0 # Default: 5.0 Matches Laser scan frequency (6 Hz)

For Seggy, stopping distance wasn’t the dominant factor. Reliable navigation was—and that likely ties back to the 6 Hz LiDAR update rate. BTW, Seggy doesn’t use Ubuntu’s R/T kernel.

The biggest elephant in the room (partially highlighted in the article), of course, is:
How fast does the robot NEED or SHOULD go?
Overall? Or moment-to-moment? Bringing you a beer versus rushing to help? Casually patrolling the house versus scanning for intruders?

And - what can you realistically do on a time and budget constraint?

Well… use my code, of course 😉 - and read that article! 

Best Regards,

-- Sergei

--
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/EF2E30E7-E62C-45D2-8C19-CAED370101A9%40gmail.com.

--
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/EF2E30E7-E62C-45D2-8C19-CAED370101A9%40gmail.com.

[Chris Albertson]

It can go a lot faster.    I built one that would do up to about 85 MPH.     It was a quad copter drone.         Some math...  Typically, a minimal design criterion is that the copter needs to hover at 1/2 throttle.  Many can hover with less power.   This means the motors provide 2G acceleration or more.  Mine could accelerate vertically at better than 1G.   With that kind of power available, it could turn and stop on a dime.        The trouble is path planning.  Mine hit my garage wall at high speed, missed the window but hit a stucco wall.   Surprisingly, many parts were reusable, as the robot copter is 3D printed, so I would carry a couple of full sets of parts while testing.      The other problem with a high-performance robot is that it can get out of sight in seconds.  And if you have a software bug, you can lose the robot if you can’t see where it went.   I had a radio-link kill switch.   The ‘bot would fall like a rock if you pressed it.

I eventually decided I would need to live near a clear and open area for testing.

In use, the robot would never go that fast.  But you need to debug the software.

So there is one more how fast is too fast story.    

--
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/EF2E30E7-E62C-45D2-8C19-CAED370101A9%40gmail.com.

<HowFastCanIGoV1.pdf>