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
- Add JSON caching to Fibre. This drastically reduces the time odrivetool needs to connect to an ODrive (except for the first time or after firmware updates). The updated firmware is compatible with the old odrivetool and the updated odrivetool is compatible with the old firmware.
- Fix IPython `RuntimeWarning` that would occur every time `odrivetool` was started.
Samuel Sadok
Unknown
Oskar Weigl
Adam Munich
Ben Wang