Skywalker 1900 Crash due to GPS failure

It was a clear Montana day with light winds from the North gusting to about 12 mph. The first a.m. flight mapping a meandering fluvial process went very well. After recovery, we moved station to approximately 2 miles East up river to setup for another mapping mission. All preflight checks went as they should, sats 12 and with a hdop of 1.6. The mission started with an auto take off, was to meet about 30 wp’s and cover approx, 1 sq km of river. The launch was to the North, with flaps at half. The plane took off as planned to reach an alt of 100m before turning to its first wp. In doing so, flew over a set of high voltage power lines as it turned to its first mapping wp. I have flown over high voltage before and had no issue. This time hdop went to 100 and sats to 0. As I walked backward to get back to my FPV the voice enabled MP shouted “BAD GPS HEALTH”. Before I could respond, the plane rapidly descended into the forest. If said at one point per the OSD HUD on my FPV that the vehicle was traveling over 200 mph which I don’t believe could be true. I am curious if others have found issues around power lines as well. Is the stray EM flux enough to completely drown 1200-1500 mhz? The attached graphs and images are at the time of the crash. You can see as the vehicle reached its max alt over the power lines that the GPS connection had completely bottomed out. vehicle has been recovered but the fuse will have to be replaced. I also have both sets of logs attached. If anyone would like to look at the FPV video, message me and I will dropbox it to you. Mahalo, Chuck

Good to see a fellow Montanan flying an APM-powered skywalker! But sorry to hear about the crash.

Hearing that the plane started plummeting after the reported Bad GPS Health makes me think that warning was a symptom and not a cause- that is, a GPS error shouldn’t affect your barometer/altitude. Have you flown the APM since then?

I tried to look at your .log, but it does not make any sense, it’s altitude , current, throut is just wrong.
is it really from that flight ?
Anyway - 2.74 is old, but losing GPS is not a reason to crash, nor is power lines.
If you flew low, bad compass could mean a less optimal heading for a shortwhile, but not even enough to notice.
There is no autocrash feature on GPS failure. your config sets action if GPS is lost in an mode that needs GPS.

@Andre-K
What did you mean by “your config sets action if GPS is lost in an mode that needs GPS.”

Are you saying there is a parameter that controls the action for the APM to take upon GPS failure? I was not aware of that feature.

sorry about that, I mixed ArduCopter 's FS_GPS_ENABLE into this.
Arducopter have that conbfiguration options, and also a “GPS glitch protection”.

Still - losing GPS fix is not a reason for ArduPlane to crash like that.

[quote=“Andre-K”]I tried to look at your .log, but it does not make any sense, it’s altitude , current, throut is just wrong.
is it really from that flight ?
Anyway - 2.74 is old, but losing GPS is not a reason to crash, nor is power lines.
If you flew low, bad compass could mean a less optimal heading for a shortwhile, but not even enough to notice.
There is no autocrash feature on GPS failure. your config sets action if GPS is lost in an mode that needs GPS.[/quote]

The log is valid and it is for 2.78 not 2.74. Not sure what you were looking at.

It is the right log as well. Its validated by the kmz. Attached are screen shots and graphs of the log.

Tridge, I’m really looking forward to your opinion on this one when you can get to it.

Tridge responded to this inquiry outside of this forum, so I am copying here for others to see:

