[Feature request] Adding an automatic disarm if the gyro sees too much rotation immediately after arming

[braeden]

This would help prevent potential injury when props are installed wrong, flight controller direction is not set, motor direction or order is set wrong, etc.

What do you guys think?

[mikeller]

Hmm, I think the difficult part will be to detect any of these conditions in time to react before the tasmanian devil is taking off. Do you have any suggestions on how to detect them?

[braeden]

I suppose you could check the roll and pitch rate, and of they exceed say 100deg/s when uncommanded within say .5 seconds of arming, then it disarms. Maybe something similar to crash recovery?

[fftunes]

However, a quad with wrong prop- or motor-direction could still keep sitting on the ground after arming, and only unleash taz after enough throttle is applied...

So instead of a delay after arming, maybe a large difference between command and actual rates?

[etracer65]

There would have to be some limiting delay to have this active only for some seconds after the initial activation. If it was still active after taking off then the first gate or branch clip would cause a disarm due to the difference in actual vs. commanded.

Maybe a scenario where it's active for 2 seconds after throttle goes above min_check or if R/P/Y are commanded (even if throttle is below min_check). If actual rate on any axis exceeds the commanded rate by a significant margin then disarm. After the 2 second limit it's assumed you're flying and everything is ok.

Wouldn't stop the initial Tasmanian Devil (which I don't think is possible), but would disarm almost immediately - much faster than the pilot could respond.

Just have to be careful on the triggering threshold - high enough not to trigger as the pilot may be orienting their quad after arming preparing for a race start, but not too high to disarm quick enough.

We can call it "anti-taz" or "Taz Stopper" :)

[jflyper]

I sometimes do a backward flip while taking off to show off. What should I do? 😉

[etracer65]

As long as your tune is not so poor that your error (actual - commanded) on any specific axis doesn't exceed the limit you shouldn't have a problem. :) Although that sounds like a "watch this" moment and we all know how those go...

[ledvinap]

Isn't this going too far? User should have some responsibility/common sense. This feature will only complicate code, create new boundary cases and probably won't work for user crazy enough to need it.

[martinbudden]

I agree with @ledvinap

[etracer65]

Well after watching a friend's quad come spinning straight towards me because he accidentally swapped the two front props I'm not sure it's going too far. Fortunately we were flying indoors and I was behind a net at the time otherwise it would have been very bad. Stuck in the net at chest level about 3 feet in front of me...

[ledvinap]

@etracer: you can't handle all cases. Just consider quad with battery connected as dangerous and act accordingly.. We can do as much as possible to make disarmed quad safe, but even that isn't 100%.. There was a big some time ago, failsafe applied 50% throttle.. Nasty combination with frsky signal lost os short

[ledvinap]

... lost on too short range.. Making the firmware simpler is only way to reduce such bugs. But it would end up too simple to be usable far sooner than being bullet proof...

[ledvinap]

(sorry, on phone)

[mikeller]

I think the 'making it simpler' in this case is not only a good strategy for reducing the chance of bugs, but also one we should be following when it comes to UI design. A lot of these situations (think props on the wrong way) are brought on by user error. In terms of reducing user error, giving the user a simple, understandable user interface will help ('if I move the throttle up, the props will spin faster'). Adding more complexity to this will increase, and not reduce, the chance of user error.

[fftunes]

I don't think safety concerns are "going too far".

I just guess it should be possible to detect within fractions of a second wether the PID start exaggerating "correcting error" in the completely wrong direction and get stuck in a self-intensifying loop.

I'm not the programmer, but you guys can't pretend you haven't done more complicated things in the past... ;)

[mikeller]

@fftunes: As I said in my last comment, the source of the safety concern in this whole thing is the human factor. If the user uses a diligent approach, the existing manuals, and common sense, these dangerous situations will never arise. Considering this, I am not sure if adding technical measures that try to fix the human error is actually going to improve the overall situation. Real world examples show that this often just leads to users becoming even more careless, with no net benefit to safety.

