libaditof Documentation

Table of Contents

• License
• Architecture
  • Top Level Diagram
  • Class Diagram
  • Sequence Diagrams
    • Initialization Sequence
    • Acquire Frame Sequence
• API
  • FrameHandler

License

ToF SDK is licensed under the MIT License.

Architecture

The ToF SDK consist of two layers.

A high level API allows clients to easily grab a camera object, configure it and request frames. There are three main interfaces to accomplish this. The System object is responsible for detecting cameras that are connected and for the construction and owning of Camera objects. The Camera object is associated to the physical camera and makes possible the communication with the hardware. Frames can be retrieved from the Camera by using the Frame object which behaves as a data container and also holds information about the data it contains such as frame resolution.

The other layer is the low level API which exposes the DepthSensorInterface, StorageInterface and TemperatureSensorInterface through which low level operations can be made to the camera hardware. For example one can read or write the internal registers of the hardware or read it's internal temperature.

Top Level Diagram

A top level overview of the ToF SDK consisting of the high level API and low level API:

ToF SDK Top Level Diagram

Class Diagram

The class diagram add more details on top of what the top level diagram describes.

The System, Camera and Frame use the pimpl (pointer to implementation) idiom which provides some advantages such as helping achieve binary compatibility. The DepthSensorInterface, StorageInterface, TemperatureSensorInterface and SensorEnumeratorInterface mark the invisible line between high level and low level API. The DepthSensorInterface, StorageInterface and TemperatureSensorInterface abstract over the connection type made with the hardware thus keeping the implementation specifics hidden from the client code (high level layer or external client code). The responsibility of the SensorEnumeratorInterface is to detect any hardware that is compatible with ToF SDK.

ToF SDK Class Diagram

Sequence Diagrams

The sequence diagrams show the order in which calls need to be made to achieve a result and how the calls are propagated throughout the entire SDK.

Initialization Sequence

The initialization sequence shows what needs to be done in order to initialize System and Camera before doing any other operation on them.

ToF SDK Initialization Sequence Diagram

Acquire Frame Sequence

The acquire frame sequence shows how a frame is obtained and how the calls propagate down the stack towards the hardware.

ToF SDK Acquire Frame Sequence Diagram

API

The below code snipped shows an example of how the ToF SDK can be used to get a frame from one camera.

#include "aditof/aditof.h"
 
 
aditof::System system;
aditof::Status status;
std::vector<aditof::Camera *> cameras;
 
// Get the cameras
status = system.getCameraList(cameras);
 
// Initialize first TOF camera
aditof::Camera *camera1 = cameras.front();
status = camera1->initialize();
 
// Choose the frame type the camera should produce
std::vector<std::uint8_t> modeDetails;
camera1->getAvailableModeDetails(modeDetails);
status = camera1->setMode(modeDetails.front());
 
// Create a TOF frame and request data from the TOF camera
aditof::Frame frame;
 
status = camera1->start();
status = camera1->requestFrame(&frame);
status = camera1->stop();
 
uint16_t *frameData;
status = frame.getData("depth", &frameData);

FrameHandler

The role of the FrameHandler is provide the means to save the content of a Frame object to a file and to readback content from a file and construct a Frame object based on that content.

The following diagram shows how the content of a frame is organized within the saved file.

Saved Frame Content Map