Fly-away and crash at 30mph...

[Fracapouille]

So, just to clarify, at the end of the flight, before it crashed, can you confirm that the drone was heading north, or a little west of north, as indicated in your diagrams? That is certainly consistent with the location you marked for the crash, but it is in completely the opposite direction from the log and DAT data record.

In terms of the accuracy of the inertial-data-derived track that I put in post #28, that is in agreement with your estimated position at 800 s, but apparently diverges wildly in the final 30 s from where it ended up.

Also - if you can give coordinates for the location then I can superimposed the derived track on the aerial image for comparison.

Yup: Google Maps

I am affirmative about the track before the crash, I was desperately looking at the drone accelerating to its death...

 

[Mackie]

Hello to all of you experimented P4 users...


I've had quite a bad day, as my P4Pro went crazy and crashed in a cliff at 80 mph (yup...).
I'm looking for some clues about what happened and if, as a pilot, I had anything to do with this.

A little bit of context below, but feel free to ask me anything that could help:

- I was doing a surveying mission in a remote area along a cliff. No GPS signal here, so I had to launch the mission in OPTI mode. I disconnected the ground sensors in order to reach 30m, then reactivated them while in flight. Maybe a bit clumsy, but it seemed to work perfectly fine for the first flight, quite sporty though when shifting from OPTI to ATTI, but everything went well. Absolutely no wind, calibration done before each flight.

- During the second flight, I totally lost control over the UAV. It made its own decision (no warnings or so before, except regarding the fact that I had reached the max altitude), and it was a very poor one. It decided to accelerate with no limit whatsoever until it hit a cliff at almost 80mph, and falled along the cliff to hit the ground 30 meters below. No need to say it is now in very bad condition...

- I've got no video recording to show, as I'm only using it as a camera. I was using it (and fully aware about that) with no GPS positionning: it seems that phantomhelp doesn't manage files without GPS positions (maybe I'm wrong here?), so there's no viewer available. Anayway the txt flight log is atttached. There's also a video of the last minute of flight as viewed by the DJI Go log viewer available here: Dropbox - 20170809_150206.mp4
I can send any other document if required for a better understanding.


Any clue about what happened would be really appreciated, and sorry about english mistakes, frenchman pilot here...

Thanks by advance for any help.

Cheers

I just have to ask....no gps signal where you were flying....seems strange, unless you were flying in polar regions. My understanding was there is basically worldwide coverage. Surely a contributing factor in the crash to have it in atti mode if in fact gps was available.
Sorry that you crashed though, always the worst ending to a flight.

 

[With The Birds]

When I said the heading was 27°, I was referring to the direction that the aircraft was pointing. Its track (direction of travel) was reporting very different, 121° just before impact. So it was facing NNE, and traveling ESE (i.e. sideways to the right). Right aileron would be accelerating it.

More worryingly, the log data do not seem to agree well at all with your aerial map. Integrating the inertial velocity data with respect to time to get position relative to takeoff point, we get the following position trace:

View attachment 86674

That doesn't seem consistent with your map at all, so I'm not sure what to conclude. I cannot see any inconsistencies in the log file data itself, unless I'm missing something that should be obvious. I guess I'll try the same exercise with a known good flight log file to compare inertially derived position with GPS.

Some very impressive and useful analysis you are sharing- are you using freely available tools?

 

[Fracapouille]

I just have to ask....no gps signal where you were flying....seems strange, unless you were flying in polar regions. My understanding was there is basically worldwide coverage. Surely a contributing factor in the crash to have it in atti mode if in fact gps was available.
Sorry that you crashed though, always the worst ending to a flight.

Thanks for your sympathy!

I was not that much disappointed that I couldn't get a proper GPS positionning there. As I'm very close to the cliff, there is a huge mask, and I'm surrounded by the trees. IIRC I had 3 satellites available at the beginning of the mission, when I started the first flight. I've been waiting 15 minutes or so, with no change. GPS positionning was available at 30 meters high, but not from my takeoff platform.

 