Of more concern to me is that adding this will add non-linear behaviour that the user needs to be aware of (i.e. you can't arm and then straight away do hard move, or the craft will disarm and slam into whatever is in his trajectory). In my opinion this just adds to the things that a pilot needs to be aware of, at a cost to overall safety.

[etracer65]

I really disagree with the philosophy of dismissing an idea because "we can't protect pilots from mistakes." If that was the case then why do we bother to check for zero throttle before arming for example?

This point of view discourages people from looking for what might be a simple implementation that has serious safety benefits. Every one of us here has at one time put props on incorrectly and experienced the result. Every race I go to it happens to at least one pilot during a heat (stress of changing props between heats contributes). Is it the pilots fault? Yes of course, but that doesn't mean we can't help protect them and the others in the vicinity if we have the opportunity. Look how much effort has gone into working around the YSTTM gyro overflow problem. We could have simply said "don't crash and you won't lose your quad!". And yes, I realize I'm being hyperbolic for dramatic effect.

Maybe no good solution can be found but that seems unlikely. I agree that it shouldn't make anything more complicated for the pilot or require extra steps that could lead to more errors. Also false triggers should be eliminated or minimized as much as possible. We don't want racers disarming as they rocket off the line!

So along those lines and to maybe turn the conversation into a productive direction...

I'll throw out the idea of leveraging the existing crash recovery code - specifically the detection logic. This already triggers on high angular error so it may be a good starting point. This would trigger a disarm instead of a recovery attempt so no accel would be required. There would still need to be an "active period" on initial takeoff of maybe a second after which the disarm logic deactivates and full crash recovery reengages (if enabled). So a behavior difference would be that if the pilot crashes on initial takeoff within the first second they get a disarm - not really sure this is a bad thing. A common kind of crash on takeoff is too much initial pitch and the front arms hitting and flipping the quad (at least on race starts). Disarming instead of crash recovery would be more desirable in this case.

So just an idea. Maybe not the best and certainly not the only option.

And Merry Xmas in Australia!

[mikeller]

@etracer65: I am not trying to dismiss this, I am just trying to have a discussion about safety aspects that go beyond how things appear to be on first sight.

To take you up on your example, even the zero throttle check has a negative side: If it causes pilots to change their behaviour, and stop checking their throttle before arming (and I am sure it does in some cases), this will lead to potential accidents once these pilots are using a (say RTF) craft with firmware that does not have a zero throttle check. This very effect was observed and documented with the introduction in anti-lock brakes in cars - this did not cause the accident rates to drop, it just resulted in drivers driving faster in bad road conditions.

My main concern in practical terms is the avoidance of false positives, the craft should behave identically right after arming and mid-flight, so that the pilot does not have to remember 'can't do a flip right after arming'.

In this respect, I really like your idea of making this an extension of the crash recovery mode - this way the activation conditions can stay the same after arming and mid-flight. Also, we already have experience with what parameters are needed for activation, and how they can be configured.

We could do this the 'cheap and simple' way by adding a crash_disarm_window parameter to configure for how long after arming the behaviour should be 'disarm' instead of 'stabilise', and change the on/off parameter to accept 'off' / 'arming only' / 'always', Then we probably want to set 'conservative' defaults for detection, and default the switch to 'arming only'. @martinbudden what are you thoughts on this proposal?

[etracer65]

@mikeller I get your point... but maybe not the analogy. I think we'd be hard pressed to presume that pilots will be more lazy about how they put their props on due to this. You're still going to crash with or without some auto-disarm feature. But the crash will probably be less severe and might save the equipment and maybe prevent injury.

However maybe we can make it so good that it doesn't even flip out (probably unlikely). In that case I can see more questions along the line of "I armed and then when I moved the throttle it twitched and disarmed." But the education would be worth it. Maybe have a unique beep pattern that sounds on the event (something like the S.O.S. pattern on failsafe).

[mikeller]

I think we'd be hard pressed to presume that pilots will be more lazy about how they put their props on due to this.

Good point. I am probably wrong by assuming that pilots aren't already too lazy to do testing before arming for the first time with props on... :-D

If the main concern of this is props being put on the wrong way, then I propose a different, better solution: Whenever a craft is armed for the first time after powering up, disable all motor output control, and simply spin the motors at idle speed until the craft is disarmed and rearmed. This way, the pilots get a chance to confirm that their props are on the right way without any risk of accidents.

[etracer65]

I don't think that would work. Just spinning the motors wouldn't generally tell anything as what we're really looking for is the PID controller to flip out because the incorrect response from the axis. I guess if you waited long enough I-term windup would eventually cause it to flip out.

We'd need to wait until the pilot raises the throttle above min_check or moves R/P/Y rc_command (probably beyond the current deadzone settings). We'd also have to consider how pid_at_min_throttle is taken into account. In the default setting of "ON" the above would work. When "OFF" then only think we can consider if throttle is above min_check because moving R/P/Y won't cause any affect since PIDs are disabled.

Props on wrong is the most common, but it would also help catch novice builders who have the motor directions or order incorrect.

Added later...

From a racing perspective understand that often you don't have any opportunity to power your quad to test until your ready to put it on the line for your heat. There's very little if any downtime between races. I generally try to test arm and wiggle the R/P stick when put my quad on line, but that's not always possible. It's too late to do anything about it anyway other than withdraw.

[mikeller]

I think we need to make a distinction here: Things that will be revealed and fixed during bench testing, and things that won't.

For 'things that won't', the only thing I can think of is some of the propellers being mounted backwards. My suggestion (idling the motors at constant idle speed, without throttle and PID) is only intended to allow pilots to catch exactly this case.

Every other type of misconfiguration that I can think of will be revealed during bench testing, so it should never go undetected to the point where the craft is armed with props on. Fixing the problem of these misconfigurations should probably be addressed by fixing the process. This could probably be done by introducing a 'configuration tested' switch similar to what iNav is doing, and requiring pilots to confirm that they have done bench testing before they can switch this switch to 'tested' (and probably by not allowing them to arm while not connected on USB unless they are in 'tested' mode).

Adding the feature requested here as a 'fallthrough' option still has potential value, but if this is a real concern then fixing the process should be considered, and not just ameliorating the consequences.

[etracer65]

Not disagreeing with the "tested configuration" concept - would be annoying to have to reset it after each firmware flash though. Not sure how it could be done such that people won't just "click the switch" out of habit though.

For 'things that won't', the only thing I can think of is some of the propellers being mounted backwards. My suggestion (idling the motors at constant idle speed, without throttle and PID) is only intended to allow pilots to catch exactly this case.

I don't see how this will reveal that the props on wrong. Even at idle the motors are spinning to fast to visually confirm their direction. Even worse if the first time I'm arming is when I'm under the goggles with the race starting in 5..4..3..2..1. I could simulate this now with set pid_at_min_throttle = OFF, arm and leave throttle at zero with the props completely mixed up and it will just sit there and idle.

The other thing is this is something that does introduce an extra step in the arming process and is likely to be met with much resistance - particularly by racers.

[mikeller]

Not disagreeing with the "tested configuration" concept - would be annoying to have to reset it after each firmware flash though. Not sure how it could be done such that people won't just "click the switch" out of habit though.

This seems to be a constant in just about every aspect of security / safety engineering: Additional safety can only be achieved at a cost to convenience. Taking extra steps to act in a safe manner is annoying. (Also, it should really be done for every config change.) And as you say, 'alarm blindness' is always a problem.

I don't see how this will reveal that the props on wrong. Even at idle the motors are spinning to fast to visually confirm their direction.

It is possible to confirm their direction when they are starting / stopping - I usually do that as a check after changing props. But I am not saying that we should be doing this. I am just giving an example of - if 'props mounted wrong' is the main concern - we can solve this without having to fully arm and then hope that we can disarm in time to avoid damage or injury if things go pearshaped because of this problem.

The other thing is this is something that does introduce an extra step in the arming process and is likely to be met with much resistance - particularly by racers.

I think this is easily fixed - by adding this as an option, enabled by default. We are trying to make it safer mostly for newbies - if experienced pilots find that this does not suit their needs they should be able to override the default.

[etracer65]

I think this is easily fixed - by adding this as an option, enabled by default. We are trying to make it safer mostly for newbies - if experienced pilots find that this does not suit their needs they should be able to override the default.

The problem with this is that every racer and probably a good percentage of other "experienced" pilots will disable this option and be left with no protection. The incident I described where a fellow pilot's quad flew at me wouldn't have been prevented as this was a race start incident (high throttle off the line causing violent results) and I can assure you we would have this feature disabled. Having some protection always be active behind the scenes with crash_recovery integration (or some other scheme to detect/disarm) would help in every case. If done right then the pilot will not even realize the protection is there until they need it. To me this is the ultimate solution.

We can't ever stop people from making mistakes but my goal is to minimize the bad consequences wherever possible.

Heck, last time I put a prop on wrong it wasn't even my fault. My daughter sorted a batch of props into normal and reverse bags for me and she goofed on a few. Cost me a qualifying heat and a couple of broken props. Technically it was my fault since I didn't catch it in the scramble between heats when installing, but still...

[mikeller]

The problem with this is that every racer and probably a good percentage of other "experienced" pilots will disable this option and be left with no protection.

Totally agreed. But the same applies to the 'misconfiguration detection and disarm' function - every racing pilot will disable this if there is even a 1 percent chance that it could kick in accidentally (clip ground on take off), and cost them an otherwise winnable race. (At least that is the experience that I have had in other sports - competitors will go to great lengths to gain as much competitive edge as they can legally get away with.)

[etracer65]

So we just need to make it perfect and and only trigger on an extreme event like the Tasmanian Devil! :) I haven't played with crash_recovery much but the tunable parameters look like it'll offer enough flexibility. But your earlier suggestion about having a preset setting for the crash_disarm_window makes sense as we wouldn't want to leave this adjustable or rely on the users settings for crash_recovery. Just have to find the appropriate settings. Should be easier than tuning real crash recovery as a "normal" takeoff is a lot less dynamic than crashes occurring during flight.

