Dangerous Loiter flyaway with good GPS sats and HDOP

2,181 views
Skip to first unread message

David Dewey

unread,
Sep 26, 2013, 2:25:04 PM9/26/13
to drones-...@googlegroups.com
Today I was flying Arducopter V3.0.1 around in Stabilize for about 8 minutes and then switched into Loiter. It had good GPS (10 satellites) and good HDOP (1.60). It was perfectly solid and holding very still in loiter, but then all of a sudden it rolled way to the right and took off like a rocket. I immediately switched into Stabilize to regain control.

Looking at the logs, I expected to see loss of GPS satellites and larger HDOP at the point Loiter went crazy, but in fact I saw the opposite: Num satellites actually went up, from 10 to 11, and HDOP went down, from 1.60 to 1.57 at that point.

This issue could be very dangerous, because some people like to use loiter to land, and if it flies off so suddenly at low altitude when you're least expecting it because of how rock solid the loiter is at first, then it could easily hit and injure someone.

Flash log attached. Graph of log zoomed to the point the issue occurred:


2013-09-26 21-47 15.log

Randy Mackay

unread,
Sep 26, 2013, 2:51:04 PM9/26/13
to drones-...@googlegroups.com

     Maybe your GPS suddenly became more accurate.  The position change to a more accurate (in absolute position) would cause the copter to shift positions just as badly as a jump to an inaccurate position I'd guess.

     I guess you've seen the discussion and video re GPS Glitch protection?  The code is in trunk now but I'm unsure if the glitch you faced was big enough to qualify.  It needs to jump by over 10m for it to be considered a glitch although that 10m is configurable of course.

-Randy



From: David Dewey <da...@mavbot.com>
To: drones-...@googlegroups.com
Sent: Thursday, September 26, 2013 11:25 PM
Subject: [drones-discuss] Dangerous Loiter flyaway with good GPS sats and HDOP

--
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/groups/opt_out.


Robert Lefebvre

unread,
Sep 26, 2013, 2:51:16 PM9/26/13
to drones-discuss
I'm wondering if something really bad was happening with the GPS system in the past 24 hours or so.  Last night I was flying and had, absolutely the worst "auto" performance I've ever had.  By far.  I actually almost hit myself at one point.  The night before, my quad had flown brilliantly in Loiter, Alt Hold, Auto and Guided.  I changed nothing. And then last night it was completely out of control.

Loiter was doing massive toilet bowling.  And I had a number of really bad flyaways.  I almost lost it in fact.  After it tried flying away in Loiter, I couldn't see it so went to RTL, and it continued to fly away at a 45 degree angle and falling.  I ended up having to fly it back in Stabilize using MP for IFR.  I fiddled with the compass declination, but couldn't get it working right.

I had even reduced the WP Speed and Loiter speed, and accelerations, because I was trying to teach my son to fly it in Loiter mode.  But it was zipping around at very high speeds.  Worst night of Arducoptering I've had in a long long time.



Gary McCray

unread,
Sep 26, 2013, 5:10:03 PM9/26/13
to drones-...@googlegroups.com
Especially while we are in this cycle of above normal solar disturbances it would be really nice to at least have a general idea of what GPS condition affecting events were here on earth even after the fact.

We could at least look at them and say Ah! now I know why my copter flew into a cliff.

If anybody knows, is there an online entity that provides this information and what is their link?

Regards,

Gary

Robert Lefebvre

unread,
Sep 26, 2013, 5:12:06 PM9/26/13
to drones-discuss
I have an app on my phone actually.  I checked last night, and sure enough, it was red.  But it's not enough info as it's simply green/red.  I've flown on lots of red days.  But how red is red?  Need more data.  I don't know of an online source that I could recommend, but I know they're out there.  If somebody has a favorite, I'd like it too.

Peter Plischka

unread,
Sep 26, 2013, 6:07:21 PM9/26/13
to drones-...@googlegroups.com
This page helps you to see how much SATs are possible.
http://www.trimble.com/GNSSPlanningOnline/ # / NumSats

I would rather have an app for Android.

Regards Peter

Gary McCray

