[wpimath] Remove units from trapezoid profile classes

[SamCarlberg]

They were assuming inputs were always going to be in SI units, which is not the case

[calcmogul]

Does TrapezoidProfile give incorrect answers if you pass in a non-SI unit? The profile should still work as long as the units are consistent.

[SamCarlberg]

Does TrapezoidProfile give incorrect answers if you pass in a non-SI unit? The profile should still work as long as the units are consistent.

It works if measurement inputs are provided in terms of the SI base units. But people setting everything in terms of the same non-SI unit (such as degrees or inches or native sensor ticks) would have the math break

[calcmogul]

But people setting everything in terms of the same non-SI unit (such as degrees or inches or native sensor ticks) would have the math break

That should work, actually. The equations in TrapezoidProfile don't care what the length unit is.

[WispySparks]

Can confirm we ran into this issue ourselves, we were using the profiled pid classes with trapezoid profiles and thought using units would be good but quickly found out everything was wonky when we didn't use what the class internally expected

[SamCarlberg]

That should work, actually. The equations in TrapezoidProfile don't care what the length unit is.

Right. They just care that units are consistent. If you create constraints with the unit-taking constructor new Constraints(DegreesPerSecond.of(...), ...) and then run the profile with states with raw numbers in non-SI units (eg gyro.getRotation2d().getDegrees(), then units aren't consistent and things break even though the naming of the things used in the code is implies otherwise; the unit-taking constructor makes the constraints in terms of SI units, but the measurement inputs are in terms of non-SI units.

[Daniel1464]

Units-safe trapezoid profiles should arguably be a separate class.