now

currently motor duty is checked for change to reset the timeout count

goal

reset timeout when there was any input

• certain joystick movement
• http input
• button press
  -> this fixes the problem that there is basically no timeout in shake mode or any future automatic mode

idea

reset timeout differently in different modes? e.g.

• massage longer timeout (no input)
• automatic mode any other event?
• joystick 300s

new features might break the old 2 board approach.
Listing issues here that need to be patched in case two board approach is re-used

Compatible until tag V2.1

• chair adjust
  95f2403 double assigned stepper outputs -> needs to be put to config option

hardware is prepared for ds18b20 temperature sensors

todo hardware:

• mount sensors to
  • motors
  • drivers

todo software

• configure sensor addresses
• read sensors
• use/display data

x / y coordinates do not snap to -1
even though the confiured max adc value is reached
apparently snap feature works the wrong way

might also fix weird turning behavior since radius gets calculated correctly?

currently startup takes very long due to ADC-lock aquire error spam.

its probably best to initialize the objects in a function called from main() instead of simply in config.cpp
since it currently happens at unknown time - probably too early at startup thus adc not available yet

Currently two separate functions are preset for each variable stored persistently in nvs. That results in a significant amount of duplicate code!

tasks

• add general function to read a value and/or copy a default value
• add general function to write a value
• apply functions where possible
• remove redundant code

Pass string to storage and pointers to default and target value?

this needs testing
noticed a few times that controller crashes and restarts
maybe when releasing the joystick very quickly

features

video feed

• add small webcam so one can navigate safely without direct view
• raspberry will be necessary to handle control

control

• joystick

  • sensivity
  • slider for max duty / speed

• chair adjustment

  • configure and start presets

config

change parameters of motorctl e.g. max duty, max current...

due to separate boards
changes in configuration of motorctl have to be sent via uart to the motorctl board

tasks to restore V2.0 functionality

the controlledmotor objects are no longer accessable directly thus certain features were disabled and need rework

• control.cpp 'changeMode'
  • switch from MASSAGE enables fading
  • (switch from AUTO enables fading)
  • switch to MASSAGE disables fading
• button.cpp
  • case 8: toggle fading

tasks

• motorctl board: repeatedly boradcast current active config
• motorctl board: receive and update config
  • add method to update or refresh config in object
• control board: store current config
• control board: method to modify and update config

issue

currently making a hard turn using joystick in any quadrant seems weird / is almost not possible
thus changing to full turn mode (wheels in opposite direction) is usually necessary.

• at low angle (Y almost at 0) radius is not 1? noticed outer wheel slowing down compared to at 45Deg max radius

ideas

• set inner wheel duty to 0 earlier, this could optimize turning radius
• increase outer wheel duty above configured duty limit (95)

tasks

• test whether radius is not read 1 at low angles
  • wass issue due to wrong scaling
  • fixed in d715f2e
• add threshold for joystick angle where the ratio snaps to 0
  • implemented in ffbf9cc
  • needs to be enabled later, see #19
  • now reworked and implemented in a6a630a
• boost duty of outer tire #19 - added in a6a630a
• more responsive
  • see #21

Issue

While testing V2.2.1 Idling in joystick mode seems unreliable...
Noticed Armchair randomly starting to move without touching the stick several times.
Even though i just calibrated it a few seconds ago.

Already observed that kind of random action for a few seconds while testing, when putting down the stick on the bench.

debugging

• find out how to reproduce
• issue with joystick input?
• issue with motorctl task?

when driving a slight turn at medium speed (r=0.5), then moving the stick back to Y to drive straight while keeping the radius approx 0.5 the duty jumps for about 10% which is noticeable with low accel limit

ideas

issue with axis-tolerance snapping? thus ratio instantly changes

debugging

log when moving the joystick from slight right of y-axis to Y-axis while keeping radius