unread,
Sep 26, 2013, 7:35:29 PM9/26/13
to drones-...@googlegroups.com
Hi Peter,
Knowing satellites available for a given location at any time is of course very valuable, so a good link.
But what I would really like to see is a low resolution earth map where it would display likely loss of service or interference due to various events including solar activity (the bigee).
And you could select the date and time you wanted to look at or maybe scan forward and back from.
It wouldn't actually solve anything, but it would let you know the actual level of loss of service and interference taking place s you could better gauge your activities.
Right now we are in a high period of interfering solar activity which is still going to be getting worse for some time yet before it even starts to get better.
A lot of what we interpret as our GPS not working right is actually due to this outside interference.
I don't know if anybody offers this, but since it is so critical now for full sized air travel, I would be surprised if it isn't out there somewhere.
Possibly not free though.
Come to think of it, it really ought to be a selectable overlay feature for Google Earth.
Regards,
Gary

Kevin Hester

unread,
Sep 26, 2013, 10:19:47 PM9/26/13
to drones-discuss
A lot of what we interpret as our GPS not working right is actually due to this outside interference.
I don't know if anybody offers this, but since it is so critical now for full sized air travel, I would be surprised if it isn't out there somewhere.

Alas - I did about 15 minutes of googling and following web links. And alas, I didn't find anything - If someone can find a site out there with this data it would be pretty easy to have droneshare scrape it and provide an easy API for the GCSes to show a warning...  

(Though I'm not sure how much of the problems we are seeing are due to this outside interference.  I bet once glitch detection is in the need/concern for this will go way down)


--

Robert Lefebvre

unread,
Sep 26, 2013, 11:28:30 PM9/26/13
to drones-discuss
I think my problem probably had to do with my airfield.  I've noticed a number of times there strange, inexplicable compass errors that I don't have anywhere else.  Maybe the fact that it's next to a toxic waste dump has something to do with it. (no joke!)

Brandon Jones

unread,
Sep 26, 2013, 11:32:24 PM9/26/13
to drones-...@googlegroups.com
Space weather is definitely a factor with our single frequency GPS receivers, and it is generally a good habit to check it like one would check other normal weather forecasts prior to flight.  A space weather indicator on a GCS would be a great feature!

There are a few resources available:

Kp-index:

Total Electronic Content (TEC):

Forecasts:

How these measurements map to specific navigation performance is a topic of research, and can be highly dependent on the GPS receiver.  But here is a good guide: http://www.swpc.noaa.gov/NOAAscales/  When solar storms are predicted you'll see GPS researchers running out into fields to collect data!  Looks like the kp got up to 5 yesterday.  Using data from droneshare to show any systemic performance degradation as a function of Kp across the ublox receivers would be an interesting project.

Also, here is a good short overview paper:

Brandon Jones


Gary McCray

unread,
Sep 27, 2013, 12:33:29 AM9/27/13
to drones-...@googlegroups.com
Hi Robert,

Aside from radioactive, I don't think most toxic wastes would be likely to directly influence the compass.

Our which is leased to us for free was generously provided by the Forest Service, unfortunately, it is the fly ash dump site for the Luber mill that ran for 80 years and cloosed down 10 years ago.

It does have a small influence very close to the ground, but it is negligible because it is homogeneous.

However, I volunteered to Mow it with our Husky Lawn Tractor Mower (without a dust mask) one summer after it had dried out.

Took me 2 weeks to recover.

Avoid toxic dump sites.

However if you are near (or worse over) a large a dump containing a lot of metal (or metallic salts or oxides), that is a different matter.

But you can determine that just by walking around your field with a regular compass, if the needle moves around you may have found your demon.

Of course where you live, natural deposits can have big effects locally on compass's too, but you already knew that didn't you.

Any of the old giant iron mining stuff can also affect a considerably larger area than you might think too.

Regards,

Gary

Kevin Hester

unread,
Sep 27, 2013, 1:12:57 AM9/27/13
to drones-discuss
Hi Brandon,

This actually looks pretty easy to parse.  So if one were to show a warning in a GCS would KP5 be a good threshold?  (I know nothing about space, except that it is relatively dark ;-))

Kevin

