CSPS topology_beta 0.4

Overview

Streams and modules are the central concept of CSPS library. The CSPS topology translate the way streams are used to link modules and their related devices in order to produce the desired results. From this point of view, the topology is the front-end of the library. This pages gives a presentation of topology edition standards as expected by the parser implemented in the library.

Topology edition

Topology are given to CSPS library in a simple formated text file. First of all, devices engaged in the topology have to be given before editing links between modules. Considering a camera device, the definition line waited by the parser is as follow :

device cam 
    model EYESIS4PI 
    tag   eyesis4pi
end

The device keyword indicates device definition. The device type is then given, here with cam parameter for camera devices. The model keyword precede camera model that has to correspond to an implemented device. To deal with ambiguities, devices are referenced with a tag in the CSPS processing flow using the tag keyword.

For module links edition, initial streams are created through extraction modules. Those modules are device specific and are called in the following form :

module cam-mod-DSIDE 
    level  1
    device eyesis4pi
    block  1024
end

The module keyword indicates a module call. The called module name has to be given as next parameter. Then, the input devices tags have to be given using device keyword. Then, module-specific parameters are set using their specific keyword, here block for buffer size parameter. Because this example shows extraction module call, input stream are implicitly known.

The level keyword is used to determine if the module has to be called according to topology execution mode. This allows to define multiple modules processing sequences within the same topology that can be executed at different times. If the level keyword is not specified, one is assumed as default value.

The stream modules have to consider input streams in addition to input devices. A typical call is illustrated here :

module imu-mod-SGSFR
    level           2
    device          adis16375
    module          mod-DSIDE
    freq-in         2460
    freq-out        60
end

As extraction module call, the module name is given just after module keyword. Then a list of devices tags is given according to module expectations using the device keyword and in the order expected by the module. Only after device specification, input modules are specified using the module keyword also in the order expected by the module. Then specific keywords are used to specify module expected parameters. Here input and output frequency of signals are provided as parameters.

Origin directives

Because topology of CSPS processing can become rapidely complicated, the access the to processed data results implies complicated switches on streams specification. To solve this problem, a simple origin directive is defined to easily detect and access streams that carry the wanted results. Those directive are defined for orientations, position, inertial still ranges and camera trigger streams. Origin directives are defined as follows :

origin orientation
    adis16375
    mod-IFETI
end

As a results, if queries are performed using the origin directive for orientation, the library automatically considers the output streams of the mod-IFETI module with device adis16375. It follows that only path to the standardized directory structure is necessary to access such orientation results. Those directive can be written anywhere in the topology file.

Topology example

An example of a simple CSPS topology is provided here. It considers three devices that are a camera, a GPS reciever and an IMU sensor. The topology example file content is given by :

origin orientation
    adis16375
    mod-IFETI
end

origin position
    ls20031
    mod-SGNQF
end

origin trigger
    eyesis4pi
    mod-DSIDE
end

origin still
    adis16375
    mod-ISRAD
end

device cam
    model EYESIS4PI
    tag   eyesis4pi
end

device gps
    model LS20031
    tag   ls20031
end

device imu
    model ADIS16375
    tag   adis16375
end

module cam-mod-DSIDE
    level           1
    device          eyesis4pi
    block           1024
end

module gps-mod-DSIDE
    level           1
    device          ls20031
    block           1024
end

module imu-mod-DSIDE
    level           1
    device          adis16375
    block           1024
end

module gps-mod-SGNQF 
    level           1
    device          ls20031
    module          mod-DSIDE
end

module imu-mod-SGSFR
    level           1
    device          adis16375
    module          mod-DSIDE
    freq-in         2460
    freq-out        60
end

module imu-mod-SGNDN 
    level           1
    device          adis16375 
    module          mod-SGSFR
end

module imu-mod-ISRAD 
    level           1
    device          adis16375 
    module          mod-SGSFR
    maximum         256
    minimum         32
    trigger-gyro    0.05
    trigger-accel   0.50
end

module imu-mod-IOBMA
    level           1
    device          adis16375 
    device          ls20031 
    module          mod-SGNQF
end

module imu-mod-IFICR
    level           1
    device          adis16375 
    module          mod-IOBMA
    x-angle         +0.0
    y-angle         +0.0
    z-angle         -1.57079632679489655800
end

module imu-mod-IFETI
    level           1
    device          adis16375 
    module          mod-SGNDN 
    module          mod-IFICR
end

module imu-mod-AACEX
    level           1
    device          adis16375
    module          mod-SGNDN
    module          mod-IFETI 
end

The devices are initially declared with their specific options. Then the extraction modules are called for the camera, GPS reciever and IMU sensor. The stream modules are then called in order to generate the desired results. On this example, all modules have a defined execution level of one.

Topology results

The following image gives a three dimensional illustration of the results provided by the example topology. The earth-attached positions of camera capture are given in yellow when orientations are provided by the red-green-blue frame attached to each camera record :

On the previous image, an Eyesis4Pi camera device was mounted on a car. Two whole turns around a building located at Geneva where performed during this record in 4 minutes and 57 seconds.