Failsafe and InflightAccCalibration

Post Reply
frogstarb
Posts: 59
Joined: Wed Jul 25, 2012 10:52 pm

Failsafe and InflightAccCalibration

Post by frogstarb »

Something that just occurred to me, thinking back to some thread where there was some interest in using baro or acc to automatically calculate the correct failsafe throttle as the same copter would be flying with different payloads; Why not set a "HOVERTHROTTLE" in eeprom when setting the acc calibration in flight, and just use a fixed amount to decrement that for landing? This way we could set up the slow descent throttle each time we fly with a different payload.

It would be great to also have sonar landing and even an acc redundancy check by making sure that there is a negative Z axis ACC value to boot, otherwise the throttle setting needs to be decremented for sure, but I think that the hover throttle setting as a manual parameter would be really helpful.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Failsafe and InflightAccCalibration

Post by jevermeister »

Interesting Idea for sure, especially for pilots with expensive gear onboard (DSLR etc).

But, in my opinion one should not overrate the failsafe function, if you loose connection to the copter, the savest thing to do is jsut shut down the engines, I do not fly over people so a direct crash won't hurt anybody. A copter that is in fast forward flight that looses tx would drift fast forward in failsafe and could hurt somebody or damage something.

So keep your failsafe time as short as possible, I have 10 seconds, enough to change my TX LiPo.

I started on coding

Failsafe Baro landing,
failsafe sonar landing,
failsafe RTH and land (w/wo baro / sonar)
failsafe PH and land (w/wo baro/ sonar)
failsafe autodestruct (by shortcircuiting LiPo with relay switch)

frogstarb
Posts: 59
Joined: Wed Jul 25, 2012 10:52 pm

Re: Failsafe and InflightAccCalibration

Post by frogstarb »

Well, when you have a 1kg flying machine doing 20km/h (my case, others obviously have heavier and/or fly faster) I'd much, much rather have failsafe stabilize it and even counter the movement (though without a GPS or speed sensor that's not going to be possible, I guess) and start a controlled descent (while the buzzer is screaming) giving people around time to get out of the way than shutting the engines down and have the 1kg rock shoot towards someone's head...

Baro landing I have very little faith on, as my baro (BMP085) seems to not be all that precise, or I might just need more pid tunning, not sure.

But I digress... setting the failsafe throttle statically in the code is not very helpful, and since you already coded inflightacccal I believe this extra setting would be a great enhancement. I know failsafe is just that, a last resort safety net, and with GPS it can get really safe with your RTH/PH and land, but even then the gps height resolution isn't good enough, so I guess a sonar or a better baro is required to be really safe.

Gotta get myself a sonar and a gps soon :)

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Failsafe and InflightAccCalibration

Post by Hamburger »

I think for safety reasons the handling in case of failsafe must remain as simple as possible. You do not want to have weird errors in that part of the code. So the simple slow descend seems just right. I will turn the failsafe throttle value into a tunable parameter soon, so you can change it whenever your load changes (like with vs. without camera, small vs. big battery etc.)

frogstarb
Posts: 59
Joined: Wed Jul 25, 2012 10:52 pm

Re: Failsafe and InflightAccCalibration

Post by frogstarb »

Hamburger wrote:I think for safety reasons the handling in case of failsafe must remain as simple as possible. You do not want to have weird errors in that part of the code. So the simple slow descend seems just right. I will turn the failsafe throttle value into a tunable parameter soon, so you can change it whenever your load changes (like with vs. without camera, small vs. big battery etc.)


Agree to the simplicity part, but I don't think a manual entry number is less error prone than an in flight procedure than you must do while hovering. But it does add one extra place for bugs so I guess I understand you not going that route. I would still like to have at the very least a way to assert what the hover throttle level is, so maybe the advisory value is safe enough if left isolated from the actual parameter change?

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Failsafe and InflightAccCalibration

Post by jevermeister »