:Product: 09270030three_day_forecast.txt
:Issued: 2013 Sep 27 0030 UTC
# Prepared by the U.S. Dept. of Commerce, NOAA, Space Weather Prediction Center
#
A. NOAA Geomagnetic Activity Observation and Forecast

The greatest observed 3 hr Kp over the past 24 hours was 1 (below NOAA
Scale levels).
The greatest expected 3 hr Kp for Sep 27-Sep 29 2013 is 3 (below NOAA
Scale levels).

NOAA Kp index breakdown Sep 27-Sep 29 2013

            Sep 27     Sep 28     Sep 29
00-03UT        2          2          2     
03-06UT        1          1          1     
06-09UT        1          2          1     
09-12UT        1          1          1     
12-15UT        1          2          1     
15-18UT        1          1          2     
18-21UT        1          1          3     
21-00UT        2          1          3     

Rationale: No G1 (Minor) or greater geomagnetic storms are expected.  No
significant transient or recurrent solar wind features are forecast.

B. NOAA Solar Radiation Activity Observation and Forecast

Solar radiation, as observed by NOAA GOES-13 over the past 24 hours, was
below S-scale storm level thresholds.

Solar Radiation Storm Forecast for Sep 27-Sep 29 2013

              Sep 27  Sep 28  Sep 29
S1 or greater    1%      1%      1%

Rationale: No S1 (Minor) or greater solar radiation storms are expected.
No significant active region activity favorable for radiation storm
production is forecast.

C. NOAA Radio Blackout Activity and Forecast

No radio blackouts were observed over the past 24 hours.

Radio Blackout Forecast for Sep 27-Sep 29 2013

              Sep 27        Sep 28        Sep 29
R1-R2            5%            5%            5%
R3 or greater    1%            1%            1%

Rationale: No R1 (Minor) or greater radio blackouts are expected.  No
significant active region flare activity is forecast.

Sean Limes

unread,
Sep 27, 2013, 2:28:11 AM9/27/13
to drones-...@googlegroups.com
Earlier today I rebased my flying branch to today's trunk commit 99da118faaf86ed846095920cacec607ecf176e9 and applied my (already flying) tricopter motors fixes. 

I warmed up my tricopter, got a solid GPS lock, took off in stabilize, flipped to alt hold, and hovered for a touch, all fine, normal. Then went to loiter. It immediately took a 45 degree bank to the right and accelerated EXTREMELY fast.   Since there was a house about 150 feet away, I reflexively dropped throttle before i flipped through alt hold and back to stabilize, and my bird took a bit of a bellyflop :)  Only lost a prop though, it looks. 

This "fly to the right like a rocket" behavior sounds very similiar to what David experienced.  I have never experienced this before, and my last rebase I believe was about a week ago.

Maybe my log will assist in locating the issue.... as far as I can tell there is no association between a change in sat count or HDOP  with changing to loiter (and subsequent 43+ degree desired roll...) Furthermore GPS location seems constant, other than the rapid change post roll request. 


2013-09-26 19-01 72.log

Randy Mackay

unread,
Sep 27, 2013, 3:17:49 AM9/27/13
to drones-...@googlegroups.com

     Intresting - your GPS is updating at only 1hz.  I saw this same problem in a log yesterday from an arduflyer user.  What GPS are you using?

-Randy



From: Sean Limes <tex...@gmail.com>
To: drones-...@googlegroups.com
Sent: Friday, September 27, 2013 11:28 AM
Subject: [drones-discuss] Re: Dangerous Loiter flyaway with good GPS sats and HDOP

Randy Mackay