[fftunes]

Of more concern to me is that adding this will add non-linear behaviour that the user needs to be aware of (i.e. you can't arm and then straight away do hard move, or the craft will disarm and slam into whatever is in his trajectory). In my opinion this just adds to the things that a pilot needs to be aware of, at a cost to overall safety.

Imho not if done right. As i said, it only takes fractions of a second for the quad to completely freak out. I think in the past i read numbers like 50-60ms for motors to reach full throttle? Then there's no reason for the "protection phase" to be a lot longer than this. It could still be made adjustable, say from 0-500ms for example, so everyone could adjust to their gear.

How could we detect that PID try to correct but actually make it worse? We should make out a logic to detect the self-intensifying part of error rising. Crash detection alone is not quite the same.

[RipperDrone]

Wow what an extensive thread about safety features rationale :-) Understanding where both of you are coming from, I just wanted to throw in my Automotive point of view: Did anti-lock brakes (you brought up this reference in the discussion ealier) cause drivers move closer to physical limits of the car, thereby putting safety to risk? Yes! But have anti-lock brakes been dropped for that very reason? No! They're on virtually every single car today, for the overall net safety benefit. Next will be more & more autonomous (ADAS) functions, again associated with safety benefits and malfunction / adjusted drivers' behavioral risks at the same time. So whenever some feature helps overall net safety in Automotive, it does get very much attention and priority...

[mikeller]

@RipperDrone:

Wow what an extensive thread about safety features rationale :-)

Yeah, I needed something to break the boredom while bisecting master. :stuck_out_tongue_closed_eyes:

No! They're on virtually every single car today, for the overall net safety benefit.

Very good point, taken.

[chime13]

Preflight checklist.... 1 - visual inspection of craft 2 - observe prop orientations 3 - install fresh battery 4 - place on level surface 5 - verify TX/RX operation 6 - arm and fly away from crowds

I accept responsibility for my actions - I kinda prefer it this way

[phobos-]

I'm with @mikeller on this one. Now imagine a situation that indeed this feature got implemented and is working perfectly. A new pilot happens to have a quad that does not want to take off once he arms it and tries to fly it. How would he diagnose the problem? Probably by disabling this feature right away to see what is going on and rule some possibilities out. Back to square one.

[RipperDrone]

If the feature works perfectly a new pilot can always take off. It just engages once there is massive gyro rates detected in armed state. Whether you hold it in your hand inducing high gyro rates and then arming unintentionally or whilst flying and hitting high gyro rates, shutoff will be the best option. Only thing which needs to be addressed carefully is 'high gyro rates during regular flight / FreeStyle manoeuvres'. This should not lead to a false positive...

[fftunes]

