Fault injection takes a long time

🧪 Flight Testing & Log Analysis v1.13
1

Background:
I am running px4 in a docker container and a mission SW in another container. The containers are running in WSL2 in a windows host machine. I have a mvsdk python application that runs in WSL2 which triggers a faults based on a config file, again , in linux (WSL2). The python app doesn’t run in a container. When I fail gps for example, it takes a long time to trigger the fault. Like a reallly long time, say 3 min. When I try to fail mavlink interface (one of the possible failures supported by PX4) it doesn’t have any response.

I do not know what am I missing, the likely explanation is the setup, which due the heterogenous file system between windows and the docker container’s linux file system running the PX4.

I would like to know if someone has run into this issue, perhaps shed lights on what might be the culprit

2

That’s odd with the 3mins. Are all other commands or telemetry slow as well?

This tells me it’s either not supported, or you no longer get feedback because mavlink is down?

3

Well, it takes a variable and long time. Also for some reason, I can’t fail the battery, or motors or mavsdk comms (or c2 link)…I am able to fail only the gps, gyro, airspeed sensors out of these six. Note, I am enabling failure paramter and that I am working as SITL (simulator).

On the other hand, I was curious about adding additional failures, but have no idea where to start from, I suspect I need to download px4 sdk or clone px4 code and dig deep into the actual code. Let’s take for example battery, I’d like to play with its model, such that to simulate high temperature, low temperature, battery bms failure. Do I modify the px4 code or Gazebo, I am not sure which one to modify. I do run a gazebo server ?

4

Yes, you’d have to implement the failures yourself.

Here is one example how some failures are implemented in SITL:

5

JulianOes
Great. Thank you
In SITL, are the sensors and subsystems models modeled in Gazebo or in PX4 (as in the link you shared), to my understanding it is Gazebo that provides the sensor and actuator models via plugin dynamic libraries (*.so) , and received by PX4 ? is my understanding wrong ?

Also, in case I’m wrong, that is to say that the sensors/actuators models are provided by the PX4 simulation modules as pointed out by you. Is it possible to build only select modules ?
The reason is I have only a PX4 running on a docker container (coupled with a number of apps), I am forced to work with the container only. The build artifacts in said modules from the looks of it are static .a files. Is that possible ? I am still digging deep into PX4 internal operations and code

6

Correct.

But you can inject the failure on the PX4 side. It doesn’t really matter where you simulate the failure as long as it’s somewhere.