Ways to tune top speed or acceleration

[cozymentor]

Hey there,
I am working with path planner and am having a lot of fun, and enjoying the results. One challenge our team is running into is getting the robot to complete the path in a reasonable amount of time. Path planner shows that the robot should be able to complete the path in around 9 seconds, but in reality it turns out to be just over 13 seconds. We are hoping to shave some of this time off to allow more time for game piece acquisition and placement, and I was wondering what would be some strategies we could try to accomplish that.
Thank you for your time,
Cozy

[WarrenReynolds]

The time the path planner GUI shows, is the robot travel time of the path/s based on the max vel and max acc set in the GUI. When building trajectories, these speeds can be pulled from the GUI values (from the path files) or hard coded in the constructor, depending on the how you have written your code. So the execution time and GUI time could be different if you are using hard coded values that are different to the GUI values.

When a path is being followed, it is sampled using a timer so there is no real way that the it could "run slow".

Also, do you have your robot stopping and waiting for commands to end at stop points. Because the total time in the path planner GUI doesn't account for this.

[cozymentor]

We are using hard coded values for max vel and max acc. I have tried raising those values, but it doesn't seem to reflect in the result. The reason why I believe the robot could accelerate faster, is we were working with Pathweaver prior and the robot ran way too fast to be accurate. Path planner seems to have smoother acceleration and deceleration built-in, but I was wondering if that behavior could be tuned at all.
The robot stops for a fraction of a second when it reaches its first target destination. This was mostly to test the stop feature and see what is required to insert a command at that point.

[WarrenReynolds]

but I was wondering if that behavior could be tuned at all.

Simple, increase the acceleration value. Your max speed can be as high as you like, but if the acceleration is too low it will never reach this max speed.
Simple way to think of this is, if the max Vel is 3m/s and the max Acc is 1.5m/s^2 its going to take 2 seconds for the robot to reach its max speed.

What is your drive base?
If you are using SDS 4i Swerve Modules with L2 gearing with Falcons (This seems to be the most common these days for the teams that are using PathPlanner) You should be able to get up to 5m per second top speed. I've run 3m/s^2 values for acceleration in the past and not had wheel slip.

Believe it or not, but we found accuracy improved the faster we went when using a swerve drive base.

NB: You need your drivebase to be setup properly (ie when you tell it to go 1m/s it actually does 1meter per sec). For us we ran velocity control mode on the Falcons Motors directly and scaled our encoder counts per 100ms using the gear ratios and wheel diameter.

I suggest changing your code to read the values from the GUI and then you can use the graph option (far right icon on the bottom of the Pathplanner GUI) to see what everything is supposed to be doing. Also this lets you tweak the speeds without having to do a recompile every time you make a change to the speeds. All you have to do is a "deploy code" and provided the code hasn't changed this will only take a couple of seconds to copy across the the .path files. You can even use a third party ftp program to move the paths across. Meaning you can free up one of your "programming" laptops.

NB: The paths will have to be copied across to the "programming laptop" eventually as any paths that have manually been copied across will be overwritten the next time the code is pushed from the programming laptop.

Good Luck.

Word of warning, if you are using the speed and acceleration values from the GUI, MAKE SURE you set them to values you want every time you make a new path.

[cozymentor]

We are using a differential drive with Spark Maxes. Looking into the code a bit more, we defined max accel and max vel, but those values weren't being used anywhere in our PPRamseteCommand constructor that I can tell. The only ways I am aware of to set these values would be DifferentialDrive.setMaxOutput(), which takes a value from 0 to 1.0 and isn't in m/s and then DifferentialDriveAccelerationLimiter. Am I thinking about this properly?

[cozymentor]

Update: I discovered where in the trajectory the max vel and max acc are set, my apologies. Still trying to wrap my head around this stuff. I will take some video this evening and show the result to help paint a better picture of what I am talking about. If updating these values produces a different result I will mark this thread as answered.

[cozymentor]

Updating the values in the trajectory did the trick. I had hard coded them initially instead of using the values from my constants file, hence nothing changed when I updated the constants.

[WarrenReynolds]

Lets go back a few steps.
The way trajectory following works is by trying to be at an exact point on the path at an exact point in time. The job of the x,y,theta PID controllers is to help the robot get as close as possible to these points by looking at the difference between the co-ordinates of the points and the co-ordinates reported by the robot odometry (=the error). The feedforward part is an approximate power level that should get you to the next point on the trajectory in 20ms. The feedforward (if setup correctly) will do most of the work to get the robot to correct spot on time. The extra bit added (or subtracted if in front of the point) by the PID controllers helps get the robot to hit these points as you travel along the trajectory.

The points are generated by the trajectory generator when you load a path, they contain an x, y , theta, time stamp, velocity, amongst some other things. Check out the trajectory point struct to see the finer details.

These points are created using the max velocity and max acceleration values that are passed to the trajectory generator.
Basically it works out where you would be if you started a 0 velocity and accelerated at max acceleration until you reached max velocity. It creates the coordinates of the points with a time stamps. If there is stop point coming up it works out where it has to start slowly down so that it will be at a complete stop by the time it reaches the stop point. There is bit of other fancy stuff in there that extrapolates between trajectory states when the time stamp on the points are different from the current time elapsed since the trajectory started, but basically that is how it works.

So this is the weird part about your trajectories taking longer to execute than what the GUI is saying they should take. The time taken to follow the trajectory is locked in once the trajectory point are generated.
You could query the length of the generated trajectory by calling the .getTotalTime() method on the generated trajectory. This would be a good sanity check to see if this value is reported to be different to the value in the GUI. If these are different, then the problem is in the GUI path time calculator and you have nothing to worry about. The time reported by .getTotalTime will be the exact time it takes. Actually the robot is told to stop moving once the timer hit the .getTotalTime value.

[cozymentor]

That makes sense and helps me to paint a better picture in my head of what the robot is doing when following a path. It will definitely help us troubleshoot should an issue arise. This is our team's first year running Pathplanner and I am truly impressed with the result.
I really appreciate the help. When you are stuck in the weeds it is great to have people to talk to who know the ins and outs of this stuff.
God bless,
Cozy

[WarrenReynolds]

All Good.
Our team was where you are now but 12 months ago with swerve drive. By our last tournament we hit the 5 ball auto with a 95% success rate and it was all due to this amazing piece of software. The only reason we missed the 5% was either the limelight picked up a skylight in the early matches on one alliance side or the human player was to sleepy.

If you really want to understand what is going on, I suggest creating a new project and copying the all the path planner lib code locally into your project. Then you can go through it to your hearts contents adding fmt::prints and smartdashboard::putnumbers all through the code so you can see what is happening under the bonnet.

Another good spot to start is with the WPILib example code on path following.