W (166371) joystickCommands: left=17.67, right=0.51 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (166421) joystickCommands: left=17.27, right=0.81 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (166471) joystickCommands: left=16.94, right=1.35 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (166521) joystickCommands: left=16.99, right=1.85 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (166571) joystickCommands: left=17.05, right=2.13 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (166621) joystickCommands: left=16.59, right=2.48 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (166671) joystickCommands: left=16.17, right=2.75 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (166721) joystickCommands: left=15.92, right=2.91 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (166771) joystickCommands: left=15.15, right=3.32 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (166821) joystickCommands: left=14.36, right=3.80 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (166871) joystickCommands: left=13.40, right=4.20 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (166921) joystickCommands: left=13.09, right=4.45 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (166971) joystickCommands: left=12.73, right=4.80 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167021) joystickCommands: left=12.01, right=5.49 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167071) joystickCommands: left=11.88, right=5.74 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167121) joystickCommands: left=11.42, right=6.33 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167171) joystickCommands: left=11.16, right=6.70 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167221) joystickCommands: left=10.98, right=7.04 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167271) joystickCommands: left=10.82, right=7.14 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167321) joystickCommands: left=10.33, right=7.75 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167371) joystickCommands: left=10.17, right=7.95 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167421) joystickCommands: left=9.98, right=8.34 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167471) joystickCommands: left=9.73, right=8.74 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167521) joystickCommands: left=9.37, right=9.26 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167571) joystickCommands: left=9.19, right=9.74 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167621) joystickCommands: left=8.97, right=10.14 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167671) joystickCommands: left=8.81, right=10.73 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167721) joystickCommands: left=15.28, right=15.28 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167771) joystickCommands: left=15.54, right=15.54 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167821) joystickCommands: left=15.58, right=15.58 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167871) joystickCommands: left=15.36, right=15.36 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167921) joystickCommands: left=15.61, right=15.61 -- dutyMax=50, dutyBoost=35, dutyOffset=5
W (167971) joystickCommands: left=15.87, right=15.87 -- dutyMax=50, dutyBoost=35, dutyOffset=

Display messed up after driving? some time.

Observation

• not happening when idling?
• last line works correctly offset though

Things tried

• added regular displaly update (slow loop) had no effect

Todo

• reproduce this with new, larger display

see photos:

Issue

currently when releasing the joystick while moving and immediately moving it again in the same position the motors stop and start ramping up again from 0, this results in weird driving experience

solution

when duty was already higher within the last second, ignore the ramp and set target duty immediately

EDIT: utilize available speed-sensors for that?

Needs testing, certainly is difficult to make precise movements after some time (probably massage mode?).

current workaround:

reset to defaults (tested)
or restart armchair?

currently a fix conversion factor is defined to convert adc voltage to battery voltage (due to voltage divider)

however noticed during discharge test that the low voltage was not very accurate
specifically while charging the display showed 24.8V (3.54V per cell) and the power supply showed 22.4V at 5A
so the factor must be too high or not linear?

=> do tests with voltmeter and lab power supply to optimize that conversion factor

Joystick currently simply defines the target duty.
It might be useful or interesting to test other setting other target units.

duty

current behavior

current

• should behave like the previous driver while coasting and moving the chair manually
• torque gets controlled?

speed

• very abstracted mode (advanced regulation)
• feedback from speed sensors or GPS to determine actual speed
• anti-slipping included

e.g. parked armchair with cover for days, ON state remains unnoticed

current situation

currently armchair switches from active mode (JOYSTICK, HTTP...) to IDLE mode when there is no activity for 5 minutes

potential issues

board, driver, display, sensors, usb-charger etc. use up power even in IDLE mode

• battery drains completely
• motor driver might bug and activate motors

ideas

• measure voltage ()
• timeout
  • no activity for hours
  • general timeout e.g. at 12h uptime

action

• beep in certain intervals
• blink display?

Currently the handle function is run extremely fast in task_motorctl all the time
Which causes issues seen in #42
Also noticed the controller is getting quite warm

Ideas

• Add additional delay when targed reached
• Do not run fade functions etc when already at target duty

When using hardware-text scrolling, which was introduced in screensaver status-screen in 3514dd6 and before, a bugged column of pixels scrolls over the entire display.

ideas

Most likely issue using a 132 pixel display with 128 library (reason of OFFSET_X = 2 is neccesary).

All pixels including the bugged ones scroll right

Currently one mosfet controlling a relay for chair-adjust is on by default on startup or flashing until the chair-adjust is initialized. (GPIO15)

• Find out reason
• Burn eFuse to permanently disable the feature causing this?
• alternatively workaround: change pin assignment, so back rest moves up instead of leg rest down, which is less annoying

strapping pin
https://esp32.com/viewtopic.php?t=297
https://electronics.stackexchange.com/questions/622750/esp32-boot-strapping-pins-problem-gpio15-and-gpio5

Issue

It was planned that wifi only starts when changing to HTTP mode (in control.cpp) however wifi_init_client() or wifi_init_ap() fails / crashes the controller with the below error when run from control.cpp.

When run from main.cpp wifi_init and wifi_deinit works totally fine every time for some reason?!

