DJI Drone Help Forum

Return to Home not working - including log


The Phantom 4 has been gathering dust for 2 years, but was just brought out to play again. I updated the software on drone as well as controller to the latest.

Everything works just fine, except return to home… It used to work perfectly.

Here is the link to a test-flight, illustrating the problem:

I click “RTH” at the 1m 36.9s mark.

Log then reads:
RTH: Heading alignment; Aircraft is returning to the Home Point. Minimum RTH Altitude is 30m. You can reset the RTH Altitude in Remote Controller Settings after cancelling RTH.
RTH: Ascending to RTH altitude

RTH altitude is set to 30m in the settings.

When I click return to home, the drone will turn the camera towards home and ascend to the max allowed altitude - and just stay there, hovering.

The distance to home is >200m or so, so it is not because it is too close. The home point is also clearly visible in the display, so it does know where home is. There is a clear line of sight to home as well, no obstacles. Also no obstacles close to the drone.

What could be the problem here, and how do I fix it?

Which firmware version does DJI GO show is installed on your Phantom? Does this happen every time you use RTH?

It happens every time, yes.

Normally from most of the data that I have seen, the max climb was due to a VPS issue. This data does not definitively show that although it could still be possible. You cancelled RTH approx 1 second prior to max altitude being reached. That said, the aircraft only hovered after you switched to sport mode. This could be the reason the aircraft did not begin the return path. Granted, I am only guessing but you could test that with another flight with the VPS turned off.

1 Like

Thanks for your suggestions.

I have tried all sorts of different scenarios, including staying entirely in p mode. The behavior is always 100% identical: rotate towards home, ascend to max altitude, stay there.

I waited for minutes as well, when it’s just sitting there at max altitude. I tried various settings for max altitude, RTH altitude etc. Always same behavior.

It’s also in the exact same environment, where I have flown quite a bit two years ago, where rth worked perfectly.

It’s a real headscratcher…

Here is a log, where I after about 7m30s am in P-GPS mode and engage the RTH and the same behavior can be observed:

You have not yet attempted a flight with the VPS turned off, as suggested. The issue will persist IMO until you have tested that. Should the same anomoly occur, then I might agree that this would be a head scratcher.

I don’t think the VPS is causing this problem. The flight logs show the downward sensors aren’t close enough to detect anything. Since they aren’t detecting anything, they wouldn’t cause the aircraft to automatically ascend. I think it’s more likely that there is a bug in the P4 firmware or there is an issue with the front sensors.

@frostyPind, did you look at the DAT flight logs? They might contain some additional details in the event log generated by DatCon.

Neither do I, but it is a possibility. That is why I suggested testing with the VPS off. I agree as well, as far as the .dat file goes. As I mentioned Litchi is a great for flying, but it does have it’s limitations for device flight logs.

I’m not seeing it. Nothing in the logs indicates the downward sensors are detecting an obstacle. And if that was the case, it’s highly unlikely that the downward sensors would only be detecting an obstacle while the drone is in the process of returning home.

During the climb, it far surpassed the set RTH altitude. Point being, that simply because the aircraft is too high for the downward sensors to report properly ( and or not at all which would be expected ), does not mean that the VPS is not an issue unless that is tested. Both you and I have seen these climb issues before involving the VPS. Some proven, some not.

I have never seen the VPS cause an aircraft to climb when it was not reporting data in the flight log. If you have an example handy, I’d love to see it.

Exactly my point. Simply because the data was not reported as has been seen many times before, does not mean that there is not a VPS issue. Usually it is intermittent data, such as from a gimbal guard etc…This is why I suggested testing that before guessing further…due to the lack of additional data.

As far as I can tell the only downward facing sensor data is the OSD:sWaveHeight data. It’s reported as 0.0 when the data doesn’t existed or is invalid. There is also the OSD:isSwaveWork signal that tells us if the OSD:sWaveHeight data is valid. This plot shows the intervals where OSD:isSwaveWork is true (green background) and where it is false (red background). The orangeish background is that interval where RTH is in progress and OSD:isSwaveWork is false.

Beside all this, invalid VPS data won’t cause this RTH behavior.

These flights have the appearance of a front sensor reporting that the P4 that there is an obstacle in front of it. But, the problem is that MC_PARAM:rthOA enabled is set to false meaning that the P4 shouldn’t try to avoid obstacles during an RTH.


Agreed, but it possibly could cause the un-commanded climb above the RTH altitude set point. Since the OP cancelled RTH just before it reached the max altitude, there is really no way to know if the aircraft would have begun the return flight at max altitude, which has been seen before with a VPS issue. That was really all I was suggesting by trying another flight with the VPS off. That is the easiest way to verify if it is or is not an issue.

Here is another log, where it reaches max height after selecting RTH and still staying stationary: (would not let me post phantomhelp link for some reason)

Around 7 min mark.

Yes, it is only for a few seconds, but I tried similar approaches several times, also where I let it just sit there for 30+ seconds at max altitude in RTH, without anything happening.

I have not tried analyzing a dat file. I will have to look into how that works. Was difficult enough getting the logs off an Ipad for a non-apple user. :smiley:

Simply for the sake of asking the question. Are you using the APP RTH or the RC RTH? Not that it should make any difference, but according to the data you are using the APP RTH.

I have tried both with same result, but I believe in the two logs I have posted, I used the app RTH.

I don’t know if the tablet .DAT has the front sensor data. But, why don’t you post it so we can take a look. You might have to use Dropbox or a sililar public sharing site.

Happy to share any data I have to resolve this. This is the full export of the Flightrecords folder from the ipad.

There is an empty folder “MCDatFlightRecords”, which I fear is what you are asking for. :frowning: