@BudWalker Just for the heck of it, here is the GE profile. Notice the First RTH. The OP was already heading back before that occured.
Ultrasonic Systems Error
- Thread starter Elbert Hill
- Start date
Small distinction. The first RTH shown on that image was actually the SmartBattery commanding an RTH. The second, and redundant, RTH was commanded by the pilot at 636 secs here
I agree, didn't look closely at the second one, because I couldn't figure out why the OP would have cancelled the first Low Battery RTH in the first place. Seems like a silly thing to do. I was just primarily confirming the fact that neither you nor I saw the AC flying away from the HP.
But, the pilot didn't cancel the RTH. Maybe you could say that the pilot replaced the SmartBattery RTH with a pilot commanded RTH. Either way the RTH was active from 494 secs until 993 secs when the SmartBattery commanded a landing.
That was part of my quandary. I could not distinguish if the pilot cancelled the the first RTH, or If he commanded a second one. There were no cancellation messages, or anything definitive that I could see that were OP initiated. It was quite confusing, to be quite honest with you. And I agree with the Low Battery Auto Land.
He said he landed in a desert? I remember somewhere out west the military was turning off gps for some kind of training could he have been in a area that this was going on? I don’t remember how long that gps blackout was supposed to happen or if it still being done at random times? Just a thought.
You need to use the TXTlogToCSVtool converter to see it. At 636.406 secs the flightAction signal changes from SmartPowerGoHome to RCOnekeyGoHome indicating the pilot initiated RTH. This is followed by the usual 3 sec hovering interval. There was no ascending and aligning interval after that because it wasn't required. So at 639 secs the P3 continued the (now pilot commanded) RTH.
AirData has it's uses but it's not very good for some incidents. The Notifications is just one column where it really needs to be multiple columns, one for each notification type. But, then that would be confusing to most people.
Bud
To call it a bashing would be an understatement. Thanks for recognizing it for what it was. But sure, attached/uploaded is what I believe your asking for the DJI Flight record and also including the error log as well.
I don't know why I didn't think of it earlier, but I was so put off by the initial responses I had to take a break, anyway, here's a link down below to the video of the entire flight. At around I think it was 14 minute point, the craft developed a mind of it's own, it went into reverse and drifting to the right and that's when errors were popping up like crazy. The aircraft did climb, but not to 700 feet, and it was a real struggle trying to bring the craft back on course to home which was to the left initially, then back to the right again to keep from going down into some ponds,
Video link: 2018_03_04_06_03_25.mp4
I KNOW something was going on with the craft, I just don't know what exactly it was. I've made this same flight / same route numerous times in the past with no issues.
I would appreciate any and all input ......... as long as no bashing is included !
Thanks
We already have the .txt file. What we need is the .DAT file which is on the P3 itself. Look here to see how to retrieve the .DAT. It will be large so you'll need to upload it to a public sharing site like Dropbox or GoogleDrive. Then provide the link to that uploaded .DAT.
I'm particularly interested to see if there are other anomalies that coincide with the ultrasonic sensor shown in post #18. Especially, the GPS data. If so, that would indicate either an on board system wide failure or a disruption caused by something external to the AC.
DroneJI
It was in the Coachella Valley, Palm Springs CA area, closest military training area would be about 60 miles due north which is the 29 Palms Marine Corp Base, and there's a low range of mountains between the Coachella Valley and that base. Therefore I highly doubt that played into the errors I experienced.
But thanks for the input anyway.
I had a related idea, but it didn't really make sense when looked at closely. The ultrasonic sensor glitches occur at exactly 0.5 HZ. 1 second on followed by 1 second off. I was supposing this was due to a radar rotating once every 2 seconds. But, then you wouldn't expect the on and off durations to be the same. Also, the onset of the glitches occurred with gradually increasing values
Bud
Here it is, I found what I think you need. See attached. I'm not sure if the smaller file was a continuation of the larger one or not.
Woops, files were too large, so here's links to the two files. Not sure if the smaller one is a continuation of he larger one, but they were both in same time frame.
Larger file: FLY091.DAT
Smaller file: FLY092.DAT
Neither of those .DATs are the right one. There were no motorStarts. FLY091 was created at 2018-3-4 14:16:38 GMT which I suspect is a continuation of the one we need. How about FLY090.DAT
Regarding item 3
"3) I didn't see where the AC was flying away from the HP"
If you'l follow the video link, move forward to about 13 min at that time I was heading straight towards home which was immediately just past the ponds, and, then abruptly at 13 min and about 10 or 15 sec the craft suddenly reversed direction, and heading to the right, all on it's own, I wasn't touching the controls. It was a constant struggle after that to get it back on course.It kept wanting to go either about 15 to 20 degrees right of the RTH point, or to the left of it.
Video link: 2018_03_04_06_03_25.mp4
Also worth noting I've made this exact same flight numerous times with no issues.
That right turn at 13:06 corresponds to this
Which was commanded by right rudder input.
How about at about 13 min 18 sec when it veers to the right, goes way over the dyke and over the country club, but, that's not reflected in the path from the kml file is it ? That was the turn that wasn't commanded. Also, I'm referring to the time stamp on the video, I'm not certain how that matches up to the flight record.
I was also referring to the video time stamp. I think it just appears that the P3 went over the country club. The video is showing what's out front of the P3 and not straight down.
FLY090.DAT was the right .DAT. The most prominent issue was the GPS. It seemed to quit working at about 768 secs. This can be seen by looking at the GPS:Time signal where it stops increasing. Note the steps in this signal; that's where 60 secs is reached.
The GPS didn't work for the remainder of the flight and through the next .DAT as well. However, after the P3 was turned off, at the end of FLY091, the next time it was turned on (FLY092.DAT) the GPS was functioning properly. What ever the problem was it seems to have been resolved by power cycling.
The question remains whether the issue was confined to the GPS or was this caused by something that caused other problems. At time 819 secs there was the altitude anomaly. It's not the raw barometer that jumped. Rather it was the smoothed barometer value.
As I understand it the smoothed value is computed from the raw value and this would have to be some kind of processing glitch. @sar104 might want to take a look at this.
Finally, there were the ultrasonic height glitches that I described previously. By running DatCon at the highest sampling rate it can be seen that distinctive pattern is just an artifact. But, it still remains that the ultrasonic sensor was invalid for most of the flight.
Got all that?
. If it were my P3 I wouldn't want to fly it before I knew the GPS problem wasn't going to happen again. Maybe some short test flights. And, practice switching from P to A instead of F so you can be ready
I seem to remember way back suggesting that the major fault was GPS ...
GPS and its changing info is of extreme importance to the whole flight - even in ATTI mode ...
GPS does not give Hover stability in ATTI - but it is still if available providing RTH data.
The system will be confused and fighting conflicting info .....
Personally I would have the machine checked out as I would never trust it after such a flight.
Forums are great for suggesting possibilities why .. but at end of day because of so many data streams coming into the FC - you can say its one part - fix it - but still be in the crapper - because its very difficult to identify each and every fault. DJI would have the diagnostic capability for this, where it delves deep into the machine itself....
Nigel
GPS and its changing info is of extreme importance to the whole flight - even in ATTI mode ...
GPS does not give Hover stability in ATTI - but it is still if available providing RTH data.
The system will be confused and fighting conflicting info .....
Personally I would have the machine checked out as I would never trust it after such a flight.
Forums are great for suggesting possibilities why .. but at end of day because of so many data streams coming into the FC - you can say its one part - fix it - but still be in the crapper - because its very difficult to identify each and every fault. DJI would have the diagnostic capability for this, where it delves deep into the machine itself....
Nigel
The data from this flight provides a one of a kind opportunity to observe how GPS data is used. Not really pertinent to see what happened, just interesting - to me at least.
The Lat,Long coords used by the FC don't come directly from the GPS module. Rather, the Lat,Long coords are derived from the GPS data and IMU data. By fusing these data it's possible to obtain higher accuracy coords (both temporally and position) than can be obtained from either GPS data or IMU data. This flight allows us to observe the fused coords with GPS data held constant. Here the red plot is GPS longitude data (held constant) and the blue plot is the fused longitude data.
Presumably the changes in the fused longitude are due to just IMU data shown here. The pink background are where the FC has decided the GPS data can't be used and coincides with abrupt changes in IMU data.
The Lat,Long coords used by the FC don't come directly from the GPS module. Rather, the Lat,Long coords are derived from the GPS data and IMU data. By fusing these data it's possible to obtain higher accuracy coords (both temporally and position) than can be obtained from either GPS data or IMU data. This flight allows us to observe the fused coords with GPS data held constant. Here the red plot is GPS longitude data (held constant) and the blue plot is the fused longitude data.
Presumably the changes in the fused longitude are due to just IMU data shown here. The pink background are where the FC has decided the GPS data can't be used and coincides with abrupt changes in IMU data.
Similar threads
