How to tune Feedforward constants? | Trajectory Tuning

Hi,

We have been trying to get path-following working on our robot. Even though we ran many tests, we still seem to have off-paths. (example videos below)

We are aware that FF values are model-based values, however, using the calculated values (from the characterization tool) did not give us great results. Therefore, we started to tune them (possibly with a very wrong approach).

This tuning approach got us incredible results for the path we were trying to run. However, when we tried another path with it, it was worse than ever. We would be very grateful if someone could give us more resources on how to tune FeedForward values or fix it in any way.

Here is our drivetrain configuration:

  • 4 x CIM + Toughbox Micro 12.75:1
  • 4 X Talon SRX + SRX Mag Encoder
  • 4 x 6" Mecanum Wheels
  • NavX

You can view our code here.
The path we tried is this:

Here are the steps we followed:

  1. We tried the calculated trackwidth with PID enabled. (We also passed the calculated trackwidth to the Pathweaver project.) The calculated trackwidth was better compared to the real trackwidth. Video here.

  2. We passed 0 to the PID values and ran the path again. (This and all consecutive steps use the calculated trackwidth with PID disabled unless specified otherwise.) This was very similar but a bit better compared to the first step. Video here.

  3. Afterwards, we zeroed, multiplied by 0.5 and 1.5 the kS, kA, and kV values one at a time to see their effect.

  4. After we saw how each affected the trajectory, we started tuning the kS. It seemed to affect how long the trajectory was in real life. We found that calculated kS * 2.0 was sweet enough. Video here. (My right foot is the expected arrival point of the path.)

  5. After kS, we started to mess around with kV. Playing around with this messed up the length of the path we fixed by tuning kS but fixed the heading error greatly. Videos: kV * 0.75, kV * 0.65.

  6. Now that our heading was correct, but our endpoint was behind. So we went back and increased kS. kS * 3.2 fixed the path length. Videos: kS * 2.5, kS * 3.5, kS * 3.2

  7. We were happy with our FF values, so we enabled the PID with the calculated P value. Video here.

  8. As the WPILib documentation suggested, we shrunk the P value by a factor of 10. This made a perfect path with no noticeable heading error and a length error of 3-5 centimeters. Video here.

We were very happy that we got this path working. However, when we switched to a more extreme path, it was nowhere near the path it was supposed to follow. The path we tried as the ultimate test:


And the video of our fail is here.

Our Questions

  • Even though the characterization tool gives us model-based values, can we tune the FF values in any way? If so, are there any methods we can follow? If it is wrong to tune the model-based FeedForward values, how should we improve our auto routines?

  • We realize that having mecanum wheels and running the auto routine on a normal floor might cause some slips/errors. We will be switching to a more robust drivetrian next year. However, we want to learn what we are doing wrong using this mecanum chassis.

  • Also, we have read that it is a known issue that mag encoders cause noise on characterization here. We think this is the biggest issue in our case because we had a lot of noise. You can view our characterization data here. We want to learn if there are any other ways to solve this without switching encoders?

3 Likes

Even though the characterization tool gives us model-based values, can we tune the FF values in any way?

Ideally, you shouldn’t need to tune the feedforward values, but if they are not working, this paper gives some procedures on getting feedforward values.
Although by skimming through your procedure, it doesn’t seem like you understand what each feed-forward constant means. As shown here, the feedforward constants essentially relate voltage to a motor’s motion. As kS is the minimum voltage to make the robot motors spin, kV is the volts per units/s to get the desired velocity, and kA is the volts per units/s^2 to get the desired acceleration. This then allows you to get an accurate estimate of the voltage needed for a particular motion.

We think this is the biggest issue in our case because we had a lot of noise. You can view our characterization data here. We want to learn if there are any other ways to solve this without switching encoders?

You could try increasing the number of samples that the encoder averages together for velocity (CTRE_Phoenix: com.ctre.phoenix.motorcontrol.can.BaseMotorController Class Reference). If you are using the wpilib encoder class (encoders plugged into the rio) you can mess with the encoding settings to help reduce noise.

Also for next year, there will be a new tool called sysid which will have more robust ways of filtering noise and fitting data to get ideal feedforward constants. Perhaps @calcmogul could the data through his new OLS setup and get you better constants.

1 Like




3 Likes

Thanks for the resource and insight! We have initially read the docs you linked but we were too overwhelmed with failures to develop such stupid solutions.

We will try out the new values @calcmogul provided. If that does not work, we will increase the number of samples as you suggested and try again.

Huge thanks to both of you, @Piphi5 @calcmogul! Special thanks to @calcmogul for taking the time to go through our data! It is greatly appreciated.

Any idea what’s going on in that quasistatic plot?

2 Likes

Not really. We’ve also seen applying median filtering and trimming to the data doesn’t help on its own. Combining it with the new OLS algo looks great though.

1 Like