[BudWalker]

Thanks for your participation in the discussion. Heading of 36°, and direction of travel of 128° are not compatible with an impact on the left side of the drone, and with how things happened. Those values are can't be correct, and there is definitely something wrong here...
But I still don't get if and how this anomaly may have disrupted the attitude of the drone... I mean, trivially, any problem there might be regarding the referential, the left, right, front, back sides of the drone remain the same, and when using the controls, I don't see why the referential would interfere there? Except for yaw...
If this asumption is true, do you agree this means:
- either this anomaly may, or may not have lead to the crash, but anyway I didn't have control at all on the drone anymore and it decided itself what to do. Meh...
- or the drone was effectively accelerating and hit rightwards, and then there must have been a 180° turn at some time. If so, there should be a record of that command between the moment when the last picture was taken and the time it crashed. If there's no such record, it means at some time I lost control of the drone too...
In that case there is a good chance the compass anomaly was the reason it lost its orientation. I can't confirm that this U-turn has occurred, it can be really fast. There is something that could confirm this scenario: I took pictures of the drone before sending it to repair. It was badly damaged (TBH, I didn't want to look at this mess too much, it was quite depressing), but it seems the right arms have been more damaged:

View attachment 86703

Are you affirmative about the left side impacting first?

Thanks to all of you for your implication...

I was hesitant to mention the compass anomaly because as I said "it was very small and didn't have any significant effect."

All the available data indicates the AC had a NE heading and was flying to it's right in a SE direction of travel. The control inputs support this, and now your photo shows the impact to be on the right side.

I've been thinking more about the accelerometer and gyro data. I think what happened is that the point of impact was on the lower front right side. This would have caused the small negative X and Y accel values followed by the small roll right and small pitch down.

 

[BudWalker]

@Fracapouille , one more question. What was the heading at launch? I know the log files are saying 95 degrees. But, can you confirm that?

 

[Turbejb]

Why were yout pushing it beyond the design parameters?

 

[sar104]

Some very impressive and useful analysis you are sharing- are you using freely available tools?

Thanks. I rather enjoy these kinds of data puzzles. For the analysis of the log and DAT data I'm using Wavemetrics IGOR Pro, which is very good at processing and displaying large data sets. It has an extensive suite of built-in functions for simple analyis, filtering, fitting, calculus, FFT etc., and also a fully compilable scripting language for more complex stuff. It's not free though - the current version is around $1000.

 

[sar104]

A couple more observations.

Overlaying the integrated and scaled X, Y velocity data, i.e. position, on the aerial map gives the following:

Note that its position at 800 s (well into the flight) is approximately where you indicated previously. That could be coincidence, but it does suggest that the inertial data are good. But within 30 seconds, those data, consistent with the yaw and pitch data, show it heading fast to the SE.

The aircraft was unambiguously flying to its right, based on pitch and roll data. Right aileron was accelerating it further. The remaining question is how was it moving NW when the data all indicate SE?

To check whether the compass could have been completely wrong I took the gyro Z data from the DAT file (rotation rate in degrees per second) and integrated it with respect to time over the entire flight, with an intial value of 94.5°. If the gyro is accurate, the result is the instantaneous yaw angle as a function of time. Comparing that with the recorded yaw angle from the compass yields the result below.

The agreement between inertially derived rotation and compass heading is quite good, suggesting that the compass and Z gyro are both working fine. Looking at the last 30 s of the flight:

Still pretty good agreement right up to impact at 834 s. By both measurements, the aircraft was facing NE, and therefore flying SE, and that is completely consistent with the integrated accelerometer data. No room for the possibility that it was flying NW, which would have required the data to be 180° out.

I cannot find a credible explanation for the discrepancy between the aircraft flight path and impact location that you described with any of the recorded data in either the log or the DAT files, which basically agree with each other. I'm afraid that I'm completely out of ideas.

 

