Flight Logs and RTH Ascent Issue

[hsmith1514]

Trying to get a better understanding of how to read the flight logs to determine causes of unexpected flight behavior. Couple days ago I was flying over a lake, with RTH height set at 200ft (I confirmed during flight, and flight logs agree). I put the drone to a height of 170ft and initiated RTH. As expected, the drone held horizontal position while it ascended to 200ft, and then it started it's horizontal return. Unexpectedly though, it also continued to climb, although at a slower pace. It got up to 366ft before I finally canceled RTH. I manually dropped down to 201ft, initiated RTH, and it immediately started it's horizontal return, but like before, continued a slow ascent. I canceled this one when it reached about 345ft, and which point I manually dropped back down to 201ft, and flew it back with the sticks. During the manual fly back, the drone did not ascend like it did during the RTH, it held it's height perfectly. When I got back to shore, I initiated another RTH while at a height of 120ft, and this time it worked as expected. It ascended to 200ft and flew back, while holding the 200ft height the whole way.

I went through the Flight Log to try to find any indication of what was happening during the unexpected climbs. There was no stick input (RC.aileron, RC.elevator, RC.throttle, RC.rudder were all at 1024), OSD.vpsHeight [ft] showed 83.7 (which I assume is the upper limit, since it never went higher than that the whole flight), OSD.flycState, OSD.flycCommand, OSD.flightAction were all Go Home, OSD.gpsLevel stayed at 5 throughout, OSD.isBarometerDeadInAir was false, OSD.isCompassError was false, OSD.isVisionUsed was false, MC.isAvoidingObstacle was false, MC.isAvoidingActiveObstacle was false, and MC.isAscentLimitedByObstacle was false. What other values should I be looking at to try to find the reason behind the behavior I experienced, or is this something that can't be determined from the logs?

 

[msinger]

I went through the Flight Log to try to find any indication of what was happening during the unexpected climbs.

Can you share your flight log?

OSD.isBarometerDeadInAir was false, OSD.isCompassError was false, OSD.isVisionUsed was false, MC.isAvoidingObstacle was false, MC.isAvoidingActiveObstacle was false, and MC.isAscentLimitedByObstacle was false

The fact that those values were false could also mean the model you were flying does not record data in those fields.

 

[hsmith1514]

DJI Flight Log Viewer | Phantom Help

Upload and view flight logs from your DJI drones

www.phantomhelp.com

The behavior I'm referring to started at 13m 22.8s

 

[msinger]

Per the Mavic 3 manual:
"If the current altitude is higher than the RTH altitude, the aircraft flies to the Home Point at the current altitude."

That was the case here. Shortly after the drone started returning home, you attempted to descend while the drone was flying home. You continued to attempt to manually adjust the drone's altitude/progress as it flew home.

While I've never seen this behavior before (or in documentation anywhere), it appears the drone marked it's current altitude before it started flying back to the home point. And then every time you attempted to descend, it counteracted by attempting to fly back up to that marked altitude.

 

[hsmith1514]

I was above the RTH altitude the first time I initiated RTH, so it held height as expected, no issue there. I then canceled that RTH, manually descended to below the RTH altitude while not under the RTH status, and then initiated a RTH again, at which point it made it continual ascent. Are you saying it "marks" an altitude and uses that as your new RTH for the rest of the flight, regardless of canceling a RTH and initiating a new one? Because that also wouldn't explain the final RTH initiated at 26m 32s at which point it raised to only 200ft and maintained height.

 

[Yorkshire_Pud]

I am wondering two things,
1) why the vertical speeds differed between the two troubled RTH's and within each troubled RTH? (see attached)
2) whether or not you actually think the drone did execute the climbs......but at those distances I doubt the drone was visible so, were you screen watching? If so did the video look as if the drone was climbing, or did you record video?

I would suggest one other thing, reduce the max height ceiling!
In the csv it appears to be set to 1640ft/500m. If you had lost connection and been unable to regain control then Lord knows what height your drone would have reached before it was over the homepoint. Whether or lost it would have broken a lower ceiling is open to debate.

 

[hsmith1514]

I am wondering two things,
1) why the vertical speeds differed between the two troubled RTH's and within each troubled RTH? (see attached)
2) whether or not you actually think the drone did execute the climbs......but at those distances I doubt the drone was visible so, were you screen watching? If so did the video look as if the drone was climbing, or did you record video?

I would suggest one other thing, reduce the max height ceiling!
In the csv it appears to be set to 1640ft/500m. If you had lost connection and been unable to regain control then Lord knows what height your drone would have reached before it was over the homepoint. Whether or lost it would have broken a lower ceiling is open to debate.

1) That's an interesting question, I didn't really notice while I was flying that it ascended so much slower during the second troubled RTH, but it was definitely faster with the first one.
2) I checked my video recording just now. I think the combination of being too far from land and only having the water as a frame of reference and it ascending too slowly during the troubled period, I couldn't really tell. However, when the RTH brought it up to the 200ft mark (at the faster speeds), I could tell based on the water that I was gaining altitude, and when I canceled RTH and brought it down manually almost 200ft from what it said was 366ft down to about 180ft, I could tell the drone was descending. And if the drone didn't actually climb but just erroneously reported it was climbing, I think bringing it down almost 200ft would have put me in the water, or at least very close to it. And I was definitely still way up above the water.

 

[msinger]

I then canceled that RTH

At which point in the log did you cancel RTH?

 

[hsmith1514]

At which point in the log did you cancel RTH?

At 13m 5s, it switches from Go Home to P-GPS (Brake) and OSD.flycCommand changes to Drop Go Home

 

[Yorkshire_Pud]

784.8 sec / 13:05,
856.4 sec / 14:16 &
1043.4 sec / 17:23

 

[msinger]

At 13m 5s, it switches from Go Home to P-GPS (Brake) and OSD.flycCommand changes to Drop Go Home

Got it. I see it now.

It doesn't make sense that it attempted to ascend beyond the RTH altitude. On the second RTH attempt, it stayed in place while ascending to the RTH altitude (as expected), and then started heading home (as expected). However, it continued ascending while flying home.

 

[hsmith1514]

Got it. I see it now.

It doesn't make sense that it attempted to ascend beyond the RTH altitude. On the second RTH attempt, it stayed in place while ascending to the RTH altitude (as expected), and then started heading home (as expected). However, it continued ascending while flying home.

Exactly. So there's nothing to indicate in the flight log what exactly is happening (other than the obvious of its climbing) or why it's exhibiting this behavior? Assuming the answer was a negative on those questions, would my only other step be to reach out to DJI and possibly give them the DAT file to determine the rogue flying?

 

[msinger]

So there's nothing to indicate in the flight log what exactly is happening

Nothing that stands out to me.

would my only other step be to reach out to DJI and possibly give them the DAT file to determine the rogue flying?

I think so. They'd probably be able to determine what happened with the DAT -- or might already know if they've seen this issue before.

If you contact DJI for help, please let us know what you find.

 

[hsmith1514]

Nothing that stands out to me.


I think so. They'd probably be able to determine what happened with the DAT -- or might already know if they've seen this issue before.

If you contact DJI for help, please let us know what you find.

Will do

 

[Don Testme]

Is there any possibility that a bottom sensor had something blocking it? I've seen dust, water droplets and or evaporated water stains cause a drone to climb, thinking there was an obstacle below it.

 

[msinger]

Is there any possibility that a bottom sensor had something blocking it?

That's often the cause of something like that. This case is a little different though. The bottom sensor shows no nearby obstacles and the drone was only ascending after RTH was enabled.