- overcurrent error during motor calibration (this is caused by
overshoot. For now we just ignore the current limit during motor
calibration as we did before)
- factor 2 error at encoder calibration
- set error flag if Motor::arm() is called while the brake resistor is
enabled but disarmed.
- only arm brake resistor if enabled
- auto-arm brake resistor on clear_errors()
Updated API Migration Notes
Changed Axis error that is thrown for over temp from ERROR_OVER_TEMP to ERROR_MOTOR_FAILED
Moved setting of thermistor_.motor_ = this from motor apply_config() to motor constructor
Moved motor_thermistor apply_config call from Motor to config_apply_all() in main.cpp
Thermistor apply_config now called in Motor::apply_config()
Thermistor errors rolled into motor errors
odrivetool and GUI updated to handle change
Removed CurrentLimiter,Thermistor arrays abstraction
The InputPort/OutputPort infrastructure facilitates safer
data paths between components: OutputPorts store a value
and the age of the value measured in number of control loop
iterations. InputPorts can be connected to various sources,
for instance an OutputPort. InputPorts expose the values to
consumers in the form of std::optional to reflect the fact
that an InputPort can be dangling or connected to a stale
OutputPort.
Where viable, customizations in the CubeMX code (mostly the USER
CODE sections) are moved to our own files (primarily main.cpp and
board.cpp).
This will minimize code duplication when adding a new, completely
separate instance of the CubeMX files. The USB code still contains a
large amount of customization which is not touched by this commit and
should be refactored separately later on.
The entry point is now in main.cpp (moved from the CubeMX-generated
main.c). This increases control over the boot process while also
improving code organization.
This new method is more flexible in the sense of what timers to
synchronize and also provides clearer guarantees with respect to
the repetition counter and prescaler.
Instead of using a declarative compile-time type that defines the layout
of the NVM data, now we use procedural style code to load and store the
configuration as a series of pop and push calls. This allows for more
flexible code organization and opens the future possibility of storing
dynamically sized data (e.g. an array prepended by a length field).
Samuel Sadok
Matt Quick
Oskar Weigl
Paul Guenette
PAJohnson
Shaun Meehan