Hamburger wrote:I think for safety reasons the handling in case of failsafe must remain as simple as possible. You do not want to have weird errors in that part of the code. So the simple slow descend seems just right. I will turn the failsafe throttle value into a tunable parameter soon, so you can change it whenever your load changes (like with vs. without camera, small vs. big battery etc.)


I ve never seen it from that point of view and Hamburger is right.
I titally agree on that

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: Failsafe and InflightAccCalibration

Post by Mis »

For some time I'm working on intelligent failsafe with return to home.
First, stabilization is activated at the level of hovering, then after checking the battery status the copter lands with baro (if battery is low), or perched on a pre-defined height (eg 20m up from takeoff height), then executes a return to home using GPS and then automatically land using baro.
Of course, after restoring control , whole procedure is interrupted. Every stage have timeouts too.
In-flight tests were very encouraging. The entire test on the CRIUS AIO Pro controller.
The throttle value for hover point is memorized during test flight. First you start, make a hovering, then 4 times within 5 seconds, turn on and off the baro switch. After landing the hover point is memorized.

frogstarb
Posts: 59
Joined: Wed Jul 25, 2012 10:52 pm

Re: Failsafe and InflightAccCalibration

Post by frogstarb »

I get nervous thinking about landing with baro... I mean, mine appears to have an accuracy of +-1m, which would make it unusable for vertical speed measuring. But the hover point setting is exactly what I meant initially, with some value subtracted from it for failsafe landing instead of a generic, hard-coded value in the source code.

But RTH failsafe feels a bit dangerous if you are doing long range FPV, as there might be people in the way between where you are and the home pos or, not as bad but more likely, a high tree or building. Unless you are using horizontal sonars, I don't think it is safe at all.

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: Failsafe and InflightAccCalibration

Post by Mis »

IMHO The coming home is less dangerous than crash or fast landing at the site of lost control.
If the copter climb up to 20-30 meters and start return to home, you have a great chance to quickly restore RC control and manual return to home then land.

LenzGr
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany
Contact:

Re: Failsafe and InflightAccCalibration

Post by LenzGr »

Mis wrote:IMHO The coming home is less dangerous than crash or fast landing at the site of lost control.
If the copter climb up to 20-30 meters and start return to home, you have a great chance to quickly restore RC control and manual return to home then land.


Only if there are no obstacles between you and the copter and it lost signal while going behind a building, for example. You can not always assume that going home on a straight line is not blocked by any objects (e.g. a tree). If the copter could log its path (e.g. by memorizing some recent waypoints), it could try to backtrack its way until it either has better reception or runs into a time out and gives up (and performs a slow descent).

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Failsafe and InflightAccCalibration

Post by Hamburger »

on the other hand when reverting its original path while in second half of fuel capacitiy it will run out of fuel while on its way.
No single best strategy, some AI needed :)

frogstarb
Posts: 59
Joined: Wed Jul 25, 2012 10:52 pm

Re: Failsafe and InflightAccCalibration

Post by frogstarb »

So there are two main solutions with the simplest machines (no GPS, no sonar), and that's "drop like a rock" and "slowly approach ground with skin cutting propellers"

I still prefer the latter, especially if I can add a loud buzzer to it, but I can also see the point for the former. This thread has derailed a bit, though, as what I really wanted was a good way to set descent throttle on failsafe without much guess work, but I see this point is problematic in many ways.

As for RTH failsafe, the logged path solution is great assuming the battery is monitored and the return is aborted if battery becomes too low (and either drop or slow descent would apply), but there's another option using a front facing sonar, and that's to try and avoid obstacles. It's not as easy as that (does it climb or go around?) but that way it is a bit safer to try the shortest route to home. I'm not sure we're not overdoing the failsafe thing here, but as a separate feature for FPV flights it seems interesting.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Failsafe and InflightAccCalibration

Post by Hamburger »

I still want a simple rock solid implementation of failsafe strategy.
When it is needed it must just work. So it must be as simple as possible.

