TrapezoidProfile Wildly Inconsistent

My students are working on implementing Trapezoid Profiles for a smoother acceleration in their drive-distance auto commands, but we’re seeing some really random results. We ran the FRC-Characterization toolsuite for the drivetrain (with all units consistent and set to inches), getting values of kS = 0.333, kV = 6.18, and kA = 0.885. Our drivetrain is tank-drive, with two NEO motors per side.

We’re using the TrapezoidProfileCommand, following the example given in, but the distances traveled make no sense. We’re pulling them from Shuffleboard, and I can confirm that we’re definitely passing in the correct values. When we enter a setpoint of 1 (of what I assumed were inches), the bot actually travels about 14-16 inches, and when we enter a setpoint of 2, it’s closer to 30 inches. At 3, the distance is about 50-ish. So points for consistency?

A question: I see a lot of the motion profiling examples based on meters. Is that a hard requirement here? I don’t see any indication in the libraries that units matter, as long as they’re consistent. Are we missing something?


I would definitely graph out your actual speed compared to your target trapezoidal speed. This will give you better sense of what your robot is actually doing. You may find that it doesn’t travel exactly how you expect.

We have consistently used the libraries with feet instead of meters, and not had any issues so far.

If you are using the PID controllers on the spark maxes themselves, I believe you need to use setVelocityConversionFactor() to convert from native units (RPM) into the unit you set on the robot characterization page in order for the PID and constant values to be valid. See the note here.

We’ll have to give it a more thorough try, thanks! I’m glad to hear firsthand that people have used it successfully in other units.

Thanks for checking! It’s a pretty common oversight, and it definitely took my students a few failures to realize its importance. We’re definitely applying our conversion factors appropriately.

There was a bug in the TrapezoidProfile class when the profile wasn’t recomputed every iteration. It has been fixed, and is in the most recent WPILib release on github.

Thanks for letting me know. Unfortunately, the problem has persisted. We’ll probably have to try a different approach. We just can’t seem to figure out why the trapezoid profile isn’t working.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.