template<typename EventType>
class drake::systems::EventCollection< EventType >
There are three concrete event types for any System: publish, discrete state update, and unrestricted state update, listed in order of increasing ability to change the state (i.e., zero to all).
EventCollection is an abstract base class that stores simultaneous events of the same type that occur at the same time (i.e., simultaneous events).
For each concrete event type, the LeafSystem API provides a unique customizable function for processing all simultaneous events of that type, e.g. LeafSystem::DoPublish(const Context&, const vector<const PublishEvent*>&) for publish events, where the second argument represents all of the publish events that occur simultaneously for that leaf system. The default implementation processes the events (i.e., call their callback functions) in the order in which they are stored in the second argument. The developer of new classes derived from LeafSystem is responsible for overriding such functions if the custom LeafSystem behavior depends on the order in which events are processed. For example, suppose two publish events are being processed, events = {per-step publish, periodic publish}. Depending on the desired behavior, the developer has the freedom to ignore both events, perform only one publish action, or perform both publish actions in any arbitrary order. The System and Diagram API provide only dispatch mechanisms that delegate actual event handling to the constituent leaf systems. The Simulator promises that for each set of simultaneous events of the same type, the public event handling method (e.g. System::Publish(context, publish_events)) will be invoked exactly once.
The System API provides several functions for customizable event generation such as System::DoCalcNextUpdateTime() or System::DoGetPerStepEvents(). These functions can return any number of events of arbitrary types, and the resulting events are stored in separate CompositeEventCollection instances. Before calling the event handlers, all of these CompositeEventCollection objects must be merged to generate a complete set of simultaneous events. Then, only events of the appropriate type are passed to the event handlers. e.g. sys.Publish(context, combined_event_collection.get_publish_events()). For example, the Simulator executes this collation process when it is applied to simulate a system.
Here is a complete example. For some LeafSystem sys at time t, its System::DoCalcNextUpdateTime() generates the following CompositeEventCollection (events1):
PublishEvent: {event1(kPeriodic, callback1)}
DiscreteUpdateEvent: {event2(kPeriodic, callback2)}
UnrestrictedUpdateEvent: {}
This LeafSystem also desires per-step event processing(events2), generated by its implementation of System::DoGetPerStepEvents():
PublishEvent: {event3(kPerStep, callback3)}
DiscreteUpdateEvent: {}
UnrestrictedUpdateEvent: {event4(kPerStep,callback4)}
These collections of "simultaneous" events, events1 and events2, are then merged into the composite event collection all_events:
PublishEvent: {event1, event3}
DiscreteUpdateEvent: {event2}
UnrestrictedUpdateEvent: {event4}
This heterogeneous event collection can be processed by calling the appropriate handler on the appropriate homogeneous subcollection:
sys.CalcUnrestrictedUpdate(context,
all_events.get_unrestricted_update_events(), state);
sys.CalcDiscreteVariableUpdate(context,
all_events.get_discrete_update_events(), discrete_state);
sys.Publish(context, all_events.get_publish_events())
For a LeafSystem, this is equivalent to (by expanding the dispatch mechanisms in the System API):
sys.DoCalcUnrestrictedUpdate(context, {event4}, state);
sys.DoCalcDiscreteVariableUpdates(context, {event2}, discrete_state);
sys.DoPublish(context, {event1, event3})
- Template Parameters
-
