# Drone Autopilot PX4 and PX4-RT HitL Simulations
User Manual

Masum Bin Alam, Yves Sorel

► To cite this version:

Masum Bin Alam, Yves Sorel. Drone Autopilot PX4 and PX4-RT HitL Simula-
tions User Manual. INRIA. 2025, https://gitlab.inria.fr/kdbench/multicore/documents/-
/blob/main/userManual/userManual.pdf?ref_type=heads. hal-05489396

HAL Id: hal-05489396

https://hal.science/hal-05489396v1

Submitted on 3 Feb 2026

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# PX4 and PX4-RT
HitL simulations User Manual

Masum Bin ALAM
Yves SOREL

INRIA Paris, Research Team KOPERNIC

## Contents

<table><tr><td>1</td><td>Introduction</td><td>4</td></tr><tr><td>2</td><td>Terminal Prompt Aliases and Command-Line Formatting</td><td>4</td></tr><tr><td>2.1</td><td>Terminal Prompt Aliases</td><td>4</td></tr><tr><td>2.2</td><td>Command-Line Formatting</td><td>4</td></tr><tr><td>3</td><td>Downloading GIT repositories</td><td>5</td></tr><tr><td>3.1</td><td>PX4 Repositories for Xenomai (to be cloned and built directly on Raspberry Pi)</td><td>5</td></tr><tr><td>3.2</td><td>PX4 Repositories for NPRT/PRT Linux (to be cloned and built on Ubuntu 18.04 Virtual Machine)</td><td>6</td></tr><tr><td>3.3</td><td>Bouif HitL Simulation Repository (to be cloned on main laptop)</td><td>6</td></tr><tr><td>4</td><td>Dual microSD Card Setup for Xenomai and NPRT/PRT Builds</td><td>7</td></tr><tr><td>4.1</td><td>Xenomai SD Card (Model: Kingston - 16 GB)</td><td>7</td></tr><tr><td>4.1.1</td><td>SD Card Contents</td><td>7</td></tr><tr><td>4.1.2</td><td>Identifying the Current Runtime System - Xenomai</td><td>7</td></tr><tr><td>4.2</td><td>NPRT/PRT SD Card (Model: MICTG - 16 GB)</td><td>7</td></tr><tr><td>4.2.1</td><td>SD Card Contents</td><td>7</td></tr><tr><td>4.2.2</td><td>Identifying the Current Runtime System - NPRT/PRT</td><td>8</td></tr><tr><td>4.3</td><td>Making backup of the SD cards</td><td>8</td></tr><tr><td>5</td><td>Transferring Already Built PX4 to Raspberry Pi</td><td>9</td></tr><tr><td>5.1</td><td>Copying PX4 Built for Xenomai</td><td>9</td></tr><tr><td>5.2</td><td>Copying PX4 Built for NPRT-PRT</td><td>9</td></tr><tr><td>6</td><td>Common Setup for All Simulations</td><td>10</td></tr><tr><td>6.1</td><td>Prerequisites and Environment Setup</td><td>10</td></tr><tr><td>6.2</td><td>Choosing the Flight Plan</td><td>14</td></tr></table>
# 7 Downloading, Building and Running PX4-RT on Xenomai

<table><tr><td>7.1</td><td>PX4-RT HitL Simulation on Xenomai (Singlecore)</td><td>16</td></tr><tr><td>7.1.1</td><td>Increase ftrace buffer size</td><td>16</td></tr><tr><td>7.1.2</td><td>Run PX4-RT on Xenomai</td><td>16</td></tr><tr><td>7.1.3</td><td>Assign All Control Tasks to a Specific Core</td><td>17</td></tr><tr><td>7.1.4</td><td>Using corresponding Bouif simulation folder</td><td>18</td></tr><tr><td>7.1.5</td><td>Verifying run_rpi.sh Script Configuration before starting simulation</td><td>18</td></tr><tr><td>7.1.6</td><td>Running the Simulation Command</td><td>19</td></tr><tr><td>7.1.7</td><td>Data Processing</td><td>21</td></tr><tr><td>7.1.8</td><td>GTKWave Visualization</td><td>22</td></tr><tr><td>7.2</td><td>PX4-RT HitL Simulation on Xenomai (Multicore)</td><td>23</td></tr></table>

# 8 Downloading, Building and Running PX4-Standard on Xenomai

<table><tr><td>8.1</td><td>Downloading PX4-Standard on Xenomai</td><td>24</td></tr><tr><td>8.2</td><td>Building PX4-Standard on Xenomai</td><td>24</td></tr><tr><td>8.3</td><td>Run PX4-Standard HitL simulation on Xenomai</td><td>25</td></tr></table>

# 9 Switch Between NPRT and PRT on Raspberry Pi

<table><tr><td>9.1</td><td>Booting with the NPRT Kernel</td><td>27</td></tr><tr><td>9.2</td><td>Booting with the PREEMPT-RT Kernel (PRT)</td><td>28</td></tr><tr><td>9.3</td><td>Final Steps</td><td>29</td></tr><tr><td>9.4</td><td>Important Notes</td><td>29</td></tr></table>

# 10 Downloading, Building and Running PX4-RT on NPRT/PRT

<table><tr><td>10.1</td><td>Run PX4-RT HitL Simulation on NPRT/PRT (Singlecore)</td><td>36</td></tr><tr><td>10.2</td><td>Run PX4-RT HitL Simulation on NPRT/PRT (Multicore)</td><td>41</td></tr></table>

# 11 Downloading, Building and Running PX4-Standard on NPRT/PRT (Singlecore and Multicore)

<table><tr><td>11.1</td><td>PX4-Standard HitL Simulation on NPRT/PRT</td><td>42</td></tr><tr><td>11.2</td><td>Difference in jMAVSim Launch for PX4-Standard</td><td>43</td></tr></table>

# 12 Troubleshooting

