Tuesday, June 5, 2012

AVC: My Steering Algorithm Sucks

Sunday testing went... um... sub-optimally.
The latest Data Bus update is that I'm hosed if I don't get the robot navigation nailed in the next day or two so I can work on barrel avoidance. The Sparkfun AVC is in less than two weeks.

Here I thought I had this clever little steering algorithm that worked oh so well. As it turns out, it sucks rocks. The robot keeps driving into curbs.

It even knows full well that its going off course, but it doesn't correct its course.

Strange? Yeah.

Well, here's what's going on...

I figured either the robot wasn't doing anything to change its course, or whatever it was doing wasn't having any effect, based on the position estimates coming out of the robot log files.

The purple path is the estimate; very close to reality.
It hit me on the way back from Boulder. Steering slop. And my crap steering algorithm.

Trying to be fancy the robot attempts to navigate to a goal point that is on a straight path between it and the target waypoint.

It doesn't account for cross track error. And for small heading errors, the robot commands steering angles that are too small for the physical resolution of the steering system.


At more than 70 meters, the heading errors I was seeing in testing fall below 10 degrees. The computed steering angles are under 2.5 degrees. That's a tiny angle for a cheap 1/10th RC truck steering system.

But it also amounts to a big heading difference after 70 meters of travel.

Small heading errors mean very small steering angles

To further verify my theory I ran experimental code on the robot to move the steering servo between the ranges corresponding to steering angles of -2.5 to +2.5 degrees. Play in the servo linkage and the servo saver was causing a dead band of about 3-5 degrees around the center point.


I've implemented some mechanical changes to reduce steering play but I doubt it'll be enough. I may try to implement a couple more mechanical improvements, but I think a software solution is required.

Converting to a pure pursuit algorithm is likely best. The robot would compute a steering angle to intercept a point that moves along the desired path at a fixed distance L from the robot. In doing so it smooths out transitions between waypoints and it inherently corrects for cross track error.


I modified my Processing playback program to become a rudimentary simulation program. I wrote code that implements my original steering algorithm and, with help from Jesse, the pure pursuit algorithm.

Then I modified the simulation code to simulate steering slop and misalignment that causes the robot to pull to one side instead of driving a perfectly straight line.

Lo and behold. With my crummy algorithm controlling a robot with misalignment and steering slop, the simulated robot behaves exactly as the real one, unable to properly track a straight course to the target waypoint, veering off, and correcting nearly at the last moment.

By contrast, the pure pursuit algorithm had no problem staying on track with the same steering slop and misalignment, though some oscillation in heading resulted.

Another interesting discovery is that the pure pursuit algorithm has no problem correcting initial heading errors, for example, where the robot should be pointed at 90° but is pointed at 95° instead. My dumb algorithm can't do this, explaining some anomalies from a few weeks ago.

I was feeling pretty down on Sunday after the crashes, but with the work above, some confidence is returning. I hope I can get the navigation nailed down and the speed up where it needs to be. There's still the matter of obstacle avoidance...


  1. oooh, this is brilliant! I'm having a very similar problem. Problem Solved! (I hope).

  2. This has been a great series, clearly explaining your design ideas and experimental results. Looking forward to seeing Data Bus race across the finish line in ten days. Thanks for sharing.


Note: Only a member of this blog may post a comment.