Flying/not flying detection

[digitalentity]

Add some heuristics to figure out if we are flying or not to allow different behavior of i.e. failsafe mode.

[krzysztofmatula]

Two cases happened to me recently where such information could be useful:

1. I crashed at some distance and the RX signal was lost (probably because RX antenna was digging the ground). The quad engaged RTH (I saw this on FPV) and the motors were spinning almost full throttle trying to do something. But it didn't actually change much. It took me couple of minutes to get closer and disarm. During that time the RTH was active. Good that motors didn't get burned...

2. I crashed in stabilized mode (horizon). I couldn't hear the motors and I didn't disarm. When getting closer I realised the motors were spinning fast, probably trying to level.

Not sure if we need to change #2, but in case of autonomous flight (#1) the procedure should be finished when already in the ground to minimise destruction and to conserve battery.

[teckel12]

Disable NAV_LAUNCH when flying to avoid issue where NAV_LAUNCH is always activated and the model is disarmed mid-flight.

[teckel12]

2410 If in the air, home reset just reset X & Y as it works previously. If not in the air, home reset should do a 3D reset (reset altitude as well).

[jelle737]

I had the scenario of crash/signal lost/failsave triggered twice, It spins the motor very powerfull until the battery is dead. Second time I was prepared and took the radio to disarm though. But I am in favour of automated disarming in such scenario.

[teckel12]

@jelle737 If in FAILSAFE mode and no longer flying, disarm would be ideal as well.

[Redshifft]

Is not just a longer Failsafe ignore time when "closed throttle" needed to get them through any RC gitches/packet loss ?

[teckel12]

@Redshifft This issue isn't really about failsafe, It's knowing when the model is flying or not. Once that is known, lots of other features/safeguards can be added based on that knowledge.

[giacomo892]

After we have this I'd add the ability to NOT reset the home point if we are "flying" and we mistakenly disarm and re-arm in the air.

[teckel12]

@giacomo892 Or, if in the air and a home reset, just reset the X & Y (as it works now). But if NOT in the air, do a 3D home reset (altitude as well).

[OlivierC-FR]

I've been trying to find what tells an aircraft it is flying, and what tells it is not.

First, the position alone is not telling, cannot check for the altitude or distance to home etc, the ground is obviously not always flat. Then the movement is not much clue either, a multirotor can hover still for a long time and be fine. Or it can be still on the ground because it crashed. Same for a plane, it can have null speed because there's a lot of wind and going well, or be stuck in a tree. Thus I see nothing in the GPS datas that could help.

So the me the logic should be to assume by default that yes, the aircraft is flying. Then case by case, mode by mode, find conditions that'd tend to proove the aircraft is afterall, not flying.

*** For both MR and FW, in modes ANGLE, RTH or WP or POSHOLD : If the pitch or roll angle is more than the max banking angle + some % for safety, for X seconds, then it shows the aircraft is unable to reach to the requested attitude. probable cause is : aircraft is crashed / not flying.

*** For both MR and FW : The sum of all I terms growing larger than X for Y seconds, shows the aircraft is unable to reach to the requested attitude over a long period of time. Not flying.

*** For MR : If at least one motor is at throttle>70% and at least one other is at <30%, and the pitch+roll+yaw are not varying by more than Y%, for more than X seconds, then not flying, because stuck or grounded. This one can potentially catch a lot of non-flying conditions, it's not normal to have a large differential in motors RPMs for a long time, on any kind of multirotor.

[teckel12]

@OlivierC-FR I had assumed something more on the lines of if GPS speed is basically zero, Acc X, Y, Z are not varying by more than a certain amount, and motors are below a certain point, it's no flying. It would be easier for FW as if the GPS position isn't changing, it's obviously not flying. For MR, some kind of minimum for motor speed would need to be factored in (to deal with a super stable hover on a calm day).

Not to say that I've put in a lot of thought into this, but I'd like to think we could keep it as simple as possible but still be accurate. We may want to ease our way into a feature like this. For example, only making it do things that wouldn't be catastrophic (like home position change).

[OlivierC-FR]

But then what about aircrafts with no GPS ? And accelerometers not varying, this can happen during normal flight, for planes mostly.

[pmarkiewicz]

I think we should start by limiting flight modes to FS as this is most common case, RTH crashed/failed for whatever reason. If I'm not wrong ardupilot/copter have something like that so maybe it makes sense to check their ideas also. http://ardupilot.org/copter/docs/crash_check.htmlv https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/crash_check.cpp

