Crashed in STABILIZE due to (very) bad GPS conditions with EKF enabled

[Holger Steinhaus]

Today I made a short test flight - much shorter than originally intended. GPS conditions were pretty bad (several thick layers of clouds), horizon obstructed up to 45° of azimuth, HDOP has improved below 3 when I decided to takeoff. 

A few seconds after takeoff, hovering in about 1m in STABILIZE, there were sudden uncommanded roll impulses of the copter to the right, I countered them and tried to land asap. Due to tue large roll impulses, I landed on one skid, when the next heavy roll impulse happened, turning the onto its back. As the logs reveal, during arming the HDOP went to about 6, coming back to 2.6 during flight, and jumping back to 6 shortly before the crash. During the seconds before the crash, there were amazing GPS speeds (around 10m/s), while the copter was definitely nearly static. Binlog is available on PN request.

Is there any way to safely and completely disable any GPS support for this kind of test flight? Is setting EKF_USE to 0 enough?

Holger

[Łukasz Wasik]

Same problem here.

Reported: https://github.com/diydrones/ardupilot/issues/1402 

[Randy Mackay]

Holger,

 

     I’ll take those logs if you’ve got ‘em.  Alternatively you can post the logs to the AC3.2 thread.

            http://diydrones.com/forum/topics/arducopter-3-2-beta-testing

 

-Randy

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Riseborough]

Holger,

Are you able to send me your log? The EKF has a gate to reject large velocity glitches, but if they persist then it can be a problem.

I'm not aware of a way to stop it using GPS other than unplugging it. This is something that will be addressed later as part of the optical flow update for EKF.

Regards,

Paul

[Paul Riseborough]

Holger,

Although the EKF did eventually reject the bad GPS velocities, it was close to doing so earlier. The attached figure shows the normalised innovations starting just prior to the GPS glitch. You can see that the normalised velocity innovation SV almost makes it to the rejection threshold of 1 at the start of the glitch.

Setting EKF_VEL_GATE to a smaller value (eg 3 instead of the default of 6) would make it more resistant to these types of GPS errors, at the expense of being more likely to false trigger the EKF velocity and compass variance check, so if you do so, then it would be advisable to relax the variance check by setting EKF_CHECK_THRESH to 1.6, or if you are confident in your compass, disabling altogether by setting EKF_CHECK_THRESH to 0.

The GPS only had 4 sats for most of the flight so regardless of the HDOP it was risky. Probably the safest strategy in similar circumstances if you needed to fly at low speeds in stabilise would be to disconnect the GPS.

Regards,

Paul

On Sunday, 21 September 2014 21:40:11 UTC+10, Holger Steinhaus wrote:

[Holger Steinhaus]

Hi Paul,

thanks for the analysis. 

 

Although the EKF did eventually reject the bad GPS velocities, it was close to doing so earlier. The attached figure shows the normalised innovations starting just prior to the GPS glitch. You can see that the normalised velocity innovation SV almost makes it to the rejection threshold of 1 at the start of the glitch.

Yes, after looking into the logs, I also remember both glitches. They were in oposite direction, I guess the first time the new sat was found, later it was lost again. 

 

The GPS only had 4 sats for most of the flight so regardless of the HDOP it was risky.

Yes, that's obvious now. Unfortunately I only had the HDOP number displayed on my radio (have changed that now) and I am still a bit a bit surprised that the HDOP number does not include such errors, that obviously have diluted the precision of the horizontal position. Additionally, I did not have any trouble at the same location about 100 times before (which is probably a great achievement of the glitch filtering, but nobody is ever reports if it works ;-) ). 

 

Probably the safest strategy in similar circumstances if you needed to fly at low speeds in stabilise would be to disconnect the GPS.

Will do that in the future. May be it would be a good thing to have a GPS kill switch? So if I am aware that the GPS is probably not working well on my chosen flying site, I could simply disable it. Of course there should be some logic preventing changes to GPS modes...

Holger

[Robert Lefebvre]

Hi Holger, I have also been surprised on a few occasions, how bad the GPS position can be while still reporting a not-terrible HDOP.  It's especially true when the GPS had a good lock, and looses it, the HDOP can take a few seconds to report bad.

In some testing I was doing with complete GPS loss, I'd see the position jump 100m instantly, but the HDOP would still report good for several seconds.  

A GPS kill parameter has been talked about in the past.  It's necessary, and I imagine will be added eventually.  We have the same problem with people who attempt to fly indoors.  Obviously just making a parameter to disable it is easy, but we need to figure out all the corner-cases where such a parameter would cause problems.  ie: people forgetting to turn it back on, etc.  I think last time we talked about it, some ideas were tossed around such as a different tone on arming, a warning in GCS, etc.  One of the big risks is people taking off and flying in Stabilize, without knowing that RTL will not work.

Rob

[Jesus Alvarez]

I must admit I am suprised to learn that GPS is used in stabilize mode.

I really though that STABILIZE was a only IMU/COMPASS mode and thus the safest and inmune one.

Just curious here. What is GPS used for in STABILIZE?

And more important, Would it be interesting to either leave GPS out of Stabilize or create a more raw mode as a failsafe and backup mode when we have a situation like the one mentioned here?

[Gary McCray]

Hi Jesus, 

No GPS isn't used in Stabilize mode, Robert was simply stating that if you get an RTL while in Stabilize mode it won't work if the GPS isn't working. 

It will go to alt hold or auto land instead depending on which you have selected for GPS fail mode.

Taking off and flying around in stabilize without having gotten GPS lock is a very common situation and people are often surprised when some failure occurs and it doesn't do an RTL which they have selected as their failsafe fallback.

Clearly from what Robert is saying above a condition of inadequate GPS glitch detection / response is taking place which is still permitting the GPS to jump the position 100 meters or so, this undoubtedly is responsible for the copters suddenly departing their current course and heading off in some indeterminate direction.

I have encountered this several times myself as has my friend Oliver.

This is what glitch detection is supposed to solve, but apparently there are still some serious latency issues.

One thing that probably will help are the new UBLOX M8 series GPS/Glonass/etc sensors which are typically showing over twice the number of satellites continuously (with correspondingly improved HDOP) versus what we are using now.

But it also seems glitch detection and response still has room for improvement as well.

Best Regards,

Gary

[Robert Lefebvre]