I (11707) control: noting to execute when changing FROM this mode
W (11717) control: switching to http mode -> enabling http and wifi
I (11717) control: init wifi...

assert failed: xQueueSemaphoreTake queue.c:1549 (pxQueue->uxItemSize == 0)

Backtrace:0x40081a5e:0x3ffbd2d00x40088575:0x3ffbd2f0 0x4008f225:0x3ff
...

Current workaround

currently starting wifi every time at startup (never disable) independent of mode...

custom speed sensors with optical sensor and encoder disk.
The current firmware returns random direction

debug

• measure actual signal
  maybe noise problem?l

fix firmware?

fix hardware?

• optimize encoder
• thickness
• gaps

as in old firmware project add support for limiting current, hardware already implemented

• configure current sensors
• test whether current sensors work
• read current sensors
• handle limit
• set limit (config/command?)

currently fans are controlled per motor object
make this a independent task?

individual control must be dropped because now fans are powered with one common pin

currently simply configured same pin, will cause bugs...

add firmware for reading newly added rotary encoder

dynamic deceleration

due to new driver deceleration is slower by default due to otherwise unintended hard braking
when driving forward fast and releasing joystick it takes configured fade time (1,9s) for the motors to brake.
In some situations faster reaction is necessary

idea

when joystick already in other direction than currently fading from:
fade down faster or brake immediately

Added this in 021a366 needs testing though:

• test dynamic decel boost
• rotating not affected?

dynamic acceleration / start duty

example situation 2:

1. moving forward at full speed
2. right turn

• left tire 100%
• right tire 0%

3. go straight again

issue

issue: moving joystick straight, but it takes some seconds time for right motor to accelerate from 0...
result:

• taking too much of a turn...
• feels just laggy,
• you have to compensate the overshoot all the time

current workaround

• reduce fading overall

ideas

• reduce fading in that situation
  • implement some kind of duty history for that?
• use speed sensor / get rotational speed
  • adjust fading dynamically according to current speed
  • immediately start at certain higher duty according to speed

prevent uncomfortable shaking at change between joystick position enum
especially between forward right and full turn (y=0 <-> y>0)

Also related to #37

since outsourcing code to common/ folder i could not get joystick logging to work

needs testing (mayby sdkconfig was fault?)

workaround: replace LOGD with LOGE in joystick.cpp

slow mode for people that struggle handling the joystick (they just go full radius or nothing)

• add mode with very limited acceleration
• switch to this mode with button

implementation

• store preset accel in config
• maybe no actual mode, more command to set preset limits? function already exists for command mode
• nevermind, use common mode infrastructure and simply run accel-config commands at mode change
  • switch to mode: change accel time slow
  • switch from mode: set accel time to default

Sometimes when driving in JOYSTICK mode and switching to MENU while driving the armchair did not stop

Even though idleBothMotors() is executed when switching to MENU mode sometimes the motors stay on!

Race condition in control and button task: stick mode still executing while mode already switched

tasks

• re-arrange delay in modes?

• add mutex to wait for finished cycle?

• also re-test 10s timeout in motorctl since it logged the error message but did not stop?

• Re-evaluate the approach only setting the duty once at mode change in general

original char adjustmen electronic broke down 3 time by now
=> replace it with custom control

ideas

• use free 4x mosfet outputs
• use joystick as control interface
• h-bridge?
• relay board
• connector
  • additional connector (6 pins) required
  • upgrade existin 9pin subD? -> not practical due to wiring in armchair

tasks

• update connection plan
  • schematic
  • connection to board
  • wiring 3d-model box?
• housing for relays on armchair
• new connector
• test relays (inverted?) -> pullup?
• firmware
  • implement adjust mode

When change to objects in HEAP and passing with pointers instead of having global variables was introduced in 2fcf17f i noticed the following:

Issue

In MENU mode scrolling in menu turning the encoder fast worked fine, but slowly one tick at a time was not detected at all

Debugging

while debugging found out disabling motorctl task or increasing the delay in that task helps
while commenting out more code step by step found out the call of motordriver method to set duty in lambda function caused the lag

testing

store in STACK, access directly

• declaring the motordriver in STACK again as global variable 4da9989 (branch t_motordriver-in-stack-direct)
  • Observation: menu worked well without lag but the display laged once (cant reproduce)

store in STACK, access via pointer

