Fix bug where armchair moved too long every once in a while (especially
at start).
Minor adjustments of parameters.
main.cpp:
- set individual task priorities for each task e.g. fan or buzzer task has very low priority (did not have any immediate effect though while testing)
- increase handle interval of motorctl
change from 20 to 10 (same frequency as generation of massage
commands)
-> this fixed the bug with unexpected movement (motorctl could not
process every command from massage mode)
control.cpp:
- decrease delay in massage mode for more detail/levels at joystick
radius (from 20 to 10ms)
- increase fading in massage mode (400ms to 500ms) for slightly less hard
shaking
joystick.cpp:
- reduce max shaking amount
- swap modes
- top left shake backward
- top right shake forward
- bottom left/right shake rotating
Modified function that generates commands in massage mode (joystick.cpp)
- define variable stickQuadrant with axis as hysteresis from actual joystick data/pos
- prepare switch case for implementation of 4 modes (each quadrant)
- add basic content to modes for testing (different motor directions)
TODO: remove old code with pulsing shake variable and implement actual modes
In massage mode it is required that the motors react quicker, Added the
following functionality to control.cpp:
- when changing to MASSAGE mode the downfading is disabled and upfading is
reduced
- when changing from MASSAGE mode downfading is enabled and upfading reset
to default value
- add 3 functions to controlledMotor class in motorctl.cpp/hpp
- setFade: set specific msFade duration for acceleration or
deceleration
- setFade: disable or set to default ramp for acceleration or
deceleration
- toggleFade: toggle between fading enabled or disables for
acceleration or deceleration
- button.cpp
- add controlledMotor objects to constructor
- add new command 8x press which now toggles fade-deceleration of both
motors
- config.cpp
- slightly decrease fading durations
- Fix bug where case duty=0 was not handled in fading if structure thus no
incrementing action happened anymore (stuck at duty = 0)
- Set fade duration (acceleration, deceleration) to realistic value in
config
- Change fading algorithm to handle Acceleration and Deceleration for
forward and reverse separately (4 different cases)
- rename variables to make fading direction more obvious
e.g. msFadeUp -> msFadeAccel or dutyIncrementDon -> dutyIncrementDecel
TODO: fading needs optimization
- Fix bug where downfade did not work when driving forward
- Add BRAKE command functionality to motorctl (untested, since not used anywhere atm)
- Cleanup: Optimize code, add comments
!!!TODO: there is a fault in the current concept/logic:
fading up/down generally works, however when accelerating
REVERSE fade-down is utilized instead of fade-up.
=> Fix that bug, fade down should only be used when decelerating.
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)
While testing this feature briefly that approach did not appear to be a good idea.
- noticed that the driving with joystick was a little unintuitive/unexpected (maybe just not used to it?)
- BUG that the state does not reset to center when previous state was
X-AXIS? Resulting in the armchair to slightly shake randomly at
joystick center
-> this has to be fixed if this approach is tested again.
This reverts commit b2b12fe5de1e16ea2f25dfa4b0c3ac6845024c71.
modified function
joystickPos_t joystick_evaluatePosition(float x, float y, joystickPos_t* prevPos)
because prevPos has to be stored http.cpp/hpp and joystick.cpp/hpp had
to be updated as well
TODO: add function without hysteresis again?
WIP this has to be tested
Use reference to joystick object in control class instead of accessing
the global evaluatedJoystick object
control.hpp:
- add joystick reference to constructor
- add local joystick pointer variable
control.cpp:
- constructor: copy pointer to joystick object
- use methods of joystick reference instead of global object
- update log output of timeout check
config.cpp:
- add joystick object to control object construction
- joystick.hpp/cpp
- add function joystick_scaleCoordinatesLinear(joystickData_t * data, float pointX, float pointY)
that scales the coordinates with 2 different slopes before and
after certain point
- control.cpp
- scale coordinates linear with new function instead of exponential in JOYSTICK mode
- scale coordinates linear with new function instead of exponential in HTTP mode
- config.cpp
- adjust / decrease http joystick tolerances
Note: tested the armchair in http and joystick mode briefly and
optimized the scaling point slightly
- joystick.hpp/cpp
- add function joystick_scaleCoordinatesExp(joystickData_t * data, float exponent)
which updates joystick data with its scaled coordinates and
re-calculated radius
- control.cpp
- scale coordinates exponential (pow 2) in JOYSTICK mode
- scale coordinates exponential (pow 2) in HTTP mode
- config.cpp
- fixed swapped x/y zero tolerances for hardware joystick
Note: tested armchair with scaling exponents 1.5; 2; 3 and noticed that
2 works best
- add function joystick_generateCommandsShaking that generates motor
commands from joystick data
- pulses motors:
- intervals depend on joystick radius
- direction depends on joystick position (currently only on-x-axis and on-y-axis
supported)
Update react web app:
- add dark background color
- change joystick colors
- increase joystick size by 50px
- change heading
- remove angle and radius
- not displaying anymore
- not sending to api anymore
Update http.cpp:
- remove radius and angle from json parsing
- limit radius to 1
As already did for http joystick:
- Add different config options tolerance zero for X and Y axis for
normal/actual joystick.
This makes it possible to set Y tolerance to a lower value resulting in
a more responsive turning action, with still having a large range around
X axis for turning mode
Fix several bugs noticed while testing the preceding commits in dev
branch:
- Fix bug in function scaleCoordinate
- scaling was wrong resulting in negative/inverted values at start of axis
- Adjust timeout value from 30s to 5min
- Fix http joystick behaivor
- calculate angle, radius and evaluate position AFTER the coordinates
have been scaled in control.cpp (bug introduced when switching applying tolerance
on controller instead of in the app)
- Add independent toleranceZero for X and Y axis -> unnecessary to have
large tolerance for x axis... makes turning more sensitive
- Fix stack overflow in control task
- controller crashed repeatedly when logging output was enabled in
control task
- -> doubled stack size at task creation in main.cpp
currently works, position hast to be evaluated AFTER coordinate scaling
- create new struct control_config_t with several variables previously
hardcoded in control.cpp
- modified constructor: add config parameter
- add definition of config struct in config.cpp
typedef struct control_config_t {
controlMode_t defaultMode; //default mode after startup and toggling IDLE
//--- timeout ---
uint32_t timeoutMs; //time of inactivity after which the mode gets switched to IDLE
float timeoutTolerancePer; //percentage the duty can vary between timeout checks considered still inactive
//--- http mode ---
float http_toleranceZeroPer;//percentage around joystick axis the coordinate snaps to 0
float http_toleranceEndPer; //percentage before joystick end the coordinate snaps to 1/-1
uint32_t http_timeoutMs; //time no new data was received before the motors get turned off
Add feature that switches to mode IDLE when duty of both motors did not
change over certain time.
control.cpp/hpp:
- add private function that handles timeout
- add public function that resets timeout
- add slow loop with timeout handle inside control handle loop
- joystick.cpp/hpp:
- move method scaleCoordinate from joystick class to public function
- modify scaleCoordinate function to accept float values instead of
ADC pin, change tolerance parameters to percent instead of absolute
number
- change method getData to use the public function now
- control.cpp:
- use scaleCoordinate function in http mode
- calculate radius in http mode
- config.cpp
- adjust tolerance thresholds for joystick to percent
- App.js
- disable "snap to zero" feature -> just scale joystick output to
value of -1 to 1
since the web-app runs successfully on the esp32 webserver now, the api
can be accessed directly - this makes the web app independent of the
dynamic controller ip
- remove ip from api url -> uses current host
- add testing code for changing a variable with a button
- comment out some debug output
With this commit the webserver of the controller can serve a folder (/react-app/build/), when the ip is accessed in a web-browser.
Currently the react app is successfully served and the armchair can be controlled when in HTTP mode and connected via AP.
- CMakeLists: Add command that creates and flashes the spiffs partition when running
idf.py flash
- main.cpp: Add function to initialize spiffs
- http.cpp: uncomment handler for default URL (accesses spiffs)
- Add partitions.csv: needed for the creation of spiffs.bin during
compilation
- Add sdkconfig: It was necessary to change the FLASH_SIZE from 2MB to
4MB. To avoid having the same trouble on other devices the sdkconfig
is now added to the repository
- Functional react project which currently provides a web-interface with a
joystick element.
- Coordinates, angle and radius are calculated and sent via http POST request
to an API provided by the esp32 controller (websocket approach was dropped)
- Currently the URL/IP is hardcoded in App.js and has to be changed depending
on the IP-address of the esp32
- control.cpp: Add feature to HTTP mode, that turns motors off when at least one motor is still on
but no data was received for more than 3 seconds (e.g. wifi connection
lost)
- change queue size from 20 to 1 - no need to store multiple joystick
data since only the latest one is relevant
- add "preset command" to control.hpp to set both motors to IDLE
- Create http.cpp and http.hpp
- functions for initializing a http server
- function for URL api/joystick
- receive joystick data from http post request
- parse json, define joystick position (function from joystick.hpp)
- send data to control task via queue
- control.hpp/cpp:
- add HTTP mode to handle loop
- receive joystick commands from queue, generate commands, send to
motorctl
- upgrade changeMode function with ability to run functions at switch
FROM and TO certain modes
- add code to start/stop wifi and webserver when switching to/from
HTTP mode
- change toggleModes and toggleIdle to use the changeMode function
- main.cpp:
- add several sections with code for testing new functions (commented
out)
- add http loglevel
- buzzer.cpp:
- add command (press 4 times) to toggle between HTTP and JOYSTICK mode
FIXME: moved initialization of wifi to main.cpp at startup because of an
error -> resolve this and place wifi start and stop functions into
mode-change as intended
currently works best in accesspoint mode with laptop connected using the
react-webapp
Move section that defines joystick position enum to a separate function
(outside of joystick class), this makes it usable for other inputs as
well
- create new function joystick_evaluatePosition
- call the new function in joystickgetData (where code was initially)
- change function joystick_generateCommandsDriving to accept joystick
data struct instead of joystick object as parameter -> makes the
function usable with other input than hardware joystick too
Create functions in wifi.c and wifi.h:
- an wifi accesspoint can be created
- connect to an existing wifi anf disconnect
Add code for testing to main.cpp:
repeatedly connects, disconnects and switches between AP and connecting
to BKA-network every run
New functions
//init components (run in main function once)
void wifi_initNvs_initNetif();
//function to start an access point
void wifi_init_ap(void);
//function to disable/deinit access point
void wifi_deinit_ap(void);
//function to connect to existing wifi network
void wifi_init_client(void);
//function to disable/deinit client
void wifi_deinit_client(void);
Big update of function flowchart
- add task overview
- add several new classes and functions
Except the fan and motordriver class all current functions are described
in a flowchart
- 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
- Move all separately declared functions in control.hpp to a new class
'controlledArmchair'
- now passing other objects only one time with constructor instead
of accessing them globally
- Create control instance in config.hpp, and passing objects in
config.cpp
- Add functions to new control class
- toggleIdle(): toggle between last mode and idle
- toggleModes(mode1, mode2): toggle between two modes
- Add commands to button.cpp
- 2x button press: call toggleIdle()
- 6x button press: toggleModes MASSAGE -> JOYSTICK
- Define control task in main.cpp
- Adjust button files and main.cpp to use the new command object instead
of the previus functions
Add control.hpp and control.cpp
- task that repeatedly generates motor commands depending on the current mode
- function to change to a specified control mode
Add button.hpp and button.cpp
- class which runs commands depending on the count a button was pressed
Update main.cpp
- create button task
- create control task
- comment out previous testing code
- remove unnecessary includes (already included in config.hpp)
Add control.cpp and button.cpp to CMakeLists
Notes: Tested this state on the armchair: All currently implemented features
work. You can switch between IDLE and JOYSTICK by pressing the button 2
or 3 times. Also driving works well (limited to 60% duty, with no fans
yet).
- Copy buzzer function from gate project
this makes it possible to easily trigger and queue up buzzing events
without having to worry about delaying the program
- Add instance buzzer to config
- Add code for testing the buzzer to main.cpp
Copy gpio component from gate project
Add instance of evaluatedswitch for button next to joystick to config
Add code for testing the button to main.cpp
- add new function to joystick.hpp/cpp
- reads data from joystick and generates commands for driving in
"joystick" mode
- returns struct with commands for both motors
- main.cpp
- add code for testing the new function
- enable 5v regulator (needed for pullups AB left motor)
- add newly created motorRight to handle function
- add new struct with two motorcommands to motorctl.hpp
- Create class 'evaluatedJoystick'
- evaluates a joystick with 2 analog signals
- scales the adc input to coordinates with detailed tolerances
- calculates angle and radius
- defines an enum with position information
- Add joystick configuration and class instance to config.cpp
- Add code for testing the new class to main.cpp
- Add joystick.cpp to cmakelists
now function `joystick.getData` can be used globally to obtain a struct with
current position data of the joystick
- 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.
- Add brief description
- Add installation and compilation instructions
- Add links to websites and connection-plan
- Add planned features
- Add Usage section with usage description of old firmware