Let's pretend this "misconfiguration detection phase" would only last for around 100-250ms max after passing min_check - i don't think this would prevent you from doing harsh moves right after take-off.

Especially if the detection logic was smart enough to see that error coincides with stick commands and would not kick in in this case.

I repeat, what would be needed here is different from crash prevention. Somehow we need to figure out how to check for PID going crazy all by themselves.

[fiveangle]

@RipperDrone : If the feature works perfectly...

That there is no easy way to ensure this premise is the issue.

The anti-lock brakes analogy is a good one that illustrates mikeller's point of needing consistent UI : if any safety measure can be added that does not change UI (like anti-lock brakes), it absolutely should be.

This case doesn't pass that test. The feature proposes that under some circumstances the UI changes. In such situations, the unsafe condition must be 100% assured, else routine false-positives would result in the safety feature being watered down to the point of uselessness (see Windows Data Execution Prevention dialog error circa Vista). This is also @phobos- argument above.

This safety feature cannot be easily implemented to meet the level of assured safety fault to pass the test. That's what's being argued here.

If anyone can come up with a viable test condition (tested - not just an armchair quarterback theoretical scenario) that assures no false-positives, then I'm sure everyone would be all-ears. Knowing that I rely on the ability to re-arm mid-air under some emergency situations and that I am not the only one, I don't see an easy solution. It would be nice, but is simply impractical as of today.

-=dave

[mikeller]

@fiveangle:

Knowing that I rely on the ability to re-arm mid-air under some emergency situations and that I am not the only one

I have thought about that part of it - as you say that is one use case where you absolutely cannot afford to be caught in a false positive. This could probably be worked around by only triggering the 'misconfiguration disarm' if it is the first time that the craft is armed after being powered up - and to counter the 'hold my beer while I try again' effect, arming should be permanently disabled (same UI as failsafe) after the disarm was triggered.

[RipperDrone]

Maybe introducing a completely different way to approach this issue - at least 'halfway':

Could the 'calibrate' procedure be extended into a plug&play calibration like this:

• put props on, put the quad level on the ground
• trigger p&p calibrate by switch
• quad idles all 4 motors, then slightly speeds up (idle_percentage increase by x%?) one motor at a time, measuring gyro feedback, thereby auto-detecting mounting direction of FC and good/bad props configuration. Yields an SOS beep sequence if props are wrong, yields an OK beep sequence once props are ok and FC/gyro mounting angles have been auto-adjusted as per the p&p calibration routine.

So if users do this routine, they should be safe. If they skip it - their fault, can't be helped...!

[mikeller]

@RipperDrone: That can even be done entirely without props on a flat surface. And it's part of any good set of instructions on how to bench test. The problem there seems to be that users choose to skip this step and instead put props on and try to fly. Adding this step for a second time is not likely to improve that, unless we make it mandatory like I proposed above.

[etracer65]

@mikeller Making the detection only work on the first arming wouldn't be good for racing scenarios. Often when putting the quad on the starting line there's only time for a quick arm/disarm to make sure the props spin. Also while sitting there under the goggles sometimes there's a delay and pilots will like to spin their motors intermittently to keep their vtx's from overheating. This doesn't usually involve any stick movement or throttle so if the props were on wrong it's not likely to cause a spaz-out.

