DIY lawn mower robot

Run unit tests:

poetry run pytest -s

Run simulation:

poetry run python .\record.py

(Replay log file, should add fail safe detection ++):

poetry run python .\record.py .\data\burned-motor.log

• motor burned (one wheel was tangled in grass):

  • wifi connection delayed - commands and feedback
  • figure out why robot estimate wrongly turned and why it did not recover when moving "right"
  • fix: move control to robot, detect connection delays, ignore delayed information, timestamp from STM32, use timestamp from GPS

• high load on motor detection - possibly integrate and average

  • cut in STM or in control? Control, as will get to know what is going on?
  • STM will stop robot if communication errors, safe to cut in control.
  • different max for instantaneous and average load?
  • Simply stop when above threshold (instantaneous)

• robot stuck detection: anomaly on prediction and GPS

  • measure distance travelled over last 5 say on GPS and compare to integrated speed

• wifi delay detection

  • shorter timeout (1s/2s)
  • embed timeout in command
  • alert in GUI

• stop cutter outside fence?

• cutter stuck detection

• revs sensor on cutter

• slow down near fence

• keep estimating position with odometer only when no GPS fix -> higher uncertainty

• Fence

  • increase area behind garage
  • reduce fence area near stairs

• App robustness

  • restart GPS service when USB unavailable, also ntrip client fails badly? restart service should be ok...
  • properly stop all tasks, also controld connection, from PC app
  • program firmware with heartbeat on commands

Usability: * Don't make PC app always be on top: run GUI task in own thread? * PC/Web/mobile app framework: pyplot, JS, plotly-dash, ... * identify what goes wrong / status * restart e.g. line scan from current position?

• Tidy up app:

  • remove unused code

• move app to robot

• change direction of robot

• slow down near fence, speed up in the middle (may make crash prediction below unnecessary - if reducing heartbeat timeout in robot)

• keep going for large HDOP if far from fence

• use GPS hdop in tracking, figure out why HDOP is 0.5 when RTK

• looser cut-off on no RTK - either adjust error in GPS tracking (check out HDOP in RMC)

• or - accept no GPS for a while - at least if heading is good and is not going to crash. estimate time to impact from last good RTK position? BUT: also quicker than 5s heartbeat timeout, i.e. direct STOP command if about to crash and loose RTK

• avoid going in circles on drifting GPS: HDOP -> tracker could solve that

• area filling - scan lines

• if HDOP high: alternative targets or wait for ok HDOP

• fence bump control: reverse out from fence

• automatic charging

• docking garage

• camera

• camera coverage of garden

• realsense - mapping, collision avoidance

Mission control dashboard

• map (draw AOI, speeds/behavior, move fence, path, density, ..., GPS/tracking error, heading error)
• system health: show currents, battery level
• (E)stop button
• Duration, Ah drawn (total, trip (since charge), button for reset trip charge), distance covered
• Mode: fence bump, lines, manual, manual override (temporarily)
• Manual controls
• Start mission - which mission
• app to monitor status, with notifications on issues

Analytics

• GPS/tracking precision
• Coverage
• Replay/show mission on map

Mapping

• find fence - show position on map with manual control - recorder mode....

Mission control

• run to area of "little" probability
• speed and cut speed as fn(x,y)
• avoid tail swinging out (reverse back out, put GPS above cutter and turn around cutter)
• estimate error based on odometry and GPS signal - keep on going if looses RTK
• TODO: check GPS error when stopped and no RTK