Lua state machine
| Reported by: |
tim |
Owned by: |
tim
|
|
Priority:
|
major
|
Milestone:
|
0.3
|
|
Component:
|
Fawkes
|
Version:
|
|
|
Keywords:
|
FSM
|
Cc:
|
|
|
Git Branch:
|
|
|
|
For reactive behaviours, a reactive agent and challenge applications in the RoboCup@Home league a generally usable Lua (finite) state machine (FSM) is necessary.
The state machine should obey the following criteria:
- minimum amount of code overhead for the state machine
- allow for hierarchical usage, this does not mean that it needs explicit API support, but for example that it does not use a global variable that prevents us from instantiating several state machines
- Allow for the usage of our usual design patterns, like executing code on the entry to a state and not (necessarily) on the transition to the state. This allows for easier recycling of states, like driving to a standby position from different states does not need the very same code in every transition, which is more likely to be defined for the outgoing state
- Allow safe state transitions. An example from the AtHome? league: the robot is grasping a cup. Now the time is up and to get the points for exiting the arena it should abort the current action. This would mean to retract the arm and then leave, and not drive with the extended arm. So if the "leave arena" transition is executed by a trigger, the state machine should make it simple for this safe behaviour.
Desired but not required features:
- Visualization of the state machine (offline)
- Visualization of the current FSM state and flow (online)
No decisions made, yet.
Change History |