State machines
Event framework lab

In the previous lab, we used a switch-case structure to implement a state machine. Hopefully, you are now able to understand and implement complex robot actions over time in terms of state machines. In this lab, we are going to learn about the event-driven paradigm and apply it to state machine design.

The previous state machine lab used a switch-case structure to implement the state machine. There are more complicated ways to formulate state machines that provide more expressive power, such as an event-driven paradigm. In this paradigm, any change in external state is considered an event (e.g., button press/release, digital input rising edge, timer expiration). The current state in a state machine can choose to consume the event and initiate a state transition.

Hierarchical state machines

State machines can also serve as states themselves. When the parent state machine transitions to it, events received by the parent state machine are passed down to the child state machine which can consume it first and cause a transition. If the event isn't consumed, it is passed up the hierarchy to parent state machines which can choose to consume it. If none do, the event is discarded.

Understanding the problem

For this lab, you will modify your solution for the previous state machine lab to use our event-driven framework instead of a switch-case structure.

Setup

Make another project containing the same files as your previous solution, then copy the following event framework files into it. A new Main.cpp is provided as a starting point.

• DigitalInputHandler.cpp
• DigitalInputHandler.hpp
• Main.cpp
• Events/DigitalInputEventGenerator.cpp
• Events/DigitalInputEventGenerator.hpp
• Events/EventAcceptor.hpp
• Events/EventGenerator.hpp
• Events/JoystickEventGenerator.cpp
• Events/JoystickEventGenerator.hpp
• Events/TimerEventGenerator.hpp
• SM/State.cpp
• SM/State.hpp
• SM/StateMachine.cpp
• SM/StateMachine.hpp

Implementation

Our 2016 robot used an event-driven framework for the state machines. It uses a State class with the following function objects which can contain lambda functions. See examples of lambda functions here.

• Entry (upon entering a state)
• CheckTransition (returns name of the next state if an event caused a transition)
• Run (while within a state)
• Exit (upon exiting a state)

The StateMachine class handled calling those functions at the appropriate time.

Here's an example state machine from our 2016 robot:

TODO: example

TODO: Documentation on example here.

Once you are satisfied with your state machine diagram, translate it into C++ and test it. Main.cpp provides a template for you to do so. You shouldn't need to modify the RobotMock and Timer classes. We recommend adding print statements upon entering and exiting your states so the state machine's progress is externally visible.

Submission

See the CI submission instructions.

Use the project name event-framework. Once you are confident your state machine works, let your instructor know and they will review your work.