Open amikhalev opened 7 years ago
An article with useful information:
DriveStraight would basically use this for getting it to drive a distance smoothly, and then use a PIDController to make it actually drive in a straight line. So instead of having it set the power + output
to the left side and power - output
to the right side, it would get power from the motion profiler
Maybe the controller could base everything based on time deltas, but it could sort of 'hint' at the actual time based on the current position feedback from the encoders
And for S-curve profiles, we would need an additional parameter for maximum lurch, or change in acceleration. This should be optional though
So there are certain commands for which we may want to do a smooth motion profile. For example, driving straight. Right now we just start applying power and assume that we will get up to speed quickly, and then we drop power and assume it will stop almost immediately. But in reality, we can't have instant acceleration (or change in acceleration, ie. lurch). So if instead, we model the desired acceleration profile at the start of a movement and at the stop of the movement as a trapezoid, we would achieve much smoother and more controlled movements.
This is sort of what we want:
This should probably be implemented as a Steppable, possibly an Controller. Although it really has two inputs. One is the x-axis in the graph above, which is time. The motion profile is really actually feed forward control, where it assumes that by setting certain speeds to the drivetrain at certain time eventually it will arrive at the correct distance. But somehow we need feed-back to be implemented, where the current distance on the drive train is also taken into account. Currently we basically have a motion profile where we assume we have infinite instantaneous acceleration to the travel rate, then infinite acceleration to stop when the encoder reaches a certain amount of ticks. I guess the whole thing could be based on just encoder ticks, but the issue with that is that it would never get started because at distance 0, desired velocity is 0. So it needs to be primarily based on time, but then also take feedback from the current position. It also needs to have the option of not ending at speed 0, but ending at a different speed or not changing the speed at the end at all so we can continue with the next drive part smoothly. Same thing with the start. In that case, some parameters would be:
Just spitting out ideas here, but I think this could be a valuable item in our toolbox for smoother controlled driving, and also movement for some mechanisms. Please ask or comment with any questions or ideas.