|
|
|
The `SensorManager` component manages all the sensors connected to the board.
|
|
|
|
Periodically, sensors are sampled and their corresponding callback is called, so that further operations can be performed on the retrieved data.
|
|
|
|
|
|
|
|
|
|
|
|
## Component Structure
|
|
|
|
|
|
|
|
TODO
|
|
|
|
|
|
|
|
## Sensor
|
|
|
|
|
|
|
|
The `Sensor.h` header file contains the base classes that every new sensor in the system must inherit from it.
|
|
|
|
|
|
|
|
`Sensor` is the top-level virtual class.
|
|
|
|
|
|
|
|
Each `Sensor` object has to override some methods:
|
|
|
|
* `init()`: this is the first method to be called before using the sensor. It set
|
|
|
|
* `onSimpleUpdate()`: this method is called every time the sensor has to be sampled. Data read from the sensor is stored in local variables or structures. Override this method if you directly want to read data from the sensor.
|
|
|
|
* `onDMAUpdate()`: this method is called every time the sensor has to be sampled using DMA. Data read from DMA is stored in local variables or structures. Override this method if the communication with the sensor is performed through DMA.
|
|
|
|
* `selfTest()`: check if the sensor is correctly working.
|
|
|
|
All these methods return a boolean value indicating whether the operation succeded or not.
|
|
|
|
|
|
|
|
The `getLastError()` method can be useful to get the last error generated by the sensor driver.
|
|
|
|
|
|
|
|
Subclasses are provided for different types of sensors, e.g. `GyroSensor`, `AccelSensor`, `PressureSensor` and some others.
|
|
|
|
Since these classes are a bit limited, you can always directly extend `Sensor`, defining your own data structures to store data sampled from the sensor and methods to read them.
|
|
|
|
|
|
|
|
## Sensor Sampler
|
|
|
|
|
|
|
|
Sensors are grouped by type (simple or DMA) and the required sampling frequency.
|
|
|
|
|
|
|
|
A `SensorSampler` is characterized by a type (SIMPLE_SAMPLER or DMA_SAMPLER), the sampling frequency and a set of sensors.
|
|
|
|
|
|
|
|
In particular, the `SensorSampler` class maintains a `map<Sensor*, function<void()>>` that maps each sensor to its corresponding callback function.
|
|
|
|
Every time the `sampleAndCallback()` method of the `SensorSampler` is called, the sampler cycles through all its sensors, samples them and calls their corresponding callback, where these samples can be processed and dispatched.
|
|
|
|
|
|
|
|
## Sensor Manager
|
|
|
|
In order to add a sensor to the `SensorManager`, the `addSensor()` method is provided: simply pass it the sensor, the callback function and the sampler type (it has default value equal to SIMPLE_SAMPLER).
|
|
|
|
|
|
|
|
Every time a sensor is added, the `SensorManager` assigns it to a `SensorSampler`, according to the required sampling frequency and the sampling type, that can be either SIMPLE or DMA.
|
|
|
|
If a `SensorSampler` for that frequency and type doesn't exist, the `SensorManager` manages its creation.
|
|
|
|
|
|
|
|
Note that when a sensor is added, it is also initialized and its `selftest()` method is called. The sensor will be added only if both those functions return `true`.
|
|
|
|
|
|
|
|
When `start()` is called, the `SensorManager` initializes the `TaskScheduler`: for each `SensorSampler`, it adds to the scheduler the `sampleAndCallback()` method to be called periodically according to the sampler's frequency.
|
|
|
|
|
|
|
|
## Example
|
|
|
|
|
|
|
|
TODO |
|
|
|
\ No newline at end of file |