In the recommended SMACC Event Model, events are generated by Clients & Client Behaviors, from inside their respective Orthogonals. These events are then consumed by either the State Reactors, or by the States themselves. When State Reactors consume events, they then output another event. And when States consume an event, they output a transition to another state.
Entity | Inputs | Output | Lifetime |
State | Events | Transitions | Temporal |
State Reactor | Events | Events | Temporal |
Client | ROS Msgs | Events | Persistent |
Client Behavior | ROS Msgs | Events | Temporal |
States, and their functions, are allowed to generate events directly as well, but this is discouraged.
One reason is that once more than one event is generated by the state, it becomes difficult to track what is going on in the SMACC Viewer. Another reason, is that event generation is often tied to callback functions, and to be thread-safe, the callback function needs to be placed in the client behavior (or client). Otherwise, a message/service/action can come into the ROS queue, but the State containing the callback function may have already vanished.