Add Velocity Measurement for DutyCycle and Analog Encoders

[HoJo42]

While attempting to characterize my team's swerve drive using SysId I got stuck because my team uses analog encoders for the rotation position of the modules. SysId Issue #433 says that the reason SysId doesn't support the DutyCycle encoder is because there isn't a velocity measurement built into WPIlib's DutyCycle Encoder. I assume the lack of Analog Encoder Support is for the same reason.

I would like methods in DutyCycleEncoder and AnalogEncoder classes that return a velocity measurement like Encoder.getRate()

Alternatives could be that SysID and teams implement the velocity measurement themselves.

Link to the SysId issue: wpilibsuite/sysid#433

[calcmogul]

There's not really a good way to implement velocity measurements for those. We can modify the OLS fit to accept position though, like this: https://github.com/calcmogul/SysIdOpt/blob/main/src/Main.cpp#L129

[HoJo42]

Why isn't there a good way to implement velocity measurements?

[PeterJohnson]

The FPGA does not provide an easy way to measure velocity in a delta time stable way. You need two timestamped measurements to calculate it.

[HoJo42]

Looking in AnalogEncoder.java the Counter object has methods for getting the period and the rate of the Counter. Would these not work?

[ThadHouse]

The counter is used for rollover counting, and not actually the position. So that rate would only give you the rate rollovers are happening. And wouldn't even detect movement if a rollover didn't occur.

The way DutyCycle and Analog actually grab the current relative value is completely different from how normal Encoders work. So logic for normal Encoders just don't work.

[sciencewhiz]

Using the rollover detection would work for velocity if the encoder shaft is turning at 3000 rpm or higher. This allows 1 measurement per 50hz robot cycle.

However, if the Analog Encoder is spinning at 3000 rpm, you've lost any benefit of using an absolute encoder. You'd be much better off using an incremental encoder in that use case.

[ThadHouse]

It also wouldn't solve this case (the rotation encoder on a swerve module). Those don't move anywhere near fast enough, and likely don't roll over as well.

[ThadHouse]

This is actually going to be a won't fix. We're going to be completely removing rollover support from DutyCycleEncoder (It's fundementally broken), and changing AnalogEncoder to default to not having rollovers. Also we still couldn't implement proper velocity measurement anyway. We could do exactly what a team could do, where they measure every x milliseconds and compute the velocity that way.

Also without the separate sysid app, this is much easier to fix in user code.