Thanks for reading! Fair warning, I enjoy delving into a lot of detail, so here goes!
Why did you take away the initial acceleration for the target velocity calculations and then add in the rate limiter to compensate instead of just starting with a small positive target velocity (so the robot will start to move) and limiting the acceleration via the target velocity motion profile?
Because there is no interpolation between points when finding the target velocity, it jumps between values, especially at low speeds. Removing the acceleration from the velocity profile and adding in the rate limiter makes the robot follow a more smooth acceleration curve at the beginning of the path.
Otherwise, both methods should work, you just need to make another pass through the target velocities in the forward direction to apply the acceleration limits. One possible disadvantage of using a rate limiter is that if your robot is traveling faster then it should, it will drive through deceleration points faster then the rate limiter allows it to decelerate and could overshoot the end of the path. This hasn’t been an issue for us.
How well does this method handle 180° turns? Can it drive backwards or only forwards?
We have never tried a path that goes straight forwards then straight backwards, but we did do a small U-turn once in testing, which worked pretty well because the robot slows down around sharp turns. If the turn is too small the robot could turn too early and not slow down because the closest point would never be the one with the sharp curvature and slow target velocity. This is where it could be helpful to adjust the lookahead distance based on robot speed or path curvature, so it follows the sharp turn more precisely. I suggest experimenting with the simulator, which I would love to do to help answer your question but I have to go on this thing called “vacation”. Sigh.
Amazingly, to make the robot drive backwards all you have to do is negate the target velocity before sending it to the left/right wheel speed calculations. We haven’t tried this on the real robot yet, only in the simulator.
Did you play around with the difference between increasing path smoothness (from 2168’s algorithm) and increasing lookahead distance? It seems like the two would do the same thing, possibly to the point where smoothing the path might not be necessary.
We haven’t really played with this, but here’s why I think smooth paths are better:
- When you increase the lookahead distance to try to follow an unsmoothed path smoothly, the robot cuts corners, making it difficult to make small, precise turns.
- Smoothing the path and using a smaller lookahead distance to precisely follow it means that when you graph the path you see precisely where the robot will be driving ahead of time.
So for best results, we smooth the path, use a smaller lookahead distance so we can go around sharp turns, and if we want sharp and less sharp turns in the same path we truncate the corner of the less sharp turn (so one 90 angle turns into two 45s).
Did you ever see the robot get far enough off the path that it couldn’t recover (i.e. further than the lookahead distance away). If so, what did you have the robot do?
While this has never happened to us, if the robot can’t find a lookahead point it will use the value of the last one and steer back onto the path. However, it might be better instead to use a point a bit farther down the path than the closest point, because:
- This point will travel with the robot as the robot continues forward, unlike the last lookahead point, so the robot won’t have to do a u-turn to get back to the point.
- There might be a reason for starting the robot off of the path, in which case there is no last lookahead point.
- Another place the robot can’t find the lookahead point is at the end of the path, and using a point a few ahead of the closest point will make the robot aim for the end of the path, like it should.
How much of these calculations was done pre-match and what was done in “real time”?
The smoothed paths are calculated pre-match and loaded into files, because for large smoothing amounts the smoothing algorithm can take a decent amount of time to work. Once autonomous starts, the path data is read and the path curvature and velocity setpoints are calculated. Then odometry, finding the lookahead point, curvature, closest point, left/right wheel speeds, etc., is done in real time.