Whitepaper: Trapezoidal-Exponential Motion Profiling

[ControlFreak]

you mentioned that you are ignoring deceleration in your time-to-target calculation,
is that because the deceleration strategy is the same for the different profiles?
if so what strategy is used?

[Oblarg]

This is a pretty compelling argument for implementing the exponential-trapezoidal profile in WPILib.

[rafi]

I did that initially just to simplify the calculations. Both approaches use the same decel method (though exponential could be even more aggressive on stopping if we want, I guess), so the results are pretty similar. They aren’t exactly the same because they start at different pre-stopping speeds.

After that, I created a similar comparison that does include the stopping portion, shown here:

@rafi

As you can see, while the trapezoidal-exponential sometimes simplifies into a trapezoidal profile, it always either matches or outperforms the trapezoidal profile, and sometimes outperforms by a substantial margin.

Here is the desmos link if you’d like to play around:

Trapezoidal-Exponential vs Trapezoidal | Desmos

[Eugene_Fang]

I’m curious how much benefit you’ll see in practice. Motors are rarely reaching their true free speeds due to loading conditions and other losses. The lower v_cap is, the less pronounced of a difference there will be between the two profiles.

[Oblarg]

Those factors apply to attempts to follow an aggressive trapezoidal profile, too. I think the fractional time-to-target results are pretty telling.

[calcmogul]

Software maintenance concerns

My main concern with implementing this formulation for a current-limited exponential profile in wpimath is its long-term maintainability. The whitepaper is unhelpful when translating the equations into an implementation, and the sample implementation in the desmos is spaghetti. As the primary maintainer for wpimath, I have to maintain everything and fix bugs when the original contributor leaves, and I don’t feel comfortable with this formulation because it’s likely to turn into a buggy piece of abandonware.

The recently added exponential profile class had the same maintenance concerns, which made it difficult to review and delayed its merge for weeks. At least there, we had sympy do a lot of the algebraic heavy-lifting. Our trapezoid profile implementation is the simplest profile you can have, and it still has lingering reported bugs (side note: it could use a rewrite in a more powerful abstraction like phase-space to deal with the corner cases).

The problem with plug-and-chug

I dislike “plug-and-chug” physics derivations that result in alphabet soup because it’s error-prone to verify the correctness of and to implement. In software, this is like writing all your code inline in one function instead of refactoring it into testable classes and functions. Math has abstractions like software does, and I’d feel better if more were applied here.

Alternative formulations

One method we used to make state-space manageable was to find numerical solutions to difficult subproblems, like the matrix exponential and the DARE. The roboRIO is capable of more computing than people think, as long as the math is done in native code. The motion profile derivation pieces that specifically result in alphabet soup are good candidates for numerical methods.

The other extreme is formulating the whole motion profile as a quadratic program and solving it numerically (quadratic cost and linear constraints). An example would be “minimize the sum-of-squared error between here and there subject to a first-order DC motor model and current or acceleration limits”.