The Kopernic team proposes KDBench as measurement-based WCET estimation benchmarks.
How it works
The framework is based on an original Pixhawk (this model) flight management unit (FMUv2) running a modified PX4 autopilot called PX4-rt. The original PX4 flight stack is orchestrated by sensor drivers, which are the only modules whose periods are imposed by a timer, every module is synchronized with other modules by waiting for data these modules produce (diagram). Every module waiting for the availability of data may have a period which varies in great proportions, which makes it impossible to guarantee that a module is sporadic or periodic.
PX4-rt makes sure that each module part of the control loop runs at a user-defined period and priority. This is achieved by leveraging the micro-controller’s high resolution timer (HRT).
To extract activation traces (from HRT) and the execution traces (from the scheduler), the Pixhawk FMU performs a flight in HITL mode (e.g. hardware in the loop) where sensors’ data are provided by and actuators’ data from Gazebo, a robotics simulator.
How to get PX4-RT
The version of PX4-rt presented at RTAS2022 can be obtained by applying this patch to the original PX4 (tag v1.12.1) and compiling target mc-rt-inria.
Alternatively, a precompiled image is available here.
Settings requirements
On the SD card, /etc/config.txt need include the following:
set LOGGER_BUF 32
set LOGGER_ARGS -r 4000
and also /etc/logging/logger_topics.txt need include the following:
activator
scheduler
How to use
RT-parameters can be modified through mavlink. They are listed under RT_*.
After a flight, the logs will contain an activation trace as well as a scheduler trace. Their CSVs are obtained as you normally would for other traces.
The format for the activation traces is as follows:
- Field one is the timestamp (u64)
- Field two (u8) contains two pieces of information. Its most significant bit is a flag: it is set to 1 when a deadline violation occurs.
The last 4 least significant bits (field & 0xF) - are the task id. Task ids are described further below.
The format for the scheduler traces is as follows:
- Field one is the timestamp (u64)
- Field two is the execution time (u16)
- Field three (u8) has two pieces of information: the task id (
field & 0xF) and the reason (field >> 4) the execution was ended. When reason equals 2, it means the task was preempted. When reason equals 4, it means the task blocked because of some I/O. All other values mean the task had no more work to do.
Task ids are defined as follows:
- 0: sensors
- 1: rate control
- 2: ekf
- 3: attitude control
- 4: position control
- 5: hover thrust estimator
- 6: flight manager
- 7: commander
- 8: navigator
Example
Below is an example of application with the traces collected using our framework. For each control module (ordered vertically with higher priorities to the top):
- a green bar depicts an execution
- a white bar depicts a preemption
- a solid green line depicts inactivity
- a solid white line depicts a suspension due to I/O accesses
- a blue arrow depicts an activation
- a red arrow depicts a deadline violation
Citation
If you use KDBench benchmarks, please cite our following publication:
@inproceedings{mwek-bp-rtas22,
title={Work in Progress: KDBench – towards open source benchmarks for measurement-based multicore WCET estimators},
author={Wehaiba El Khazen, Marwan and Zagalo, Kevin and Clarke, Hadrien and Mezouak, Mehdi and Abdeddaim, Yasmina and Bar-Hen, Avner, and Ben Amor, Slim and Bennour, Rihab and Gogonel, Adriana and Kougblenou, K. and Sorel, Y and Cucu-Grosjean, L.},
booktitle={the 28th IEEE Real-Time and Embedded Technology and Applications Symposium {RTAS}},
year={2022},
}