[teckel12]

@OlivierC-FR This is INAV, I think GPS would be a requirement? If you don't have a GPS, wouldn't you be using BF or CF? Also, I believe this would be an option anyway so you'd just lose some functionality if you didn't have a GPS.

[OlivierC-FR]

You're right, GPS is basically almost a pre-req. Problem is that GPS are not the most reliable devices. I still think the unability of the stabilization loop to reach the target pitch/roll/yaw angles within a given delay would be a good indicator of the aircraft flying or not.

Some basic angle check for the RTH/WP modes, like a pitch or roll angle higer than 90° for some seconds, would avoid a lot of bad events I'm fairly sure.

But that's not proper flying/not flying detection as the topic of this PR says, it's just an extra safety for a specific mode.

[Tygrys-1]

I understand the problem with "flying" condition, but there are some cases when we could tell that something is not as expected, ie. plane doing RTH or nav mission should change the position. As we assume GPS data to be good enough to do the RTH or mission, we can belive them the same way for the fact the craft is not moving in desired direction or not moving at all.

On the other hand if the GPS position changes significantly the craft is probably flying and then some actions should also be possible like armnig despite the distance from the first waypoint of the mission, in case we disarmed the craft by accident or for whatever reason.

[Tygrys-1]

But that's not proper flying/not flying detection as the topic of this PR says, it's just an extra safety for a specific mode.

I think we need extra safety for the specific modes ASAP. :)

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help. This issue / pull request will be closed if no further activity occurs within two weeks.

[giacomo892]

Definitely not stale.

[fiam]

Bad bot

[stronnag]

setting Feature Request puts the bot in its place ...

[lgojniczek]

I'm really interested int this topic, is there any chance to solve it?

[potater1]

I did a little bit of bench testing looking at gyro and acc measurements, and based on the results I would propose the following solution:

• update a gyro reading averaged over ~1 second or so, for example: gyro_avg = AVG(fabs(imuMeasuredRotationBF.x) + fabs(imuMeasuredRotationBF.y) + fabs(imuMeasuredRotationBF.z));
• when the aircraft is armed, go into flying mode
• when gyro_avg > threshold, go into landed mode
• when an acceleration shock is measured, say >4 g, go into landed mode

If you set the gyro threshold value to just a bit over the minimum that you see when the aircraft is lying on the ground, you may be able to completely eliminate false positives. I'm seeing a value of 0.004 - 0.006 rad/s, and when hand holding the plane trying to keep it completely still, I get values of > 0.012 consistently, and can't get a false "landing detection". In flight even a stable multicopter should wiggle more than that.

This method would work in most cases I think... I guess it can fail if you manage to do a soft landing into a tree that is swaying in the wind so you don't get an acceleration spike, and the aircraft is not sitting still after the crash.

I'll be testing this method in flight pretty soon, let's see how it works out...

[wx4cb]

wow.. that sounds cool... one thing i would suggest is having a configurable threshold and the ability to turn it on and off with a switch if it's above threshold a lot so you can tweak it.

[krzysztofmatula]

What about hitting a branch when flying? Acceleration shock may be noticeable, yet the flight can be often safely continued. Relying solely on gyros definitely is not enough. Crashed model with spinning props is not still on majority of cases I guess.

[potater1]

@krzysztofmatula We'll have to tune the shock detection so that a light hit doesn't trigger it. Or failing that, just accept that we're not gonna use this feature to trigger a disarm when flying close to trees.

Anyway, there's no way to make this perfect, but something that detects landings most of the time and doesn't produce false positives should be better than no landing detection at all.

[teckel12]

@potater1 I don't think shock can trigger it. I've hit things really hard and recovered, and different model weights would have vastly different shock. Also, my use for flying/not flying is to reset home position in 2D or 3D, nothing to do with a crash (I just hit the disarm switch after a crash).

In other words "not flying" would also need to know when a model was armed, props spinning, but on the ground, or hovering totally stationary.

This is why flying/not flying is so difficult. And probbaly needs to also rely on the GPS and barometer, as well as not switch to "not flying" state for some period of time.

There's all kinds of different uses for this information, which seems to conflict with each other at times.

[potater1]

@teckel12 That's interesting. In my so far very limited flying experience (with planes only) I always crashed after a hard hit.

Hm.. so you want to reset the home position when you stop for a hover mid flight? That requires using GPS of course, but it's something you don't want to do on waypoint missions so it needs its own setting.

[krzysztofmatula]

Definitely avoiding false positives should be a priority. I think we should start collecting logs from flights where something unusual happened and have them analysed later to prove or reject a theory. No one would like to crash or hit something on purpose, so it will take some time until a representative set of logs can be collected.

[teckel12]

@potater1 I only fly quads and they can hit trees or even walls and recover. I imagine for fixed wing that's quite a bit different.

Currently, when you engage home reset, it only resets the lat/lon not the altitude, even if on the ground. It's quite common for me to launch from under a tree, fly out into a clearing, then hit the home reset switch. This way, a RTH won't end up at the top of a tree. If the terrain is flat, not resetting the altitude isn't an issue, but when hilly it can result in a hard landing.

Also, an option that wouldn't allow home reset when flying would be nice. I've accidently hit the home reset switch instead of return to home, which could be really bad. Knowing if the quad is flying or not, could make this impossible. Other safety systems could also be used, like not allowing the disarm switch while flying.

[potater1]

@teckel12 Alright, I did some more testing, this time with the motor running... of course @krzysztofmatula was right -- the gyro can't be used to determine flying status, as the motor causes significant noise in the gyro readings. (if the gyro is giving zero readings, we know we've landed and motors are off but it's not very useful knowledge).

Looks like the gyro can't reliably tell us whether a quad is hovering, or sitting on the ground with props spinning. Maybe most of the time, but not without errors.

In order to disarm, we need to be sure the model is not flying. For a quad, the only way I see to be reasonably sure is if the model is tilted at a steepish angle and GPS speed is close to 0. On a plane, we can disarm if the model is immobile according to the gyro after an impact is measured on the accelerometer.

For preventing an accidental home reset or disarm, the gyro could be used with the understanding that the prevention isn't 100% foolproof.

[krzysztofmatula]

GPS speed is tricky. It is zero on a hovering multirotor (even tilted, when fighting with wind) and can be zero on a plane flying against strong wind. I think good direction is the one @OlivierC-FR mentioned on May 2nd (see above). Not being able to reach requested attitude (for some time, with some error) could be an indication of not-flying. Normally multirotors are able do adjust attitude very quickly and precisely. I think planes as well. We could do some log analysis (including aggressive acro flights) to see what are the errors in normal flying.

[potater1]

Ok, how about this idea for quads: if you measure >=1 g of acceleration (in any direction), and throttle is significantly below hover, you should be grounded (or falling at terminal velocity).

[teckel12]

@potater1 What if you land? Throttle would be below hover, but accZ would be about 1 and accX & Y would be about zero. That would be not flying, yet not trigger.

Or, I often take throttle well below hover throttle for a free-fall. I wouldn't want that to trigger not flying as in a quad with air mode, near zero g free-fall is flying.

Maybe this should be broken into two types of detection. "not flying" and "crash detection"?

[potater1]

This logic should work for landings.

Whenever you measure <1 g in whatever direction, you know you're falling (I just realized this today and added low g detection to the GSM module).

For a quad to have 1 g of acceleration in the air, it needs to have thrust at least equal to its weight. So if throttle is well below hover level, but acceleration is still about 1 g, it tells you the quad must be supported by something.

Now reading @OlivierC-FR's post again, is there any reason the PID error check wouldn't work as a general solution?

[teckel12]

@potater1 When stationary and upright, there's 1g of accZ and 0g of accX & accY. A "fall" of less than 0g can happen on a quad (upside down with throttle) which is still totally in control.

I do like the @OlivierC-FR suggestion that if the model can't obtain the desired position within a certain amount of time there must be something wrong. That could trigger a crash mode. Also high g forces could possibly also trigger crash mode.

I believe totally different logic should be used to detect if the model is stationary on the ground (which shouldn't trigger crash mode).

With this combination, I feel "is flying" could be determined. A LOT of blackbox recordings would be needed.

[potater1]

I'll try out PID term based crash detection when I find the time to do some tests. I think for fixed wings it may be OK to rely on negative X acceleration.

[potater1]

I'm going to try the following simple logic for detecting when the FC has lost control of the model:

if (angle error on roll or pitch stays positive or negative for N seconds
    AND gyro rate has the wrong sign, or is too small, say <0.1 rad/s)
    set CONTROL_LOST_FLAG 

and then we can just disarm when this happens soon after an impact is detected. Additionally we can check that acceleration is ~1g, to avoid disarming on fixed wings when recovering from a stall.

Setting N large enough should prevent false positives.

To prevent a home reset while flying: just require that throttle is 0 to do a home reset, and to make sure the model is landed, also check that acceleration is 1g.

[potater1]

if (angle error on roll or pitch stays positive or negative for N seconds
    AND gyro rate has the wrong sign, or is too small, say <0.1 rad/s)
    set CONTROL_LOST_FLAG 

Tested this with N = 3 seconds flying in circles in POS HOLD mode. Looks like this condition gets triggered frequently, so N must be increased for fixed wing use. Or we can relax the condition so that either pitch OR roll angle error changing sign / hitting zero is a sufficient signal that control is maintained.

[potater1]

Did another test flight with a limit of 10 seconds on nonzero angle error on either roll or pitch, and a limit of 3 seconds on nonzero angle error on both at the same time. This condition works, but it gets triggered when flying in circles at minimal throttle (just barely maintaining altitude). In this case I think the FC is unable to keep the pitch angle error at zero. You could say that the condition is correct, as it indicates that thrust is insufficient for the FC to control altitude.

For landing detection we can add the condition that all gyro measurements must be close to zero, let's say <0.1 rad/s. This would cause landing detection to not be triggered in the low throttle circling case.

[avsaase]

@potater1 Did you get any further with this? I'm thinking that a combination of zero rotation, constant gravity vector, a PID sum at its maximum and zero stick input for 10 seconds or so should be exclusive enough to avoid false positives. There could be some edge cases that would not trigger this detection, but that's already an improvement over the current situation of having no crash detection at all.

[MrD-RC]

@avsaase mentioned this post to me in #6789. I made some suggestions, and he suggested I put them in here. You guys have obviously been getting on with things. But I was thinking along different lines, with triggers for in flight and no longer flying rather than constantly detecting the flight state. Anyway, here’s the comment in case it helps. But it looks like you guys are beyond this already. ———————————— I think it would only ever be an estimation, but it could be accurate enough for most purposes I think. Maybe this would be a good place to hash out some ideas?

In flight triggers

All would be after arming. Once a threshold is met, it would stay in-flight until the no longer flying trigger.

• 3D speed > 400 cm/s (14.5 kmh) This speed is half way between average human walking and running speeds. This should mean that walking with the model would not trigger, but running would. This allows the failsafe test to still work.
• Alt < 1000 (10m) || Alt > 1000 (10mm) This should cover aircraft like multirotors (that lift off slowly) and sloping gliders (which can have a slower ground speed, depending on the wind conditions).
• Launch mode completes This should be a pretty obvious one.

No longer flying triggers

• Disarmed > 2 seconds
• Nominal movement detection We would need some kind of detection for detecting when if the model has crashed. This could of course be hung in a tree with some movement. Another option could be to trigger no longer flying in failsafe, then rely on a flying trigger once it has recovered. Though that gives a false state, which I’m not overly keen on

They’re just a couple of thoughts. It would be great to get your input guys. ———————————— For clarity, this would just be a boolean state. The In flight triggers would set it to true, the No longer flying triggers would set it to false. The in flight state is not something that is constantly evaluated. Just the trigger conditions.

[pmarkiewicz]

I think alt <10m is too strict, especially when FC doesn't have baro. I regularly land "undeground" and sometimes often my land alt is > 10m.

I also recently have weird crash (no idea why) but my copter was digging into ground upsite down on FS.

So I think we can add one more condition in RTH plane/copter cannot return to normal position in < 5secs.

[MrD-RC]

@pmarkiewicz I think you misunderstand. The alt <> 10m is only for is flying activation, not a condition that constantly has to be met.. So if you arm, then fly above or below the arm point by 10m, it activates the is flying state. So landing above or below the arm altitude would not matter at all. Maybe I should have written alt < 10m || alt > 10m for more clarity. I'll amend that.

To clarify, in my idea, it acts like a sticky. You don't always have to be above the or below the 10m. Any of the top 3 triggers activate the is flying sticky. And any of the bottom 2 triggers release it.

10m could also be changed to 5m, or whatever. It's an initial thought only. So long as it is clear of people. But not having a baro would actually require a higher margin; as GPS altitude is not as accurate or quick to update as a baro.

[pmarkiewicz]

right, good point, you are right

what about unability to rotate upside?

[MrD-RC]

@pmarkiewicz the inability to rotate could trigger not flying

I’m just putting ideas up. You guys have already done great work on this.