State Machines

[tomtzook]

Part of an attempt to improve and manage control of robot operations and scheduling, this new feature will introduce State Machines integrated with the Scheduling System, allowing the activation of Actions and management of Triggers in a smarter way.

Based on NFAs (inspired by this), users will be able to manage states of separate Subsystems on the robot, configure transitions between and attach actions to them.

Basically, the machine will hold a set of active states, each configured by the user. Transitions between states will be enforced based on those configurations to deny certain invalid transitions.

States will allow attaching Actions` to them.

Transitions are more of an instant change of states, triggered manually by a user API call, or automatically via some condition (or Trigger).

API design is still in brain-storming phase. See branch feature/state-machines.

[tomtzook]

Some notes about designing:

• For it to be effective, it needs to be able to support multiple unrelated states connecting
  • For example, a connection between a turret and shooter systems
  • This probably means an NFA
• Should be able to link with actions
• transactions must be limited only to wanted ones
• we have
  • States: the current state of operation of the system
  • Transition: a change of state
• We could consider it as States being long-term and Transitions being just the change between them.