Author: Georg Hinkel

Static Validation & Verification for Neurorobotics Experiments: Aims and Scope

Validation and Verification (V&V) techniques have been widely used to make sure that simulation results accurately predict reality. As the NRP is a simulation platform to simulate a neural network embodied by a robot, the primary problem of validating that simulation results can be transferred into reality is an intrinsic problem. In fact, validating that a given neural network connected to a robot in a specific way produces the desired results is the very purpose of the NRP.

However, as of today, these validation tasks are performed entirely dynamic, i.e. through actually simulating the experiments. In this series of blog posts, we investigate how this dynamic validation can be supported by static validation and verification activities.

For this, we see the following advantages:

  • The neuroscientist gets an early feedback on their experiment. Because a static validation or verification is independent of a concrete simulation, the analsis can be performed before the code is actually simulated. This aid the design of neurorobotics experiments escpecially without a running simulation. For the NRP where the editors are currently only available within a running simulation, this means we could validate for example Transfer Functions before they are actually applied to the simulation.
  • The simulation platform uses resources more efficiently as no simulation resources are aquired for experiments that cannot be run. As of today, this advantage is not significant, as users may only change an experiment within a simulation unless they are willing to edit the plain XML models, but in the future, this is an important goal.

Static V&V argue on all possible execution paths of an experiment. However, the ability of a neural network to learn and adapt to new situations, but also the complexity of the interactions of a robot with its environment make it infeasible to argue based on single execution paths. Therefore, static V&V techniques are mostly restricted to arguments on all execution paths, in particular errorneous parts.

Therefore, the aim of static V&V in the context of neurorobotics must be to find neurobotics experiments that are errorneous for all errorneous executions, i.e. experiments that include flaws such we know that the experiment is not going to work, regardless of the exact behavior of the neural network.

For a successful validation and verification, we need to look at the three main artifacts in a neurorobotics simulation:

  • The neural network
  • The robot
  • The Transfer Functions that connect the latter.

These parts will be looked at in more detail in future blog post on this subject.

Advertisements

The Closed Loop Engine Architecture Explained

In order to simulate arbitrary neurorobotics experiments incorporating a coupled simulation of a neural network and a robot as its physical counterpart, it is required to abstract from the technical details.

Specification in Python

For the specification of a closed loop in the Neurorobotics Platform, we have chosen the Python language, as Python seems very popular among neuroscientists and is generally easy to learn. The specification of a closed loop is divided into Transfer Functions, which can be specified in a Python internal DSL called PyTF. PyTF essentially defines a set of decorators to specify how the parameters of a regular Python function should be mapped either to the neural network or to robot sensors or control channels. Transfer Functions in PyTF look as follows:

import hbp_nrp_cle.tf_framework as nrp
from geometry_msgs.msg import Vector3, Twist
@nrp.MapSpikeSink("left_wheel_neuron",nrp.brain.actors[0], nrp.leaky_integrator_alpha)
@nrp.MapSpikeSink("right_wheel_neuron",nrp.brain.actors[1], nrp.leaky_integrator_alpha)
@nrp.Neuron2Robot(Topic(’/husky/cmd_vel’, Twist))
def wheel_transmit(t, left_wheel_neuron, right_wheel_neuron):
   linear = Vector3(20 * min(left_wheel_neuron.voltage,
                             right_wheel_neuron.voltage), 0, 0)
   angular = Vector3(0, 0, 100 *
                     (right_wheel_neuron.voltage - left_wheel_neuron.voltage))
   return Twist(linear=linear, angular=angular)

Here, the decorators of the Python function describe how the parameters of the underlying Python function should be mapped to Robot control and neural network information. Each decorator specifies the parameter that is mapped and how this parameter is mapped. The first parameter must be named t and must not be mapped. Instead, it is automatically filled with the simulation time.

Runtime Architecture

From this specification, the CLE deducts a runtime architecture of the Transfer Function. For the Transfer Function above, this creates the Transfer Function component WheelTransmit in the diagram below. The CLE then creates the necessary components to connect each required interface of the Transfer Function component with a respective implementation.

runtimearchitecture

Not shown in the diagram, the CLE also deducts a specification to which neurons the leaky integrator components should be connected to. Furthermore, the choice of the concrete component type is

A Transfer Function generally only implements an open loop, thus either forwards information from the neuronal network to the robot or the other way round. To establish a closed loop, other Transfer Functions in the opposite direction are required, as depicted in the lower part of the diagram above.

Static Architecture

To assemble the runtime architecture from a given specification, the CLE uses a static architecture to dispatch which components should be created for a given interface based on the chosen neural and world simulator. A diagram of this architecture is shown below.

staticclearchitecture

For each world and neural simulator, the CLE distinguishes between components managing the control flow and components managing the data flow. The concrete implementation is encapsulated behind one of four interfaces, making the simulators used by the CLE easy to exchange. This separation also makes it possible to reuse data flow implementations for multiple simulators. For example, multiple world simulators use ROS to communicate with the robot.

Continue reading “The Closed Loop Engine Architecture Explained”