Quote:
Originally Posted by artK
This is awesome! Do you have any video of this running on your robot during auto?
My one question is why are you generating these 200 points? Because that seems like a lot. Each spline covers about 2", and you have 199 points where the quintic constraints have you driving straight locally (Since the second derivative is zero when it approaches the waypoint in the spline configuration we developed). I suspect this would make the robot drive a little twitchy, especially when trying to turn.
|
We don't have a video running auto, in my
initial code repo all this was done on a coprocessor (and worked flawlessly on a practice field), however we had some issues with FMS not forwarding ports at the regional I went to, so I turned Motion Profiling off in favor for just a 'go forward for x encoder ticks'.
The reason so many points are generated is because of the nature of the control loop. Each point has a dt value (i.e. how long this control loop iteration lasts before moving onto the next) - in our case, it was 1 / 50. Each iteration (which is timed with the Notifier class from WPIlib) will fetch the next segment and process it.
It is possible to look at the second derivs in order to reduce the amount of points, but that would (at least in the current algorithm) add more time to the actual generation sequence. I can modify the algorithm to correct for this and suffer next to no time overhead. Maybe something to put on my todo list
The path didn't jitter at all, in fact it was very smooth. Turning was very smooth and didn't seem to have any issues