Dealing with mid-air rearming could be handled with a disarm logic lockout after some amount of successful time of "successful" flight on this battery. We only need to worry about dealing with the Tasmanian Devil the first time the PID controller tries to move the craft. If that doesn't cause a runaway feedback in the PID controller then the props, motor directions, etc. are correct.

1. Pilot arms and motors spin (or not if motor stop is enabled) - logic disabled
2. Pilot raises throttle above min_check or moves R/P/Y enough to cause PID controller to react - logic enabled
3. 500ms (or some yet to be determined threshold) pass with no crash - permanently disable logic for this battery.

[etracer65]

And as far as detection goes, maybe the crash recovery logic is more complicated than we need. It seems like it shouldn't require anything more than looking for "excessive" PID_sum on any axis - probably over a (short - maybe 100ms) interval in pid.c (before it is limited in the mixer). This should give a clear indication of runaway caused by the craft not responding correctly to the PID controller.

[etracer65]

I did some crash testing (contained inside a large plastic toolbox) with an old quad by intentionally changing the gyro alignment to be 90 degrees off. This causes the runaway PID/spaz-out for testing.

I then modified pid.c to check for abs(PID_sum) > 600.0f (just a guess/starting point) on any axis and trigger the disarm. Testing seemed positive at least in triggering the event.

For further testing, what's the best way to trigger a full disarm? I used a call to disarm() but this seems to only be momentary and the quad immediately re-arms because the arming switch is still active (I'm assuming). Calling disarm() gave interesting results in that it kind of acted like a rev limiter and stuttered right at the threshold. Not what I want but interesting.

Here's a log of what happens during the spaz event that I'm using as a baseline. This is an old quad running 3S so it's less violent then it could be. The event was triggered by leaving the throttle at idle and slowly increasing roll until it flipped out (roll and pitch were reversed because of the gyro alignment mismatch).

baseline - gyro alignment incorrect 2.BBL.zip

[RipperDrone]

Maybe I'm oversimplifying the underlying problem, but shouldn't it be possible to detect an accel/gyro signal which is almost at rest / 'calm' first (quad at standstill) and then upon switching the PID loop live shows an INCREASING error accumulated despite corrective signals from inputs received and motors trying to correct towards smaller errors?

[etracer65]

Looking for excessive values in the PID_sum is effectively this. The error is increasing (or at least not getting better) and the PID controller is pushing harder and harder (increasing PID_sum) but the wrong way so a runaway event occurs.

[mikeller]

@etracer65: I'd probably look into triggering a failsafe event - that one will stay on once the condition triggering has gone away. In general it probably makes sense to put the craft into failsafe once this is triggered, since fixing the condition that caused it should be done while powered off.

[brycedjohnson]

This would help in situations when filters are wrong and resonance causes it to jump in the air. Like the people that went from biquad to pt1 on noisey quads and had them taking off on their own. That is something that you can't test on a bench without props.

Also might help in situations such as sort of bug with the sdcard DMA being ON on some omnibus boards. They would takeoff in the air. Had that happen a couple times.

I'm pretty careful in general with bench testing, but I've had the FC orientation wrong once or twice... didn't catch it because my Acc was off and I that is how I verify orientation. Just about all my quads have yaw=90 or 180 or something.

Also I'd be glad for the other guy at the starting line to have this.. it would stop someone elses quad from hitting me when people are doing a quick spin up check when we are putting quads on the line. Usually I see it happen a couple times at each race. (props on backwards, or something else busted)

I'm in favor of a one time check on first arming (and perhaps throttle above min check or pitch and roll moving) for the first .5sec or less.

[fiveangle]

@fftunes - However, a quad with wrong prop- or motor-direction could still keep sitting on the ground after arming, and only unleash taz after enough throttle is applied...

