Sensorhub simulation idea

[niewim19]

Sensorhub sim-sensor

Testing of Phoenix-PIlot software stack is currently limited only to testing on hardware as there is no way to get sensor data without physical sensors. This issue present and idea of simulated sensors in sensorhub (later called simsensor) so that it will be possible to run and test EKF repetitively on test data.

Idea consist of implementing a simulated sensor for each sensor type with possibility of feeding it a file with time-series of data to output. The scenario file format will be designed so that file interpreters may be generalized as much as possible (with goal have as little file interpreter in each simulated sensor as possible).

Requirements

1. Simsensor is a sensor implementation that mimics the behavior of specific sensor.
2. Each sensortype in sensorhub shall have its own simsensor implementation.
3. Simsensor shall not require any specific hardware setup.
4. Each simsensor shall accept a local scenario file

Requirements decomposition

1) Simsensor is a sensor implementation that mimics the behavior of specific sensor.

1. Simsensor shall be implemented as if it was a real sensor implementation
2. Simsensor shall produce output as if it was a real sensor of specific type
3. Simsensor shall utilize the typical way of sensorhub sensor implementation:
   • setup procedure
   • separate thread for data generation
4. By default simsensor shall generate time-invariant, physically valid data as if sensor is not disturbed
5. Default simsensor data shall be predetermined in sensorhub code.
6. Default simsensor data shall be determined as correct operational values.
7. If possible simsensor shall mark that data it outputs is simulated data (e.g in gps output data)

2) Each sensortype in sensorhub shall have its own simsensor implementation.

1. Each supported sensortype shall have an option to run it as a simsensor
2. Simsensor selection shall be selectable on sensorhub argument list using -s argument as if it was a normal sensor
3. Simsensor name shall be construed as <sensortype>_sim, for example imu_sim, baro_sim etc.
4. Simsensor may accept parameters as in the case of normal sensors

3) Simsensor shall not require any specific hardware setup.

1. Simsensor implementation shall not impose any sensor-specific hardware implementations (bus access etc.)
2. SImsensor shall be self-contained which means that it shall not be dependent on data generated in runtime by an external application

4) Each simsensor shall accept a local scenario file that overrides the global one

1. It shall be possible to specify the scenario file for a given sensor as a parameter to a sensor
2. All data that is directly measured by sensor shall be published as is.
3. All data that is indirectly measured (summed, precalculated based on measurement) shall be precalculated based (e.g gyroscope integration done in sensor).
4. If the scenario file is exhausted the simsensor shall loop back to the beginning and start the scenario again as if the simsensor was just initialized but with the exemption on sensordata that is generated indirectly.
5. Scenario file shall be follow a csv file convention
6. First row of scenario file shall have column names
7. Scenario line may follow the following convention: timestamp,smooth?,fld1,fld2,...
8. The reading logic shall be generalized between simsensors (have common implementation)
9. The reading logic may utilize a fifo queue to store elements read from scenario file

---

[niewim19]

Implementation approach

Common reader logic

1. reader_open(reader_t rd, const char *path, read_queue_t *queue, int sensorTypes, time_t timeout))
2. read_close(reader_t rd)
3. reader_fill(reader_t rd, queue_t queue)

If read sensor flag if equal to 0, then add stopEvent to queue.

Sensor logic

START:

1. get element from queue
2. if timestamp is ahead, wait for timestamp and publish and loop to START
3. if imestamp is back, publish and loop to START
4. if queue empty wait 3/4 timeout and loop to START
5. if event is stopEvent then EXIT

EXIT

Queue implementation

1. uses table of fixed size of sensor_event_t
2. holds max capacity and head/tail position in table
3. traverses table forward during push/pop operations and treats table as circular buffer

[PNieck]

Scenario file format

sensor	timestamp	fld1	fld2	...
1	1000

sensor - sensor flag taken from libsensor implementation
timestamp - relative timestamp of the sensor event in microseconds
fldx - measurement value