[color=#000080][i]I have looked at it a couple of times, but haven’t come to any definite conclusions. I don’t at all mind you reminding me about it.

The ‘2014-05-01 09-30-21.tlog’ log is clearly showing nonsense from the GPS. The GPS speed shows at 115m/s which is far beyond what an X8 can do. So for that flight the GPS is clearly highly confused and giving rubbish. Unfortunately with DCM on an APM2 there is nothing that ardupilot can do to avoid crashes when the GPS is giving rubbish data. We can cope to some extent with GPS outages where the GPS tells the APM that it has lost lock, but if the GPS claims lock and gives rubbish data then the APM will lose its attitude estimate, and is likely to crash as it can no longer control roll and pitch.

On the Pixhawk with the EKF enabled the plane would have stood a chance, as the EKF could see that the velocity numbers are not consistent with the rest of the sensors. It would still have likely flown badly, but would have a much better chance of remaining stable.[/i][/color]

This next part refers to this crash with an older Skywalker (crash #2) but with the same equipment. viewtopic.php?f=44&t=6948&hilit
Tridge mistakenly refers to this as an X8, but it is actually a Skywalker 1900. Chuck’s 1st crash was an x8 viewtopic.php?f=44&t=5808&hilit. It was also caused by a GPS outputting bad data, and led to a bug fix.

[i][color=#000080]The ‘2014-03-26 17-03-04.tlog’ log is less clear. The GPS velocity numbers are within the sane range for an X8, but the AHRS.error_rp value shows that the DCM code is not happy about its attitude estimate. The value should stay mostly less than 0.25 or so. It is OK to get occasional spikes up to higher values, but in this log it spikes up a lot, spending a lot of time above 0.8.

The end of that flight looks very much like a stall and spin. The X8 is rather prone to that, especially if it is a bit tail heavy. The high Z gyro values show it is rotating along with a rapid descent. Once an X8 is in a spin the APM can’t recover, as spin revovery in an X8 is rather specialised and the normal stabilisation won’t work at all (in fact it may make things worse).

The real puzzle is why DCM was so unhappy earlier in the flight, which may have led to a poor attitude estimate and ended in the spin. There are a number of possible causes:

  1. bad GPS data again, as above, but more subtle

  2. vibration leading to accelerometer aliasing. On the Pixhawk we can
    detect and fix this by using the two sets of accelerometers sampled
    at different rates, but on the APM2 we can’t do anything about
    it. It isn’t common, but it certainly can happen

A faulty sensor is also possible, although it is quite rare.

I’m sorry I can’t give you anything more definite to help you avoid this problem happening again! All I can suggest is:

  1. check all GPS settings, or even replace the GPS

  2. minimise vibration, try a new anti-vibration mount and make sure the
    motor shaft isn’t bent

  3. if you can, switch to a Pixhawk as the dual sensors and EKF will
    both make problems less likely to happen, and the much more detailed
    logging will help us diagnose issues if they do happen

Cheers, Tridge[/color][/i]

We have recently discovered that there is a momentary GPS dropout on this system that coincides with nearly every takeoff. Usually the GPS quickly recovers and the flight continues normally. Possible causes are a faulty GPS cable, the GPS antenna location directly in front of the motor, or a faulty GPS. We will conduct some testing to find the cause.

Thank you Tridge!

If you want to be secure that you’re not going to spin, I’d recommend installing rudders and setting up the yaw damper. Don’t use the sideslip controller on the X8 as it may not have enough cross section to produce detectable lateral acceleration.

This was a crash of a 2013 Skywalker 1900, not an X8.
But that is good advice I hadn’t considered when I had an x8.

This is very similar to what happened to my Skywalker 1900 which flew-away last weekend… fully loaded… Gopro, Mobius, EzUHF diversity and APM2.6 running 2.78.

The first indication of a problem was when my FPV LCD blacked out – my FPV LiPO was drained – the controls became sluggish (I wasnt really flying far and can see the plane), regained some control, lined it up for a landing, too high, came around (bad idea), the EzUHF TX lost power, heard and saw the plane go on RTL, ran to the tent to get spare batteries, heard the plane go around overhead a couple of times – as it should in RTL – and then silence. didnt have time to plug in the spare batt. Plane decided to go somewhere else… was not able to recover the aircraft.

Couldnt sleep for a couple of days on what could have, should have, would have… anyway, it does sound like the flyaway was caused by the GPS failure (probably caused by the motor vibration… my throttle was at 70-75% for RTL).