CSPS architecture_beta 0.4

Overview

The libcsps is designed to be easy to enhance without having to go deep into the code. The overall architecture is based on the notion of streams coming from the different physical devices, that are engaged in the motion tracking process of the camera, and from virtual devices that realize signals crossing.

Streams are initiated through extraction modules, that are specific to a given type of physical device, and provided to the stream modules in order to process them. The stream modules can consider those streams to perform specific computation according to desired results. Modules are the nodes of the processing, the streams being the links between them.

As processing is performed, queries can be made on results carried by the streams through a query interface thanks to the standardized directory structure given by the last section.

Modules architecture

The libcsps modules have a common generic nomenclature. A module recieves streams as input and export its results into output streams. A module can recieve more than one stream as input that are related to different physical or virtual devices and can initiate more that one stream to carry its results.

Each module is related to one or more specific devices, that can be a physical devices, providing measures, or a virtual devices, responsible of signals crossing.

Extraction modules

The extraction modules are the signals front-end of the CSPS library. They have the responsibility to read physical devices logs, in their specific format, to engage initial streams. The streams that come out of those modules carry usually raw data that other modules have to process in order to correct and to cross them.

Stream modules

The stream modules can perform specific task on specific streams that can be provided by extraction modules or other stream modules. Each module of this type has to perform a specific and well identified task.

The stream modules can consider specific streams to process them and, by this way, simply being a step for those specific streams. It can also consider streams coming from different modules to create a new type of stream related to a virtual device, for signals crossing typically. It is so because at end, no matter how many physical devices are considered, the usual libcsps result is a thirteen components stream that represent the position and orientation of the camera, or device assembly, according to time. The role of libcsps is then to reduce all the incoming information in this specific form.

Query interface

The libcsps provides also an interface for query in order to easely ask the camera position and orientation and other inertial provided information, typically on the basis of a time value or an index. This interface consists simply in functions that answer the desired information asked by the client software.

The usual query consist in a three components and a nine components vectors that store respectively camera position and orientation at a given time provieded by the client.

Storage structure

Because CSPS processing consists in data handling, it needs a directory structure in which streams content are dumped and where device-specific logs are fetch. The less indented directory of this simple structure is always ask by the library features, its content being standardized as follows :

csps-main/                    Structure main directory
└── devices/                  Device-specific logs directory
    └── eyesis4pi/            Eyesis4Pi specific logs directory
        └── fpga-log.bin      Eyesis4Pi logs-file
└── streams/                  CSPS streams directory
    └── streams.bin           Stream component data files
    :
    :   
    └── streams.bin           Stream component data files
└── topology                  CSPS topology file

A non-standard directory structure or a bad path to the main directory is the first thing to check if a library feature fails naming being the second major source of error.