Actually... GPS is used in a way, even in Stabilize.  Stabilize, as we all know, attempts to self-level the copter.  To do that, it has to know which way is "down".  The primary way that it does this, is to integrate the gyros over time, and try to remember how far it has rotated from level.  However, this is always subject to error due to drift of the gyros, vibration, numerical inaccuracies, etc.  So, to help out, it also uses the accelerometers.  In a perfect level hover, on a perfect setup, the accelerometers indicate 0 acceleration on both the X and Y axis, and the Z axis will show -1G, representing gravity... however, if the copter was oriented nose-down 90 degrees, and you had lots of power applied, you would find that the accelerometers would indicate the exact same thing, you'd see -1G due to the copter accelerating forward, and you'd have 0G on the X-axis as the copter will be freefalling.

So even with the gyros and the accelerometers, there can an ambiguity about which way is down.  The GPS is used to help with this.  In the case above, the GPS would be telling the system that it is accelerating forward, so it would know that the accel vector is not actually pointing down, but must be pointing forward.  

This is why the GPS is actually used in Stabilize mode.  It's not used to help fly the copter, but it is used to help the system keep track of which way is down.  Without this, it was quite common for the system to get confused about which way is down any time you were doing something other than hovering.

However, when the GPS is bad, it reports false accelerations.  This rolls through this calculation, and ends up upsetting the estimation of where down is.  Trying to prevent this is what Paul and Jonathan have spent a lot of time trying to do.  It's not easy.

[Gary McCray]

Hi Rob,

I stand corrected, 

I didn't know GPS was being used in Stabilize at all.

All the simpler controllers out there that don't have GPS simply rely on the Gyros and accels to provide the necessary down reference and functionally we operate the same way.

I can see that the GPS could compensate for confusions, but it also seems to me that those confusions are only likely to occur under extreme maneuvering conditions such as acrobatic maneuvers and overly gusty wind conditions.

I have never seen significant flight path departures taking place in Stabilize mode although I have seen the occasional odd twitch or bounce that seemed to have no relevance to any wind or control actions.

And I often take off and fly around in Stabilize without achieving GPS lock.

So I presume the mixing in of GPS is unlikely to generate significant (bad) flight behavior regardless of GPS condition or erroneous reporting when in stabilize mode.

Best Regards

[Gary McCray]

Hi David, 

I was just saying (incorrectly as it happens) that GPS wasn't used in the actual flight operation of Stabilize mode.

I was not saying that it couldn't be used by one of the failure modes that could happen while in Stabilize mode (such as fence breach).

Or more particularly by Robs original consideration that those expecting an RTL to result from whatever failure or breach mode might not get the response they expected.

It is interesting to me that GPS integrity does appear to have the possibility of impacting stabilize mode flying and I would like to know more about what the expected "departures"  from normal flight in stabilize mode might be expected to be based on GPS problems.

Best Regards,

Gary

On Sunday, September 21, 2014 11:42:39 AM UTC-7, David Pawlak wrote:

@Gary,

There seem to be two situations here:

1) Glitch detection problem AND less likely (in this case) but possible
2) RTL due to "Fence Breach" (Isn't this still possible?...  Fence enabled, GPS prearm disabled)

We have seen cases where in the early stages, takeoff with instable GPS causes GPS glitches. Various levels of effort have gone into resolving these situations, but the fact that GPS glitches and Fence breaches can happen in Stabilize mode means that GPS IS USED IN STABLIZE.

Other threads here have also made it clear that GPS IS used in Stabilize mode.

Fortunately the damage in this case is minimal, but it is good that it has happened as a reminder. THAT GPS IS USED IN STABILIZE MODE:

[Jesus Alvarez]

Gary,

I have read again Holger's post and I still understand that the uncommanded/undesired roll seems to be caused by bad GPS.

If a bad GPS can cause a failsafe mode like STABILIZE to act like that, it is something to look at.

[David Pawlak]

Hi Gary,

LOL You repsonded before I could delete my post. Rob handled it much better.

In fact I tend to agree with you in this situation. It's sort of a pet peeve I have. It's quite natural that one thinks that the vehicle should not rely on GPS in STAB mode, and most still believe such. To the extend that more than a few stiches have been required. Our users are RTFers. Turn it on and fly.

I'm still not sure what happens in the case that CIrcular Fence is enabled, and GPS prearm check is disabled, when a glitch takes it beyond the fence in stabilize mode. Perhaps the glitch detect prevents an RTL trigger...

[Gary McCray]

Hi Jesus,

Yes, I agree, it does seem that this is exactly the example that illuminates the potential difficulties involved with using GPS in Stabilize mode.

Possibly we need 2 Stabilize modes, perhaps: Traditional Stabilize which simply relies on gyros and accels and Enhanced Stabilize which mixes in GPS down correction.

Clearly there are significant issues to be worked out in the GPS "enhanced" part anyway.

I always looked at stabilize as the mode that would bail me out of anything, in particular GPS screw ups, now it seems we have the worst of both worlds.

Please don't get me wrong, I do understand the fundamental value of being able to use the GPS to compensate for corner cases of extreme stabilize flight behavior and the work that has gone into it,

But you have also introduced an obvious Achilles heel into an otherwise fairly benign flight mode.

Best Regards,

Gary

[Jesus Alvarez]

I absolutely agree.

A failsafe IMU Stabilize mode is needed as the last backup/failsafe mode that you will use in case of trouble!

[Paul Riseborough]

The glitch trap logic did isolate the nav solution from the worst of this glitch, and was very close to triggering earlier. The tilt error was less than 10 degrees at any point in time, so the vehicle was controllable, however not with the precision required to set down without tipping. This is not a flyaway scenario.

The EKF tuning is a compromise to handle a wide range of flying from aggressive aerobatics to precision hovering and tightening up the velocity innovation gate would have prevented the tilt error in this instance. I can see there would be benefit to a different tune for the EKF when operating in a mode where position and velocity data is not required. Such a mode could afford to be be a lot more discriminating of GPS errors and be tuned to maximise the reliability of the angle estimates. Another possibility in such a mode is to use the accel values to detect when the vehicle is manoeuvring and to only use the GPS when sustained manoeuvres are detected.

There would also be benefit in scaling filter parameters based on the number of satellites. For example when operating with 4 satellites, severe glitches are much more likely (almost a certainty) compared to when operating with 6 or more. This has been on the EKF to-do list for some time, but I have had difficulty in gathering the required data to do it scientifically, rather than just implement something ad-hoc.
.

[Robert Lefebvre]

This also gets back to the discussion we had the other week about about Acro, and the need for a "pure acro" mode that is just gyros.

Gary, it's true that probably better than 90% of users would not notice the absence of GPS correction on the AHRS.  But it's definitely detectable if you fly aggressively.  I still remember the first day I tried using it, was probably 2 years ago.  Jonathan had done the work to do the correction, and it was an option on Ch7 I think.  Maybe you can still see the param "AHRS_GPS_USE"?  

I remember turning it on, and it was like a moment of clarity, where you realize "wow, I can't believe I didn't notice how bad it was before".  It was the same thing with the earth-frame-body-frame transformation.  If all you do is hover, you don't notice.  But if you fly around, you do.  If you were flying in a pure acro mode, like some of the other controllers, you wouldn't see a difference.  But as soon as you start using the accels and fly in an auto-stabilized mode, then you notice.

[Gary McCray]

Hi Paul,

It seems to me that there are going to be a lot of multicopter circumstances in the future where we will purposely want to fly without any reliance at all on GPS.

Indoors, or in places of severe multipath like forests and cities for instance,.

So it seems to me that to at least allow the user the ability to switch off GPS usage could be a really valuable feature.

It looks like the new M8 series Ublox can improve GPS reliability, but it is certainly not going to overcome all of GPS's limitations.

And as newer relative position navigational options become operational (optical flow, 3D ranging, etc), how GPS is mixed into this data is going to be something that will require complex logic and user/use specific determinations.

I for one, at least for the present, would very much like to have a full manual stabilize like mode that was utterly - not dependent on GPS.

Best Regards,

Gary

[Gary McCray]

Hi Rob,

I hear and understand and don't doubt that what you are saying is true.

The problem is that GPS itself is the problem.

Even if we go with the M8 (vastly improving it by all accounts), there are still a lot of circumstances where GPS is a liability rather than an asset.

Signal blocking and strong multipath situations especially for our copters are very common and are still places where we want to fly.

At least at the moment at the simplest level it would be nice to have as good a non-GPS stabilize mode as we can manage in parallel with the GPS version.

As time goes on the ability to operate various missions without strong or any reliance on GPS is also going to go up as other sensor technologies become available.

Then we may want to be able to "program" the specific level and aspects of GPS involvement we want for any given mission.

Ring gyros could put a drone I launched here pretty much through your front door using inertial guidance only.

We probably won't get those, but you can bet huge improvements in the gyros (and accels) we can get will be forthcoming.

And that's just on the inertial front.
Not saying GPS isn't a truly great thing, just that it's got, for us, some severe limitations as well.

Best Regards,

Gary

[Gary McCray]

To All,

I would like to point out that the little Blade 200QX Quadcopter:

 http://www.bladehelis.com/Products/Default.aspx?ProdID=BLH7780

Is extremely high performance and instantly rights itself under all conditions without any external GPS reference necessary.

If a $200.00 toy doesn't need a GPS to achieve an absolutely excellent stabilize mode - why do we?

If you don't believe it look on line or get one they are little rocket ships with near perfect stabilize functionality.

Just a thought (and a bit more fuel).

Best Regards,

Gary

[jdennings]

Confused ... and  scared. I fly a lot indoors or in GPS deprived or poor  environments, in stabilize or alt-hold, and always thought that those modes did not involve GPS. ("Directly". I do know about fence, failsafe rtl, and other conditions that would trigger a situation where gps would be needed. I always disable these when I know I have low or zero GPS signal). In addition, stabilize has always been my "goto" and simplest mode when I know conditions are not ideal, I perceive something is wrong, or fly "abnormally", testing. etc ...

 

But now it seems that GPS is used even for basic stabilize? Is this 3.2 and rc releases only? And would ekf-use = 0 prevent it?

 

I agree with Gary that just about all fc's capable of self-leveling do so very well without GPS. The ones I can confirm include the Blade Nano Qx FC, the DJI naza in atti mode (alt hold equivalent), the DJI WKM, and openpilot. Not saying AC 2 should follow these by not using GPS, but the availability of a stabilize mode without any sort of GPS need should really be there. The acro option is not as good, when things go wrong the stabilization really helps in spluit seconds  ...

 

 

 

[Paul Riseborough]

It's not a EKF vs DCM issue, nor is it a 3.2 issue. DCM (just like EKF) has always used GPS velocities to correct for manoeuvre accelerations when a 3D lock is available. This has been built into DCM from day one. If you arm indoors with noisy GPS data with either DCM or EKF selected, you can see the HUD moving around slightly - this is the effect of GPS velocity errors on attitude.

Copters (like the cheap indoor model Gary mentions) can get away without manoeuvre compensation whereas planes cannot as they perform often perform sustained circular loiters in the one direction, where eventually  the AHRS solution will think it is flying level as the acceleration is always sensed downwards. The DCM (and EKF) algorithms are a general purpose solution that have been designed to work for both planes, copters and more recently rovers.

BTW it is possible for planes to have a attitude reference without GPS if airspeed measurements or assumptions about sideslip and wind are made.

For those wanting to fly without GPS, the short term solution is simple - disconnect it.

[govsux]

I too had a crash or better described as a fly away. I am fairly certain either a complete loss of gps was involved or bad gps data was involved. It started acting odd like it was toilet bowling whist hovering with the wind. I tried RTL, loiter, and poshold [ 3.2 beta ] but it continued to simply drift away. As a last measure I tried stabilize but it was dark and it was hopelessly far away and down wind. I had many problem free flights with 3.2 leading up to this but had just added the Ublox M8. 

Question.... does the gps itself use the sat data to report to the pixhawk position and velocity data or does the pixhawk take all those raw numbers and calculate it itself? The reason I ask is it has occurred to me that a higher sat count might require more processing ability?? yes?? No ?? I have no idea how that works. But for right now I am suspect of the M8. Maybe many including me have been star struck by the impressive sat count and yet remain unaware of other issues with it?? Just a thought. 

[jdennings]

Got you. Thanks.

 

Now I may start hating  those df13 connectors even more  :)

 

If there is a way to have a pure GPS free stabilize that would allow for seamless mode changes  it would be great ...

But maybe I am over-reacting, Been flying indoors for a long time and never had issues, after all  ...

[Randy Mackay]

 

     I think it’s possible that it’s an EKF vs DCM issue so we should do some more testing of EKF vs DCM’s response to GPS glitches.

 

     Like many have said on this thread, both EKF and DCM use the GPS indirectly for the centrifugal force correction in all flight modes but it’s possible the accelerometers are weighted differently in the two solutions and they are certainly weighted differently between plane and copter.  In particular Copter/DCM reduces the weighting of the accelerometers by 8x after arming.  This is why with official arducopter you see the HUD move a bit while disarmed but it calms down once the vehicle is armed.

 

     So, let’s be cool, before we have a crisis of confidence, let’s remember that:

·         This was flying latest with EKF enabled (not DCM which is the default)

·         DCM has been used reliably for years.  The centrifugal correction has been there since AC2.4 or earlier and we have never diagnosed a crash as being caused by a GPS glitch affecting DCM’s attitude estimate in Stabilize mode.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Paul Riseborough