Barely on-topic, having recently had board orientation set incorrectly upon initial test (outdoor and disarm switch already half-activated before throttle-up), the "Tasmanian Devil" description is exactingly apropos 😝

-=dave

[braeden]

Here's what I've gathered. If PID sum experiences rapid accumulation after min_check has been reached within, say .5 seconds, a failsafe condition should trigger.

An adjustable CLI command could be used to change the "delay_taz_after_thottle" timing, or to disable it entirely.

@etracer65 would you be willing to test your quad again but raise a fail-safe instead of disarm?

[mikeller]

@brycedjohnson: Not sure if disarming the craft is the correct way to remediate these situations. In flight it is hard to distinguish between what is misbehaviour but controllable and what is uncontrollable. In controllable situations (or situations like the SD card DMA issue that can be remediated by switching off logging), disarming seems to be the wrong course of action, compared to a controlled emergency landing.

[brycedjohnson]

@mikeller Yeah I agree it can be hard to tell is controllable or not in flight. Much like it is hard to tell when the gyro was inverting on in the ysttm issue.

All those situations above are where it was uncontrollable instantly upon arming (maybe some where upon throttle above min throttle) so that should help limit the problem a bit. The only way out for all of them was to disarm. If there was a way to reduce some of them without causing a false positives I think it would be great.

The SD card DMA issue example I ran into was before there was a fix. 1 out 10 times it would go nuts (upwords) on arming. If there was a way to catch an issue like that, it would have been much safer for me, but in that case maybe it wouldn't have caught it.

I know it is silly to be try and limit issues caused by mis-configuration or props on wrong, etc... But I've seen it happen to people quite a bit and although a quad flying at your face is a good reminder to double check everything on the bench, people don't seem to learn (or just make mistakes like I have done a few times).

[etracer65]

Although this logic will be beneficial for configuration problems like motor direction, motor order or flight controller orientation, that's not really my goal. These things should be caught on the bench. My real motivation is in-the-field events like props on wrong. Everybody makes mistakes and this could help make those mistakes less costly.

[etracer65]

I did some more testing with code that now activates a failsafe (basically simulates toggling the failesafe kill switch). Seems to work well and depending on the PID_sum threshold used it catches the event very quickly - even before the quad flipped! Tested with the gyro oriented incorrectly and with front props swapped and both behaved as expected. Then I fixed the gyro and props and successfully hovered without the detection kicking in. So the PID_sum limit threshold seems to look promising.

For a fully complete solution the following would need to be added:

1. Successful takeoff lockout. Basically a mechanism to deactivate the threshold logic after a successful takeoff. Something like X time after throttle reaches a threshold (like maybe the airmode_start_throttle which defaults to 1350).

I don't think we need any initial time for the check to be completed after arming. It's possible to arm and just sit there with zero throttle and have nothing bad happen. The spaz-out happens when throttle is applied and or enough rate is requested by the sticks. So ideally we want to determine that we're in flight conditions and nothing bad has happened.

2. Only perform the check once per battery. Once we successfully get through the takeoff phase we don't need to check this again.

This would solve the re-arming in the air problem.

Also we need to consider some other scenarios:

Arming in a self-level mode. Depending on the orientation of the quad when the arming switch is activated it will "snap" into level. Not sure yet if this would trigger the PID_sum threshold.

Dealing with motor_stop. Initially moving the throttle above min_check shouldn't cause a problem as the quad has no rate to correct. Some interaction again with self-level modes.

pid_at_min_throttle = OFF shouldn't be a problem. Below min_check it's impossible for it to spaz-out because PIDs are disabled. As the pilot advances the throttle above min_check at that point the spaz can occur but we should still be in detection since we're not above the threshold for "successful flight".

Small "bump" when taking off like pitching too far forward and dragging the battery. Not sure yet how this will behave. I'm a little concerned that the initial hit will cause a big enough (though extremely short lived) PID_sum spike to trigger detection. May need logic that looks for the PID_sum to be over the threshold for a preset amount of time.

And probably some more edge cases I haven't thought of yet...