[Fracapouille]

@Fracapouille , one more question. What was the heading at launch? I know the log files are saying 95 degrees. But, can you confirm that?

It seems rather plausible. Without your suggestion, if you had asked me, I would have been pretty confident answering it was orientated in my general direction, i.e. heading east.

 

[Fracapouille]

Why were yout pushing it beyond the design parameters?

Believe me, mate, I'd rather not...

 

[Fracapouille]

A couple more observations.

Overlaying the integrated and scaled X, Y velocity data, i.e. position, on the aerial map gives the following:
View attachment 86715

Note that its position at 800 s (well into the flight) is approximately where you indicated previously. That could be coincidence, but it does suggest that the inertial data are good. But within 30 seconds, those data, consistent with the yaw and pitch data, show it heading fast to the SE.

The aircraft was unambiguously flying to its right, based on pitch and roll data. Right aileron was accelerating it further. The remaining question is how was it moving NW when the data all indicate SE?

To check whether the compass could have been completely wrong I took the gyro Z data from the DAT file (rotation rate in degrees per second) and integrated it with respect to time over the entire flight, with an intial value of 94.5°. If the gyro is accurate, the result is the instantaneous yaw angle as a function of time. Comparing that with the recorded yaw angle from the compass yields the result below.

View attachment 86713

The agreement between inertially derived rotation and compass heading is quite good, suggesting that the compass and Z gyro are both working fine. Looking at the last 30 s of the flight:

View attachment 86714

Still pretty good agreement right up to impact at 834 s. By both measurements, the aircraft was facing NE, and therefore flying SE, and that is completely consistent with the integrated accelerometer data. No room for the possibility that it was flying NW, which would have required the data to be 180° out.

I cannot find a credible explanation for the discrepancy between the aircraft flight path and impact location that you described with any of the recorded data in either the log or the DAT files, which basically agree with each other. I'm afraid that I'm completely out of ideas.

Again, thanks a lot for your job, you should apply for FAA...

I understand that this assumption of a 180° turn at some time is not confirmed by the gyro record.

However, I have to say the aerial map is not very consistent with the flight path the drone has been following...

Here is what I had in mind (and what the pictures show) - red first, then blue, then purple:

I have to keep in mind that Google orthomozaic basemap may not be a true orthomozaic, and that some important correction could be applied to the picture. There is some kind of cave where the circled area is positionned, but I think the track is far too much north compared to my initial position.
The end of the track is pretty consistent though. It seems to me that it is not consistent anymore from the moment it starts moving east (where the yellow and red tracks cross).

You'll find a video showing the area there: Dropbox - test.mp4
My takeoff and landing zone is a 1mx1m white square at the entrance of the cave (zoomed at 17s).
And another one to better understand the flight path: Dropbox - test2.mp4

 

[sar104]

Again, thanks a lot for your job, you should apply for FAA...

I understand that this assumption of a 180° turn at some time is not confirmed by the gyro record.

However, I have to say the aerial map is not very consistent with the flight path the drone has been following...

Here is what I had in mind (and what the pictures show) - red first, then blue, then purple:View attachment 86716

I have to keep in mind that Google orthomozaic basemap may not be a true orthomozaic, and that some important correction could be applied to the picture. There is some kind of cave where the circled area is positionned, but I think the track is far too much north compared to my initial position.
The end of the track is pretty consistent though. It seems to me that it is not consistent anymore from the moment it starts moving east (where the yellow and red tracks cross).

You'll find a video showing the area there: Dropbox - test.mp4
My takeoff and landing zone is a 1mx1m white square at the entrance of the cave (zoomed at 17s).
And another one to better understand the flight path: Dropbox - test2.mp4

That's pretty much what I assumed you would say, since the northern part of that track looks like it should be undergroud in the caves. Your takeoff point is strictly an unknown variable but would have to be significantly further south to make that track possible.