unread,
Sep 27, 2013, 3:24:59 AM9/27/13
to drones-...@googlegroups.com

     by the way, too much logging is turned on.  Best to stick with the defaults and then turn on just a single additional message type when you think you need it.  I know it's tempting to turn them all on because you never know what you might need but the APM's cpu is heavily loaded and the extra logging (although we've improved the efficiency of the writes) only makes things worse.  In particular the INAV and IMU mesages are very heavy.
                http://copter.ardupilot.com/wiki/downloading-and-analyzing-data-logs-in-mission-planner/#Setting_what_data_you_want_recorded

-Randy



From: Randy Mackay <rmac...@yahoo.com>
To: "drones-...@googlegroups.com" <drones-...@googlegroups.com>
Sent: Friday, September 27, 2013 12:17 PM
Subject: Re: [drones-discuss] Re: Dangerous Loiter flyaway with good GPS sats and HDOP

Stefan Gofferje

unread,
Sep 27, 2013, 10:05:19 AM9/27/13
to drones-...@googlegroups.com
Judging by the auroras we are seeing up here recently, there is quite a
bit of stuff hitting earth... I also had some unstable loiters in the
last few weeks. One of my facebook friends is an aurora photographer who
lives in a neighbor town. Meanwhile I just check his facebook and his
photo page before I start flying, because when he has the coolest new
photos, any GPS-based flying usually doesn't work.

=> http://tomeklund.kuvat.fi/kuvat/aurora/2013/

-Stefan

On 09/26/2013 05:51 PM, Robert Lefebvre wrote:
> I'm wondering if something really bad was happening with the GPS system
> in the past 24 hours or so. Last night I was flying and had, absolutely
> the worst "auto" performance I've ever had. By far. I actually almost
> hit myself at one point. The night before, my quad had flown
> brilliantly in Loiter, Alt Hold, Auto and Guided. I changed nothing.
> And then last night it was completely out of control.
>
> Loiter was doing massive toilet bowling. And I had a number of really
> bad flyaways. I almost lost it in fact. After it tried flying away in
> Loiter, I couldn't see it so went to RTL, and it continued to fly away
> at a 45 degree angle and falling. I ended up having to fly it back in
> Stabilize using MP for IFR. I fiddled with the compass declination, but
> couldn't get it working right.
>
> I had even reduced the WP Speed and Loiter speed, and accelerations,
> because I was trying to teach my son to fly it in Loiter mode. But it
> was zipping around at very high speeds. Worst night of Arducoptering
> I've had in a long long time.
>
>
>
> On 26 September 2013 10:25, David Dewey <da...@mavbot.com
> <mailto:da...@mavbot.com>> wrote:
>
> Today I was flying Arducopter V3.0.1 around in Stabilize for about 8
> minutes and then switched into Loiter. It had good GPS (10
> satellites) and good HDOP (1.60). It was perfectly solid and holding
> very still in loiter, but then all of a sudden it rolled way to the
> right and took off like a rocket. I immediately switched into
> Stabilize to regain control.
>
> Looking at the logs, I expected to see loss of GPS satellites and
> larger HDOP at the point Loiter went crazy, but in fact I saw the
> opposite: Num satellites actually went *up*, from 10 to 11, and HDOP
> went *down*, from 1.60 to 1.57 at that point.
>
> This issue could be very dangerous, because some people like to use
> loiter to land, and if it flies off so suddenly at low altitude when
> you're least expecting it because of how rock solid the loiter is at
> first, then it could easily hit and injure someone.
>
> Flash log attached. Graph of log zoomed to the point the issue occurred:
>
> <https://lh4.googleusercontent.com/-DmX8Y3hjPOc/UkRBeliBduI/AAAAAAAABPU/P9cy3XmFMEE/s1600/loiter_issue.png>
>
>
> --
> 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
> <mailto:drones-discuss%2Bunsu...@googlegroups.com>.

Emile Castelnuovo

unread,
Sep 27, 2013, 11:52:46 AM9/27/13
to drones-...@googlegroups.com
Strangely enough the same exact situation happened two days ago to our port of the 3.0.1rc1
As soon as the loiter was engaged it flew at full speed towards unknows location with 10 sats and good hdop.
No log, because it was on a friends board, but once in stabilize everything went back to normal.
Wondering if this could be a "software glitch"....
Emile


2013/9/27 Stefan Gofferje <stefan....@gmail.com>

Randy Mackay

unread,
Sep 27, 2013, 12:03:09 PM9/27/13
to drones-...@googlegroups.com

     There's a lot of people flying the code, let's not fall into the "me too" trap prematurely.

     Mavbot's incident was accompanied by a change in hdop and num satellites which leads towards a GPS glitch being the cause.  I've investigated 4 other loiter incidents in the last 24h (the incidents themselves happened over the past couple of weeks but I only reivewed them all yesterday).  They were flown with a variety of different code bases and the causes have been:
            2 x incorrect compass orientation
            2 x GPS update rate incorrectly set to 1hz

     The GPS update rate set incorrectly does need to be investigated so we should discuss on the next dev call.

-Randy



From: Emile Castelnuovo <emile.ca...@gmail.com>
To: drones-...@googlegroups.com
Sent: Friday, September 27, 2013 8:52 PM
Subject: Re: [drones-discuss] Dangerous Loiter flyaway with good GPS sats and HDOP

Randy Mackay

unread,
Sep 27, 2013, 12:19:38 PM9/27/13
to drones-...@googlegroups.com

     I should add that the GPS issues were both with non-3dr GPSs.  3dr GPSs come with the 5hz update rate pre-configured so this wouldn't happen with those.

-Randy



From: Randy Mackay <rmac...@yahoo.com>
To: "drones-...@googlegroups.com" <drones-...@googlegroups.com>
Sent: Friday, September 27, 2013 9:03 PM

Harry Gibson

unread,
Sep 27, 2013, 12:28:46 PM9/27/13
to drones-...@googlegroups.com, Randy Mackay
I hesitate to bring my "user query" onto the dev list but since it has come up: my crash did not seem to be incorrect compass orientation as it was the internal APM compass at this time, with a decent separation from power sources, and previously flying well. You suggested that it was probably an issue of compass calibration being out by >90 degrees and I can accept that but it leaves 2 things unanswered. Firstly, how / why did it change since the previous successful flights. Secondly, the yaw recorded in the logs matches well with the direction the copter was actually pointing (I have video too) - as far as I can judge (i.e., not very accurately but certainly within 90 degrees). 

On the first point, it occurred to me that I was using a camera on the doomed flight and reading around now, it seems that it is a very RF-noisy camera. So I can well believe this affected the GPS, although there is no evidence of that in my log that I can see; I don't know whether it could affect the mag as well, or even the APM itself? If the mag is affected that could give a >90 degree offset that wasn't present before.  But even that leaves the second point unanswered, unless the APM itself is somehow affected by the noise. If the yaw in the logs is the yaw the APM is getting from the compass, and if it was at least approximately correct, I'm not totally clear that my crash was caused by compass issues alone. The camera is now staying in the box, anyway!

I had IMU logging on and had wondered about the consequences of this as I know it's recommended to turn it off when not required. My understanding of realtime programming is pretty limited but surely the point is that something either will execute in time, or it won't; it should be deterministic? If that's not how the APM runs, then what actually are the consequences of too much logging? Are you saying that leaving IMU logging on and flying in a CPU-intensive mode like auto may lead to a crash? It would be good, if possible, for warnings like this to be made more explicit: as a user I am aware of the "recommendation" to turn off excess logging when not required but not clear of the actual consequences, or if these are risks or definites?

Harry

Sean Limes

unread,
Sep 27, 2013, 2:46:58 PM9/27/13
to drones-...@googlegroups.com
Randy, the tricopter has rct's ublox CN-06. I guess that explains the 1 hz update rate. I'll figure out how to fix that...

Nevertheless I've never had loiter like that on that hardware before, so food for thought perhaps.

The logs were on so high because I don't have telemetry hooked up (bad ground loop burned out my transmitter) and I've been tuning by flying a little, checking logs, rinsing and repeating. I'll crank it back down after I get the bird airworthy again.

Sean

Robert Lefebvre

unread,
Sep 27, 2013, 2:59:16 PM9/27/13
to drones-discuss
Yeah, I'm pretty sure that the horrible performance I had with my quad was due to compass orientation.  I just can't figure out what happened because I was flying at *exactly* the same location I was flying at the day before,, almost to the foot, and had changed *nothing* in the program or settings.  I was even using the same battery.  Randy suggested maybe a bad compass bootup, but I rebooted a couple times.  So I dunno.

This is the same APM that had the SPI bus failure on my little helicopter in August.  It's all I've got so I am trying to use it.  So far the SPI bus hasn't given me a problem, and the compass is on I2C so I don't see a connection there.

I've had compass problems at this field before, it seems to come and go.  They're unexplained, like the Bermuda triangle.

Olivier ADLER

unread,
Sep 27, 2013, 9:49:54 PM9/27/13
to drones-...@googlegroups.com


In theory, WAAS or EGNOS should be able to detect and inform about solar induced glitches (and other glitches caused by atmospheric events or satellites faults).

SBAS ground stations should detect almost instantaneously those problems and transmit them to the GPS receivers. The max time to delivery is 6 seconds.

For this integrity detection system to work, SBAS integrity detection must be enabled in the Ublox. Actually it is disabled. When integrity detection is enabled, the GPS receiver automatically remove bad satellites from the solution according to the latest SBAS integrity messages.


This is not a perfect protection, but it is better than nothing.


Another more efficient protection, would be a ground GPS connected to Mission Planner. If something becomes wrong with the GPS system, then the ground GPS position will drift and this will be a good indicator that position integrity is affected.


This seems difficult to implement directly at the user level, but eventually volunteers around the world could have "ground GPS base stations" that could monitor the GPS integrity and stream their results to a server through Internet so that Mission Planner could get realtime integrity data.

Perhaps it's possible to have this integrity data somewhere else, ideally from the SBAS ground stations network.


A complementary protection would be to parse satellite prediction data inside Mission Planner from a prediction site, and inform the user about the GPS system quality for a given position at a given time.


There is too the official "GPS STATUS AND OUTAGE INFORMATION" where "OPS Advisories" can be downloaded.

http://www.navcen.uscg.gov/?pageName=gpsStatusExplained


Olivier.





Kevin Hester

unread,
Sep 27, 2013, 10:11:27 PM9/27/13
to drones-discuss
Hmm - I still know very little about GPS sats, but from reading your good posts and various web articles it seems like it would be possible to make a web service to do provide RAIM outage prediction just like in aircraft GPSs (true?).  The sat orbit information is free on the web and there seem to be a couple of good Java celestial navigation libraries.

However, I'm kinda reluctant to add this to my queue until I really know how much of a problem it is.  I'd be inclined to say, let's wait for two months of glitch resistant flying to see if we need RAIM prediction.  If we see crashes it would be awesome if someone who has the right background was able to dig through the GPS data and say yes, this crash happened during an outage that would have been predicted.  Until we have such a 'smoking gun (or hole in the ground ;-))' I'm kinda reluctant to make a lot of software which might not have helped at all.

