Simsensors

Simsensors (simulated sensors) are a set of tools designed to facilitate the mocking of data from physical sensors during software development and testing. It provides a flexible and configurable environment to simulate sensor readings, allowing developers to mimic various sensor behaviours without relying on actual hardware.

The concrete implementation of the Simsensor publishes prepared measurement readings from a special file.

Supported sensors

Currently, all types of sensors supported by Sensorhub have their simulated type. The naming convention assumes the use of the _sim suffix, for example, baro_sim for the barometer.

File format

The concrete simulated sensor needs a special CSV file, which contains measurements saved in table structured format.

Columns

• The first column contains the ID of a sensor type, which corresponds to IDs from Sensorhub. The first column contains the ID of a sensor type, which corresponds to the IDs from Sensorhub. Furthermore, as described in the Timestamps logic section, the end scenario indicator can be used as a value of this field. All currently available values are listed below.

• The second column contains a timestamp of a particular measurement. The timestamp should be in milliseconds. It is important to note that it does not have to be a real-time timestamp. The precise meaning of a timestamp is described in the section Timestamps logic.

• In consecutive columns, measurement results are stored. Depending on a particular sensor type meaning of a particular column can be different. Below all the possibilities are described.

Accelerometer

1. Acceleration along $X$ axis [$mm/s^2$]
2. Acceleration along $Y$ axis [$mm/s^2$]
3. Acceleration along $Z$ axis [$mm/s^2$]

Barometer

1. Pressure in Pascals [$Pa$]
2. Temperature in Kelvins [$K$]

GPS

1. Altitude above MSL [$mm$]
2. Latitude in nanodegrees [$ndeg$]
3. Longitude in nanodegrees [$ndeg$]
4. GPS UTC time in microseconds [$us$]
5. Horizontal dilution of precision
6. Vertical dilution of precision
7. Altitude above Ellipsoid [$mm$]
8. GPS ground speed [$mm/s$]
9. GPS North velocity [$mm/s$]
10. GPS East velocity [$mm/s$]
11. GPS Down velocity [$mm/s$]
12. GPS horizontal position accuracy [$mm$]
13. GPS vertical position accuracy [$mm$]
14. GPS velocity accuracy [$mm$]
15. Heading [$mrad$]
16. Heading offset [$mrad$]
17. Heading accuracy [$mrad$]
18. Number of used satellites
19. Fix quality

Gyroscope

1. Angular velocity value along $X$ axis [$mrad/s$]
2. Angular velocity value along $Y$ axis [$mrad/s$]
3. Angular velocity value along $Z$ axis [$mrad/s$]
4. Delta angle in [$urad$] since driver start along X axis
5. Delta angle in [$urad$] since driver start along Y axis
6. Delta angle in [$urad$] since driver start along Z axis

Magnetometer

1. Value along X axis in 1E-7 [$T$]
2. Value along Y axis in 1E-7 [$T$]
3. Value along Z axis in 1E-7 [$T$]

Thermometer

1. Temperature value in Kelvin [K]

Header row

The first row can be a header, which describes the meaning of particular columns. Structure of a header is shown below.

SensorID,Timestamp,Fld1,Fld2, ...

First two columns - SensorID and Timestamp are mandatory. The rest of header columns are optional. Value of these fields is not specified.

Timestamps logic

Timestamps from file represents the time delays between subsequent measurements. Precise algorithm:

1. Read first measurement and publish it with current time,
2. Read next measurement and calculate offset between actual and previous timestamp from file,
3. Wait for offset milliseconds,
4. Publish measurement with timestamp equal to previously published timestamp plus offset.

It is undefined behavior, when previous timestamp is bigger than the current one. In file, they should be sorted in not descending order.

Ending and looping scenario

By default, when simsonsor encounter last measurement in a file, then it goes to the beginning of the file and repeats reading all measurements. Timestamps monotonicity is preserved. Time span between the last reading and the first one from file is considered to be equal to 0. In practice the time between publishes is as small as possible.

It is also possible to end the scenario. For this purpose special end scenario indicator - 0 should be placed in first column (as described in this section). Simsensor doesn't publish any new events after this symbol.

File example

SensorID,Timestamp,Field1,Field2,Field3
1,2282607175,748,-419,-9780,0
8,2282607175,-2,-64,0,0
1,2282610344,740,-484,-9776,0
8,2282610344,-6,-71,-2,0
1,2282612689,740,-484,-9776,0
8,2282612689,-6,-73,-3,0
1,2282614538,742,-510,-9788,0
8,2282614538,-1,-68,-2,0
1,2282617192,723,-517,-9783,0

Usage

Running selected Simsensor is analogical to start collecting data from a physical device. There is only one required argument: the path to a file containing the measurement scenario to be used. Command to start sensor should look file this:

./sbin/sensors -s <sensor_type>_sim:<scenario_file_path>

From perspective of data consumer, nothing changes.

Starting simsensor

Assume that mocking barometer data is needed and path to file with data to be published is ./etc/mock_measurements.csv. Then the command to start looks like this:

./sbin/sensors -s baro_sim:./etc/mock_measurements.csv