Yes, at 4min 5 sec is where the App go home was issued. Within a few milliseconds after that the "Out of Control" Go home was issued, and speed errors began.
Phantom 3 Pro crash in fog
- Thread starter matti
- Start date
This is very puzzling. It's clear that something went badly wrong with the front right motor, but some of the log data are not physically possible. Looking at the usual diagnostics (altitude, pitch, roll and yaw) the obvious problem started at 227 s:
That almost looks like a lost prop or motor, but not quite - the period of oscillation is a bit too large and the aircraft spins, pitches and rolls but does not tumble. To be precise, it spins CCW for nearly one rotation, then CW for nearly one rotation, and then goes into a sustained CCW spin until it hits the ground.
Looking at the motor data it gets even stranger:
According to that the right front motor simply stops at 177.2 s. Clearly it doesn't though - the attitude data in the first graph show no problems at that time. At the moment that the aircraft instability started (227 s), the only thing that we see is the onset of oscillation on the the other motors.
Motor demand also goes to zero, which seems odd:
Motor voltage is obviously wrong starting at the same 177.2 s - I had to use a log scale on the voltage axis to make it readable. I can confidently say that the front right motor voltage was not 5.7 kV:
Motor current is similarly unreasonable, although less silly than the voltage:
Total battery current is all over the place and it's not surprising that a battery error was produced, but it is more consistent with four nominal motor currents:
I'm not sure which of those motor parameters are direct measurements and which are derived, so it may be that the strange values all derive from just one incorrectly reported parameter.
My guess would be failure of the reporting from the front right ESC, which did not, apparently, stop the motor from working at some level. The result was a very inelegant spinning descent that reached around 9 m/s, or 20 mph.
Unless it has somehow cured itself I'd be surprised if it will fly.
@BudWalker ?
That almost looks like a lost prop or motor, but not quite - the period of oscillation is a bit too large and the aircraft spins, pitches and rolls but does not tumble. To be precise, it spins CCW for nearly one rotation, then CW for nearly one rotation, and then goes into a sustained CCW spin until it hits the ground.
Looking at the motor data it gets even stranger:
According to that the right front motor simply stops at 177.2 s. Clearly it doesn't though - the attitude data in the first graph show no problems at that time. At the moment that the aircraft instability started (227 s), the only thing that we see is the onset of oscillation on the the other motors.
Motor demand also goes to zero, which seems odd:
Motor voltage is obviously wrong starting at the same 177.2 s - I had to use a log scale on the voltage axis to make it readable. I can confidently say that the front right motor voltage was not 5.7 kV:
Motor current is similarly unreasonable, although less silly than the voltage:
Total battery current is all over the place and it's not surprising that a battery error was produced, but it is more consistent with four nominal motor currents:
I'm not sure which of those motor parameters are direct measurements and which are derived, so it may be that the strange values all derive from just one incorrectly reported parameter.
My guess would be failure of the reporting from the front right ESC, which did not, apparently, stop the motor from working at some level. The result was a very inelegant spinning descent that reached around 9 m/s, or 20 mph.
Unless it has somehow cured itself I'd be surprised if it will fly.
@BudWalker ?
RodPad
Premium Pilot
There is something wrong with the .DAT conversion. I'll need to look at that tomorrow. In the interim please use DatCon 1.3.9
OK - that makes more sense. The DAT conversion of the motor data was the problem. Motor speed looks like this:
The blue trace was previously missing, and the trace order has changed. While that looks much better, it doesn't explain the incident. The motor speeds look reasonable until they go into oscillation at 227 s for no apparent reason that I can see yet.
Looking into the bug in DatCon 3.1.0 uncovered some other problems that will take a while longer to fix. But, the PWM values seen in version 1.3.9 aren't quite right either. Either choice encounters a bug. 
However, by using 3.1.0 and specifying that the Parsing Mode is DatDefined Only the bugs are avoided and the requisite data can be seen.
The ctrl_motor: pwm_3 increases to 100% but the escm:esc3_speed does not increase. This indicates that it's the leftBack motor with the propulsion issue. The numbering scheme is rightFront (#1), leftFront (#2), leftBack (#3), rightBack (#4).
Typically, the P3 won't tumble like the Mavic when there is a propulsion issue. It just spins like in this incident. Maybe that's because P3's center of mass is further and lower from the props than it is in the Mavic. Maybe not, I'm just spit balling here.
However, by using 3.1.0 and specifying that the Parsing Mode is DatDefined Only the bugs are avoided and the requisite data can be seen.
The ctrl_motor: pwm_3 increases to 100% but the escm:esc3_speed does not increase. This indicates that it's the leftBack motor with the propulsion issue. The numbering scheme is rightFront (#1), leftFront (#2), leftBack (#3), rightBack (#4).
Typically, the P3 won't tumble like the Mavic when there is a propulsion issue. It just spins like in this incident. Maybe that's because P3's center of mass is further and lower from the props than it is in the Mavic. Maybe not, I'm just spit balling here.
RodPad
Premium Pilot
Just got to a computer today, need to leave pretty quick, will look at the mission when I get home.
Rod
Rod
RodPad
Premium Pilot
Well one of is confused because the zip file did really get me anywhere.
This is the mission for the video I shared on (one drive).
Mission Hub - Litchi Which would be opened with a browser from the hub.
I doubt there will be anything that I would find on your mission that would be any help. I was just curious.
Rod
This is the mission for the video I shared on (one drive).
Mission Hub - Litchi Which would be opened with a browser from the hub.
I doubt there will be anything that I would find on your mission that would be any help. I was just curious.
Rod
I haven't shared Litchi missions before. I first tried the web sharing but was unsure about it so I exported the mission and zipped it because phantom pilots didn't accept files without an extension. Litchi mission hub should be able to import it unzipped. But not much to see there: is was a very simple short mission where I tested against a prior very similar mission how precisely I could set the heading to reference points (some fences) so I don't have to rotate the footage in Final Cut at all (Litchi/P3P precision seems to be very good, about 2-3°) and learn how to smoothly control the gimbal pitch and AC/camera movements (fixed values vs POIs -- fixed value -20° seems to show just enough sky for some of my projects. Previously I have set it by hand at the start of the mission). I also tested how iOS 11.2 behaved because there were some issues with DJI GO (iOS 11.2.5 and DJI GO 3.1.27 seem to have fixed them yesterday). And then I wanted more foggy footage experience...
Maybe the 2.5 year old battery (re-charged 100 times) was already almost on its last leg and the short mission's quick climb from 10m to 120m, then a few hundred meter spurt at max speed, and finally the quick stop and preparations for RTH were too much for it, especially in the icy moist environment. I have always checked the battery via HealthyDrones/Airdata but previously there were no alerts for low voltage even in -15°C missions. I always charge the battery just prior to flying.
I haven't yet tried to fly the crashed AC (currently there is a snowstorm outside). I plan to take it very easy: maybe take off and hover a few minutes, then climb to 20-50m and carefully test the movements, then more aggressively while looking at the voltages. Then hover at 5m until there are battery warnings. I plan to get a new battery if the AC seems to be OK. If not, I might get a new P3P (I have a case, NDs, and a polarizer for the P3P so I'm in no hurry to get a newer model).
AFAIR after the crash the AC was on its left side with left side motor(s) jammed in the snow. Even if the AC seems to fly OK, should I change those or all motors after this kind of crash?
Maybe the 2.5 year old battery (re-charged 100 times) was already almost on its last leg and the short mission's quick climb from 10m to 120m, then a few hundred meter spurt at max speed, and finally the quick stop and preparations for RTH were too much for it, especially in the icy moist environment. I have always checked the battery via HealthyDrones/Airdata but previously there were no alerts for low voltage even in -15°C missions. I always charge the battery just prior to flying.
I haven't yet tried to fly the crashed AC (currently there is a snowstorm outside). I plan to take it very easy: maybe take off and hover a few minutes, then climb to 20-50m and carefully test the movements, then more aggressively while looking at the voltages. Then hover at 5m until there are battery warnings. I plan to get a new battery if the AC seems to be OK. If not, I might get a new P3P (I have a case, NDs, and a polarizer for the P3P so I'm in no hurry to get a newer model).
AFAIR after the crash the AC was on its left side with left side motor(s) jammed in the snow. Even if the AC seems to fly OK, should I change those or all motors after this kind of crash?
I was reading this thinking no way. Clearly the incident happened when the rightBack was being commanded higher (100% PWM) but it didn't respond with higher RPMs. But, there were battery problems. The green area below is where the batteryStatus is LimitOutputMax which started when the AC increased velocity.
I'm not a battery or motor guy but I wonder if the voltage was just low enough and the rightBack started to "stall". Maybe @lolo780 could render an opinion.
Yes. These are from the DatDefined signals and so are neither scaled or biased correctly. But, you can get the idea.
Just to be clear it's the Flight Controller (not the ESC) that's cutting in and out. As @sar104 observed there is some hunting back and fort at first but then it settles into a CCW spin that's consistent with reduced propulsion on either leftBack or rightFront.
As I said, I'm not a motor guy. Is it significant that the escTemp for the leftBack is about 10 degrees C hotter than than the other 3.
What I don’ understand is how you maintained VLOS at 200’ in the fog. For both recreational and commercial drone flight, you are not cleared for “instrument flight rules”. You must have VLOS at all times.
I have never seen this type of graph before, could you tell me where you got it? Seems like a great thing to see if all motors are running close to same rpm at idle or hovering. The other graphs you posted seemed to difficult for me to grasp but there must be an explanation for those.
Thank you.
That particular plot you are referring to was one that I mentioned before that was in error. If you looked closely you could see that one of the markers was mis-labeled and therfore was the wrong graph for the point I was making at the time of the post.
I understood your explanation just fine, some of the other graphs were hard to get my head around. Basically I am interested in the graph making software so I could look at my birds internal workings and try to see if all is well before/after my flights, or is it possible to check some of these things while in flight?
Possibly this data software would be to elaborate and expensive for most of us? Just curious I guess.
You can make graphs within Excel. You need that anyway to see all the data from the .csv file.
Flying through clouds, or fog, in near freezing temperatures is dangerous. Depending on a number of factors including moisture droplet size. I only experienced light icing flying through clouds which was quickly resolved by requesting a lower altitude (Air temp increase averages 2.5 degrees F as you descend 1000'). Icing usually starts forming at the leading edges such as wings and props causing disturbed airflows and loss of lift. If loss of lift is great enough than increasing RPM may not be enough to overcome the conditions I am reading about. There is a possible hole in my theory. Why only one prop affected. Perhaps dings in the prop may have been greater on one prop. These imperfections would give ice crystals a focus point to start forming.
Similar threads