Sent: 22-Sep-14 11:05 AM
To: drones-...@googlegroups.com

[Paul Riseborough]

You could route the power (red) wire to the GPS through a switch or in-line connector.

[Josh Welsh]

There are two little “tabs” on the DF13 connectors that you can easily and carefully (VERY carefully!!) sheer off to make unplugging and plugging easier.  I use an exacto knife on all my DF13’s to do that.

 

Not trying to go off topic, just providing an alternative in line with Paul’s suggestion that may be easier.  I don’t recommend this on Rob’s gas heli, though J

--

[Gary McCray]

Hi Randy, Paul, and everybody,

I knew that my response would be controversial, but I think there is a significant issue here where inappropriate (if damped) behavior on the part of the GPS can actually cause inappropriate behavior in stabilize mode (as I recall the subject of this post in the first place).

As Paul said if you don't want GPS in the first place just disconnect it, but as Jdennings said - DF13 connector, a solution is almost never to disconnect a DF13 connector unless your life depends on it. (I have clipped off the little retainer tab on all of my DF13 connectors at this point, but this is not really a solution for the general membership of this club.)

The bottom line is that I as a loyal DIYDrones member would really love to have a parameter that would let me do just that (from stabilize at least).

Of course I am very much on record with favoring the method of operation that permits our group members to make their own choices regarding exactly this sort of decision and then providing them with the best information they can so they can choose wisely themselves.

As opposed to simply making it for them.

The toy copter I have mentioned by the way does not simply fly in stabilize mode, it flies extremely acrobatically in stabilize mode and always recovers virtually instantaneously.

The Blade 200QX is very simply the micro quadcopter to buy if you want to learn how to actually fly a quadcopter very well in the shortest possible period of time.

And if you look at the enthusiast base and fan and mod group that they have built up in a very short period of time, you will see that they are flying without compromise.

I am not arguing for the removal of GPS from stabilize mode I can certainly concede that under a lot of circumstances it can provide valuable enhancement, what I am arguing for is a non-GPS using mode as well, so that the single item of greatest inaccurate data is eliminated to the loop and the ability to choose whether to use it or not myself rather than pre-decided by others.

If it is a giant programming task or un-achievable by reasonable means I will be happy to withdraw, but the incredible capability of the no-GPS Blade in stabilize and the current ability to operate without the GPS connected really suggest that at least a good start can be made by providing a simple mode enable parameter that simply disables the GPS in stabilize mode.

It seems much more of a political decision than a technical one.

Best Regards,

Gary

On Sunday, September 21, 2014 4:40:11 AM UTC-7, Holger Steinhaus wrote:

Today I made a short test flight - much shorter than originally intended. GPS conditions were pretty bad (several thick layers of clouds), horizon obstructed up to 45° of azimuth, HDOP has improved below 3 when I decided to takeoff. 

A few seconds after takeoff, hovering in about 1m in STABILIZE, there were sudden uncommanded roll impulses of the copter to the right, I countered them and tried to land asap. Due to tue large roll impulses, I landed on one skid, when the next heavy roll impulse happened, turning the onto its back. As the logs reveal, during arming the HDOP went to about 6, coming back to 2.6 during flight, and jumping back to 6 shortly before the crash. During the seconds before the crash, there were amazing GPS speeds (around 10m/s), while the copter was definitely nearly static. Binlog is available on PN request.

Is there any way to safely and completely disable any GPS support for this kind of test flight? Is setting EKF_USE to 0 enough?

Holger

[Paul Riseborough]

Gary,

I would rather you didn't use the 'political' word as it has negative connotations and implies motives that we are not in a position to judge. The reason for me not providing such a mode with EKF stemmed from the fact that when I started it's development, I had zero experience with copter and did all my early developmental testing using the plane code-base, and planes just don't need/can't use such a feature. Since then 3DR have been kind enough to provide a copter for me to do testing on which has provided better a understanding of the unique requirements that the copter community has.

I am happy to provide a patch to the EKF to enable such a mode, user selectable,  if it will be useful to enough people, and it has the blessing of Randy and Tridge. I am doing this in my spare time as a volunteer and avoid spending time on features that do not stand a good chance of making it into master.

Regards,

Paul

[Randy Mackay]

 

     I’ve done a little testing today with DCM (and EKF to a lesser extent) to better judge what impact a large change in velocity from the GPS would have on the attitude.  I’ve created a little video showing the impact which seems quite small (about 4deg for a 20m/s change).  https://www.youtube.com/watch?v=I2aPw1jNZDs&feature=youtu.be.

 

     I’ve also tested turning off the correction by setting the AHRS_USE_GPS parameter (or AHRS_GPS_GAIN parameter) to zero and indeed it seems to remove the correction completely.

 

-Randy

--

[Paul Riseborough]

You can get a bit more by simultaneously ramping up the position and velocity error so they stay just under the rejection threshold for a few seconds, but it takes a bit of fiddling.

[Paul Riseborough]

Well, this has been a worthwhile exercise. Whilst discussing the behaviour with Randy, I realised that there is a AHRS_GPS_MINSATS parameter that the EKF is currently not using. This would have prevented the EKF from using the bad GPS data in Holgers case as it is set by default to 6, and he had 4 and sometimes 5 satellites.

I will put together a patch so the AHRS_GPS_MINSATS parameter is used the same way with EKF selected as it is with DCM/INAV.

Thank you to Holger for the valuable test data.

[Robert Lefebvre]

Hi Paul, just a minor correction.  DCM hasn't *always* used GPS, it was brought in probably around AC2.8, about 2 years ago.  I remember I was still flying my Trex600 with flybar at the time.  But that comment is also directed at John.  This isn't a 3.2 or an EKF thing.  It's been used for a LONG time.  If nobody noticed, that's a good thing. ;)  It is possible that the EKF usage still needs some tuning in this regard, I don't know. 

I definitely remember planes having problems before it.  They would get "dizzy" if you Loiter for too long.  It actually resulted in a pitch error I think?  I used to experience the same thing simply pulling a single 180° turn with the helicopter.  The pitch would be off by 5-10 degrees.

[Robert Lefebvre]

Hi Paul,  I'm glad you are volunteering to work on this.  As we discussed before, I would like an option to use the EKF while doing aggressive Acro that will hopefully not fail over to DCM so easily.  Maybe these two things are one in the same?  I will agree with Gary here, that there are other examples, such as the Bavarian Demon flybarless controller, that can handle extreme acrobatics, but then "bail out" to a stabilized mode that reportedly works very well, without GPS.  I would like to have the same thing with Arducopter.

