My son was flying his P4 on Christmas Day and it disconnected mid-flight (not a Christmas gift thankfully - it was a graduation gift... he's had it about 6 months). It was about 1700 ft away and 150 ft. in the air, and not within visual line-of-sight, so he waited while trying to reconnect and/or RTH automatically. When it didn't show up, we went looking for it at the last known location.
We weren't ever able to reconnect with it or find it that day, but three days later I went back to look in the vicinity of LKL and found it. The battery was missing, so I thought it might have come out in-flight since we were very close to it on the day he lost it. The other possibility is it had a hard landing and that jarred the battery out. Although I didn't see it laying close by, it was near a ditch with high weeds and I wasn't going to dig around and find a snake instead!
Here are a few pics of what it looked like when I found it. Unfortunately, I didn't think to take a picture of the spot where I found it. I was actually a bit concerned someone might think I was trespassing and so I didn't want to linger. Took these after I got home with it:
Two props look like they hit mud first, but they weren't broken. There is also a significant splotch of "something" on the top rear above the battery slot.
Here's a closer look into the battery slot. There's some discoloration near the bottom left of the back "wall" of the slot, and it appeared that possibly water had accumulated there. We had light precip in the Houston area off and on between the time it was lost and recovered, but nothing hard. This wasn't facing up toward the sky when I found it, but I've no doubt some of the precip probably got into this opening.
Here's a closer look at that splotch near the battery slot. The first thing I noticed is it's a different color than the mud on the rotors. It's obvious that the splatter that's on the side wall of the slot couldn't be there if the battery had been in the slot. I'm not sure how tight the seal is, but I'd guess not much could get on the top of the opening either. This looks like something that got there after the battery was gone. Of course, we don't know when over the course of the 3 days that happened...
Front view... the legs and gimbal seemed to be fine structurally. I have never tried operating it by hand (or even flown the P4), but the gimbal only rotates horizontally about 60-75 degrees. Having watched some of the video my son has shot, I think this is the normal range of motion to avoid getting the struts in the picture. The rotation in the vertical plane is closer to 90 degrees.
This shows a close-up of the rubber baffle or grommet that sits above the gimbal assembly. A small part of it was hanging down out of the body of the drone, but I was able to tuck it back into the opening and it appears okay.
Went back out and found the battery the next day... it was fried, presumably from laying in the mud. It had a slightly swollen area in one of the cells.
Here's where it and the drone landed...it was sitting in the tall weeds, upright, well above the water level in the ditch.
Those are some pretty tall trees, but they aren’t nearly tall enough to reach out and grab it when it was 150 ft. in the air… they’re 80-100 ft. tall, at most.
My son opened a case with DJI, and they sent us a pre-paid shipping label to return the drone and RC to them for evaluation and repair, which we did the first week of January. I hoped they could access the flight log and share it with us. I'd really like to see what it did after it disconnected, but they haven’t done that. With how the battery went splat in the mud, I'd say it had to have fallen from a decent height. Hoping this would all be covered under the warranty... we're under 1 year, but over 6 months so some parts may not be covered. Based on the quote below it appears that everything was functional when they powered it up.
| Item | Quantity | Unit Price（USD） | Total Price（USD） |
| Phantom4 central cover component | 1 | 8.00 | 8.00 |
| Phantom4 top cover | 1 | 6.00 | 6.00 |
| Service Charge | 2 | 65.00/H | 130.00 |
| Freight: | | | 0.00 |
| Total Amount: | | | 144.00 |
| DJI Care deduction： | | | 0.00 |
| Total Payment: | | | 144.00 |
I was a tad uncomfortable with sending it off not knowing what the internal flight log had on it... I have trust issues when the same people who will be deciding whether it was their fault or ours are the ones who control the information flow. That's the only way we could get to the next step in the process, since we weren’t willing to fork over the $115-140 (depending on where it comes from) to get a spare battery. Unfortunately, they concluded it was our fault.
From initial DJI Customer Service quotation:
CAS-382776-L0W5S7
| Remarks: | Customer flying at dangerous environment with a lot of trees around, the drone hit the tree branch from bottom while returning to home. |
There was no photo or video of the crash of the drone, nor did DJI send someone to the location to investigate, so they were clearly looking at Google Earth and responded with a canned answer. They have no way of proving the drone hit a tree branch - I cleaned it up before we shipped it, so there was literally no sign of damage. If it had hit a tree branch while ascending, it wouldn't have escaped with all four props intact. Furthermore, as you'll see below, the log shows a very controlled descent before loss of contact.
The log from the DJI Go app for the flight in question is here. I wanted the file stored on the drone itself, which should contain more information about what happened after it disconnected until it lost power. As mentioned, DJI has not shared that file with us.
I posted about this incident, and included this flight log, on a different forum. For comparison, the log of the flight immediately prior (just minutes before) is here. On that flight, Go to Home was activated at 2m 29s, and it shows the craft stopping forward motion, ascending to 246 ft., then continuing flight toward home. That altitude is consistent with what my son had programmed - 70 meters (even though the units on the app are set in Imperial, the selection for RTH altitude is in Metric – how confusing is that?). He disengaged Go to Home and flew it in Sport and P-GPS most of the way back, but that brief period of flight in Go Home mode indicates to me that the RTH altitude was set correctly.
On the flight he lost the drone, it shows the drone essentially hovering and decreasing in altitude after the return to home mode was activated. The drone was on the ground only a few minutes between those flights, and my son says he didn't change the RTH altitude.
I did some data analysis of those two flights... I am more comfortable with graphs, so here are pictures to illustrate the two flights.
This is the full first flight of the day. Four parameters plotted are altitude (blue line, left axis, ft.), speed (brown line, right axis, mph), battery (purple line, right axis, %) and an indicator when Go Home is activated (green line).
Here is the part of that flight where Go Home was activated (there were two downlink gaps in the data). You can see that altitude increased as expected and forward speed was resumed. This graph is on slightly different scales to match with the plots for the second flight.
Here is the full flight where the drone was lost... time on the x-axis is in minutes of flight, which picks up from the preceding flight.
Here is the last minute of data to zoom in on altitude and battery... wouldn't have expected it to suddenly start trying to land at 43% battery, but wondered if there was any correlation. The step-wise decrease in battery percentage is just because the value is reported without decimal places... in reality it was a slow, steady decrease.
It is clear to me that the drone behaved differently on the second flight than the first, and it isn't obvious that the change in altitude was correlated to activation of Go Home... this makes me wonder if there was an operational issue that caused it to lose altitude. I am less concerned now that there was an erroneous Go Home altitude set in the app, since the altitude did go up for a bit after Go Home was activated. I've looked at the other values recorded in the log and don't see anything that closely correlates to altitude decrease, but there's a lot I don't understand about the data.
A significant element of the discussion on the other forum revolved around the proximity of a small General Aviation airport nearby (Baytown Airport). The airport is west of Home point, and the app wouldn't let it fly into the restricted space, which is why my son triggered Go Home. There was a decent breeze blowing the day this happened, but not sure how that would affect it in the P-GPS mode. It appeared to hold at the boundary of the restricted altitude space.
Once Go Home is activated, I would have thought it would ascend (which it was trying to do at first) then fly home. It's like it hit a conflict in the command code that over-rode the ascend-then-fly-home instruction. If the wind was pushing it in the direction of the restricted space, could it somehow cause it to auto-land? Why isn't there any warning message about the restricted space landing?
One of the responses to my post on the other forum provided the following insight based on the flight log (thanks to msinger of PhantomHelp):
Before taking off, DJI GO did warn your son that he was about to fly in a warning zone (which has no flight restrictions). He took off and flew directly toward the airport until he hit the restricted altitude flight zone at 13m 48s in the flight log. From that point until 14m 8s in the flight log, he continued to attempt to fly toward the airport with the right stick in the full up position. Instead of pressing forward, the Phantom stopped and auto descended at its current location. While there is no message in the flight log indicating what happened, I can only assume the Phantom was trying to descend to a safe altitude since it was in a restricted altitude flight zone.
I don't understand the way it behaved… he called it “auto descending” but why would it do that without warning? Then it yawed around from -96 deg. to 90 deg. 5 seconds after RTH activated (pointing back toward Home) and then began ascending toward RTH altitude while holding station 1 second later. There were no inputs from the RC – my son was completely allowing it to function on auto. It ascended for 4 seconds then began descending again (all while pointed away from the restricted zone with no inputs from the RC).
This map shows the boundary which he reached on the second flight of the day. What's interesting is he has previously taken off and flown within the Authorization Zone (larger radius) around Baytown Airport (at a local park), but never tried to cross the boundary. That flight reached a higher altitude (186 ft.) and never generated any sort of a forced landing or even a different warning (only the same one on start-up as the flights on Christmas Day). The only difference is he never used the Go Home feature.
This wiki page is hard to decipher, but appears to have some useful info as well. It doesn't use the same zone descriptions as the map pages, but has an illustration of how the altitude limit slopes up from 66 ft. at the edge of the no-fly zone up to a limit of 1640 ft. at the 1 mile radius which designates the edge of the second (authorization or restricted-altitude flight) zone. On the flight he lost the drone, he started outside the second zone, and even if he was a few feet inside it when the app stopped his forward motion, his ceiling ought to have been well above the altitude he was flying.
My son said he received a prompt from the app asking if he wanted to request authorization when he reached the boundary (presumably after trying to cross it and failing) and he replied "no" then hit the Go Home button. Loss of contact was after that happened. It should never have been in an auto-land situation.
The RTH altitude was set well below local ceiling altitude, as well as ceiling immediately inside boundary of "authorization" zone. The aircraft was not inside the boundary at loss of contact, based on last known location. The loss-of-signal action is programmed as return to home. There were 17 GPS satellites visible at loss of contact per the flight log recovered from the app.
I've loaded the KML file for the flight log into Google Earth, and on 3D view the trees are about half the height of the drone when contact was lost. Also I've measured the length of tree shadows in Google Earth using its ruler tool, and based on the maximum sun angle on the day the pictures were taken, the trees in the area the drone went down are all well below 100 ft. tall. I don't think the customer service reps from DJI would understand the trigonometry of that proof, so I’m afraid there’s no way to convince them.
We rejected the initial response from DJI and escalated the issue (opened what they call a “dispute”). After waiting over a week, they finally got back to my son with a response.
"Our Data Analysis experts re-evaluated and double checked your RTHF height is been automatically lower because he is right next to an airport, he is flying at a no-fly zone, the height needs to be limited, and that is why the altitude is been auto lower. Please do not fly close to any AIRPORT as this affect the flight of your unit."
This demonstrates their lack of understanding of the "no fly" vs. "authorized flight" boundaries, and the fact that they don't look to what happened after RTH initiated. He tried to reiterate our concerns with the lack of an explanation of the behavior of the Phantom, but they have said the case is closed from their end. We aren’t going to have them do the repairs they quoted, so they are going to ship it back to us. We will have to wait to get the drone back, and get a battery, to try to recover the flight log off the aircraft.
I am hoping one of the mods here will be able to provide us with a better explanation than we have gotten through the Customer Service contact. As it stands now, we have very low confidence that the drone can be flown very far away without risk of losing it again. We obviously intend to stay clear of the airport, but I’ve read other posts about similar “Aircraft Disconnected” scenarios where they weren’t flying in the same setting… two ended up in rivers, one still hasn’t been recovered from the urban area it was lost. I haven’t done a thorough survey of all Phantom users, that is only the result of periodic searches of the internet.
We aren’t satisfied with the response from DJI – if there is an operating limit which we were unaware of, then we would like a clear explanation of the reason the Phantom crashed. It would obviously be nice if they would replace the battery, but we’re primarily interested in learning what happened so we can fly with confidence.
lvl.1
Administrator
Captain
lvl.3
Second Officer
lvl.2
lvl.4
