iLab Neuromorphic Robotics Toolkit  0.1
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
Module Types

It is useful to distinguish different basic module types. Note that actual modules may combine several of the basic types described here.


A source generates and posts some data. A source is typically not triggered by any other module (that is, it has no subscriber port). This typically involves:

  • A function that runs in its own thread and that will obtain the data, for example from a file, or a camera, a GPS, etc. NRT provides a framework to allow programmers to create such a function easily. NRT handles starting and stopping the thread as users issue start and stop commands in the Designer.
  • Some parameter to allow users to specify the data to be sourced (e.g., specify a video device name for a given camera, or a file name of a movie). Additional parameters may be used, for example to specify the rate as qhich the data is to be acquired.
  • One or more poster ports to post the data each time new data is acquired.


A filter typically subscribes to some data, transforms it, and posts the result. This typically involves:

  • No function running in its own thread. Instead, all computation is done in the onMessage() callback of the subscriber port of the filter. That is, the filter is idle until some new data is received, and receiving the data triggers computation and posting of the results.
  • A subscriber port for the data to be received, and an associated onMessage() callback function that processes data as it is received.
  • A poster port that posts results of processing each time they are available.


A sink absorbs data and does not post anything. Thus a sink typically involves:

  • No function in its own thread. The sink is driven by its subscriber port.
  • A subscriber port and associated callback. The received data is then sunk somewhere (e.g., displayed, written to a file, etc).
  • Parameter(s) that define how to sink the data.
  • No poster port.

Client / Server

A client typically contacts a server with a request and it expects a response that fulfills the request. This is easy to achieve in NRT by using ports with non-void return types:

  • The outgoing message type defines the request, and the return message type defines the response
  • A server module implements a subscriber port for this chosen message/return type combination. Like a standard server, it will hence be dormant until the callback of its subscriber port is triggered by some client.
  • A client module implements a poster port for the chosen message/return type combination. When the client posts on this port, it will receive a vector of future results, with one entry per server module that is connected to the client. This is explained in more details in NRT Data Flow.

Data store

Data store modules are useful to share data asynchronously. They simply post some data, and they rely on the distributed Blackboard federation to keep that data over time, and to share it with any local or remote module that may want it.

This is the preferred way to share configuration parameters, trained classifiers, definitions, calibration data, etc in a distributed NRT application. For example, a trivial data store may read some camera calibration matrix from a config file and post it. Any module that needs to know the camera calibration can subscribe to or check for this data as needed (and, using parameter ports, some modules which originally had this data as a Parameter can link their parameter to the data store).

A data store typically involves:

  • Some parameters to reach or create the data (e.g., name of a config file, or focal length and other values that will give rise to a calibration matrix);
  • A poster port for the data
  • A function that posts the data, and that is called, at least:
    • In an overload of the run() function of the module, so that it is called once when the module starts (another possiblility is to overload postStart() which is discussed later);
    • In an overload of the parameter callbacks, so that it is called each time parameters (and hence the data that depends on them) are changed.
  • Typically, modules interested in the store's data would issue a check() for it, for example when they start. So even a module instantiated much later after the store has posted its data will still receive it via the check() operation.