[Paul Riseborough]

Wow - no GPS as little as 2 years ago, well that predates my involvement on the project (I flew my first APM mission in January 2013). Yes it would have been interesting without GPS corrections on planes.

A workmate with a 'self righting' non-GPS flybarless setup on his heli has similar roll/pitch error issues if he does sustained high-g funnels and then hits the bailout switch - it does however get back to approximately right way up which buys him a few more seconds to take control.

Anyway, there's plenty of scope for further EKF tweaking as we get more feedback from users.

[Robert Lefebvre]

Ah, so the bailout isn't perfect?  I've not used one of these systems myself, and I haven't heard much discussion about the feature so I wasn't aware.  I've actually tried to find videos on Youtube showing it's operation, but, nothing. 

[Paul Riseborough]

Rob,

We need to get full rate IMU data logging and the EKF replay working. Once that's done then an extreme acro flight can be used to tune the algorithms off-line. The other reason I'm interested in extending the performance envelope is a long term aim to have a small UAV fly a full length aerobatics sequence on full auto.

Regards,

Paul

[john...@gmail.com]

If we need help from GPS to perform STABILIZE, then something is fundamentally wrong.

We know that GPS is one of our least trustworthy sensors. Meaning we should make it a point to use GPS as little as possible. This way you get the traditional fallback scenario where each mode use less sensors, making the system more and more robust (provided the pilot is experienced enough to operate without GPS or in worst case with gyros only).

I always have a dirt cheap quad with a KK2 controller ready for some spontaneous "fly it like you stole it" fun. Never had a problem with stabilize other then some lean for a couple of second after brutal flying. And there is no GPS in that system.

[Randy Mackay]

 

     Yes, it has been worthwhile.  Thanks a lot Paul.  My apologies to Holger that I didn’t more quickly realise the importance of his report and for being a bit defensive.

 

     To be clear Holger’s uncommanded roll would not have happened had his vehicle been using DCM.

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Paul Riseborough
Sent: 22-Sep-14 7:43 PM
To: drones-...@googlegroups.com
Subject: [Bulk] [drones-discuss] Re: Crashed in STABILIZE due to (very) bad GPS conditions with EKF enabled

 

Well, this has been a worthwhile exercise. Whilst discussing the behaviour with Randy, I realised that there is a AHRS_GPS_MINSATS parameter that the EKF is currently not using. This would have prevented the EKF from using the bad GPS data in Holgers case as it is set by default to 6, and he had 4 and sometimes 5 satellites.

I will put together a patch so the AHRS_GPS_MINSATS parameter is used the same way with EKF selected as it is with DCM/INAV.

Thank you to Holger for the valuable test data.

--

[David Pawlak]

@Paul,

Being older.... I remember the INAV systems that I worked with in airliners (cerca 1980). These where physical gyros (who´s technology migrated from inertial/rotational gyros to laser gyros) that were fixed to a stabilized platform. The stabilized platform used axis oriented gyros much like a camara gimbal to maintain the platform level (Earth frame, which was adjusted for latitude) and accelerometers on the platform measure forward, back up down acceleration. Thus a turn, even a constant turn, showed a vector which skewed outwards with the turn.

Have we lost something there? Not having really dug into that part of the code I couldn't say, but these gyros weren't confused by constant rate turns, or knowing which way was down. For certain they had to deal with precession and drift. It's possible they used even GPS or some other radio (fixed) reference, but it seems that any such drift of that nature is slow and big/temporary glitches should have little/no effect on the solution.

Thinking out loud.

[Robert Lefebvre]

John, it's not a matter of *needing* GPS for stabilize, it's a matter of fact that using GPS improves the AHRS.  I remember the before and after, and it does help.  And you have to remember, we come at this from the opposite direction than everybody else.  We are autonomous as job #1, and acro is just a "nice to have" feature.  We are at this point, sneaking up on acro, and doing pretty well at it.  That is while maintaining our excellent autonomous modes.  

The "lean after a couple seconds" is exactly what we are trying to prevent.  While that may not be a problem for you, it would be for many of our users, some of whom can't even fly in Stabilize let alone Acro. I think the days of thinking we are going to force people to learn how to fly is gone.  That horse has left the barn.  We can be all nostalgic, but it's just not the direction this industry is headed.  I remember an old cliche I heard somewhere "When a person walks into a store to buy a drillbit, he doesn't really want a drillbit, he wants a hole."  The same is true for the majority of our users.  They don't fly copters because they want to fly a copter, they fly copters because they want a camera in the sky.  That is what Arducopters #1 objective is.

The push for Acro, is just some of us old fashioned guys who want a bit of fun flying at the same time as we have an awesome autonomous controller.

Fact is, there is nothing wrong with GPS utilization in Stabilize.  The fact that we've been doing it for 2 years without anybody noticing, is evidence of that.  It's just that in this case, it appears Paul missed something which will be rectified.

For what it's worth, I'd like to say that I've done quite a bit of acro flying with my copter using EKF.  I go inverted quite a lot and so the GPS comes and goes.  I have never had a problem.  Holger's issue appears to be a corner case, and it will be rectified.

Rob

[Robert Lefebvre]

Did those gyros weigh more than the 1 gram our gyros do? ;)

[Emile Castelnuovo]

John, I'm not the highest mind in here to reply, but I'll share my two cents.
It is not fundamentally wrong, I'ts fundamentally correct.

If you detach your GPS from APM, it will still fly great, but it will miss something that we have and that is a must for certain platforms (eg. plane)

