the situation:
I recently had a crash with my drone during an autonomous flight. The problem turned out to be a magnetometer malfunction. Since then, Ive been wondering how to identify a possible approaching problem and react with an emergency landing.
The companion computer is a Raspberry Pi 4. The Pixhawk 6c is connected via UART and commanded via a Python script using MAVSDK.
My question:
What possibillities do I have to identify an approaching flyaway due to a magnetometer- or GPS failure using Python and (preferrably, but not necessarily) MAVSDK.
The flight logs exhibit certain “estimator flags”. What do they tell me exactly and can I reach them somehow?
Do the calibration values in the health telemetry class tell me anything about the current sensor’s health or do they just stay true as long as calibration data exists.
Is there any command line tool that can query the estimator state? I might be able to call it from a script and parse the output.
I would argue that the PX4 autopilot software should prevent a flyaway. If you have to try to detect it outside of it, it’s sorta too late. The estimator has various checks and failsafes such as magless mode to deal with mag issues. If they don’t work for your case, you need to either fix your airframe, or there is a bug that we need to address in the estimator.
Any chance you could share the log of the flyaway via logs.px4.io, so that we can have a closer look?
Sure I can share the log: https://logs.px4.io/plot_app?log=046c79b5-31f4-49c3-8b47-0f49a39589a2
If there are settings I can activate that prevent a flyaway in the future and react with a landing instead of an uncontrolled drift, that would be great.
Anyway, if possible, I would like my software on the CC to notice the problems too, so they can be forwarded to the operator. Sorry for not mentioning that requirement earlier.
It looks like you are flying some branch on top of PX4 v1.12. As far as I’m aware there have been various improvements to the EKF2 since then that can help to prevent flyaways, such as the magless mode mentioned above.
So my suggestion would be to upgrade to v1.13 or v1.14 as a first step to prevent such issues.
Unfortunately, I don’t have much control over the firmware. As you say, it’s a custom branch and it is maintained by someone else.
About magless mode: I couldn’t find any precise description on what this means. As you can see, the drone started to head southeast right after takeoff, which was completely contrary to it’s commands. Would magless mode prevent that.
Also, I assumed from the log that a magnetometer error is responsible. Now that you’ve seen the log, would you share this impression?
I would ask that person then :), they might be in a better position to help than me.
Again, if you try to detect a flyaway from the outside it’s sort of too late to do anything useful about it. Doing something sensible is the whole point of the autopilot itself.
An exception would be if you companion computer actually has more location data, e.g. from vision, VIO, SLAM, that sort of thing and can help guide PX4.
As far as I’m aware the EKF can now detect if the mag is off and then try to estimate heading without it. Let me ping @bresch, maybe he has a link that describes mag failsafes a bit better.
It doesn’t need to detect a flyaway in the moment it occurs, it would be enough if I could detect problematic situations that may lead to one and decide if I want to continue the mission or land. E.g. if a magnetometer reports stronger interferences, the flight controller might still try to correct it (and possibly fail), but my logic could decide to land. I’m also willing to accept some false positives.
It’s mainly about control. The flight controller is a black box that tries to handle sensor malfunctions in a way that is beyond my reach.I’m trying to get some control about which risk to take.
Also, if something happens, even if I can’t avoid it, I’d like to report what has happened.
No, sorry. We do a pattern based landing at the end of a mission but not during the flight.
