Velocity calculation update

[Copper280z]

Use time between encoder ticks to better estimate low speeds. Calculate an upper bound on velocity based on encoder resolution and time since last tick and use that to update the current velocity estimate when no ticks are observed.

This change improves stability of conditional effects, specifically the damper an inertia, when set at high values.

Once this is merged, I would recommend removing the encoder speed filter entirely, it's no longer necessary, and increasing the cutoff frequency for the accel filter. Additionally, implementing either persistent storage for the encoder resolution, or implementing the getCpr function such that it returns the real encoder resolution instead of 65535 will improve the velocity estimate.

Right now, without a working getCpr or persistent storage for the encoder resolution, I have the value hard coded. Basically any value here is still an improvement over the prior method, even '1', but the correct value will further increase the accuracy of the estimate.

This same method could also be applied to the acceleration calc, which should improve inertia stability and smoothness even more.

[Ultrawipf]

Sounds like a good idea.
The getCpr returns the resolution depending on the encoder. Only on the tmc4671 it is currently not the case because it uses the already scaled counter at the moment.
This could be changed but then requires special handling for every combination again.

Please check out the ultrawipf/testing branch which contains upcoming changes not yet merged to development like dynamic sample rates which would affect this calculation.

[Copper280z]

The odrive and vesc motor drivers also do not return the actual cpr.

[Ultrawipf]

The odrive and vesc motor drivers also do not return the actual cpr.

Thats because the ODrive does not report the position in CPR but in float rotations so the cpr is mostly for compatibility.
There is no way to know the actual encoder resolution.
The axis requests the position as float anyways.
Same situation with VESC.

[Copper280z]

The position value is represented as a float, but the value is still quantized by the encoder resolution. This quantization is the reason why this bounding velocity estimate works at all.

I’m not sure I like the idea of adding persistent storage in the odrive/vesc class for the actual encoder resolution, it’s another setting to get wrong, but it would solve this issue.

I could estimate the encoder resolution at runtime by looking for the minimum change (above epsilon ) in position cycle to cycle. This could go in either the axis class or the odrive/vesc motor classes. It’s not very heavy and should converge pretty quickly, but it feels like maybe too much of a hack.