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

951 views
Skip to first unread message

Holger Steinhaus

unread,
Sep 21, 2014, 7:40:11 AM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 7:54:20 AM9/21/14
to drones-...@googlegroups.com

Randy Mackay

unread,
Sep 21, 2014, 8:22:50 AM9/21/14
to drones-...@googlegroups.com

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

unread,
Sep 21, 2014, 8:25:15 AM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 10:31:22 AM9/21/14
to drones-...@googlegroups.com
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:

normalised innovations.png

Holger Steinhaus

unread,
Sep 21, 2014, 11:44:25 AM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 12:24:46 PM9/21/14
to drones-discuss
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

unread,
Sep 21, 2014, 1:36:58 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 2:17:38 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 2:28:09 PM9/21/14
to drones-discuss
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.
Message has been deleted
Message has been deleted

Gary McCray

unread,
Sep 21, 2014, 2:47:20 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 2:56:22 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 3:01:04 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 3:08:30 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 3:11:37 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 3:14:14 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 4:53:00 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 5:38:14 PM9/21/14
to drones-discuss
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

unread,
Sep 21, 2014, 5:49:41 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 6:02:16 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 8:40:44 PM9/21/14
to drones-...@googlegroups.com
To All,

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


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

unread,
Sep 21, 2014, 9:19:46 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 10:05:28 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 10:15:16 PM9/21/14
to drones-...@googlegroups.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. 



jdennings

unread,
Sep 21, 2014, 10:37:41 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 21, 2014, 10:49:37 PM9/21/14
to drones-...@googlegroups.com

 

     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

unread,
Sep 21, 2014, 10:50:36 PM9/21/14
to drones-...@googlegroups.com
You could route the power (red) wire to the GPS through a switch or in-line connector.

Josh Welsh

unread,
Sep 21, 2014, 10:54:45 PM9/21/14
to drones-...@googlegroups.com

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

unread,
Sep 21, 2014, 11:10:57 PM9/21/14
to drones-...@googlegroups.com
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

unread,
Sep 22, 2014, 4:13:26 AM9/22/14
to drones-...@googlegroups.com
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

unread,
Sep 22, 2014, 5:06:46 AM9/22/14
to drones-...@googlegroups.com

 

     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

unread,
Sep 22, 2014, 5:49:47 AM9/22/14
to drones-...@googlegroups.com
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

unread,
Sep 22, 2014, 6:42:52 AM9/22/14
to drones-...@googlegroups.com
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

unread,
Sep 22, 2014, 7:29:58 AM9/22/14
to drones-discuss
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

unread,
Sep 22, 2014, 7:47:50 AM9/22/14
to drones-discuss
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

unread,
Sep 22, 2014, 7:51:56 AM9/22/14
to drones-...@googlegroups.com
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

unread,
Sep 22, 2014, 7:58:44 AM9/22/14