If certain inputs were passed to trajectory planner, an expression inside the trajectory planner which is an argument to sqrtf() could become negative due to finite floating point accuracy.
This led to Vr_ == NaN and then Tf_ == 0, causing the trajectory to jump to the final setpoint instantaneously. To the user, this manifested as a sudden increase in velocity (limited by controller.config.vel_limit) and/or an overcurrent fault.
This bug was likely to show up when constantly sending trajectory setpoints while moving in the negative direction.
See also: https://discourse.odriverobotics.com/t/move-to-pos-not-works-well/4626
- cleaner implementaiton of the overvoltage ramp with config variables separate from other functions
- explicit enable flag for overvoltage ramp (disabled by default)
- reinstate brake duty cycle NaN error
- add informational flag for brake resistor saturation
- Remove logic that would inhibit error detection until the first value is received. This logic posed a risk when no encoder is connected at all.
- check error flag in AMS mode
- Make CUI mode work. Only tested with emulated CUI encoder.
- only go to ready-state if a successful value was received _and_ the offset was already pre-calibrated
- enable pull-up on MISO so that a disconnected AMS encoder can be detected
- update encoder documentation
Before this commit, bad user input could cause the device to hang,
that is, no longer respond on USB (other side effects are likely,
though not tested for).
An example of such an input is:
odrv0.axis0.encoder.config.cpr = 10
odrv0.axis0.encoder.config.offset = 20000
Samuel Sadok
Unknown
Oskar Weigl
Adam Munich
Ben Wang