Of course, if someone already knows of a library that does all this 'snarf sat data and make RAIM predictions (similar to what the garmin av units do), please post a link - existing code makes everything much easier. Math is hard.

From a garmin 530W manual (a $12K GPS ;-)):

"RAIM Prediction is based on the current almanac of the coarse orbit information of the entire satellite network.  When you select an arrival time at a specific waypoint, as in the GNS 530W below, it advances the satellite positions along their orbits to determine which satellites are in view there (which ones and how many). From the geometry of their location and yours, a dilution of precision can be calculated and an estimate made of how good your solution will be.  This prediction uses certain criteria to determine whether RAIM will be available or not.  On the 530W it will do this calculation and give you an answer. That prediction is shown below, along with RAIM prediction from an FAA website (raimprediction.net). The FAA prediction is for a 24 hour window."

Inline image 1


Kevin Hester

unread,
Sep 27, 2013, 10:14:18 PM9/27/13
to drones-discuss
Actually - the FAA does have such a web API!  I will reach out to them...

Kevin Hester

unread,
Sep 27, 2013, 10:28:41 PM9/27/13
to drones-discuss
And it is interesting to note that right now a big swath of the US would be generation RAIM warnings if you tried a non-precision GPS approach and _didn't_ have baro based GPS estimation correction.


