Resolution-based velocity limits are problematic in simple test setups

[jdcaporale]

The default resolution in QueryCommand for velocity is int16 with a scale of 0.00025, this limits the read capability to (+-)8.192 rotations/s or 51.47 rad/s.

This is fine for most cases, but with the dev kit and other simple direct drive motors in pd loops this is not enough velocity range and we see heavy vibration cause by integer overflow.

We should default to higher resolutions for these often first time use cases to work without adjustment, but allow an option to control loop that sets the read and write resolutions for situations with more motors.
Currently we reset the write resolutions in InitializeCommand with just a feedforward torque int16.
We should also set the read resolutions here and we should use options to lower it instead of having such low defaults.

[jdcaporale]

@ShaneRozenLevy Thoughts on this?

[jdcaporale]

We can see the velocity overflow in this plot.

[ShaneRozenLevy]

Interesting, I've never seen the velocity overflow during real experiments, some rough calculation says that 50 rad/s should be more than enough for a hopping robot. Assuming a 10cm, leg, thats 5m/s ~ 1 meter of hopping height. I know for basic desktop experiments you can clip the velocity, but has it effected any hopping robots?

[ShaneRozenLevy]

If you want to support allowing the user to set it, then I would propose defaulting it to the current 16bit, but allow people to set a higher or lower resolution. I think it would be weird to set the default to support a non expected use case.

[jdcaporale]

It's possible a vibe issue that @weinitor had likely was a result of this overflow in his scaling hopping experiments.
I also think that you only need the lower resolution with more motors like in Twist and that generally in the <8 motor robots higher resolution is only a good thing.

[ShaneRozenLevy]

Interesting. I'm happy to expose these parameters to the user.