• still use a pointer and initialize the object during startup, using alloca in f63d8a3 (branch t_motordriver-in-stack-pointer)
  • When flashing the heap version first, then the stack pointer version: it still lags?! (cant reproduce)
  • When flashing the stack pointer version again/multiple times: it works very well as well
  • When changing some text in code and flashing again it still works fine

store in HEAP (original issue)

• Flashing the HEAP version multiple times 2fcf17f
  • twice exactly the same version of that commit: it works well???
  • chaning a sincle character in print text: encoder lags again
  • flashing that same version again: still lags
  • flashing the same version a third time: still lags
  • => RANDOM dependeing where in heap stored?

learning

HEAP is significantly slower depending on position? (randomly worked fine once)
calling methods via pointer is (sometimes) less performant than caling them directtly?!

ideas and todo's for improving the chair adjustment are collected here.
Also see noted todo's in chairAdjust.cpp

ideas, todo

• add separate task that controls chair adjustment
  • timeout
  • track position
  • re-calibrate automatically ( detect situation when probably at limit )
  • auto-adjust: move to position while driving
  • control via app
• add delay between direction change (to prevent abuse)

Scale coordinates of joystick to have more precision (joystick travel) at slower speeds.
Currently implemented with linear scaling (see below), however this currently results in a weird/unexpected acceleration at the rapid change of scaling.
=> find a better way to scale the coordinates

already tried

exponential scaling

first tried with exponential scaling: 1c6586c
=> smooth but some some area with almost no output change at start

linear scaling

then linear scaling with switching point: b460a52
=> can be adjusted precisely but the point it switches to the other slope is very hard/noticeable while driving

ideas

Bezier curve??

have a function that represents the desired scaling curve
example: https://www.desmos.com/calculator/cahqdxeshd

Problem:

not enough gpio pins available
-> second pcb?

Idea

• board1:
  - control motors, fan
• board2:
  - send motor commands to board 1
  - handle inputs: stick, sensors, display

V2: adjust settings to new hardware

• due to higher voltage and grip
  • armchair moves too much already drives away at second intensity level

more levels

• currently only 3 duty levels are available
• make more levels along joystick radius

Fix unconftortable shakes when switching between different massage modes

already partially fixed this in 3fa2f17 (fixed random longer movement during shaking)
however there is still too long movement exactly when switching shake modes (move joystick to different quadrant)

very annoying bug with motor driver:
sometimes a motor seemingly randomly freezes for a few seconds, then immediately starts at current set duty again - feels very bugged

especially when trying to add angle threshold (snap to 1 / 0) for tighter turn radius so one motor is off while turning
this bug basically occurs every time -> inner motor does not start again after curve

current workaround

when 1 motor frozen, release joystick so both motors are off, then go again

observations

best for testing:

• turn deceleration off (8x button press)
• forward, release, forward again

common situations

1. both motors forward

2. motor1 duty to 0

3. motor1 duty positive
   ==> motor1 freezes / stays off
   ==> after a few seconds it starts

4. both motors to 0

5. both motors forward
   ==> both motors respond again

1. both motors forward
2. both motors 0
3. both motors forward
   => one or both motor freeze for (shorter than usual) time then start at current duty

ideas / theories

• A, B driver signal gets noise from other running driver?
• bug with driver getting confused by stopped duty
  • not likely, see tests
• signals affect each other because with common diode and pullup at mosfet pins

things tried

- leave duty on in idle
- never switch do idle
- always stay in FWD with some duty on
- reduce max duty to 60%

same issue persists
1 motor gets close to 0 duty while other is on it freezes

todo

• take of chair and measure with oscilloscope
  • measure actual voltage at A, B pins
  • measure acutal pwm signal
• search the internet for issues with thos drivers
• implement workaround?
  • detect situation when motor gets to 0 duty and restarts,
  • stop other motor too for 100ms
  • restart at previous duty immediately

observations

even though joystick is calibrated recently, the armchair moves slightly / shakes randomly when not touching joystick

• fading makes it less significant
• its very noticable in sport-mode (8x button press)
• stronger shaking for some time after startup
  • temperature?
  • previous mechanical stress from cover just removed
• general issue with noise e.g. when driving slowly it feels shaky

ideas

• analyse signal with scope
• debug signal with logging
• hardware filter? (R-C)
• software filter?

problem with joystick resolution / travel
when maxDuty is high you can drive fast but have no precision while driving slow (even though scaling improved that)
when maxDuty is low you can maneuver precisely but have slow max speed

idea:

time/speed based maxDuty adjustment
start with low max-duty to generate motor commands
when at 100% for long time OR certain speed? Increase max duty

