wpilibsuite
Allow path level configuration of robot params
Is your feature request related to a problem? Please describe.
Depending on the path I'm driving, I don't always want to go "full throttle" towards it for safety/performance reason. It is non-trivial to tune a controller to use the same constants for going 10% speed vs 80%; sometimes I can want to be fast and inaccurate, and others I'd rather go slow and accurate. At the moment, this tool sets a single "Max Vel, Accel, Jerk" per "project", it would be nice to set that per path instead.
Describe the solution you'd like
Add options to specify/override the max parameters for each path. Potentially set a "default" as you do now, prepopulate a new path with those values, but give the users an option to change them.
Describe alternatives you've considered
- Create different "projects" for each speed I want to drive at (can get real out of hand fast, especially as we iterate through "...but can we do it faster?" attempts)
- Use the inferior version of graphical path generation my team made last year
If max Vel, Accel, and jerk all match what the physical robot can do, I do not know how you could get better performance. You can change the speed goal at each point by changing the “Tangent X” and “Tangent Y”.
@AustinShalit That is incorrect. The tangent magnitudes will affect the sharpness of a turn with Pathfinder V2 but are currently not used. Changing max velocity is a valid strategy for limiting your maximum speed for a path. I can look into this request.
By default short paths should be slower because there is only so much time to accelerate. You are correct that there is no straightforward way to slow down some long paths or speed up some short ones. This could be easily added as part of the follower, just dividing all velocities by 2 and running them twice as long should still produce a feasible path (acceleration and jerk will be less than maximum).
@kjrobrien is going to look into how to specify this at a per path level. Personally I think tuning these parameters per path is adding too much complexity. I do understand the desire to have a few types though. On my robots I will often have 2-3 copies of every drive function tuned with different goals for example
void driveStraight(const long distance)
void driveStraight_Ballsy(const long distance)
The latter is tuned for speed and exits the loop without perfectly settling. It is used in situations when I want to go roughly drive towards something. The current PathWeaver equivalent would be a discrete number of "aggressiveness types" and might be well suited to your wishes.
As of right now, the only way I can see implementing this is adding fields to the project json file. I'm concerned about modifying this file format mid-season.