While in high G maneuvers, the accels will get confused by the centripetal acceleration and report an incorrect inclination.
While this (please somebody correct me if I'm wrong) is less evident in copters as they have a totally different way of "moving" it is greatly seen in planes.

Just to give you an example, try to place your KK2 in a car on your instrumental panel in an horizontal position, then drive and put yourself in a roundabout and start spinning around. Take a look at the artificial horizon (if any) and tell me what you see. 
You will probably notice the artificial horizon display an incorrect inclination (even opposite of the one the car has due to suspensions). 
Then try to make big brakes and linear accelerations, this also will result in a pitch in the opposite direction.

I agree though that GPS corrections should be done in a higly reliable situation, when we know GPS is not going cucu, but this does not mean that it is wrong. 

So IMHO GPS correction is a feature not a bug.

Comparing KK2 and APM should probably be done on a plane during an auto mission...

Cheers,
Emile

If we need help from GPS to perform STABILIZE, then something is fundamentally wrong.

We know that GPS is one of our least trustworthy sensors. Meaning we should make it a point to use GPS as little as possible. This way you get the traditional fallback scenario where each mode use less sensors, making the system more and more robust (provided the pilot is experienced enough to operate without GPS or in worst case with gyros only).

I always have a dirt cheap quad with a KK2 controller ready for some spontaneous "fly it like you stole it" fun. Never had a problem with stabilize other then some lean for a couple of second after brutal flying. And there is no GPS in that system.

[Philip Rowse]

Yes, keep in mind that the old school mechanical gyros are amazing.  What we have is a micro machines piece of flexible wire, that we measure deflection on. There is no comparison between the two. Ours is mechanically constrained, whereas, an old school gyro was free on all axis.

    Also remember, other than fighter jets and missiles, the average aircraft does not do sustained aerobatics while expecting an INS to maintain position.

    And, if you did trip up an old school system, you had to "Cage" it, to reset it to level.  In many ways, this is what the GPS is being used to do, wait for the system errors to accumulate, then gently cage it back to the correct position.

    As Randy mentioned, there is a min sat used... And Paul will patch accordingly.

Philip 

[Leonard Hall]

Hi Holger,

Thanks for doing beta testing of EKF on copter!!! It is people like yourself that drive this project forward by testing new features and reporting back the problems you find.

In this case there is a simple check on one of the data sources (the GPS) that has not been included yet. Thanks to your input this will be added and I am sure Paul and the other Devs are grateful you found this problem!!

Paul has done a fantastic job to bring EKF to ArduXXX, a job many have tried to do and failed! It is an incredibly complex task that is bound to take some tuning before it reaches it's polished state. The fact so many of us are flying in EKF with such success shows how well Paul has done his job!!

For anybody that has read this thread this far and is unsure if they should worry about stabilize, you don't. This is simply a bug, one that has been found in beta testing, and will be squashed. We will then be back to the situation we have been in for a number of years. GPS provides more accurate attitude estimation when it is available and no additional risk when it is not available or sketchy.

Relax and enjoy flying,

Leonard

[Luis Vale Gonçalves]

Hi all

good discussion on the benefits of having Stabilization assisted by a GOOD GPS.

I've already seen mentioned a quad (Blade 200QX) that performs stabilization in a surprisingly good way without GPS Assistance. Ok, it's a quad and planes are different, but the same manufacturer (HorizonHobby) also has planes that on a flick of a switch do stabilize and keep level flight (given enough height :) ) in a way that is even more incredible than the Quad, and from the craziest maneuvers one can imagine a plane doing. And also without GPS assistance. Example here:http://www.horizonhobby.com/products/sukhoi-su-29mm-bnf-basic-with-safe-reg-technology-PKZ8050#t1

My question is simple. To replicate that behavior from HorizonHobby does APM really needs GPS Assistance?

brgds

Luis

ps: I have a small Quad 350QX from HH, but it has GPS, and also that foam plane linked above, but I'm more interested on getting better performance with my PixHawk hexa.

[john...@gmail.com]

>GPS provides more accurate attitude estimation when it is available and no additional risk when it is not available or sketchy.

Great! That's all I was after.

It should then be noted this relies on how robustly we can detect any GPS problem. In the case of STABILIZE it would probably be better to wrongly reject some good GPS data now and then, then risking bad data getting trough.

[Robert Lefebvre]

I think that is the point of EKF.  The DCM implementation only rejects GPS data, when the GPS itself reports it at bad.  The EKF can reject it even if the GPS reports it as good, because the EKF can see that it doesn't "fit" in with the data of the other sensors.  

Is that correct Paul?

--

[David Pawlak]

Philip,

Thanks for the perspective.

You never know when thinking outside the box can even draw from old school.

Thanks everybody, good discussion. At least for me, I'm much happier about GPS in Stab after this.

[Emile Castelnuovo]

Personally speaking we have found that the M8 is more susceptible to interference if not correctly placed far away from certain electronic devices (Eg. cameras).

I've seen terrible sat loss just by switching on a mobius placed under the GPS.

Mobius off perfect loiter, mobius on terrible loiter, glitches and what looked like toilet bowling, same day just a few minutes a part.

Apart from that if correctly configured (out of the box is not usable) it has proven to be a very reliable GPS.

Velocity, position al all that stuff is calculated by the GPS, pixhawk uses this data to make it's own calculations.

Emile

2014-09-22 4:15 GMT+02:00 govsux <gov...@gmail.com>:

I too had a crash or better described as a fly away. I am fairly certain either a complete loss of gps was involved or bad gps data was involved. It started acting odd like it was toilet bowling whist hovering with the wind. I tried RTL, loiter, and poshold [ 3.2 beta ] but it continued to simply drift away. As a last measure I tried stabilize but it was dark and it was hopelessly far away and down wind. I had many problem free flights with 3.2 leading up to this but had just added the Ublox M8. 

Question.... does the gps itself use the sat data to report to the pixhawk position and velocity data or does the pixhawk take all those raw numbers and calculate it itself? The reason I ask is it has occurred to me that a higher sat count might require more processing ability?? yes?? No ?? I have no idea how that works. But for right now I am suspect of the M8. Maybe many including me have been star struck by the impressive sat count and yet remain unaware of other issues with it?? Just a thought. 

[Matthias Badaire]

Emile
What configuration the m8 needs ? I thought that the pixhawk was configuring it properly.
I had massive problem with it and I am trying to find the interference source as well. All modes were unstable and I have ekf on.
3dr GPS with the exact same setup was rock solid.
Matthias

[Gary McCray]

Hi Paul,

I sincerely apologize for the political comment, periodically I see intent where there is none.

It was certainly not your yeoman efforts to which I would have ever ascribed it ever in any case.

I know what you have and what you are contributing and I have the utmost respect for you.

My error was made because I had no idea that GPS had been mixed in so long ago.

The logic of mixing the single most failure prone item into the most normal (bail out) mode seemed simply incorrect to me.

But of course the fact is that if it has been in there that long, somebody must have done something right to keep it from even being noticed till now.

Reverse logic but accurate nonetheless.

It may be that I have created a tempest in a teapot, but the fact is that there are other examples of both copters and planes that even under extreme conditions are seemingly able to do an excellent job of sorting out where down is without a GPS to be in the loop.

And while that is perhaps not a necessity, it could possibly be a laudable goal.

Except for Parrot which used Optical Flow, many of the non-GPS systems certainly operate with no more sensor capability than our autopilots.

And at least some of them can be flown to extremes (Blade 200QX for example) without showing any degradation of stabilization performance or down reference.

Do we need a GPS free stabilize mode?

At this point I don't honestly know, it seems the GPS mixing has been done conservatively enough where maybe just a bit of tweaking (if that) will remove any undesirable characteristics.

