Event Loop configuration in experiments¶
The EventLoop can be used in NRP-core experiments in replacement of the FTILoop as the mechanism for processing and relaying the data between simulators or other types of processes. The sections below explain how to configure an NRP-core experiment to use the EventLoop and how Engines can be used to interact with the Event Loop and the Computational Graph.
Below are commented the relevant configuration parameters in the experiment configuration file (see here for more details on configuring experiments in NRP-core):
SimulationLoop: this parameter can be set to two values: “FTILoop”, “EventLoop”. By default “FTILoop” is used. If set to “EventLoop”, at startup time, an EventLoop is created and run at a fixed frequency.
EventLoop : Event Loop configuration parameters, only used if “EventLoop” is set for the “SimulationLoop” parameter described above. It is a json object with the next parameters:
ExecutionMode: Execution Mode that will be used when running the Event Loop.
Timestep: this parameter sets the frequency at which the Event Loop is run.
Timeout: time in seconds the Event Loop will run before shutting down automatically. If set to 0 no timeout is used.
ROSNode: if this parameter is present in the configuration, a ROS node will be started along with the experiment. This is needed when using ROS Nodes in the Computational Graph.
MQTTNode: if this parameter is present, an MQTT client will be instantiated an connected to an MQTT broker. This is needed when using MQTT Nodes in the Computational Graph.
Interacting with Engines from the Event Loop¶
SimulationLoop parameter is set to “EventLoop”, an FTILoop is still started and run asynchronously with the EventLoop. This enables the possibility of interacting with Engines asynchronously from a Computational Graph using Engine Nodes. In this case, the Engines specified in the experiment configuration file are started normally but datapacks requested from and sent to them are not given by TransceiverFunctions, but from the Engine Nodes present in the graph.
To implement the behavior described above, the FTILoop normal functioning is modified when it is run alongside the EventLoop. Referring to the FTILoop simulation loop steps as described in this page, these modifications are summarized below:
step (3) is replaced by: for each InputEngineNode in the computational graph, methods
setDataPacks()are used to get the set of requested datapacks for each engine and, after they are received from the engine, injecting them into the graph.
steps (4) and (5) are skipped.
step (6) is replaced by: datapacks published to each OutputEngineNode in the graph are fetched using their
getDataPacks()method and sent to the corresponding Engines.
Running a Computational Graph Synchronously in an FTILoop¶
There is also the possibility of running a Computational Graph synchronously in an FTILoop replacing Transceiver Functions. In this case, no EventLoop is instantiated and the Computational Graph is executed directly from the FTILoop. The FTILoop runs with the same behavior described in the section above, but in every simulation loop, instead of steps (4) and (5), the Computational Graph is executed.
When running a Computational Graph from an FTILoop it is always executed in ‘OUTPUT_DRIVEN’ execution mode. Then, at run time, in each simulation loop step only those OutputEngineNodes linked to engines which are being synchronized in that step are executed. This described behavior, given the functioning of the ‘OUTPUT_DRIVEN’ mode, is analogous to the synchronization behavior of TFs, which are executed only when their linked Engine is being synchronized. In the case of the Computational Graph, only those functional nodes connected, directly or indirectly, with output engine nodes which are being executed in a simulation loop are in turn executed.