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?

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

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:

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.

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

## 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â.