If you have baro correction (I remember there was some talk on a dev call that in theory we can (do?) feed that baro data to the GPS) the whole country is in the green.

Ben Nizette

unread,
Sep 28, 2013, 12:05:40 AM9/28/13
to drones-...@googlegroups.com

Hi Kevin,

On 28/09/2013, at 8:11 AM, Kevin Hester wrote:

> Of course, if someone already knows of a library that does all this 'snarf sat data and make RAIM predictions (similar to what the garmin av units do), please post a link - existing code makes everything much easier. Math is hard.

I'm doing some work with Tridge on local area DGPS corrections, that work should be fairly complete within the next several weeks. One part of this could easily include a measure of actual quality of satellite data during flight, as we'd have a local static ground station with which solutions could be compared. The point of the DGPS is that much of this data could be corrected, but we can also apply some tricks to estimate residual error and present warnings.

The code as it stands also includes the ability to calculate sat positions using the short term, high accuracy data for specific sats (ephemeris) rather than the longer term almanac that covers all sats. Extending the calcs to the almanac should be a simple matter of parsing one more UBX message, not much work.

>
> From a garmin 530W manual (a $12K GPS ;-)):
>
> "RAIM Prediction is based on the current almanac of the coarse orbit information of the entire satellite network. When you select an arrival time at a specific waypoint, as in the GNS 530W below, it advances the satellite positions along their orbits to determine which satellites are in view there (which ones and how many). From the geometry of their location and yours, a dilution of precision can be calculated and an estimate made of how good your solution will be.

