Mapping Treuzell to Metavision HAL model

The base purpose of a Metavision plugin is to provide access to cameras through HAL. The Prophesee plugin implements the host side of Treuzell protocol, to be able to discuss with Treuzell boards. It is then necessary to map the Treuzell abstraction model to the Metavision one.

In HAL, a camera is one device, on which facilities are fetched to get access to implemented features. To make a Treuzell board fit in a HAL device representation, this means it is necessary to:

• expose Treuzell devices features as HAL facilities

• encapsulate the control of the full Treuzell pipeline in some facilities behaving as expected by HAL

Treuzell device-wide facilities

A TzDevice, and any derived class, implements a spawn_facilities method. That way, each device can map its features on HAL interface.

The standard TzDeviceBuilder builds the TzDevice (or child classes) and then calls spawn_facilities, thus the object exists when the facility is created, so the facility can reference the object, and keep it alive as long as something in HAL needs it.

Note

If this Treuzell implementation was to be used with another abstraction model than Metavision plugin ones, all it would require is to add in Treuzell devices a method to expose features to this model, and overload TzDeviceBuilder::build_devices to call a different spawn method when called with something other than a Metavision::DeviceBuilder.

Warning

Device implementors should carefully consider what features are exposed to Metavision plugin. For instance, in Metavision there is a DeviceControl class, that any Treuzell device can implement. However, at Metavision level, this class is expected to control the whole camera, and to be unique. Providing several would make that only one is used, and it would only control one Treuzell device. At device level, only facilities fully handling their feature for the whole camera should be created.

Treuzell board-wide facilities

In Metavision HAL, a camera is a single device. Consequently, there is a single entry-point for some operations involving several Treuzell devices. To handle this, after the build of all Treuzell devices, the TzDeviceBuilder creates the facilities managing the whole board.

For instance, the first operation involving the whole board is to start and stop streaming data. With Treuzell implementation, this is emulated by the TzDeviceControl object. It addresses every device to execute start/stop sequences in the right order with a single command at HAL level.

Other operations at camera level include synchronization with other cameras. The issue is that many Treuzell devices may synchronize with other devices (usually, sensors and FPGAs). As stated in the previous section, registering facilities to do so on each capable device would only cause trouble. To arrange this, some traits are added to capable devices, using multiple inheritance, for instance with TzMainDevice. Then, using rtti (run-time type identification), facilities such as TzCameraSynchronization or TzMonitoring may choose one to expose. As the plugins do not actually know the boards (we build one plugin for each board, but the code is the same in every plugin), it usually relies on a heuristic, such as the external synchronization being handled by the first capable device in the pipeline (the nearest from the communication interface). At some point it may become hard to find a heuristic working with every board, and it may become necessary to implement a way to advertise the actual implementation from the board, instead of guessing on host side.

The following diagram shows a device opening:

This next diagram helps understanding the relationship between the various technical components of the HAL and the plugin code with the example of a Prophesee EVK4 IMX636 camera.