frogstarb
Posts: 59
Joined: Wed Jul 25, 2012 10:52 pm

Re: Failsafe and InflightAccCalibration

Post by frogstarb »

@Hamburger: agreed completely. While what the strategy is can be open to discussion, the simplicity of it must be priority. If you want a failsafe rock dropping, then that's very much obvious... the shortest codepath to disarm motors, period. I don't like this approach but that is personal bias.

The other approach that is default on multiwii (if FAILSAFE defined) I like better, but the throttle being statically set in the source means that if I have it correct for the no payload setup, putting a camera on my copter will make it behave like a rock dropping, only with the propellers spinning! This is even worst than no failsafe at all.
OTOH, setting it for payload means that when flying with no payload will most likely make the copter shoot up on failsafe engage... and then come back as a rock when the battery dies only from much higher.

That's why I feel the hover point must be field configurable somehow, and that is why I wanted to piggyback on InflightAccCalibration, but I now feel there should be a separate approach having used InflightAccCalibration without much success. Probably getting the copter "light on its feet" just before takeoff and flipping a switch would be the most fool proof approach?

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Failsafe and InflightAccCalibration

Post by jevermeister »

I want to give my 2 cents for the last time now:

the failsafe is the first thing to test if I upload new software. It has to be simple and safe for me.
My copter hovers and descends for 10 seconds and than shuts down - thats it.
It is my personal choice.

My opinion is as follows:
We are all grown up individuals, if you want to code fancy failsafe algorithms do it, everyone can decide what the copter deos if he looses tx. Maybe if you carry a fancy DSLR like dramida you want to get it back in one piece, if you fly stunts like me you want it back in any state but without killing someone.

I think it is ok to offer every option possible and let the users decide which one to use.
BUT
I experienced that almost noone here took the time to really test the failsafe on his own copter - that is siomply carelss and dangerous.
We should implement immediate shutdown on tx loss as default, so the copters crash immeadietly and teach those guys a lesson they wont forget without risking to hurt people, if it crashes over someone youa re doing it wrong anyway. These are no frickin toys !

Nils

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: Failsafe and InflightAccCalibration

Post by Mis »

Some piece of code for inflight hover point setting. Switch baro switch forth and back four times within 5 seconds then land. Need to add some global variables and conf.HoverGas in conf structure.

Code: Select all

    if(f.ARMED) {
      // Hover THROTTLE value memorisation routine
      if(HoldSwitchTim) {                                // time counter for saving HoverGas value
        HoldSwitchTim--;
        if(HoldSwitchTim == 0) {
          HoldSwitchCnt = 0;
          if(SaveHoverGas==1) {
            toggleBeep = 5;                             // saving confirmation beeps
            SaveHoverGas = 2;
          }                   
        }
      }
      if(rcOptions[BOXBARO] != MemBoxBaro)   // Baro BOX is switched
      {
        MemBoxBaro = rcOptions[BOXBARO];
        if(HoldSwitchCnt == 0) HoldSwitchTim = 250;      // 5 seconds max for 4 flip-flops
        if(++HoldSwitchCnt >= 8) {                       // 4 flip-flops witchin 5 seconds is counted
          SaveHoverGas = 1;                              // set flag for save to EEPROM after landing
          conf.HoverGas = constrain(rcCommand[THROTTLE],1200,1800); // update hover value
          HoldSwitchCnt = 0;
          HoldSwitchTim = 20;
        }
      }
    }else{  // if(!f.ARMED)
      if(SaveHoverGas) writeParams(1);
      SaveHoverGas = 0;
   }

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Failsafe and InflightAccCalibration

Post by copterrichie »

In my opinion, the ultimate Failsafe should be able to do this: http://www.youtube.com/watch?v=ylwYd8ZXz94

With the addiction of sounding a warning buzzer to alarm anyone that maybe in its path for landing.

Post Reply