paper: Driving a Robot — Fastest Path from A to B

[Jared]

Originally Posted by Mr. N

Very nice work!

I think, in fact, we're in good agreement. Here are some points of clarification:

Me too. After reading this post, I agree with what you've said, that curves and drive-then-turn both have their uses, especially considering that curves are much more difficult to implement. For a single spline, the time difference is pretty small. Once you start joining many splines, or using weirder splines, it becomes a different problem.
[quote]

This I'm really curious about. In my dynamic model, the velocity/acceleration limits are set by the motor characteristics. Speed and torque are coupled. However, I don't see how third-order derivatives (jerk) enter into it.

I implement the jerk limit not because it's needed, but because it makes the path a little smoother. It prevents the motor power from going full forward to full reverse instantly, preventing tripped breakers and slipping wheels. It can also stop a top heavy robot from doing little tips as it stops. It has a very small effect on time.

In your example, the total path length is a little over 7 feet or about 2.2 meters. In my previous post, I point out that, in hi-speed gear, it takes about 1.4 meters to accelerate (and likely something similar to decelerate). So, this example is what I would classify as a "short" path (where acceleration definitely matters).

True. The longer the lines are, the faster they are, compared to curves. For something with one or two lines with small turns, lines could be faster. For something with 5 or 6 curves that are pretty short, curves could be faster.

Can you re-run your example for 25x25 foot run (e.g., a cross-field maneuver) with similar rates of turn (remembering that the speed constraint must be imposed on the outermost bank of wheels during a turn, not the centroid).

Yes. The speed constraint problem is one I don't have a great solution for. Currently, I generate the curve through the points, calculate speeds/accelerations at each point for the center, then the two sides where the wheels are, and if any point is too high, it adjusts a parameter and tries again, and repeats until it's within range. The iterating solver tries to adjust the "curviness" of the splines as well as adding a factor to cheat and increase the calculated radius of curvature at each point, which is used to limit the speed through curves. The end result is that the robot will slow down more on tighter curves, thinking they are tighter than they really are, but driving on curves/straight parts with a large radius of curvature is not slowed down.

Agreed , but is this representative of a real game strategy? I would argue that a typical game involves significantly fewer way points per scoring cycle that what you've shown.

Probably not.


Here's my setup for the bigger run
Start Point: (0,0)
End Point: (25, -25)
Max Velocity: 10 ft/s
Max Acceleration: 10 ft/s^2
Max Deceleration: 15 ft/s^2
Robot Width: 2 feet

Trial 1:
Start Heading: 0 (facing right)
End Heading: 0
Path Type: Quintic Parametric
Results:

     Time: 4.784024461201024
     Distance: 37.531625864027085
     Average Speed: 7.845199406569258

Trial 2:
Start Heading: -pi/4 (diagonal down and to the right)
End Heading: - pi/4
Path Type: Line

Results:

     Time: 4.520517763673839
     Distance: 35.3518031718333
     Average Speed: 7.820299580706168

A great example of where a line would be much faster:

 
     Time: 4.142848102721899
     Distance: 23.413771473152483
     Average Speed: 5.6516123431533405

A line for the same path:

     Time: 1.5516701850414147
     Distance: 6.099594833091013
     Average Speed: 3.9309866825392485