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:
v0.5.0
Added
- 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
, andinput_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 madexxx_setpoint
variables read-only
- New input variables:
- 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
andvel_gain
- Regen current limiting according to
max_regen_current
, in Amps - DC Bus hard current limiting according to
dc_max_negative_current
anddc_max_positive_current
- Brake resistor logic now attempts to clamp voltage according to
odrv.config.dc_bus_overvoltage_ramp_start
andodrv.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
- Changed ratiometric
motor.config.current_lim_tolerance
to absolutemotor.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 timeodrivetool
was started. - Reboot on
erase_configuration()
. This avoids unexpected behavior of a subsequentsave_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 atmotor.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.https://github.com/Wetmelon/ODrive/blob/devel/docs/can-protocol.md
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 madexxx_setpoint
variables read-only
so input_pos will replaceodrv0.axis0.controller.pos_setpoint
Cheers
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
Congrats, this release was overdue! So many features.