Same reason as before commit
Note: some changes to http were necessary due to global object
- untested!
Also remove unneded duplicate components folder
since board_single uses mostly the same code as board_control and
board_motorctl several files are outsorced to common folder to prevent
dupliate code and different versions
New controller will be run with single controller at first...
get single board version from V2.0 and create new folder
(two boards version is kept)
-> copied firmware from e6e586e5855d81ee726bb9a0fbe8ab12def5eeef
brake-mode support
in BRAKE state relays are powered that connects a brake resistor
(not tested with actual motors)
Also brake mode is currently not used at all
[untested]
Turn on brake relays in BRAKE state
Also wait certain time for relays to switch before shorting the driver
Add config option for brake relay pin
Initialize pin in constructor
Add 2x brake relay
Add 2x optical sensor for speed measurement
-> not enough ports available!
-> Split pin assignment in two pcbs connected via UART
Note: just built and soldered both bords as currently described in connection plan
(old board replaced)
Same functionality as previous commit. But way more stable and clean.
Previous proof of concept approach had issues with random partial or
too large messages due to time based method
Rework send and receive functions to work more stable
- send: encode data with frame (start, end byte)
- receive: read each byte one after the other, assemble message,
handle actual data in handle function
- add semaphore to write operation to prevent parallel write of
different data when called from other tasks
- board_control successfully sends motor commands to board_motorctl
- board_motorctl receives and applies motor commands
note: control pcb currently switches to HTTP mode after startup for testing
with data from ui
- partially commented in code that has to be reworked
- control: send commands via uart instead of to motor objects
- board motorctl handled motor: add timeout when no target data
received (e.g. control pcb offline / uart bugged)
- board motorctl uart: receive motorCommands_t struct and apply data to
target state of handled motors
- types: fix issue with global motorstateStr variable
- outsoruce common files and separate common types from source files (new
common/types.hpp)
- split source files to 2 board folders (relevant only, no duplicate)
- currently boards compile successfull but not functional at all
- comment out currently incompatible code
board_control currently sends a scruct with incrementing values
board_motorctl receives the struct and logs it
also test code for sending, receiving and returning single value
- add second pcb board_control, currently copy of previous board
- not enough pins -> board_control handle ui send motorcommands via uart
board_motorctl handle motors
add config option for minimum time motor has to be in IDLE before
changing direction. Try to prevent drivers from obvious extreme
overload. At least prevent full speed switch
Untested but simulated via log output
went trough all current files:
- remove old comments
- change structure / newlines
- main.cpp: outsource loglevel function
- http.cpp: FIX compiler warnings
currentsensor.hpp
- add currentsensor class
- add current limit to motorctl handle function
- add config options for curring limit for each motor
- update connection plan with more detailed driver-box overview
- with new hardware noticed that sometimes switch gets triggered x1
randomly when driving forward (EMI ?)
- increased delay options (less responsive but more controlled)
- joystick command generation:
- also remove min duty offset with changing ratio
- prepare threshold where ratio snaps to max for easier turning
-> issue with driver has to be fixed first
- minor motordriver optimization / add commented out debug mode
(driver forward in idle)
- uncomment coordinate scaling which caused unwanted behaivor
especially that radius never got to 1 when joystick diagonal
resulting in loss of power/speed in curves
- now scaling radius only which is the desired functionality
- optimize debug logging
- fix joystick calibration config (invertion was mistaken)
- remove second fan instance since both fans are controlled via one pin
now
- more config options so fans turn on less at short movements
=> less noise and less relay cycles
Update connection plan with new wiring and pin assignment
- add display
- add temp sensors
- single fan
- add rotary encoder
Add wiring plan with details about hardware
Changed config and code for motor driver:
Now its possible to configure whether a and b pins are inverted separately
e.g. a connected to mosfets (inverted) and b connected directly
- add more debug output in joystick getData function
- update joystick config with new min/max values while testing
=> fixed bugged movement (joystick unusable) after winter
- bump esp-idf version since successfully compiled with 4.4.4
- slightly decrease msFadeDecel by 100ms
- different approach in button.cpp for case last button press was long
e.g. reworked commands:
- 1x long press = restart
- 1x short press = center stick, freeze
- 1x short 1x long = run new auto commands
- 2x short = toggle idle
- change default minOnMs / minOffMs for evaulated switch class -> fix
button presses sometimes not recognized
the joystick object is now available in the button class/task
thus can be used to trigger commands with certain combinations of
joystick and button
- not used yet -
auto.cpp:
- forward instructions from commands to newly passed pointer
control.cpp:
- handle instructions returned at generation of commands in auto mode
- add method toggleMode
- remove dupliate code in toggleIdle method
button.cpp:
- optimize command for enabling leg support, add instruction
auto.cpp:
apply fadeAccel and fadeDecel from commands to motors
main.cpp:
double stack size of button task (crashed controller every time)
button.cpp:
Modify test command to actually eject armchair leg support
control.cpp:
apply generated motor commands to motors
rename some variables:
typo: fadeAccel
more specific: auto_instruction_t
- automaticArmchair:
- add method addCommands for adding an array of
commands to queue
- add keys to simpleCommand struct
- fadeDecel (not used yet)
- fadeAcel (not used yet)
- instructions (new enum for running other commands in control task
, not used yet)
- button.cpp
- add example command to 1x button press (comment out previous cmd
temporarily)
- control.cpp
- update changeMode function: dont do anything when current mode is
already target mode
- Create class automatedArmchair in new files auto.hpp and auto.cpp
This class currently makes it possible to queue up and run commands
(motorstate, duty for certaion duration),
- add new file to cmakelists
- create automatedArmchair instance 'armchair' in config.cpp
- add loglevel configuration to main.cpp
- add AUTO mode to control.cpp (no way to change to mode yet)
When switching mode from MASSAGE to other mode while joystick input
frozen (button). It was still frozen when switching back to MASSAGE mode
later. This is confusing and is seen as a bug
-> reset locked input variable to false on mode change
New command and feature also made some general changes to control and button necessary
joystick.cpp:
- add optional parameter to joystick_CommandsDriving function
bool altStickMapping (default false)
if true this currently swaps BOTTOM_LEFT with BOTTOM_RIGHT for experimental
different joystick mapping
button.cpp:
- fix/move variable declaration outside of switch
- add 12x case: send count to control task
control.cpp:
- create new section in handle loop for button events
- move x1 commands from JOYSTICK and MASSAGE case to new button
section
- remove unnecessary variable buttonEvent (only using buttonCount now)
- add functionality to 12x button event -> toggle alternative stick
mapping
readme.md:
- add new x12 button command
