Introduction

The Hardware Abstraction Layer allows you to handle event-based cameras.

The event-based camera is abstracted over the Metavision::Device class which allows to access camera capabilities from facilities.

As a front-end for the application, the HAL library provides:

  • Ability to discover the connected devices by:

    • Listing serial numbers of connected devices

    • Opening a camera from a serial number

    • Opening a RAW file as a device

  • Hardware features interface through facilities like:

  • Decoding information coming from the camera

This abstraction purpose is to be able to handle several event-based cameras from the same API. The event-based camera can be provided by different camera makers (called Integrator later).

Each camera maker communicates with its camera through its own protocol using a connection link, such as USB, MIPI, network, etc.

The camera integration into this API is done using a plugin-based architecture. Each Integrator can provide its own plugin, and the application can load it dynamically without recompiling.

The application needs are:

  • List connected devices

  • Open one device

  • Configure the device

  • Decode the events

Listing and opening the devices needs to discover the devices, as detailed in section Discover Devices.

Discover Devices

The communication with the camera is done by the plugin itself. Thus, the first step is to load the plugin dynamically.

The plugins are searched in the following folders:

  • <install-prefix>/lib/metavision/hal/plugins/ (i.e. /usr/lib/metavision/hal/plugins/ by default on Ubuntu OS)

  • the folder list provided by the environment variable MV_HAL_PLUGIN_PATH.

Note

The folders are separated by ‘:’ under Unix and ‘;’ under Microsoft environment.

Every library in these folders is considered as a potential plugin.

To list the devices, every plugin is interrogated about the connected devices that it can handle. The plugin returns the list of serial numbers of the connected devices. The HAL library prefixes to this number the integrator’s name and the plugin’s name.

The plugin’s name is deduced by removing the prefix lib and the file extension of the library file name.

Thus, a serial number looks like Integrator:Plugin:DeviceID to ensure the uniqueness of the number.

From this serial number the device can be opened by using the function Metavision::DeviceDiscovery::open().

The camera creation can be customized by providing a configuration.

To open a device, you can provide as a serial number:

  • DeviceID that will take the first plugin matching the serial number. If empty, then the first available device is returned

  • Name:DeviceID that will take any plugin with either an Integrator’s name or a Plugin’s name matching the specified Name

  • Integrator:Plugin:DeviceID that will open DeviceID for any plugin with the provided Integrator’s name and the Plugin’s name. If one of the fields (Integrator or Plugin) is empty, then it is ignored.

The first plugin that fulfills the requirements of the Integrator’s name and the Plugin’s name and that is able to open the DeviceID is used to open the device.

Note

Several plugins can handle one camera, thus, you may want to select the required plugin.

Note

There is no guaranty that the DeviceID is unique. Hence, you need to discriminate between them.

See also

See samples showing how to discover and open devices.

Data Recording to RAW files

While receiving events from the device, the events can be recorded to a RAW file as shown in the sample.

To replay a RAW file, the function Metavision::DeviceDiscovery::open_raw_file() creates a fake device streaming data from the RAW file.

Every RAW file contains a header with information about the device and the plugin that generated it. More information on the RAW format can be found here.

As for the real device, the Metavision::DeviceDiscovery::open_raw_file() function iterates over all the plugins to find one that is able to read and decode the data from the file.