RTH from a point "Before" contact was lost... DJI owes me a beer

Joined
Sep 12, 2014
Messages
3,470
Reaction score
945
Location
Where the deer and the antelope play
Okay, here's the scenario, you've flown behind something and the Phantom has lost connection with the controller. What will happen? If what I have learned is correct, it will initiate RTH (Return To Home).

Well, that's just fine and dandy unless there is an obstruction (which caused the break in communications to occur) between you're controller and the Phantom.

What's your bird going to do? It's going to initiate RTH. Well, that just sucks if the Phantom just flew behind an obstruction which is 100 meters higher than your Home Point.

Wouldn't it be great if the Phantom could be programmed to return to a "pre-programmed" point/time (like 30 seconds) before it lost contact with the controller. Once it reaches that point, it could pause and wait for your input and/or somehow notify you that it has returned to "that point" and it has been reconnected.

What would be even better is if it would let you know that it is awaiting new instructions. If you do not input new instructions within a predetermined amount of time, it will initiate RTH. :p



The simple version...
My Phantom flew behind an obstruction. OMG what do I do?
"Problem solved"
Contact is lost :eek: the bird stops, backs up, and awaits further instructions or (depending on what you have chosen in the programming choices), initiates RTH from that predetermined point it has returned to "before" it lost contact with the controller. :)

I'm thinking anyone smarter than me can program this into the Phantom.
 
  • Like
Reactions: dirkclod
I think you can program the RTH flying height in case connection is lost so the solution would be to calculate the aproximate height of the highest obstacle on the area of the posble retourn routes add a safety percentage, lets say and extra 10 meters and that would be fine.
So if I am operating my phantom in an area I have some threes and lightpoles in the sector and the highets of them is lets say 10 meters (30 feet), I will preprogram the Phantom RTH hight to be at leasts 20 meters. Wolud not hurt if you make it 50 or 60.
That way in any case the aircraft will return to the vertical of the landing spot at an obstacle free height.
Your idea is good but I am not sure what advantage would be gained by hovering 30 seconds out of VOL behind an obstruction far away where you can surely do nothing to improve the sittuation or regain contact in just 30 seconds. Anyway I think this preprogramd behaviour could be easily added to the Phantom by DJI as and addition safety feature for the RHT. Just give the pilotos the option to pre select it or not and everybody happy :)
 
  • Like
Reactions: IflyinWY
I think you can program the RTH flying height in case connection is lost so the solution would be to calculate the aproximate height of the highest obstacle on the area of the posble retourn routes add a safety percentage, lets say and extra 10 meters and that would be fine.
So if I am operating my phantom in an area I have some threes and lightpoles in the sector and the highets of them is lets say 10 meters (30 feet), I will preprogram the Phantom RTH hight to be at leasts 20 meters. Wold not hurt if you make it 50 or 60.
That way in any case the aircraft will return to the vertical of the landing spot at an obstacle free height.

Thank you for your reply Furia.
I believe you are correct, but that is not the point. What if it is a mountain which rises thousands of feet? The Phantom may not be able to climb, travel, and then descend for a safe landing.
 
Yes, of course you have to take this into account when you plan your flight.
I come from a background where you always plan your flight before and you always plan alternatives and escape routes and options before take off or before initiating specific maneuvers..
In your example about the drone going behind a large mountan there is not really any good solution because hovering 30 secs or for that matter 5 minutes would not probably allow you to do anything to regain control of the aircraft because there is a large mountain between you and the drone, you would need a lot of time to move to a possition you can regain control.
At this stage proper planning before flying is your best guarantee and if there are really high obstales on your area pre-program on your App the highest RTH retourn altitude possible, hehe not exceeding the legal requirements of course.
 
Yes, of course you have to take this into account when you plan your flight.
I come from a background where you always plan your flight before and you always plan alternatives and escape routes and options before take off or before initiating specific maneuvers..
In your example about the drone going behind a large mountan there is not really any good solution because hovering 30 secs or for that matter 5 minutes would not probably allow you to do anything to regain control of the aircraft because there is a large mountain between you and the drone, you would need a lot of time to move to a possition you can regain control.
At this stage proper planning before flying is your best guarantee and if there are really high obstales on your area pre-program on your App the highest RTH retourn altitude possible, hehe not exceeding the legal requirements of course.

Most of the posts in this forum would not exist if folks thought as much, and as logically as you do.
Yes, planning ahead is something one must do to ensure the outcome. :)

There is one point you may have missed. Back up
"Wouldn't it be great if the Phantom could be programmed to return to a "pre-programmed" point/time (like 30 seconds) before it lost contact with the controller. Once it reaches that point, it could pause and wait for your input and/or somehow notify you that it has returned to "that point" and it has been reconnected."

Lets call it the "BACK UP" point. At this point, you could have control.
 
