Firmware version v0.5.0 is coming soon! Help us test it!

Firmware version 0.5.0 has hit the point of “release candidate” and is ready for wider testing. To help, check out the rc-v0.5.0 branch on github!


What are the major updates to this version?

Oh, good point! I forgot to put the changelog:



  • AC Induction Motor support.
    • Tracking of rotor flux through rotor time constant
    • Automatic d axis current for Maximum Torque Per Amp (MTPA)
  • ASCII “w” commands now execute write hooks.
  • Simplified control interface (“Input Filter” branch)
    • New input variables: input_pos, input_vel, and input_current
    • New setting input_mode to switch between different input behaviours
      • Passthrough
      • Velocity Ramp
      • 2nd Order Position Filter
      • Trapezoidal Trajectory Planner
    • Removed set_xxx_setpoint() functions and made xxx_setpoint variables read-only
  • Preliminary support for Absolute Encoders
  • Preliminary support for endstops and homing
  • CAN Communication with CANSimple stack
  • Gain scheduling for anti-hunt when close to 0 position error
  • Velocity Limiting in Current Control mode according to vel_limit and vel_gain
  • Regen current limiting according to max_regen_current, in Amps
  • DC Bus hard current limiting according to dc_max_negative_current and dc_max_positive_current
  • Brake resistor logic now attempts to clamp voltage according to odrv.config.dc_bus_overvoltage_ramp_start and odrv.config.dc_bus_overvoltage_ramp_end
  • Unit Testing with Doctest has been started for select algorithms, see Firmware/Tests/test_runner.cpp
  • Added support for Flylint VSCode Extension for static code analysis
  • Using an STM32F405 .svd file allows CortexDebug to view registers during debugging
  • Added scripts for building via docker.
  • Added ability to change uart baudrate via fibre


  • Changed ratiometric motor.config.current_lim_tolerance to absolute motor.config.current_lim_margin
  • Moved controller.vel_ramp_enable to INPUT_MODE_VEL_RAMP.
  • Anticogging map is temporarily forced to 0.1 deg precision, but saves with the config
  • Some Encoder settings have been made read-only
  • Cleaned up VSCode C/C++ Configuration settings on Windows with recursive includePath
  • Now compiling with C++17
  • Fixed a firmware hang that could occur from unlikely but possible user input
  • Added 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).
  • Fix IPython RuntimeWarning that would occur every time odrivetool was started.
  • Reboot on erase_configuration(). This avoids unexpected behavior of a subsequent save_configuration() call, since the configuration is only erased from NVM, not from RAM.
  • Change motor.get_inverter_temp() to use a property which was already being sampled at motor.inverter_temp
  • Fixed a numerical issue in the trajectory planner that could cause sudden jumps of the position setpoint

Thank you for your answer. Finally the can bus function is on. So far I have used the can bus function of your branch.

But the can communication protocol on the top is not properly linked. I guess it will be the same as what is in your branch.

Thanks for everyones work on this project!
This is continuing to be improved and polished.

Sweet! Couple questions:

  • ASCII “w” commands now execute write hooks.
    what does that mean/do?

  • Removed set_xxx_setpoint() functions and made xxx_setpoint variables read-only
    so input_pos will replace odrv0.axis0.controller.pos_setpoint


Write “hooks” are functions that get called when a variable gets written. There’s a few variables that have these functions, usually because other variables need to change proportionally to the one that’s changing.

As an input, yes. pos_setpoint can still be read, and represents the actual target of the PID

That’s good info thanks. I guess the doc will be updated when the RC becomes the latest official release :smiley:

Congrats, this release was overdue! So many features.

1 Like