If this is the whole story, I'm not sure how much use it would be for us. On the scale of commercial flight paths, constellation geometry might be an issue. On the kind of scale we usually fly, bigger issues are ionospheric weather conditions, local area occlusion etc which aren't predicted by this service, or by the 530W AFAICT.

But yeah, give us a few weeks and Tridge's and my DGPS ground station should be able to detect these conditions in RT.

--Ben.


Randy Mackay

unread,
Sep 28, 2013, 12:45:42 AM9/28/13
to drones-...@googlegroups.com

     With the next release I'll be looking at a lot of log files and I could extract the position (and guess the time) from the logs.  The time might not be that accurate unless I tried hard to figure out a way to calculate the actual time back from the gps time.

     I hope the GPS Glitch protection will work well because it not only ignores the sudden glitches but on top of that when it does finally accept a big position move it immediately resets it's position without passing it through the inertial nav filter.  doing that reset avoids the nasty build up of incorrect velocity and acceleration info so it will be a much more controlled flight.

     The other thing that we could try doing is reducing the inertial filter's xy time constant.  It's set very low meaning the GPS plays a big part in the position estimate.  Making it higher might also help reduce glitches although I don't know how it would affect toiletbowling.

-Randy



From: Kevin Hester <kev...@geeksville.com>
To: drones-discuss <drones-...@googlegroups.com>
Sent: Saturday, September 28, 2013 7:11 AM

Subject: Re: [drones-discuss] Dangerous Loiter flyaway with good GPS sats and HDOP

Kevin Hester

unread,
Sep 28, 2013, 1:03:14 AM9/28/13
to drones-discuss
Hi Randy,

If it helps: If the flight comes from an andropilot tlog the time should be correct within a few ms.  I fixup the time relative to to the GPS time the phone is using...

Ben Nizette

unread,
Sep 28, 2013, 3:08:40 AM9/28/13
to Kevin Hester, Andrew Tridgell, drones-...@googlegroups.com

Hi Kevin,

On 28/09/2013, at 10:20 AM, Kevin Hester wrote:

> Hi Ben,
>
> Cool - I remembered Tridge mentioning such a project. Sounds great. Tridge also mentioned something about it depended on the local ground station also having a Ublox due to some something about how DGPS works.
>
> Would it possible to do a baby version this, with a non Ublox based ground station. i.e. would the stock Android GPS API give you enough inputs for this to work as a ground station?

It certainly won't work for the DGPS correction as we need raw pseudorange readings and preferably carrier phase measurements as well, rather than just the output fix. Even with a uBlox you need the special -T or -P suffix parts which cost 2-3x more than what's used as standard in the community.

The Android GPS API probably won't work for RAIM-style prediction of geometric dilution either as you can get where the satellite /is/ but not where it's going to be; i.e. all you can calculate something is something similar to the DOP your GPS is already giving you!