sport mode ignores this

todo hardware

• modify joystick mount part
• install display
• rework mount: larger display

todo software

• search and test display driver
• fonts
• display bitmap

features / ideas

• display stats

  • display bat level
  • display current
  • display temperature
  • current / switch mode

• config menu

  • max speed
  • current limit
  • joystick calibration
  • max duty
  • set accel limit
  • set decel limit
  • preset slow mode ( see #14 )
    • low max duty
    • low accel/decel
  • reset settings (load defaults to eeprom) and restart?
  • restart

Task list for hardware changes

Ideas

• Attachments (power outlet, frame mount):
  • detachable ventilator
  • detachable lamp
• integrate wireless phone charging

Fixes when armchair is detached:

• switch sometimes not working (box warm) fix most likely unreliable contact on pcb (=> screw terminal was ripped off due to torque, replaced, added wire)
• swap right motor to be quiet too
• change gear ratio from Z10 / Z14 to both 12 (=> changed to Z16, topspeed ~10km/h)
• oscilloscope
  • debug speed sensors (inspect signal with oscilloscope) (=> looks fine, probably issue due to previously too high cpu load)
  • debug encoder left rotation slow (=> Fixed with adding missing 3v3 Z-Diode)
  • analyse stick signal (see #37 ) (=> added hardware filter see con-plan)
    • add hardware filter?
• replace original chair board with relay board for chair adjustment
  • design and print box
  • update wiring plan
  • wire relay box, PS2 cable
  • integrate into armchair
• replace broken left encoder mount
  • optimize design (mirrored not enough)
  • print using PETG, mount with washers
• UI-Arm
  • print again using PLA (less bending) (=> noticed no significant difference between the PLA vs PETG)
  • change design
    • larger display
    • no thin wall above thisplay
  • install large display
  • install new stick

General issues

• inspect front right tire (clicking sound at each rotation) (=> built custom axle with less play and more grease)
• when driving reverse with weight on left side there is grinding noise with spring of chair mechanism at left motor
  => linkage of armchair adjustment comes in contact with nut on motor shaft, when chair in certain position and suspension far down, happens at both sides -> no idea how to fix this right now

prevent complete battery discharge in idle when forgetting main switch

ideas

• measure voltage ()
• timeout
  • no activity for hours
  • general timeout e.g. at 12h uptime

action

• beep in certain intervals
• blink display?

Notes/Ideas for improving normal turning behavior

snap to max ratio

already implemented feature so inner motor is completely off for larger joystick area
can be enabled when #18 is fixed.
see joystick.cpp line 325

ratio scaling

issue

noticed that first angle of joystick is not really used (small ratio difference never really used e.g. 1:0.95)
meaning you always move joysitck to 45 Degree immediately when the goal is to slightly adjust direction
=> this results in wasted joystick resolution

EDIT: re-evaluate that - issue only persists at fast speed. when driving slow the detail is required
only at certain radius or speed? issue with sudden transition point

ideas

• min start ratio: immediately start at certain ratio when leaving y axis (like current min start duty)?
• scale ratio/angle differently (like current radius scaling)?

overdrive

currently when turning the inner tire simply gets slower depending on angle.
idea: when inner tire slows down, also increase outer tire speed.
or think the other way: detect when obviously wanting to drive slow e.g. driving fast on garden then slow parking in shed -> scale differently until at max radius again

if current radius is not 1 duty for overdrive available
if max-duty is configured less then 100% duty for overdrive is available

find a way to somehow dynamically add the access duty to outer tire instead of keeping it at maxDuty * radius

slow fade when accelerating
fast fade when turning / changing driving direction

when rotating (joystick along x-axis) above a certain duty (stick radius) the inner tire slips always.
which just ruins grass or tires...

idea

• general: slip detection possible in future?
• reduce duty of inner tire progressively with radius?
• configure threshold where reduction starts

Noticed a few times that armchair started driving forward for some time (2-3s) with no user input / no way to stop
after switching from massage to joystick mode
--> test and fix this

needs testing
might be other reason why fans just stayed on once

edit:
could not reproduce, other situation?

current situation

currently joystick min/max value of each axis is currently hardcoded in config
only the jostick center position is auto-calibrated during startup.

issue

noticed that min/max adc values drift every other day... resulting in weird joystick behaivor
e.g. radius never reaches 1 thus drives slow in certain direction

ideas

• add calibration sequence using encoder and display
• store min/max values persistent