The Hardware Abstraction Layer allows you to handle event-based cameras.
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.
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.
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
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.
Several plugins can handle one camera, thus, you may want to select the required plugin.
There is no guaranty that the DeviceID is unique. Hence, you need to discriminate between them.
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.