So short answer: The android GPS interface won't give my DGPS drivers anything useful. But that's not to say having a vanilla GPS and/or an internet connection in your ground station is useless. Some of these ideas have been raised previously in the thread, but:

One may download the almanac and ephemeris data from various sites on the internet. This would allow an Android base station to perform the predictions of DOP figures much like the FAA or 530W does. This bit is pretty much the FAA RAIM service in terms of functionality so I'm still not totally convinced of the usefulness in our case.

More interestingly though, if you've got any GPS in a static location for the duration of the test (known location is best, but just static should do), you can measure various statistics that might at least help you to raise a warning. If the ground station fix jumps significantly as new sats appear/disappear, the fix is sensitive, probably high noise and therefore probably pretty rubbish. If many/all satellites have poor SNR, similar situation. If a small number of sample points deviate significantly from a longer term (5-10min) average then you can also suspect local area reflections or occlusions that might be worth flagging. I'm sure there are other heuristics that could be applied with enough data analysis.

Lastly, there are services that can provide real time GPS observations over the internet that are suitable as input for the full DGPS wizardry. These are mostly paid services, however some agencies may provide free access for specific (probably non-profit) causes. Not a solution for flying at a park on the weekend but possibly an option for researchers/comp flyers/special events etc.

--Ben.

Kevin Hester

unread,
Oct 3, 2013, 8:17:39 PM10/3/13
to drones-discuss
Hi ya'll,

I received a reply from the FAA.  They were very helpful.  I have a couple of other droneish things ahead of this in my queue, but in a couple of weeks I'll add support to Andropilot to warn if you are flying in an area/time the FAA would issue a RAIM warning.  I'll make the code fairly separate so it should be not too difficult to port to other GCSes.  If anyone has time and wants to write this as a little Java class that would work too - just contact me and we can work it out...

Kevin

Philip Rowse

unread,
Oct 4, 2013, 10:33:21 AM10/4/13
to drones-...@googlegroups.com
The ground GPS thing is quite simple, volunteers around the world connecting a GPS to a small web server that analyses the data and pushes a GO NOGO to a common website.... What data is gained? We will find out...

NORMAN SANCHEZ

unread,
Oct 4, 2013, 2:40:00 PM10/4/13
to drones-...@googlegroups.com
This is a Widget to display the latest 3 Hourly Planetary(estimated Ap) K Indices from http://www.swpc.noaa.gov/ftpdir/lists/geomag/AK.txt to e.g. help UAS Pilots to be aware of possible GPS-Problems. Read more about that here: http://www.mikrokopter.de/ucwiki/en/SunStorm 
The whole APP ist OpenSource and you can find the code on https://github.com/ligi/Solar-Activity-Monitor
Thanks to http://mikrokopter.de for the impulse, http://www.swpc.noaa.gov for the Data and Clemens -Nebukad- Wronski for the Graphics!

http://creativecommons.org/licenses/by-nc-sa/2.0/de/ (Creative Commons / Non Commercial / Share Alike)

Addtitonally to this Licence it is not allowed to use this project in any violent manner! This explicitly includes that lethal Weapon owning "People" and Organisations (e.g. Army & Police) are not allowed to use this Project.


El jueves, 26 de septiembre de 2013 10:25:04 UTC-4, David Dewey escribió:
Today I was flying Arducopter V3.0.1 around in Stabilize for about 8 minutes and then switched into Loiter. It had good GPS (10 satellites) and good HDOP (1.60). It was perfectly solid and holding very still in loiter, but then all of a sudden it rolled way to the right and took off like a rocket. I immediately switched into Stabilize to regain control.

Looking at the logs, I expected to see loss of GPS satellites and larger HDOP at the point Loiter went crazy, but in fact I saw the opposite: Num satellites actually went up, from 10 to 11, and HDOP went down, from 1.60 to 1.57 at that point.

This issue could be very dangerous, because some people like to use loiter to land, and if it flies off so suddenly at low altitude when you're least expecting it because of how rock solid the loiter is at first, then it could easily hit and injure someone.

Flash log attached. Graph of log zoomed to the point the issue occurred:


Reply all
Reply to author
Forward
0 new messages