And I do understand that providing a (GPS free) stabilization mode will open it to witting and unwitting abuse.

If no significant effort were involved I would definitely like to be able to make my own witting or otherwise choice and that is my "political" stance on behalf of the other users as well.

If a substantial effort is involved to make non-GPS stabilize work, then it is a matter of priority and I suspect it is reasonably of a low priority and definitely yours and the primary developer teams right and responsibility to determine.

Once again, please accept my apology for the political comment it was not aimed at you or any of the other developers and in fact seems without merit regarding this issue in all ways.

Best Regards,

Gary

[Robert Lefebvre]

Gary, I think part of the problem is, that Auto and Loiter modes both operate on top of the Stabilize controller.  Both of these modes rely on rock-solid attitude estimation.  If there are even a few degrees error, then they will begin to oscillate.  I've seen plenty of evidence of this when looking at logging data where people have a poor Loiter performance, and I find out that the problem is not actually the GPS, but rather the Rate PIDs which are not tuned properly, such that the aircraft does not achieve the target angle, or achieves it very slowly.  The Loiter controller is blind to this error.  It gives commands as to what the angles should be, based on a physical model of how the copter should move to achieve it's target position.  If those angles are not met, it does not know, and will therefore wind up an I-term error.  The same would be true if we had a case where the the attitude estimate is off.

The small(ish) errors that result from not fusing the GPS data into the AHRS might be manageable in cases such as presented where other stabilization systems have seemingly good performance despite the fact they don't have a GPS.  5-10 degree error can be corrected by the pilot.  But as I say, the autopilot cannot deal with it.

I think this is why so much emphasis was placed on the GPS feedback into the AHRS.

I do agree, that it would be nice to have a mode which is simpler, is capable of flying despite bad GPS, and is capable of dealing with acrobatic manoevers.  Hopefully Paul can put something like this together.  Or alternatively, I wonder if it would be good that once EKF is proved out and in widespread use, we remove GPS infusion in the DCM, and then use DCM as the stupid-simple back-up method.  I think there is sufficient demand for an AHRS that very very reliably achieved 15 degrees or better accuracy, no matter what.

[jolyboy]

Guys, I don't think there is anything to worry about.

No/bad GPS signal will be properly and automatically excluded from the attitude solution now with the MINSATS EKF patch Paul and Randy have discussed. No need for GPS free stab mode, but if you want you can unplug/switch yours. If I were a betting man I'd say the patch will be in 3.2 very soon.

Other systems without GPS infusion can develop 40° of error if you can fly hard. Its only useful to get the aircraft roughly upright so you can punch it out. This is not better than what we have, plus we have added GPS infusion whenever its available that makes it wayy better.

What we do need is a pure BF acro mode.

Discussions like this almost always prove very fruitful :) A few people report an issue and bam, potentially hundreds of future crashes have now been avoided. Nice work guys.

[Robert Lefebvre]

Joly, do you have experience with the other self-righting FBL controllers?  I'd really love some real-world comparisons.  Promotional videos don't really give us the data we are looking for unfortunately.

[jdennings]

On Sunday, September 21, 2014 8:50:36 PM UTC-6, Paul Riseborough wrote:

You could route the power (red) wire to the GPS through a switch or in-line connector.

 

 Thanks Paul, that's actually what I had in mind. But this great discussion has convinced me that my concerns were overblown. Sure feel better now ...

 

One extra comment I might add about AC in general.  Rob makes the  good point that Ardupilot is deeptly rooted in the  auto part of "autopilot", with historically a lower  priority to manual flights. Given current trends this makes sense and there is no need to change emphasis, and besides the attention paid to this current issue and flight quality for acro and stabilized is very re-assuring. This is all the more relevant as we  we should not forget that GPS-less flight modes are also widely used, be it by a large number of FPV fans, or the many many recreational "sports" users. I doubt this will change even as the trend for auto flights keeps going up. Maybe more important is the fact that these GPS less modes are also used by some very advanced professional user with very high end multirotor gear,  like  filmmakers. Here's an example of one of the top professionals in the industry: http://vimeo.com/80898186

 

They not only fly without GPS, but actually in acro mode without self leveling (Hoverfly FC in this case). This may be an extreme case, but I think it would be a mistake to under estimate the number of top end pros flying  copters  who prefer to fly in  stabilized or alt-hold.

 

Cheers. 

[jolyboy]

Rob, yeah I have tried 3. MSH brain (iKon), Flymentor, and WlToys.

MSH Brain was terrible except for an emergency rough level. It was continuously about 15° off even with my weak slow flying skills. Most users who do proper 3d don't bother with it because its so far off level that it makes them MORE likely to crash. I've read many reports of it actually inverting the heli which is obviously bad in a bailout situation.

Flymentor was OK, but it only stayed within a good range because it wouldn't let you get past 45° like arducopter stab. If you hold the stick forward and cruise around it would drift in the direction you were tilted. Not a big deal though because if you got bad drift you could correct it by holding the heli level for a few seconds LOL. This is how I imagine arducopter would behave without GPS.

WlToys is what's used on my sub micro heli and its pretty effective but still drifts. About half as quickly as Flymentor. Again not a big deal.

FYI the only reliable self levelling system without GPS is the CoPilot II system that uses IR horizon detection, which only works in outdoor open areas without trees or buildings. Useless to us because that's the environment where GPS works anyway.

PS the only laser rings i actually see IRL are the navy ones which are the size of a small fridge, good luck with that LOL

[Gary McCray]

Thank you Rob,

Got it, current stabilize is really the foundation of Loiter and Auto which truly need GPS for operation so it was integrated into stabilize  to provide the necessary functionality for the other modes as well.

Makes perfect sense and you all have done a magnificent job judging by the results with as Randy said no reason to cause a panic.

For myself and at least some others discovering that stabilize was at all a GPS utilizing mode was a surprise and seemed at first glance counter intuitive and potentially possessing of serious negative consequences.

Of course for the developer team it was actually a legacy circumstance to which most of the necessary tweaks had already been provided.

I also have discovered that the Rate PID is the main item and basis for all the others and I can understand why optimizing it's integrity was paramount.

Clearly if a non-GPS stabilize were implemented it is not what you would want to use as the basis for the other modes it would need to be a separate expression of stabilize mode, although at the simplest level it seems this can be done by turning off the GPS itself.

Just to carry on with that thought, why would it not be reasonable to have an additional No-GPS Stabilize mode (Simply current Stabilize Mode with the GPS feed disconnected in firmware) in addition to the standard With GPS Stabilize mode.

