For fading-down and delay-between-state-change to work correctly when switching between motorstates
(e.g. FWD -> REV) the handle function was changed.
using a duty value -100 for reverse 100% and +100 for forward 100%
allows are more mathematical approach
changes to motorctl.cpp:
- convert state and duty to duty -100 to 100 when receiving target
command at start
- convert duty -100-100 back to state and duty at the end for applying
motor commands
With this changes the motors are faded down (same as already existing fading up)
when the target duty suddenly decreases.
It can be configured or disabled with setting msFadeDown to 0 in config struct of
motorctl object.
- Add new config parameter msFadeDown
- Change msFade to msFadeDown
- Add fade down functionality to motorctl instead of just setting the
duty to lower value
!!!TODO: fix major BUG when motor direction changes suddenly (before fade got to
0) the motor immediately starts in other direction with previous duty
(no/less fading up happening)
- Add class for controlling fans for cooling the motor drivers
- Add configuration for left and right fan to config.cpp
- Create fan task in main.cpp
- Add getStatus function to controlledMotor class
- Create class 'controlledMotor':
- handles 'fading / ramp' of the pwm duty
- handles current limit **not implemented yet**
- has .handle function that is intended to be run very fast in another task
commands are sent via queue
- Create config.hpp
- Globally available instance motorLeft of controlledMotor class
- Create config.cpp
- Configuration of motordriver and control parameters for motorLeft
- Add config.cpp and motorctl.cpp to cmakelists
- main.cpp:
- create 'task_motorctl' which repeatedly runs motorLeft.handle()
- modify testing code for testing the new class
- comments
The fading/ramp capability of the new class was tested successfully
using a breakoutboard with an led.