In terms of the orientation of the aircraft at the end, there is one other slightly puzzling thing that I should mention that I omitted before. In the comparison of the magnetic yaw reading with the integrated Gyro:Z data, there was a clearly apparent gyro normalization error - at least that's what I assumed it to be. The DAT file itself contains the integrated raw Gyro:Z data as "totalGyroZ", but those data are appear to me to be wrong, as seen below.

Two things bother me about totalGyroZ (blue). Firstly, inspection reveals immediately that just like in my direct integration of Gyro:Z (red), there is an obvious superimposed constant negative drift compared to the much more believable magnetic yaw data (green), which must represent a baseline error in Gyro:Z. My other concern is why totalGyroZ doesn't start either at zero or at 94.5° which is the initial recorded heading. Instead it starts at -95°, which is 180° off the original heading.

I normalized the Gyro:Z data by doing a linear fit to the integrated data and subtracting the slope from Gyro:Z, then integrating wrt time and finally adding the initial condition (94.5°) to give the black trace which, as I mentioned before, is very similiar to the magnetic data.

 

[BudWalker]

That's pretty much what I assumed you would say, since the northern part of that track looks like it should be undergroud in the caves. Your takeoff point is strictly an unknown variable but would have to be significantly further south to make that track possible.

In terms of the orientation of the aircraft at the end, there is one other slightly puzzling thing that I should mention that I omitted before. In the comparison of the magnetic yaw reading with the integrated Gyro:Z data, there was a clearly apparent gyro normalization error - at least that's what I assumed it to be. The DAT file itself contains the integrated raw Gyro:Z data as "totalGyroZ", but those data are appear to me to be wrong, as seen below.

View attachment 86738

Two things bother me about totalGyroZ (blue). Firstly, inspection reveals immediately that just like in my direct integration of Gyro:Z (red), there is an obvious superimposed constant negative drift compared to the much more believable magnetic yaw data (green), which must represent a baseline error in Gyro:Z. My other concern is why totalGyroZ doesn't start either at zero or at 94.5° which is the initial recorded heading. Instead it starts at -95°, which is 180° off the original heading.

I normalized the Gyro:Z data by doing a linear fit to the integrated data and subtracting the slope from Gyro:Z, then integrating wrt time and finally adding the initial condition (94.5°) to give the black trace which, as I mentioned before, is very similiar to the magnetic data.

But, totalGyroZ does start at 0. It just isn't reset to 0.0 when the flight starts. It's a computation done by DatCon by integrating and then summing gyroZ. Technically speaking the gyroZ doesn't drift; it has an error that becomes a drift when integrated. Here that drift is about .80 degrees/sec. That's a bit on the high side. I don't see how this could affect the incident though. Yaw is being corrected by the compass although at a low gain.

totalGyroZ is useful in analyzing incidents where the Yaw value is suspect since it's independent of the calculations that the FC performs to calculate Yaw.

magYaw is also computed by DatCon from magnetometer data and then corrected for roll and pitch. It's also useful n analyzing incidents where the Yaw value is suspect.

 

[Fracapouille]

OK, I think this is going to remain in some kind of "Bermuda Triangle" mystery...

Anyway, I really want to tank you all for spending some time investigating that case, you rock...
I'll let you know about the outcome with DJI.

Thanks, again.

 

[EasyB]

So much knowledge. This is great. I'm enjoying reading and learning from your inputs and experience. Hopefully, it makes me a better UAS operator.
Sorry for the unfortunate incident.

 

[Fracapouille]

Hi, all!


Finally, after sending the drone to DJI on the 17th of august, I had a reply from DJI... yesterday.
So, more than 2 monthes later, here is this answer:

“SN: 07JDE1C00101HC incident date: 09/08/2017 14:42 (GMT+8)