"No GPS Stabilize" tweaks could be added at any time if desired, but the basic implementation of this seems like it would require almost no effort but would open the possibility of use - - and abuse.

Even if it didn't actually provide a significant actual solution, it could provide confidence to those seeking solutions to their own setups "problems".

Also for clarification I was definitely not trying to say our GPS Stabilize solution wasn't better than any of the non-GPS solutions, simply that some of the non-GPS solutions seem to be remarkably effective even when they are flown hard in very highly stressed maneuvers.

Looks like reality is that Randy and Paul and the others are working at effectively nullifying any of the potential negative results from the GPS Stabilize solution and that they were probably very nearly there before this whole thing blew up and that is what matters in any case.

So I will bow out of this at this point with a final thought that at some point in the future it might be nice to have a practical GPS free flight mode to serve as a troubleshooting backstop if nothing else.

No slights to anyone of the developer team were ever intended in any way and I am very firmly of the thank you very, very much for what you have done for us camp as opposed to the why haven't you done this camp.

In fact you have done a magnificent job and have now produced a very solid basis for machines that will actually be capable of being used in the real world as tools to accomplish tasks rather than just as toys for our amusement.

That is huge!

My very best regards and Thank You All,

Gary

[Robert Lefebvre]

I actually had a Flymentor on my very first heli.  That's actually how I got started 3 years ago.  Yes, it was really bad.  I don't think it even had accelerometers, and it just tried to remember where level was by integrating the gyros, with the assumption that your "average" attitude was level, so it slowly dragged the attitude estimate to where your current attitude was assumed to be level.  It worked ok as long as all you did was hover. But I had my first massive crash with it the first time I tried to fly forward for a distance.  When I released the stick, instead of returning level, it tilted backwards!

It was after that crash that I got into Arducopter, which at the time, I thought was fully functional. :)

I hear good things about Bavarian Demon, but I have yet to see an impartial discussion about it's actual performance.

I have yet to see EKF bail-out to anything but perfectly level (or as close as I can measure without putting a bubble level on it), and even DCM is within 20 degrees.  

[Paul Riseborough]

John,

Flying a quad 'like you stole it' is not the same as prolonged high g funnels in a trad heli, or a plane doing a sustained high bank loiter. Given the different user preferences, flight vehicle types and flying styles, the decision to use GPS in stabilise should be set by a parameter. We can then have the argument about it's appropriate default setting. Our AHRS library is currently capable of operating without GPS, however there is also low hanging fruit in the area of tuning the DCM algorithm to adjust the weighting on the accelerometer corrections during periods of higher G which would reduce the rate at which it develops the 'leans'.
.
Your points about relying on GPS as little as possible and having progressive fallback are good ones. However the reason Holger ran into difficulties, was that EKF was not using the AHRS_GPS_MINSATS parameter. If he had been using DCM, there would not have been a problem on that flight.

Regards,

Paul

[Paul Riseborough]

Luis,

That horizon hobby system may using an attitude estimator that builds in some knowledge of the aircraft dynamics in its algorithm. Such an approach can extend the flight envelope over which an attitude reference can be maintained without GPS. However until I see evidence it can maintain its attitude reference after a slow windup into a constant 2g banked turn held for 5 minutes, I remain skeptical. Flicking the plane through a series of manoeuvres in different directions is not the tough exam question.

The short answer to your question is that as it is currently implemented and tuned, APM plane will give a better attitude estimate with GPS, than without under those high dynamic conditions. Remember, our system was designed from the outset as an autonomous vehicle controller, not a pilot aid for aerobatics. We could no doubt  provide a better non-GPS capability given this capability has received minimal development, but it is taking our controller into a different sector of the market where there are already numerous simple plug and play (or plug and pray)  solutions.

Regards,

Paul

[Paul Riseborough]

Rob,

Yes, the EKF compares the GPS measurement with a measurement predicted by the filter using a statistical confidence check and rejects those measurement that lie outside the check threshold. These thresholds are controlled by the following parameters

http://planner.ardupilot.com/wiki/common-apm-navigation-extended-kalman-filter-overview/#EKF_VEL_GATE
http://planner.ardupilot.com/wiki/common-apm-navigation-extended-kalman-filter-overview/#EKF_POS_GATE
http://planner.ardupilot.com/wiki/common-apm-navigation-extended-kalman-filter-overview/#EKF_GLITCH_ACCEL
http://planner.ardupilot.com/wiki/common-apm-navigation-extended-kalman-filter-overview/#EKF_GLITCH_RAD

[Paul Riseborough]

Here are a couple of patches that reduce the likelihood of bad GPS affecting EKF attitudes during flight with less than 6 satellites. The first patch requires at least 6 satellites for EKF to start, the second reduces GPS measurement weighting if it has started and the number of satellites drops below 6.

https://github.com/priseborough/ardupilot/commit/7b22bed74bb856b32a2a9b94fdeb8dca17275707
https://github.com/priseborough/ardupilot/commit/d9274ed6f62d313208c2b89950d35ac954a16970

I have tested them in SITL (where I can reduce the number of satellites). They have not yet been flight tested.

Regards,

Paul

[Randy Mackay]

 

     I’ve merged these into AC3.2 branch.  I’ll give a test flight tomorrow and then likely push –rc10.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Paul Riseborough
Sent: 23-Sep-14 7:18 PM
To: drones-...@googlegroups.com
Subject: [Bulk] [drones-discuss] Re: Crashed in STABILIZE due to (very) bad GPS conditions with EKF enabled

 

Here are a couple of patches that reduce the likelihood of bad GPS affecting EKF attitudes during flight with less than 6 satellites. The first patch requires at least 6 satellites for EKF to start, the second reduces GPS measurement weighting if it has started and the number of satellites drops below 6.

--

[Jonathan Challinger]

There was some discussion on the call of the M8 GPS and checks based on satellite count - you could have 3 GPS satellites and 3 GLONASS satellites and have no solution.

[Craig Elder]

GPS Vibration test.  6 hours without failure.  This might be harder to reproduce than we thought.

[Jonathan Challinger]

Maybe try mounting it in a couple other ways?

[Craig Elder]

Testing will continue.

[Gary McCray]

I'm impressed, 

The scroll saw test looks pretty thorough to me.

I'm surprised the board didn't delaminate.

[Jonathan Challinger]

"Cake, and grief counseling, will be available at the conclusion of the test." -GLaDOS

[Paul Riseborough]

It often requires vibration energy at the resonant frequency for the support that broke. Heli's have all sorts of generators - blade passage ,main shaft, tail shaft, engine, etc. The engine will have strong harmonics. Do you have the facility to do frequency sweeps and loop for resonances? and whats the highest frequency you can generate?