High-Level State Machine - Architecture

[tbohne]

• normal operation: executing a given plan / idle (waiting for plan)
• problematic
  • contingency: problem detected, e.g. sensor failure, but ability to act remains - drive back to base in safety mode
  • catastrophe: - unsolvable problem occurs (not even solvable by the operator), if still possible, save current state, send emergency signal and shutdown
  • also covers full breakdowns where nothing is possible (e.g. battery dead)

Catastrophe and contingency differ in the robot's ability to act. In a catastrophe case it's no longer really able to act.

• e.g. robot falls over (we can even try that)
  • can not recover (move), but is still able to communicate, save the state etc.
• different case -> lightning strikes and robot has a full breakdown and is not able to do anything
• Boundaries not 100% sharp -> there are edge cases

Battery-Example:

• normal operation: battery discharges faster than expected, e.g. because of low temperatures -> replanning + execution of adapted plan
• problematic:
  • contingency: battery too low already, watchdog triggers -> have to drive back to base
  • catastrophe: battery so low that I can already tell that it's not possible to reach the base
  • can still communicate the problem and save the state, but that's it (cannot recover)
  • if the battery just breaks down suddenly, nothing can be done - full breakdown

[tbohne]

• have a high-level state machine that differs between abstract high-level states like the above: normal op / catastrohe / contingency
• normal operation - nested state machines for what the robot is actually doing (plan execution etc.)
  • via concurrency intervene when a monitoring procedure triggers and cause a state change, e.g. to contingency

[tbohne]

I think it should work like this for now: