inav
inav copied to clipboard
iNavFlight
ACRO Mode should not apply an automated Landing Procedure
Current Behavior
I like RTH Procedure of INAV, especially the final Controlled Landing Phase. I set nav_disarm_on_landing = ON. I decided to set nav_land_detect_sensitivity = 6 just to improve a little bit the impact detection on Controlled Landing Phase, which is a wonderful final phase of RHT Procedure. So I got a perfect RTH final Landing Phase. While flying in ACRO Mode it happened that INAV suddenly disarmed at 50 meters far away from home. Quad crashed. OSD final screen reported "Disarm By: Landing". Discussing on INAV Discord I realized it was the Landing Detector who caused my crash. 6 is probably a too sensible value for my quad. For sure I need to decrease it. But I want to focus your attention on another aspect of this event: INAV decided to activate the Langing Phase on its own initiative while I was flying in ACRO Mode, and this should not happen. Controlled Landing Phase should be a feature of the NAV Modes. In ACRO Mode the landing phase should be completely under the authority of the pilot. No automated Landing procedure in ACRO Mode! INAV shouldn't even look at the nav_disarm_on_landing and nav_land_detect_sensitivity variables while flying in ACRO Mode (or even ANGLE Mode).
Steps to Reproduce
- set nav_disarm_on_landing = ON
- set nav_land_detect_sensitivity = "High Value"
- Fly in ACRO Mode far away, even close to ground
Expected behavior
INAV never apply a Landing Automated Procedure while flying in ACRO Mode (or ANGLE Mode).
Suggested solution(s)
Make nav_disarm_on_landing and nav_land_detect_sensitivity variables valid only for NAV Modes.
Additional context
Diff: https://mega.nz/file/0iUXRJpZ#LTRUxNMP__FVwympc9y-fmkCauH9qUnpY2GflY_O-YE Log: https://mega.nz/file/wy0wFRhY#o8y-efVYK3xNtkYbD4FkD9zczojsR05D0QzefzqY2Xg OSD Picture: https://mega.nz/file/trtTjJAC#wcF6bDUGJEBuzwx4pF5XoQGQ7Ic9SJmf8o8U-9lYSyk Goggles Video: https://mega.nz/file/Eq900IDA#tY4hM4oQQ75cPv70ZYbOijFiHkJtsFaNCSKyScfsDWc
- FC Board name and vendor: Matek H743 V3
- INAV version string: 7.0.0
I wanted to flag that as enhancement first but when I think about it, Land detection should never trigger in the first place especially when you punch the throttle. Yes a too high sensitivity can trogger the landing disarm on vibrations But I thought there are more checks in place to prevent that.
Do you have any idea @breadoven?
Landing detection should work in any mode. It’s not just for detecting regular landings. But it will also try to detect a crash and also disarm. You’ve just set the value too high.
Landing detection is only active in non autonomous modes if the throttle stick is low or if the landing bump detection is triggered. A quick look at the log suggests it's the bump detection that might have caused this ... maybe related to the fact it's an octocopter perhaps. Needs further checking.
I think logic should be revised and landing should cause disarm only in case of automated flights unless pilot decides otherwise. Let's call it a safety precaution. Let me hack a quick change in the code
on the other hand, it's already covered by bump detection switch so maybe it's not really necessary
Yes you can disable bump detection via nav_landing_bump_detection which is OFF by default. Unfortunately it's one of those things that probably needs a lot more testing for different quad configurations in order to try and make it as reliable as it can be. I'll try and work out why it appears to have got it wrong in this. Nothing to do with sensitivity since that doesn't affect bump detection.
Ok. If disabling bump detection I can prevent a crash, it is a good solution for me. I'd like to better understand "Landing detection can also be active if throttle stick is low". Does "low" mean "completely down"?
Low means below min_check. The logic here is that if you're in ACRO and the throttle is low it's unlikely you'll have a low vertical velocity which is what the landing detection looks for (as well as low horizontal velocity and low gyro rates).
Sorry, I can't understand. I'm in ACRO mode, now... if landing detection looks for a low vertical velocity, in order to work correctly, and, since my throttle is low I have (probably) high vertical velocity, why landing detection goes active with low throttle?
Looking at the rather large Z axis ACC spike right before disarm. I would agree with breadoven. That it was the nav_landing_bump_detection that disarmed it.
But what caused it? If I had to guess. I'd say the default acc_lpf_hz = 15 is too high for this copter. And the low pass let through noise as it was making that last turn and accelerating.
Throttle low on a multirotor should result in a high velocity descent since the motors should be at idle -> no lift.
Having looked at the flight log again I'm not actually sure what the issue is. The G bump detection uses the following logic:
Z acc exceeds 2g then falls back below 1g within 100ms. There is also some additional logic related to Baro rate of change being -ve when this happens (to do with ground affect), and throttle position being lower than hover throttle.
However, looking at the flight log just before disarm the Z acc exceeds 2g but is still over 3g 100ms later so this basic requirement should have meant G bump landing detection wasn't triggered. Also the Baro rate of change didn't appear to meet the requirements either.
Can't have been normal landing detection causing the disarm because the throttle wasn't low and the horizontal velocity was 11 m/s which is much higher than the allowed threshold of only 1m/s (or 1.2 m/s with the sensitivity set to 6).
So it shouldn't have disarmed if the intended logic worked as expected. I guess that leaves the possibility that there's a bug but it's not obvious if there is.
Being that z axis acceleration doesn't appear to be based on earth frame reference ? In this case, the z axis g-force was applied under forward tilt acceleration... And this quad has d-term oscillations. It is possible the accelerometer seen vibration that the log iterations did not pickup, as he was applying the throttle.. Which fell into the window of what the logic required for a disarm.
I want to inform that Pos Z and Vel Z values were modified during an ALT_HOLD Tuning process. I don't know if it is relevant.
Being that z axis acceleration doesn't appear to be based on earth frame reference ? In this case, the z axis g-force was applied under forward tilt acceleration... And this quad has d-term oscillations. It is possible the accelerometer seen vibration that the log iterations did not pickup, as he was applying the throttle.. Which fell into the window of what the logic required for a disarm.
The "acc" values in the log are what the G bump detector is using (accADCf) and the log was running at 1000Hz so it seems unlikely it missed some random low Acc Z value (and these are filtered values anyway). If it was glitching you would see the glitches elsewhere in the log surely. Also, it's not only looking for Acc Z but Baro rate of change needs to be < -2 m/s/s at the same time and the Baro reading in the log was increasing after Acc Z exceeded 2g until around 100ms later when it did drop. But there's also a throttle check which when flying in Acro would have needed a throttle value lower than somewhere around 1150 before a landing was triggered ... it was higher than 1400 for 100ms after Acc Z exceeded 2g. So none of the factors needed to trigger the G bump landing detection appear to have been met yet it appears to have triggered regardless. I'm assuming there is some sneaky bug that's too obvious to see ... or maybe it's to do with the fact this is a MATEKH743 board.
Also, it's not only looking for Acc Z but Baro rate of change needs to be < -2 m/s/s at the same time and the Baro reading in the log was increasing after Acc Z exceeded 2g until around 100ms later when it did drop.
Just out of interest. How much worth does that check have. When the Baro has such a low cutoff frequency ?
Also, it's not only looking for Acc Z but Baro rate of change needs to be < -2 m/s/s at the same time and the Baro reading in the log was increasing after Acc Z exceeded 2g until around 100ms later when it did drop.
Just out of interest. How much worth does that check have. When the Baro has a 1Hz LPF ?
I agree the Baro update rate is slow but from the testing for https://github.com/iNavFlight/inav/pull/8744 it seems to provide useful input to indicate you're near the ground. I think I added it later after testing as an extra safety check more than anything else.
Still don't understand why the quad disarmed in this case. The only suggestion I can think of is to add an additional AUTO setting to the current ON/OFF setting for bump detection, i.e. it's only active during Autonomous flight. However, given it's not clear why it appears to have caused a disarm in this case there's nothing to say it wouldn't do it during Autonomous flight either so I can't see it being much of a benefit.
@breadoven may you please have a look at this log? It is a test on the bench.
https://mega.nz/file/FrcBhaaQ#0FMrYPvYgeOhWd8A2jdR70PLhK80oI1R7vKiQi4wopA
Thanks for the log file, however it doesn't really tell you very much. If you were trying to trigger normal landing detection (not G bump) you would first have to activate landing detection by raising the throttle above the hover throttle setting then move the quad around to increase gyro rates. This switches on landing detection after takeoff (although it only starts looking for a possible landing when other conditions are met, e.g. RTH landing phase). Doesn't need props on, just hand fly it and simulate a landing.
What would be useful would be a log file of every loop, i.e. set blackbox_rate_denom = 1, just to be sure something odd isn't being missed where Acc Z is concerned.
@breadoven No obligation. I just thought this might be worth noting for future reference. Here is a case I experienced today. It had the bump detector enabled. And it disarmed in a WP mission.
The cause was pitch bank angle speed regulation, when set to the new default nav_max_bank_angle = 35°, on a heavier copter, with a 20km/h tail wind.
After seeing how badly it reacted on a larger copter, when regulating the speed, I'm not surprised it thought it detected a landing bump.. Or bucked the rider off the back.
Pitch attitude fluctuation went from 11° to 33°, with the throttle changing from 44% to 64% in that range, within a pitching interval of 0.1 to 1.4 seconds.
@breadoven No obligation. I just thought this might be worth noting for future reference. Here is a case I experienced today. It had the bump detector enabled. And it disarmed in a WP mission.
The cause was pitch bank angle speed regulation, when set to the new default
nav_max_bank_angle = 35°, on a heavier copter, with a 20km/h tail wind. After seeing how badly it reacted on a larger copter, when regulating the speed, I'm not surprised it thought it detected a landing bump.. Or bucked the rider off the back. Pitch attitude fluctuation went from 11° to 33°, with the throttle changing from 44% to 64% in that range, within a pitching interval of 0.1 to 1.4 seconds.
Thanks for letting me know. It does seem this did meet the criteria for triggering unlike the situation with the original issue which shouldn't have triggered based on the log (still don't understand why). What was hover throttle set at out of interest ? And why was it descending when it should have been climbing to the target altitude of 30m ?
I see a simple solution to fix this particular flaw and it's simply to add a horizonal speed factor, i.e. only allow bump detection to work for essentially vertical landings. This would have prevented this disarm and also the disarm for the original issue itself which occurred at 11 m/s xy speed.
And did you manage to rearm it mid flight ?
The hover throttle is 1410 on this copter. From what I could see in the log. It started to climb. But due to it altering the pitch angle so frequently, as it was attempting to prevent speed overrun, together with the higher pitch bank angle and tail wind. It instead started to slowly loose altitude.
The leg altitude started at 16m, with a slow climb until nav_max_auto_speed was reached... Then it started to looses altitude every bounce. And by the time it had reach 8m, I was about to switch out of WP mode. But it disarmed before I got the chance. It was already on the ground by that stage I flicked the disarm/rearm.
I see a simple solution to fix this particular flaw and it's simply to add a horizonal speed factor, i.e. only allow bump detection to work for essentially vertical landings. This would have prevented this disarm and also the disarm for the original issue itself which occurred at 11 m/s xy speed.
That sounds like a good solution.