It would be easier to create a 'black box' style data log of GPS data in three dimensions, using a reasonable sample interval (waypoints recorded every 15 seconds?').

In the event of RTH being triggered, the craft re-traces it's route back along the sampled data, following an approximation of the outbound route. Simple.
 
  • Like
Reactions: IflyinWY and Furia
It would be easier to create a 'black box' style data log of GPS data in three dimensions, using a reasonable sample interval (waypoints recorded every 15 seconds?').

In the event of RTH being triggered, the craft re-traces it's route back along the sampled data, following an approximation of the outbound route. Simple.

This is a great idea and the solution to this problem. I am sure this would not be difficult to implement. The drone knows the route it has just done and most important at what height he has done it. So the only thing it has to to is to do replicate the same route backwards and at the same altitude flown before thus making sure you are not crashing into an obstacle but more interestinly, placing the aircraft in control reception area ASAP ;)

Great idea!!
 
  • Like
Reactions: IflyinWY
Yep, that's exactly what I was thinking. :D
 
It probably wouldn't be too hard to write either. The log files must exist in the flight controller unit for the home point to be stored in the first place. Use an sequential counter internally to 'stamp' the flight log entries that designate an RTH waypoint, poll the log file for those entries when the RTH routines are invoked (querying the full file for records with the waypoint stamp) - thus creating an abbreviated separate list file that will use far less memory; Then fly that list as if it was in ground station mode until it's back in control range and receives any definitive command from the transmitter. Call it 'belay' mode (as in, the rope guides used by rock climbers to minimize a fall when they lose grip!).

Where it gets tricky is in situations where GPS is intermittent (so the controller isn't able to log an accurate location stamp). This could be caused by a number of factors, including navigation around obstacles laterally - in which case, I'd look at writing the code to recognize this scenario and plot a route based on replayed sampled control inputs - which will be an approximation of what the pilot did during the GPS lock outage. But then again, maybe flying in terrain that encourages VLOS loss is a bad idea?
 
It probably wouldn't be too hard to write either. The log files must exist in the flight controller unit for the home point to be stored in the first place. Use an sequential counter internally to 'stamp' the flight log entries that designate an RTH waypoint, poll the log file for those entries when the RTH routines are invoked (querying the full file for records with the waypoint stamp) - thus creating an abbreviated separate list file that will use far less memory; Then fly that list as if it was in ground station mode until it's back in control range and receives any definitive command from the transmitter. Call it 'belay' mode (as in, the rope guides used by rock climbers to minimize a fall when they lose grip!).

Where it gets tricky is in situations where GPS is intermittent (so the controller isn't able to log an accurate location stamp). This could be caused by a number of factors, including navigation around obstacles laterally - in which case, I'd look at writing the code to recognize this scenario and plot a route based on replayed sampled control inputs - which will be an approximation of what the pilot did during the GPS lock outage. But then again, maybe flying in terrain that encourages VLOS loss is a bad idea?

Alrighty then... Over my head buddy.
Read some of my posts. I'm trying to catch up to Einstein with the most failures.
I just think them up, I don't make em work. You go with that and when it works, I'll download or upload it into the machine.
I still think if it works, DJI owes me a beer. :)
 
I still think if it works, DJI owes me a beer. :)

If my 'belay mode' idea works (and there's no reason it wouldn't, unless there's insufficient juice left in the battery to climb back to a waypoint altitude) then they owe me a job as a flight tester / software engineer :p

(Beer is useless to me as I don't drink)
 
  • Like
Reactions: IflyinWY
If my 'belay mode' idea works (and there's no reason it wouldn't, unless there's insufficient juice left in the battery to climb back to a waypoint altitude) then they owe me a job as a flight tester / software engineer :p

(Beer is useless to me as I don't drink)

I'll do the high altitude testing, and I do want the beer... :D
 
Okay, here's the scenario, you've flown behind something and the Phantom has lost connection with the controller. What will happen? If what I have learned is correct, it will initiate RTH (Return To Home).

Well, that's just fine and dandy unless there is an obstruction (which caused the break in communications to occur) between you're controller and the Phantom.

What's your bird going to do? It's going to initiate RTH. Well, that just sucks if the Phantom just flew behind an obstruction which is 100 meters higher than your Home Point.

Wouldn't it be great if the Phantom could be programmed to return to a "pre-programmed" point/time (like 30 seconds) before it lost contact with the controller. Once it reaches that point, it could pause and wait for your input and/or somehow notify you that it has returned to "that point" and it has been reconnected.

What would be even better is if it would let you know that it is awaiting new instructions. If you do not input new instructions within a predetermined amount of time, it will initiate RTH. :p



The simple version...
My Phantom flew behind an obstruction. OMG what do I do?
"Problem solved"
Contact is lost :eek: the bird stops, backs up, and awaits further instructions or (depending on what you have chosen in the programming choices), initiates RTH from that predetermined point it has returned to "before" it lost contact with the controller. :)

I'm thinking anyone smarter than me can program this into the Phantom.

For a transitory event like you fly behind a tree I don't think this is a problem, because the aircraft does not immediately go into RTH mode after the signal is lost. There are a few seconds before the **** hits the fan. I have flown out of range, and have an FPV recording showing FS activating on the iOSD. I attempted to turn 180 degrees and nothing happened immediately, but before the aircraft started its RTH phase it detected a signal again and returned to GPS mode (shown on the IOSD) and turned. I then flew it back. Obviously if you fly behind a large building for 15s then yeah fine that is more of a problem :)
 
Sounds like a good option.
Not a replacement for the simpler system we use now but an extra.
The only problem I see is that it would make understanding all the RTH processes that much more comples for pilots that don't study the manual already.
 
Do a search for Dynamic Home Point, as I believe this may be something similar to what you are suggesting.
 
  • Like
Reactions: tcope
With my P2 I could turn off the RTH option, which I always did. Can if be turned off on the P3? I don't have a P3 thats why I'm asking the question. A rewind option sounds like a very good idea!
 
  • Like
Reactions: IflyinWY
As Scarecrow entioned, this is called Dynamic Homepoint. It's in the SDK for the P3 so 3rd party apps can allow you to move the Homepoint at any point during flight.

Also, in the settings and the P3 icon (top) and then Advanced Settings there is an option to have the P3 land (and not RTH) upon a lost signal. I've never tested this.
 
I'll do the high altitude testing, and I do want the beer... :D
images4HKE7OJ0.jpg
...Hey bar keep...bring em a cold one !
 
  • Like
Reactions: IflyinWY

Recent Posts

Members online

Forum statistics

Threads
143,066
Messages
1,467,352
Members
104,933
Latest member
mactechnic