<table><tr><td>12.1</td><td>Restart Raspberry Pi After Each Simulation</td><td>49</td></tr><tr><td>12.2</td><td>Dropped SSH</td><td>49</td></tr><tr><td>12.3</td><td>WARN - Failsafe Enabled: No Manual Control Stick Input</td><td>49</td></tr><tr><td>12.4</td><td>Failsafe due to No Datalink (Drone Won't Fly)</td><td>50</td></tr><tr><td>12.5</td><td>Importance of px4_hil.config File</td><td>51</td></tr></table>

# 13 Data Analysis

<table><tr><td>13.1</td><td>Reference Reports Used for Data Analysis</td><td>54</td></tr><tr><td>13.2</td><td>Raw Data Location</td><td>54</td></tr><tr><td>13.3</td><td>Post Processed results</td><td>54</td></tr><tr><td>13.4</td><td>Test Coverage and Metrics</td><td>55</td></tr></table>

# 14 Latency Test

<table><tr><td>14.1</td><td>Latency Test on standard Linux (NPRT)</td><td>56</td></tr><tr><td>14.2</td><td>Latency Test on PREEMPT-RT Kernel (PRT)</td><td>56</td></tr><tr><td>14.3</td><td>Latency Test on Xenomai (Cobalt)</td><td>56</td></tr></table>
<table><tr><td>14.4 Installation Note</td><td>56</td></tr><tr><td>14.5 Location of Latency Test Results</td><td>56</td></tr><tr><td>14.6 References and Documentation</td><td>57</td></tr></table>
# 1 Introduction

This document serves as a technical user manual and onboarding reference for users performing PX4 and PX4-RT HitL simulations.

Afterward, the standard version of PX4 is called "PX4-Standard" whereas "PX4-RT" is a real-time oriented version of PX4-Standard achieved by the KOPERNIC Inria research team. Experiments performed in this document, use PX4 version 1.12.1 and the PX4-RT is based on version 1.12.1.

These PX4 and PX4-RT HitL simulations are executed on the RPI/Navio2 board including an ARM Cortex-A53 quadcore with three different operating systems: plain Linux with no patch (NPRT), Linux with the PREEMPT-RT (PRT) patch and Linux with the Xenomai-3 patch.

# 2 Terminal Prompt Aliases and Command-Line Formatting

## 2.1 Terminal Prompt Aliases

To simplify and standardize terminal commands throughout this document, we define the following prompt aliases:

* `P` → `pi@raspberrypi:~`

* `L` → `malam@pl1135-pro:~`

* `V` → `masum@masum-VirtualBox:~`

Whenever a command is shown prefixed with one of these aliases (e.g., `P$`, `L$`, `V$`), it should be interpreted as being executed in the respective environment.

## 2.2 Command-Line Formatting

Long single-line commands have been intentionally split across multiple lines using the backslash (`\`). This ensures that the commands remain executable when copied directly from the PDF and pasted into a terminal.

Note: Take this into consideration when copying/pasting such commands from the pdf.
# 3 Downloading GIT repositories

This project requires five Git repositories:

* px4-standard-xenomai;

* px4-rt-xenomai;

* px4-standard-linux_NPRT_and_PRT;

* px4-rt-linux_NPRT_and_PRT;

* bouif_for_NPRT_PRT_Xenomai.

Each of which should be cloned and used in specific environments. Below is a detailed guide, including commands, folder structure, and renaming conventions.

## 3.1 PX4 Repositories for Xenomai (to be cloned and built directly on Raspberry Pi)

These repositories are required to run PX4 with Xenomai real-time support. Clone them on the Raspberry Pi itself inside the `~/drone_project` folder. Each Raspberry Pi SD card should contain one PX4-RT and one PX4-Standard build. After cloning, rename the folders for consistency.

1. On Raspberry Pi - Xenomai SD Card

2. `P~$ cd ~/drone_project`

3. `# Clone PX4-RT with Xenomai support`

4. `P~/drone_project$ git clone https://gitlab.inria.fr/kdbench\ /multicore/px4-rt_and PX4-Standard-Xenomai.git`

5. `# Rename px4-rt-xenomai to px4-rt`

6. `P~/drone_project$ mv px4-rt-xenomai px4-rt`

7. `# Clone PX4-Standard with Xenomai support`

8. `P~/drone_project$ git clone https://gitlab.inria.fr/kdbench\ /multicore/px4-rt_and px4-standard/PX4-Standard-Xenomai.git`

9. `# Rename px4-standard-xenomai to px4-standard`

10. `P~/drone_project$ mv px4-standard-xenomai px4-standard`

**Important Note:** For the Xenomai version PX4-RT and PX4-Standard must be built directly on the Raspberry Pi to ensure proper linkage and real-time thread registration. Building it on a PC and copying over will not work.
## 3.2 PX4 Repositories for NPRT/PRT Linux (to be cloned and built on Ubuntu 18.04 Virtual Machine)

These versions are meant for running PX4-RT and PX4-Standard with standard Linux (NPRT) or with PREEMPT-RT patch (PRT). They must be built on Ubuntu 18.04 (in a VirtualBox VM), since later versions (20, 22, 24) cause runtime issues on the Raspberry Pi. After building, transfer the binaries to the Raspberry Pi over Ethernet.

<figure><img src="image_2.png" /></figure>

**After building:** Transfer the built firmware and binaries to the Raspberry Pi via Ethernet for testing and execution.

## 3.3 Bouif HitL Simulation Repository (to be cloned on main laptop)

The Bouif git projects are used to run HitL simulations against all PX4 variants (Xenomai, NPRT, PRT). Clone it on your host machine (no VM required).

<figure><img src="image_3.png" /></figure>

You can then run test scenarios and log comparisons against the Raspberry Pi using this repository.

*Note: The same folder names (`px4-rt` and `px4-standard`) are reused on each SD card, since they are used independently.*
# 4 Dual microSD Card Setup for Xenomai and NPRT/PRT Builds

To manage and test the different PX4 runtime environments independently, two separate microSD cards are used with the Raspberry Pi.

Both SD cards use the default and password:

* Username: pi

* Password: raspberry

## 4.1 Xenomai SD Card (Model: Kingston - 16 GB)

### 4.1.1 SD Card Contents

* Contains px4-rt cloned and built from px4-rt-xenomai.git

* Contains px4-standard cloned and built from px4-standard-xenomai.git

* PX4 must be built directly on the Raspberry Pi for this card

### 4.1.2 Identifying the Current Runtime System - Xenomai

To determine whether the Raspberry Pi is running Xenomai, use the following command:

```
P $ dmesg | grep -i xenomai
```

<figure><img src="image_4.png" /><figcaption>Figure 1: Identifying the Current Runtime System - Xenomai</figcaption></figure>

## 4.2 NPRT/PRT SD Card (Model: MICTG - 16 GB)

### 4.2.1 SD Card Contents

* Contains px4-rt cloned and built from px4-rt-linux_NPRT_and_PRT.git

* Contains px4-standard cloned and built from px4-standard-linux_NPRT_and_PRT.git

* PX4 must be built on an Ubuntu 18.04 Virtual Machine and then transferred to the Pi

**Important Note:** When using these SD cards the user should connect it with a keyboard and monitor to verify that the raspberry pi is booting correctly.
### 4.2.2 Identifying the Current Runtime System - NPRT/PRT

To determine whether the Raspberry Pi is running standard Linux with no patch (NPRT) or with PREEMPT-RT patch (PRT), use the following command:

1

P $ uname -a

```
pi@navio:~$ uname -a
Linux navio 5.10.11-emlid-v7+ #1 SMP PREEMPT Wed Apr 28 11:50:41 MSK 2021 armv7l GNU/Linux
pi@navio:~$ 
```

<caption>Figure 2: Identifying the Current Runtime System - NPRT</caption>

```
pi@navio:~$ uname -a
Linux navio 5.10.11-emlid-v7+ #3 SMP PREEMPT_RT Thu Oct 24 16:37:34 CEST 2024 armv7l GNU/Linux
pi@navio:~$ 
```

<caption>Figure 3: Identifying the Current Runtime System - PRT</caption>

Using this dual-card approach allows the user to physically switch between the Xenomai and NPRT/PRT environments by simply swapping SD cards, ensuring clean separation between builds, toolchains, and runtime dependencies.

**Important Note:** The folder naming convention (`px4-rt`, `px4-standard`) remains the same on both cards for consistency, but the contents differ based on the build environment.

## 4.3 Making backup of the SD cards

The Xenomai and PREEMPT-RT patches have already been applied to their respective microSD cards, so the user does not need to perform any additional setup steps.

However, it is strongly recommended to create a full `.img` backup of both memory cards to prevent data loss in case of corruption. This can be done using the following commands (executed on a Linux host system):

1

```
# Identify your SD card device (e.g., /dev/sdX) using 'lsblk' or 'dmesg'
L$ lsblk
```

2

3

```
# Backup the SD card to an image file
L$ sudo dd if=/dev/sdX of=~/xenomai_sd_backup.img bs=4M status=progress
```

4

5

```
# Restore the image back to an SD card if needed
L$ sudo dd if=~/xenomai_sd_backup.img of=/dev/sdX bs=4M status=progress
```

6
# 5 Transferring Already Built PX4 to Raspberry Pi

In order to save time building the px4 the user can transfer the PX4 firmware which is already built on the development machine, the full `drone_project` folder can be transferred to the Raspberry Pi using `rsync`.

The following commands are to be executed from the local machine (in the directory `/drone_project/alreadyBuiltPX4/`), and they copy the full `drone_project` folder to the home directory of the Raspberry Pi via SSH. Ensure that the Raspberry Pi is connected to the same network and has SSH enabled.

## 5.1 Copying PX4 Built for Xenomai

```
L$ rsync -avh --progress ~/drone_project/alreadyBuiltPX4/\ Xenomai/drone_project pi@128.93.67.250:~/
```

## 5.2 Copying PX4 Built for NPRT-PRT

```
L$ rsync -avh --progress ~/drone_project/alreadyBuiltPX4/\ NPRT-PRT/drone_project pi@128.93.67.248:~/
```

**Note:** Replace the IP address if the IP address of the target device changes. The `-a` flag in `rsync` ensures that symbolic links are preserved and not dereferenced (i.e., the files pointed to by the links are not duplicated). The `-v` and `-h` options provide readable progress output.

If you follow this section then you can go directly to running the simulation at each section. Following this section allows you to skip subsections 3.1 and 3.2 which describes the process of cloning and building px4 on target machines.
# 6 Common Setup for All Simulations

## 6.1 Prerequisites and Environment Setup

This section outlines the initial setup steps required before running any HitL simulation.

**Important Note:** If you encounter any errors during the processes described in this document, please refer to the section 12 called **Troubleshooting**.

1. Connect the Raspberry Pi to the laptop using an Ethernet cable.

2. Open a terminal on the laptop and run the following command to discover the name of the Ethernet interface:

```
L$ ifconfig
```

```
enxe04e7a975456: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::3d29:2e83:4b3:7bbb prefixlen 64 scopeid 0x20<link>
ether e0:4e:7a:97:54:56 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
```

<caption>Figure 4: Ethernet interface shown before IP assignment</caption>

3. Assign a static IP address to your laptop so it can communicate with the Raspberry Pi on the same subnet:

```
L$ sudo ifconfig enxe04e7a975456 128.93.67.1 netmask 255.255.255.0 up
```

```
enxe04e7a975456: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 128.93.67.1 netmask 255.255.255.0 broadcast 128.93.67.255
ether e0:4e:7a:97:54:56 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
```

<caption>Figure 5: Ethernet interface shown after IP assignment</caption>

4. Type the following command to find the ip address of the raspberry pi:

```
L$ sudo arp-scan --localnet -I enxe04e7a975456
```
<figure><img src="image_5.png" /><figcaption>Figure 6: Find raspberry pi IP address</figcaption></figure>

5. Open another terminal and SSH into the Raspberry Pi:

<figure><img src="image_6.png" /></figure>

Type the password **raspberry** when prompted. However, it is recommended to configure SSH key-based authentication to avoid entering your password each time.

(a) On your laptop, generate an SSH key if you don't already have one:

<figure><img src="image_7.png" /></figure>

(b) Copy your public key to the Raspberry Pi:

<figure><img src="image_8.png" /></figure>

(c) Now you can log in without a password:

<figure><img src="image_9.png" /></figure>

6. To allow UDP communication between **jmavsim** (running on the laptop) and PX4 (running on the Raspberry Pi), run the following command on the laptop:

<figure><img src="image_10.png" /></figure>

**Note:** This command must be re-executed every time the laptop is restarted, as the iptables rules are not persistent by default. Without it, UDP packets from the Raspberry Pi may be blocked, and the HitL simulation will fail to establish MAVLink communication.

7. Clone the Bouif Simulation Repository

Onto the laptop clone the HitL simulation environment from INRIA's GitLab:

<figure><img src="image_11.png" /></figure>

<figure><img src="image_12.png" /><figcaption>Figure 7: Clone bouif projects from Gitlab</figcaption></figure>
The repository will be cloned into a new folder named `bouif_for_nprt_prt_xenomai` inside your current directory. The cloned `bouif_for_nprt_prt_xenomai` folder contains multiple Bouif simulation setups. From this folder, you will use different Bouif projects as needed depending on the kernel and PX4 configuration.

This cloned folder also contains the **PX4-StandardReference** folder. In which there are the modified `jmavsim_run_HITL.sh` and `jmavsim_run_HITL_mavlink_communication.sh` scripts and are required to launch the MAVLink communication bridge for all HitL simulations.

**Important Note:** If the **PX4-StandardReference** folder included in the cloned GitLab project (`bouif_for_nprt_prt_xenomai`) fails to work properly, a backup copy is also available here:

1. `/referencePX4s/PX4-StandardReference`

This folder contains the same modified `jmavsim` scripts required for running HitL simulations.

8. `jmavsim` with MAVLink communication must be started from the **PX4-StandardReference** folder. After cloning the `bouif_for_nprt_prt_xenomai` project from GitLab, the folder will already include the **PX4-StandardReference** folder.

1. `L~$ cd ~/bouif_for_nprt_prt_xenomai/PX4-StandardReference`
2. `/Tools/simulation/jmavsim`

3. `L~/bouif_for_nprt_prt_xenomai/PX4-StandardReference/Tools/simulation/jmavsim$ ./jmavsim_run_HITL_mavlink_communication.sh`

<figure><img src="image_13.png" /><figcaption>Figure 8: Start `jmavsim`</figcaption></figure>
<figure><img src="image_14.png" /><figcaption>Figure 9: jmavsim interface at start</figcaption></figure>
## 6.2 Choosing the Flight Plan

To choose which flight plan to run, you must manually copy the desired plan file into the `flight_plans` folder and name it `default.plan`. This step is crucial for the simulation to work correctly.

There are three available flight plans:

* `line`

* `medium`

* `long`

Each plan is stored in its own subfolder under `flight_plans/plans/`.

To activate a specific flight plan (e.g., `line`), run on your laptop the following commands:

1

L$ cd ~/bouif_for_nprt_prt_xenomai

2

3

L/bouif_for_nprt_prt_xenomai$ cd bouif_for_PX4-RT_all Cores_xenomai\ /bouif/flight_plans/

4

5

6

L/bouif_for_nprt_prt_xenomai/bouif_for_PX4-RT_all Cores_xenomai/bouif/ flight_plans$ cp plans/line/default.plan .

After copying, your `flight_plans` directory must contain:

* The copied `default.plan` file

* The `plans/` folder

**Important:** Do not rename the file. The simulation expects the file to be named `default.plan`. Any other name will cause the simulation to fail.
# 7 Downloading, Building and Running PX4-RT on Xenomai

To build PX4-RT with Xenomai real-time support directly on the Raspberry Pi, follow the steps below. For consistency, clone the repository inside the `/drone_project` directory:

1. Clone the PX4-RT (Xenomai-enabled) repository from GitLab:

1. `P$ cd ~/drone_project`

2. `P/drone_project$ git clone https://gitlab.inria.fr/kdbench\`

3. `/multicore/px4-rt_and PX4-RT-Xenomai.git`

2. Clone the PX4-RT (Xenomai-enabled) repository from GitLab:

If your Raspberry Pi has working Wi-Fi or internet access, you can directly clone the repository on the Pi:

1. `P$ cd ~/drone_project`

2. `P/drone_project$ git clone https://gitlab.inria.fr/kdbench\`

3. `/multicore/px4-rt_and PX4-RT-Xenomai.git`

If your Raspberry Pi does not have internet access, clone the repository on your laptop and transfer it via USB or SSH:

**On your laptop:**

1. `$ cd ~/Downloads`

2. `$ git clone https://gitlab.inria.fr/kdbench\`

3. `/multicore/px4-rt_and PX4-RT-Xenomai.git`

**Transfer via SCP (network):** Make sure the Raspberry Pi is accessible over the network (via Ethernet or hotspot).

1. `# From your laptop:`

2. `$ scp -r px4-rt-xenomai pi@128.93.67.250:~/drone_project/`

3. Rename the cloned directory to `px4-rt`:

1. `P/drone_project$ mv px4-rt-xenomai px4-rt`

4. Enter the renamed folder:

1. `P/drone_project$ cd px4-rt`

5. Build PX4-RT for Xenomai using the `emlid_navio2_mc-rt-inria` target:

1. `P/drone_project/px4-rt$ make XENOMAI=1 emlid_navio2_mc-rt-inria -j$(nproc)`

This will compile the PX4-RT firmware with Xenomai support, tailored for the Navio2 board on Raspberry Pi.
# 7.1 PX4-RT HitL Simulation on Xenomai (Singlecore)

## 7.1.1 Increase ftrace buffer size

Before starting PX4, run the following command to increase the ftrace buffer size of CPU core 3 to 300 MB. This ensures that no trace logs are missed during logging:

1

```
P$ echo 300000 | sudo tee /sys/kernel/debug/tracing/per_cpu/cpu3/buffer_sizeキ
```

```
pi@raspberrypi:- $ echo 300000 | sudo tee /sys/kernel/debug/tracing/per_cpu/cpu3/buffer_sizeキ
300000
```

```
pi@raspberrypi:- $  
```

<caption>Figure 10: Increase ftrace buffer size</caption>

## 7.1.2 Run PX4-RT on Xenomai

To run PX4-RT on Xenomai use the following command on raspberry pi:

1

```
P/drone_project $ sudo env \
```

2

```
LD_LIBRARY_PATH=/usr/xenomai/lib \
```

3

```
LD_PRELOAD=/usr/xenomai/lib/libcobalt.so \
```

4

```
~/drone_project/px4-rt/build/emlidyszmc-rt-inria/bin/px4 \
```

5

```
-s ~/drone_project/px4-rt/posix-configs/rpi/px4_hil.config
```

<figure><img src="image_15.png" /><figcaption>Figure 11: Start of PX4-RT in Xenomai</figcaption></figure>
### 7.1.3 Assign All Control Tasks to a Specific Core

Open another terminal and log into the Raspberry Pi via SSH. To assign all the control-related PX4 threads (e.g., sensor processing, controllers, navigator, etc.) to a specific CPU core (e.g., core 3), run the following command on the Raspberry Pi:

```
1 P$ awk '$4=="cobalt" && $NF ~ /^(wq:sensors|commander|navigator\|ekf2|mc_hteCtrl|flight_mode_mgr|mc_posCtrl|mc_attCtrl\|mc_rateCtrl|wq:nav_andControllers)$/[{print $2}]' \
2 /proc/xenomai/sched/threads | xargs -r -n1 sudo taskset -p 0x8
3
4
```

This command uses `taskset -p 0x8` to assign each thread to CPU core **3** (core mask `0x8` corresponds to core index 3).

Then run the following command to verify that PX4-RT threads have been successfully converted to Xenomai-Cobalt real-time threads:

```
1 P $ sudo cat /proc/xenomai/sched/threads
```

<figure><img src="image_16.png" /><figcaption>Figure 12: Assigning all the control tasks to a specific core</figcaption></figure>
### 7.1.4 Using corresponding Bouif simulation folder

To start the simulation, you need to use the corresponding Bouif simulation folder. Navigate to the directory as shown below:

```
L$ cd ~/bouif_for_nprt_prt_xenomai/\n
2 bouif_for_PX4-RT_all Cores_xenomai/bouif
```

### 7.1.5 Verifying run_rpi.sh Script Configuration before starting simulation

The run_rpi.sh script plays a central role in executing PX4 HitL simulations across the network. It defines the IP address of the Raspberry Pi, controls the modules to be launched, and ensures that data is retrieved correctly after the simulation ends.

* **Correct Target IP Address:** The variable TARGET must always be set to the IP address of the Raspberry Pi you are currently using. Make sure this IP is reachable from the host machine where the script is being executed.

* **Correct Data Retrieval Path:** After the simulation, run_rpi.sh fetches the log and CSV trace files from the Raspberry Pi. It's important to ensure this path corresponds to where PX4 is actually writing the logs (typically under /tmp/).

<figure><img src="image_17.png" /><figcaption>Figure 13: Verify the target IP address ({$TARGET})</figcaption></figure>

<figure><img src="image_18.png" /><figcaption>Figure 14: Ensure scp retrieves data from the correct paths</figcaption></figure>
### 7.1.6 Running the Simulation Command

To start the simulation, run the following command in the laptop from within the appropriate Bouif project folder:

<figure><img src="image_19.png" /></figure>

This script configures and starts the HitL simulation with fixed intervals (8 ms for each task) and priorities for each PX4 thread. These periods and priorities can be adjusted by modifying the command.

<figure><img src="image_20.png" /><figcaption>Figure 15: HitL simulation command with variables</figcaption></figure>
<figure><img src="image_21.png" /><figcaption>Figure 16: Finishing of HitL simulation command script</figcaption></figure>

And the following is the raspberry pi log while the mission is running.

<figure><img src="image_22.png" /><figcaption>Figure 17: Raspberry pi log during mission</figcaption></figure>
### 7.1.7 Data Processing

After the simulation is complete, the output result files are automatically saved in the `outputs/` directory within the active Bouif folder. Each simulation run creates a times-tamped subfolder (e.g., `20250930-1416`) that contains the raw data:

* `blob.ulog` - Full PX4 log file (ULog format)

* `sched_switch.csv` - Kernel scheduling trace

* `sched_wakeup.csv` - Kernel wakeup trace

These trace files can be post-processed to generate VCD (Value Change Dump) waveform files for visual inspection using `GTKWave`. The waveform shows task activations, context switches, and wakeups over time.

For post-processing of the trace files, certain column names must be changed before running analysis scripts:

* In `sched_wakeup.csv`, change the column name `name` to `comm`.

* In `sched_switch.csv`, change the column names:

- `prev_name` to `prev_comm`

- `next_name` to `next_comm`

This step ensures compatibility with the post-processing scripts that expect these standardized column names.

1. There are 3 main python procession files:

* `merge_csv_files.py`

* `get_execution_n_response_time_PX4-RT_external.py`

* `external_n_ineternal_v2.py`

Before running the processing scripts, make sure to copy the following scripts from the following directory:

1. `~/postProcessingPythonScripts/HITLSimulationRawDataScripts/Xenomai/postProcessingScriptsForPX4-RT/`

Copy the following three Python scripts into the same folder where your output CSV files are located (e.g., `outputs/20250930-1416/`):

These scripts are required for post-processing the PX4 trace data and generating the final analysis outputs.

**Note:** The three necessary scripts may differ depending on the PX4 variant and kernel configuration you are using (e.g., PX4-RT vs. PX4-Standard). Select the scripts from the appropriate subdirectory under `/postProcessingPythonScripts/HITLSimulationRawDataScripts/` (e.g., `NPRT-PRT/postProcessingScriptsForPX4-Standard` for PX4-Standard, or `Xenomai/postProcessingScriptsForPX4-RT` for PX4-RT on Xenomai).
2. To process the raw data, use the following three scripts in sequence:

1 ulog2csv blob.ulog && \

2 python3 merge_csv_files.py &&

3 python3 get_execution_n_response_time_PX4-RT_external.py &&

4 python3 external_n_ineternal_v2.py

7.1.8 GTKWave Visualization

3. Open the generated VCD file with GTKWave:

1gtkwave combined.vcd

Note: You may need to install wave on your laptop using:

1 sudo apt install wave

<figure><img src="image_23.png" /><figcaption>Figure 18: GTKWave</figcaption></figure>

Use the visual output to verify timing, wakeups, priority inversion, and trace schedul-
ing anomalies.
## 7.2 PX4-RT HitL Simulation on Xenomai (Multicore)

Xenomai does not support automatic load balancing of real-time threads across CPU cores. Therefore, to perform multicore simulations, two manual steps are required:

* First, manually assign PX4 control tasks to your desired CPU core(s) using the following command. Modify the '0x8' mask to target the specific core.

```
P$ awk '$4=="cobalt" && $NF ~ /^ (wq:sensors|commander|navigator|ekf2| mc_hteCtrl|flight_mode_mgr|mc_posCtrl|mc_attCtrl|mc_rateCtrl|wq: nav_and_controllers) ${print $2}' /proc/xenomai/sched/threads | xargs -r -n1 sudo taskset -p 0x8
```

You can modify this command to assign different PX4 tasks to different CPU cores by changing the hexadecimal mask in 'taskset'.

**Note:** Use the following hexadecimal masks with `taskset` to target a specific CPU core:

<table><thead><tr><td>CPU Core</td><td>Hex Mask (taskset)</td></tr></thead><tbody><tr><td>Core 0</td><td>0x1</td></tr><tr><td>Core 1</td><td>0x2</td></tr><tr><td>Core 2</td><td>0x4</td></tr><tr><td>Core 3</td><td>0x8</td></tr></tbody></table>

* Second, increase the ftrace buffer size on all CPU cores that will be running PX4 threads to avoid trace data loss. Modify the following command as needed for each core:

```
P$ echo 300000 | sudo tee /sys/kernel/debug/tracing/per_cpu/cpu3/ buffer_size_kb
```

**Tip:** The value 300000 sets the buffer size to approximately **300 MB**. Repeat the command with `cpu2`, `cpu3`, etc., depending on your assignment.

**Important Note:** After these steps, the simulation can be run following the same procedure as described in the single-core Xenomai setup.
## 8.3 Run PX4-Standard HitL simulation on Xenomai

To start PX4-Standard in Xenomai, use the following command on the Raspberry Pi:

```
1. P$ sudo env \
2. LD_LIBRARY_PATH=/usr/xenomai/lib \
3. LD_PRELOAD=/usr/xenomai/lib/libcobalt.so \
4. ~/drone_project/px4-standard/build/emlid_navio2_default/bin/px4 \
5. -s ~/drone_project/px4-standard/posix-configs/rpi/px4_hil.config
```

<figure><img src="image_24.png" /><figcaption>Figure 19: Start of PX4-Standard in Xenomai</figcaption></figure>

In another terminal via SSH run the following command to verify that PX4-Standard threads have been successfully converted to Xenomai-Cobalt real-time threads:

<figure><img src="image_25.png" /><figcaption>Figure 20: PX4-Standard threads as cobalt threads</figcaption></figure>
**Important Note:** This part of the work is currently **unfinished** and has been left for future engineers to investigate and resolve.

Although the PX4-Standard HitL simulation under Xenomai can be launched successfully, the Raspberry Pi eventually freezes during execution. This issue is likely caused by **CPU hogging due to Cobalt high-priority real-time threads**, which may prevent other essential processes (such as SSH, networking, or scheduler) from functioning properly.

As of now, no robust solution has been found to resolve this issue. Further debugging, possibly involving CPU affinity adjustments, priority balancing, or isolating Xenomai threads, is needed to make PX4-Standard fully operational under Xenomai in HitL mode.
# 9 Switch Between NPRT and PRT on Raspberry Pi

On the Raspberry Pi, switching between the Non-PREEMPT-RT (NPRT) and PREEMPT-RT (PRT) kernels is done by editing the `/boot/config.txt` file. This configuration determines which kernel image is loaded during boot.

To modify this file, run:

1

```
P$ sudo nano /boot/config.txt
```

## 9.1 Booting with the NPRT Kernel

To boot with the standard (non-real-time) Linux kernel, use the following settings:

<figure><img src="image_26.png" /><figcaption>Figure 21: Raspberry Pi boot configuration for NPRT</figcaption></figure>
Make sure: - *kernel7.img* is uncommented (active) - *kernel-rt.img* and *device-tree* are commented out

This loads the default Emlid kernel without real-time capabilities.

## 9.2 Booting with the PREEMPT-RT Kernel (PRT)

To switch to the PREEMPT-RT kernel, modify the file as shown below:

<figure><img src="image_27.png" /><figcaption>Figure 22: Raspberry Pi boot configuration for PRT</figcaption></figure>

Make sure: - *kernel-rt.img* is uncommented - *kernel7.img* is commented out - *device_tree* line is uncommented (required for proper booting with PRT)
## 9.3 Final Steps

After saving the changes, reboot the Raspberry Pi to apply them:

```
pi@navio:~$ sudo reboot
```

To verify the currently active kernel after reboot, use:

```
pi@navio:~$ uname -a
```

**Expected Output:**

* For NPRT:

```
pi@navio:~$ uname -a
Linux navio 5.10.11-emlid-v7+ #1 SMP PREEMPT Wed Apr 28 11:50:41 MSK 2021 armv7l GNU/Linux
pi@navio:~$ 
```

<caption>Figure 23: Identifying the Current Runtime System - NPRT</caption>

* For PRT:

```
pi@navio:~$ uname -a
Linux navio 5.10.11-emlid-v7+ #3 SMP PREEMPT_RT Thu Oct 24 16:37:34 CEST 2024 armv7l GNU/Linux
pi@navio:~$ 
```

<caption>Figure 24: Identifying the Current Runtime System - PRT</caption>

## 9.4 Important Notes

* A mismatched or missing `device_tree` entry may prevent boot.

* These changes are safe and reversible. Simply re-edit the file to switch back.
# 10 Downloading, Building and Running PX4-RT on NPRT/PRT

To build PX4-RT with NPRT/PRT (standard or PREEMPT-RT Linux) support, follow the steps below:

1. Start VirtualBox

<figure><img src="image_28.png" /><figcaption>Figure 25: VirtualBox</figcaption></figure>

2. Check if correct ubuntu version is running:

```
V$ lsb_release -a
```

<figure><img src="image_29.png" /><figcaption>Figure 26: Check ubuntu version</figcaption></figure>
3. Go to "drone_project" folder.

```
1. V$ cd drone_project
```

4. Clone the PX4-RT (NPRT/PRT) repository on the Ubuntu 18.04 virtual machine:

```
1. V/drone_project$ git clone https://gitlab.inria.fr/kdbench\ /multicore/px4-rt_and PX4-RT Linux NPRT and PRT.git
2.
```

<figure><img src="image_30.png" /><figcaption>Figure 27: The image has an outdated link</figcaption></figure>

5. Rename the cloned folder to `px4-rt` for consistency:

```
1. V/drone_project$ mv px4-rt-linux_nprt_and_prt px4-rt
```

6. Enter the renamed folder:

```
1. V/drone_project$ cd px4-rt/
```

7. Initialize and update all submodules:

```
1. V/drone_project/px4-rt$ git submodule update --init --recursive
```

8. Make the `Tools/check_submodules.sh` script executable:

```
1. V/drone_project/px4-rt$ chmod +x Tools/check_submodules.sh
```
9. On your Ubuntu 18.04 virtual machine, navigate to the PX4-RT source directory and compile the firmware using:

```
V/drone_project/px4-rt$ make emlid_navio2_mc-rt-inria
```

<figure><img src="image_31.png" /><figcaption>Figure 28: Building PX4-RT firmware for emlid_navio2_mc-rt-inria target</figcaption></figure>
## 10. Find the IP address of your Raspberry Pi

At this stage you need to know the ip address of the Raspberry Pi. So, make sure your Raspberry Pi is connected via Ethernet. Then run the following command on the Pi:

1

```
P$ ifconfig
```

Look for the IP address under the eth0 section.

<figure><img src="image_32.png" /><figcaption>Figure 29: Identifying Raspberry Pi's Ethernet IP address using ifconfig</figcaption></figure>
## 11. Modify the build upload destination

After building, the upload rule is written to a file called:

```
build/emlidysznavio2_mc-rt-inria/build.ninja
```

Open this file and search for the line that includes `pi@navio`. You need to update the IP address from the default to your Raspberry Pi's IP (e.g., `128.93.67.248`) and also change the location where the px4 binary will be uploaded.

**Before:**

<figure><img src="image_33.png" /><figcaption>Figure 30: Before modification old IP address present in build.ninja</figcaption></figure>

**After:**

<figure><img src="image_34.png" /><figcaption>Figure 31: After modification correct IP address of Raspberry Pi and the desired destination location inserted</figcaption></figure>
## 12. Upload the firmware to the Raspberry Pi

Once the IP is updated, run the following command to upload px4:

1

```
V/drone_project/px4-rt$ make emlid upload
```

You will be prompted to enter the password for the 'pi' user on the Raspberry Pi. The password is 'raspberripi'. Once authenticated, the firmware and configuration files will be transferred.

<figure><img src="image_35.png" /><figcaption>Figure 32: PX4 firmware upload in progress</figcaption></figure>
# 10.1 Run PX4-RT HitL Simulation on NPRT/PRT (Singlecore)

Once the PX4 firmware has been uploaded to the Raspberry Pi running either the NPRT or PRT kernel, you can execute the HitL simulation in singlecore mode.

1. Before starting PX4, increase the ftrace buffer size to prevent data loss:

```
P $ echo 100000 | sudo tee /sys/kernel/debug/tracing/buffer_sizeキ
```

```
pi@navio:~/drone_project/px4-rt/px4 $ echo 100000 | sudo tee /sys/kernel/debug/tracing/buffer_sizeキ
100000
pi@navio:~/drone_project/px4-rt/px4 $  
```

<caption>Figure 33: Increasing the tracing buffer size to 100 MB before launching PX4</caption>

2. Navigate to the PX4 binary folder and launch PX4 using the script:

```
P$ cd ~/drone_project/px4-rt/px4
```

```
2 P/drone_project/px4-rt/px4 $ sudo ./bin/px4 -s px4_hil.config
```

<figure><img src="image_36.png" /><figcaption>Figure 34: Launching PX4-RT HitL firmware with `px4_hil.config` under NPRT/PRT</figcaption></figure>

3. Verify active threads and rates using the PX4 shell:

After PX4 has started, use the 'work_queue status' command to inspect all active control threads, their rates, and scheduling intervals.
```
1 pxh> work_queue status
```

<figure><img src="image_37.png" /><figcaption>Figure 35: Work queue thread status and scheduling intervals under PX4-RT on NPRT/PRT</figcaption></figure>

### 4. Use the correct Bouif project folder for single-core tests

For running HitL simulations in **single-core mode**, open a terminal the following Bouif project path:

```
bouif_for_PX4-RT_single_core/bouif
```

This folder contains scripts and mission plans tailored for assigning all RT tasks to a single core and launching the simulation accordingly.

### 5. Verifying run_rpi.sh Script Configuration before starting simulation

The `run_rpi.sh` script plays a central role in executing PX4 HitL simulations across the network. It defines the IP address of the Raspberry Pi, controls the modules to be launched, and ensures that data is retrieved correctly after the simulation ends.

* **Correct Target IP Address:** The variable `TARGET` must always be set to the IP address of the Raspberry Pi you are currently using. Make sure this IP is reachable from the host machine where the script is being executed.
* **Correct Data Retrieval Path:** After the simulation, `run_rpi.sh` fetches the log and CSV trace files from the Raspberry Pi. It's important to ensure this path corresponds to where PX4 is actually writing the logs (typically under `/tmp/`).

<figure><img src="image_38.png" /><figcaption>Figure 36: Verify the target IP address (`${TARGET}`)</figcaption></figure>

<figure><img src="image_39.png" /><figcaption>Figure 37: Ensure `scp` retrieves data from the correct paths</figcaption></figure>

## 6. Run the simulation command

To start the simulation, run the following command in the laptop from within the appropriate Bouif project folder:

```
L/bouif_for_nprt_prt_xenomai/bouif_for_PX4-RT_all Cores_xenomai\ /bouif$ ./run_rpi.sh --snsr-intv 8000 --snsr-prio 0 \
--rctl-intv 8000 --rctl-prio -1 \
--ekf2-intv 8000 --ekf2-prio -2 \
--actl-intv 8000 --actl-prio -3 \
--pctl-intv 8000 --pctl-prio -4 \
--fmgr-intv 8000 --fmgr-prio -5 \
--hte-intv 8000 --hte-prio -6 \
--navr-intv 8000 --navr-prio -7 \
--cmdr-intv 8000 --cmdr-prio -8
```

This script configures and starts the HitL simulation with fixed intervals (8 ms for each task) and priorities for each PX4 thread. These periods and priorities can be adjusted by modifying the command.
<figure><img src="image_40.png" /><figcaption>Figure 38: Running single-core PX4-RT simulation with real-time priorities and intervals</figcaption></figure>

7. Inside the Bouif folder, the `setup_tracer.sh` script is used to pin specific PX4 threads to CPU cores:

<figure><img src="image_41.png" /><figcaption>Figure 39: Task assignment logic in `setup_tracer.sh` script</figcaption></figure>
* It waits for the PX4 process ('pidof px4') to launch.

* Then it finds the thread IDs ('ps -L -p PID') matching the names of important PX4 tasks.

* The 'taskset' command is used to assign:

- 'wkr_hrt' → CPU1 (mask 0x2)

- RT control tasks (e.g., 'ekf2', 'mc_rateCtrl', etc.) → CPU3 (mask 0x8)

* It also sets the trace clock to 'mono_raw' for consistent logging timestamps.

**Important Note:** After completing these steps, the rest of the data processing procedure is the same as described in the Xenomai section 7.1.7.
## 10.2 Run PX4-RT HitL Simulation on NPRT/PRT (Multicore)

Running the PX4-RT HitL simulation in multicore mode under NPRT or PRT is nearly identical to the single-core procedure described earlier.

* PX4 firmware execution on the Raspberry Pi remains the same.

* Tracing buffer size should still be increased before starting PX4.

* The work queue and thread priorities are configured via the same configuration script (`px4_hil.config`).

The only difference is that you must run the HitL simulation from a different Bouif project folder designed for multicore experiments:

`bouif_for_PX4-RT_all Cores/`

This folder contains the appropriate launch scripts, logging settings, and processing tools tailored for multicore behavior evaluation.

**Important Note:** All remaining steps (starting PX4, connecting to jMAVSim, tracing, logging, post-analysis) are exactly the same as in the single-core case.
# 11 Downloading, Building and Running PX4-Standard on NPRT/PRT (Singlecore and Multicore)

## 11.1 PX4-Standard HitL Simulation on NPRT/PRT

The procedure to download, build and run PX4-Standard in HitL mode on NPRT or PRT kernels is **identical** to the PX4-RT process. The only differences are:

* You must use the PX4-Standard specific Git repository:

PX4-Standard-Linux_NPRT_and_PRT

* Corresponding Bouif simulation folders should be used:

- For single-core simulation:

bouif_for_PX4-Standard_single_core

- For multicore simulation:

bouif_for_PX4-Standard_all Cores

**Important Note:** All preparation steps such as buffer size increase, firmware upload, task tracing, and post-analysis are handled the same way as in PX4-RT. So, from this point, continue the procedure as in PX4-RT HitL steps.
## 11.2 Difference in jMAVSim Launch for PX4-Standard

Unlike PX4-RT, launching jMAVSim for PX4-Standard requires a few extra steps. The simulation is still run in HitL mode, but you must perform the following operations in order:

1. Start the initial jMAVSim GUI using the command:

1. `L/bouif_for_nprt_prt_xenomai/PX4-StandardReference/Tools/simulation\`

2. `./jmavsim/$ ./jmavsim_run_HITL.sh`

This command is located in the following path:

`bouif_for_nprt_prt_xenomai/PX4-StandardReference/Tools/simulation/jmavsim/`

<figure><img src="image_42.png" /><figcaption>Figure 40: Start jMAVSim GUI using `jmavsim_run_HITL.sh`</figcaption></figure>
2. Comment out ekf2 start in px4_hil.config:

PX4-Standard's internal start of ekf2 has a bug, so this line must be disabled.

<figure><img src="image_43.png" /><figcaption>Figure 41: ekf2 start commented out in px4_hil.config</figcaption></figure>

3. Start PX4 using the following command:

1

P/drone_project/px4-standard/px4 $ sudo ./bin/px4 -s px4_hil.config
4. Start ekf2 within px4:

pxh> ekf2 start

<figure><img src="image_44.png" /><figcaption>Figure 42: ekf2 start commented out in px4_hil.config</figcaption></figure>
5. Start QGroundControl GUI:

Locate the **QGroundControl.AppImage** inside the same bouif repository and double-click to launch it. No installation is needed. Click on the 'Q' on the top left.

<figure><img src="image_45.png" /><figcaption>Figure 43: Open QGroundControl interface</figcaption></figure>

6. Click the "Arm" option from the dropdown menu

<figure><img src="image_46.png" /><figcaption>Figure 44: Click on Arm in QGroundControl</figcaption></figure>
7. Slide the "Slide to Confirm" bar to arm the drone

<figure><img src="image_47.png" /><figcaption>Figure 45: Slide to confirm arming</figcaption></figure>

8. Drone becomes armed

<figure><img src="image_48.png" /><figcaption>Figure 46: Drone armed in QGroundControl</figcaption></figure>
9. Now close the first jMAVSim GUI window

10. Launch the second jMAVSim script to handle MAVLink communication:

`./jmavsim_run_HITL_mavlink_communication.sh`

**Important Note:** From this point, continue the procedure as in PX4-RT HitL steps.
# 12 Troubleshooting

## 12.1 Restart Raspberry Pi After Each Simulation

To minimize errors and ensure a stable environment, it is recommended to restart the Raspberry Pi after every simulation, regardless of whether the simulation completes successfully or not.

## 12.2 Dropped SSH

The Ethernet connection may drop during the SSH session. Regularly verify with `ifconfig` that the assigned static IP address is still present. If it is missing, reassign the IP address.

1

```
L$ sudo ifconfig enxe04e7a975456 128.93.67.1 netmask 255.255.255.0 up
```

## 12.3 WARN - Failsafe Enabled: No Manual Control Stick Input

During HitL simulation, you may see the following warning in the PX4:

```
WARN - Failsafe enabled: No manual control stick input
```

This occurs because PX4 enters failsafe mode when it does not detect manual RC control input from a transmitter or simulator.

**Solution:** Manually override the failsafe behavior by setting the parameter `COM_-RCL_EXCEPT` to `4` in `QGroundControl`:

1. Click the top-left **Q** icon in QGroundControl and select **Vehicle Setup**.

<figure><img src="image_49.png" /><figcaption>Figure 47: Open Vehicle Setup in QGroundControl</figcaption></figure>

2. Navigate to the **Parameters** tab.

3. Search for the parameter `COM_RCL_EXCEPT`.
4. Change its value to 4, then click Save.

<figure><img src="image_50.png" /><figcaption>Figure 48: Set COM_RCL_EXCEPT = 4 to disable failsafe action for RC loss</figcaption></figure>

This tells PX4 to ignore RC loss for mission mode, preventing the failsafe trigger during HitL simulation without a physical RC transmitter.

## 12.4 Failsafe due to No Datalink (Drone Won't Fly)

Error Observed:

INFO [commander] Takeoff detected

WARN [commander] Failsafe enabled: no datalink

INFO [commander] Failsafe mode activated

INFO [navigator] RTL HOME activated

INFO [navigator] RTL: landing at home position.

INFO [navigator] RTL: climb to 488 m (1 m above destination)

INFO [commander] Failsafe mode deactivated

INFO [navigator] RTL: return at 488 m (1 m above destination)

INFO [navigator] RTL: land at destination

INFO [commander] Landing detected

INFO [commander] Disarmed by landing

This error causes the drone refusing to takeoff due to a "no datalink" failsafe.

**Solution:**

1. Open **QGroundControl**.

2. Click on the top-left **Q** logo to access tools.

3. Go to **Vehicle Setup** > **Parameters**.

4. Search for the parameter: `NAV_RCL_ACT`.

5. Change its value from 2 (Return Mode) to 0 (Disable RC loss failsafe action).
6. Make sure **Manual Entry**, **Advanced Settings**, and **Force Save** are all clicked to ensure the change of parameter.

7. Click **Save** to apply the change.

This ensures that **no automatic return/landing** occurs due to missing RC link during HitL simulation, which is common in tests without a physical RC transmitter.

<figure><img src="image_51.png" /><figcaption>Figure 49: Default value of NAV_RCL_ACT is 2 (Return Mode), which enables the failsafe</figcaption></figure>

## 12.5 Importance of `px4_hil.config` File

The `px4_hil.config` file is a critical component in the HITL simulation setup. It contains the startup configuration for PX4, including sensor and module initialization, EKF2 settings, mixer loading, and most importantly, MAVLink communication settings.

Pay special attention to the following key aspects in this file:

* **IP Address & Ethernet Interface:** The line starting with `mavlink start` includes the IP address and network interface (e.g., `eth0`). This must match the host PC (where `jMAVSim` is running).

* **Port Numbers:** The correct ports must be set for MAVLink communication. Typically, port 14577 is used for outgoing messages from PX4, and port 14551 is the listening port on the `jMAVSim` side.

* **Enabling/Disabling Lines:** You may have multiple configurations in the same file (e.g., for `office` or `home`)—ensure the correct one is uncommented based on your network setup.

Make sure this configuration is accurate before starting PX4 with:
<figure><img src="image_52.png" /><figcaption>Figure 50: After setting NAV_RCL_ACT to 0, the failsafe behavior is disabled</figcaption></figure>

sudo ./bin/px4 -s px4_hil.config

Any mistake in the IP or port configuration will prevent MAVLink handshake and block simulation startup.
<figure><img src="image_53.png" /><figcaption>Figure 51: px4_hil.config file with essential PX4 startup commands</figcaption></figure>
# 13 Data Analysis

The analysis of PX4-RT and PX4-Standard was performed using data collected from 42 Hardware-in-the-Loop (HitL) simulation runs across various kernel configurations, PX4 variants, and execution setups.

## 13.1 Reference Reports Used for Data Analysis

The following two internal reports were used as primary references during the data analysis phase:

* reports/dataCollectionReport/dataCollectionPlanReport/dataCollectionReportV7.pdf

* reports/px4CodeAnalysisReport/rapportV20/px4CodeAnalysisReport.pdf

These documents provide essential background on the data collection methodology and test plans.

## 13.2 Raw Data Location

All the raw data generated from the HITL simulation runs r1 to r42 are stored in the following directory:

* data/HITLSimulationRawData/activationAndResponseTimeDataSingleCoreV5

Here, V5 indicates the latest and most complete version of the raw dataset used for analysis.

## 13.3 Post Processed results

All post-processed results, raw data, analysis python scripts, and plots are located in:

/data/statisticalTestResults/

This folder contains structured subfolders for each test configuration, such as:

* T1, T2, T3, T4 – PX4-RT tests with different control task periods;

* multiCores_8ms – Multi-core PX4-RT tests;

* PX4-Standard-Tests – Tests for PX4-Standard under NPRT and PRT;

* latencyTestResultXenomai – Tests under Xenomai kernel.
## 13.4 Test Coverage and Metrics

The 42 simulation runs were conducted using the Bouif HitL simulation framework and cover:

* **PX4 Variants**: PX4-RT (custom periodic task configuration) and PX4-Standard

* **Kernel Types**: NPRT (Linux with no patch), PRT (Linux with PREEMPT-RT patch), and Xenomai (Cobalt)

* **Flight Plans**: Short, Medium, and Long

* **Execution Modes**: Single-core and multi-core task scheduling

* **Data Extraction Methods**: Internal and External methods.

Metrics analyzed include:

* Worst-case and average latencies

* Response delays of critical control tasks

* Task preemptions
# 14 Latency Test

All commands in this section are executed on the Raspberry Pi target device. Each test runs for **10 minutes** by default. The duration can be changed with the `-D` option. Cores 1, 3, and 4 are fully loaded with `stress-ng` while the latency test runs on core 2.

## 14.1 Latency Test on standard Linux (NPRT)

1

pi@raspberrypi: / $ taskset -c 1,3,4 stress-ng --cpu 3 --cpu-load 100 --vm 2 --hdd 2 --timeout 600s --metrics-brief &

2

pi@raspberrypi: / $ sudo cyclictest -t1 -p80 -i4000 -a2 -D600s --histogram=4000

## 14.2 Latency Test on PREEMPT-RT Kernel (PRT)

1

pi@raspberrypi: / $ taskset -c 1,3,4 stress-ng --cpu 3 --cpu-load 100 --vm 2 --hdd 2 --timeout 600s --metrics-brief &

2

pi@raspberrypi: / $ sudo cyclictest -t1 -p80 -i4000 -a2 --policy=fifo --mlockall -D600s --histogram=4000

## 14.3 Latency Test on Xenomai (Cobalt)

1

pi@raspberrypi: / $ taskset -c 1,3,4 stress-ng --cpu 3 --cpu-load 100 --vm 2 --hdd 2 --timeout 600s --metrics-brief &

2

pi@raspberrypi: / $ sudo /usr/xenomai/bin/latency --cpu-affinity=2 -c 1 -T 600

## 14.4 Installation Note

If not already installed, use the following commands to install the required tools on the Raspberry Pi:

1

pi@raspberrypi: / $ sudo apt update

2

pi@raspberrypi: / $ sudo apt install stress-ng rt-tests

For Xenomai-based latency tests, ensure the Xenomai user-space tools are installed and `/usr/xenomai/bin/latency` is available.

## 14.5 Location of Latency Test Results

The statistical results for latency tests (including average, worst-case, and comparison across different kernels and configurations) are stored under the following directory:

/data/statisticalTestResults/

The three key folders that contain the latency analysis are:

* `latencyTestResultNPRT&PRT` - Contains the latency measurement results comparing Linux with no patch (NPRT) and Linux with PREEMPT-RT patch (PRT) using PX4-RT.
* `latencyTestResultXenomai` - Holds the results obtained when running PX4-RT with the Xenomai-3 kernel.

* `singleCore_vs_multiCore` - Contains analysis results comparing single-core vs multi-core configurations.

## 14.6 References and Documentation

* stress-ng (Linux load generator)
  https://manpages.debian.org/stress-ng

* `cyclictest` (Real-time latency testing)
  https://manpages.debian.org/rt-tests/cyclictest

* Xenomai latency test utility
  https://xenomai.org/documentation/xenomai-3/html/man1/latency/