1. Due to the weak GPS signal, the aircraft was working in optical mode after taking off, and finally changed to Atti mode;
2. The aircraft cannot hover and position in Atti mode, and the avoidance system cannot work;
3. At t=13:54，h=38m，The aircraft crashed and caused the attitude imbalanced;

Conclusion: pilot fault, non warranty is suggested.”

tl;dr : In ATTI mode, you're f**ked up.

I'm disappointed by the lack of concern and feedback from DJI about this case. It's now a 1000€ (~1200$) bill to get it replaced through RMA.
This whole experience leaves me with quite a bitter taste...

My personnal conclusion is that there is still a very long way to get those birds as reliable as an eBee, for exemple, which I can still trust after 400+ flights and 5 years of duty.
For professionnal purposes, especially in photogrammetry - i.e. you don't fly where you would like to, you fly where you have to - I think this is not a proper device, except if you consider those as consumables, and if you budget to buy one replacement every 6 or 12 monthes. An if you wear an helmet, just in case...

Anyway, feel free to share your feedback here, I would appreciate to know how you would react in my place...


Thanks!

 

[Meta4]

In ATTI mode, you're f**ked up.

In atti mode you are severely limited with what you can do.
That's understandable, given that you don't have the benefit of GPS position holding.
Flying in atti mode close to obstacles is always going to be risky.

My personal conclusion is that there is still a very long way to get those birds as reliable as an eBee, for example, which I can still trust after 400+ flights and 5 years of duty.

Would you fly the eBee close to obstacles without GPS?

For professional purposes, especially in photogrammetry - i.e. you don't fly where you would like to, you fly where you have to - I think this is not a proper device, except if you consider those as consumables, and if you budget to buy one replacement every 6 or 12 monthes.

It would be very rare to fly a photogrammetry mission without GPS.
Normally they are done from 200 ft+ up where you will have full GPS satellite reception.
The Phantom is a perfect machine for photogrammetry and is very reliable.
Your incident was not caused by any fault in the Phantom or its design or programming.

 

[Fracapouille]

In atti mode you are severely limited with what you can do.
That's understandable, given that you don't have the benefit of GPS position holding.
Flying in atti mode close to obstacles is always going to be risky.

I accept those risks. It shouldn't make my drone go left when I push right and the other way round...

It would be very rare to fly a photogrammetry mission without GPS.
Normally they are done from 200 ft+ up where you will have full GPS satellite reception.

I have to disagree here. The MR is used when a fixed-wing can't do the job, so most of the time remote places, with difficult access, or steep slopes/facades:
- cliffs, faces of open pit quarries, waterfalls (yup), mountain slopes for ski lifts,...
- buildings, and especially here in Europe buildings in narrow streets where oblique imagery from aircrafts can't reach the bottom of a facade
- combined indoors/outdoors surveys
-...
In most cases, those are configurations where GPS signals are pretty rare. I would say at least 50% of the missions would require atti mode. GPS is luxury.

The Phantom is a perfect machine for photogrammetry and is very reliable.
Your incident was not caused by any fault in the Phantom or its design or programming.

I was disappointed by DJI customer service, now I'm more disappointed by this forum, where for the moment I had found more objective analysis and less partial point of views.
I think you should read a thread before answering without knowing. The flight log analysis shows serious inconsistencies, that still aren't explained. Don't blame the pilot and exonerate DJI before giving me an explanation about what happened, OK? Thanks...

 

[Meta4]

Don't blame the pilot and exonerate DJI before giving me an explanation about what happened, OK? Thanks...

You asked for opinions ... and I gave my opinion on what you said.
Despite your opinion, the Phantom has proved to be very, very reliable and the opinion you state does not match what other users are seeing every day.

Using it in that environment, without GPS position holding ability and little experience is asking for trouble.
An advanced pilot with experience would be very cautious attempting it.

And ...without GPS to provide location data for each image, how did you think you could do photogrammetry?