Simulation Synchronization and Data Exchange¶
Synchronization mechanism¶
The synchronization solution strongly relies on the capability to control both the simulations in
terms of starting and running for a fixed amount of simulated time (timestep).
The idea behind this synchronization mechanism is to let both the simulations run for a fixed
timestep, receiving and processing the output of the previous steps and yielding data that will be
processed in the future steps by the concurrent simulation.
In other words it is not possible to receive data yielded in the current timestep by the concurrent
simulation. This can be read as the time needed for the TFs to output a results is greater than the
timestep.
cle-sync-mechanism shows the proposed synchronization mechanism. In this simulation, NEST
produces spikes and send them to the TFs. The output of the TFs can be available at the beginning
of the next timestep (or future timesteps) in the Gazebo simulation. The simulation in Gazebo produces
the output at the end of the simulation time and it is sent to the TFs. Depending on the output time
of the produced spikes by the TFs, they are sent to and processed by NEST at the right time. This
synchronization mechanism allows the simulations to run in parallel each step. This means that before
starting a new timestep simulation, both have to complete their running in order to keep the
execution and the data exchange aligned in time.
Data Exchange¶
The CLC is responsible for the control of the synchronization as well as for the data exchange among
the Simulations and the TFs. The purpose of the CLC is not only to guarantee that both the simulations
start and run for the same timestep, but it also collect data at the end of the simulation in order
to make them available for the TFs. The TFs have an internal status synchronized with Nest and Gazebo.
cle-sync-data shows a sequence diagram of a typical execution of a timestep. After Gazebo and
Nest have completed their execution, the TFs receive and process data from the simulations and produce
an output which is the input for the next execution. In each timestep, after finishing their simulation
step, Gazebo and Nest send an acknowledgment to the TFs (CLE application). At this point two data
streams are executed:
Gazebo sends the motor commands generated the previous timestep to the TFs that translate them in spike and send them to NEST.
NEST sends the spikes generated the previous timestep to the TFs that translate them in motor commands and send them to GAZEBO.
Clearly the TFs run for a timestep producing spikes for the next NEST simulation and commands for the execution in GAZEBO.
Warning
Currently, there is a Bug in NEST making this solution infeasible. Therefore, we have a completely serialized version of the CLC as backup, i.e. NEST, Gazebo and the TFs run sequentially. However, this temporary solution does not utilize the multi-processors of modern hardware sufficiently and thus we want to have the method as described in this document in the long term.