Lost total control of the AC. What happened here?

You said you were flying over a frozen lake. How cold was it? Is it possible that the batteries in the controller were too cold?
 
Turn off landing protection in vps settings u wont have that thing stopping at 9 ft up saying its unsuitable place to land....i hate that feature. Beside u will always know where you took off from anyway. Plus it makes hand catching way easier and it will not fight u back
 
  • Like
Reactions: Alonnlh
Turn off landing protection in vps settings u wont have that thing stopping at 9 ft up saying its unsuitable place to land....i hate that feature. Beside u will always know where you took off from anyway. Plus it makes hand catching way easier and it will not fight u back
Yeah. I found that setting later. Next time I’ll do that. Hope there isn’t a next time.
 
I think I’ll heed that advice. I usually do have to turn off OA for hand catching. But I never before had a problem with the safe landing feature.
 
TLDR; Running Go4. Lost connection momentarily and RTH initiates. Thereafter the AC would not take ANY commands - from app (command timeouts) or RC. Returned to home but stopped landing at about 9+ ft due to “unsafe landing area.” Had to wait for batt to get to basically zero before it came down low enough to catch. Whew.

.....

The whole story plus logs...

Flew my P4P out from a lake shore out over the (frozen) lake to a little over 16,000 feet and turned to come back when battery was about 60% (a minute or two before that I got a warning that it was returning to home due to low batt. I was heading out on a headwind. So coming back would be a tailwind and I knew I’d have plenty of batt to get back. I was right).

On the way back it lost connection momentarily. Not sure if I ever lost downlink. Connection came back but it was R’ingTH. I wanted to take control back so I hit the X in Go4 to cancel RTH so I could continue to fly back manually. I got a “Command Timeout.” I kept trying multiple times with command timeout every time. Video and telemetry were fine. I tried to use the sticks to speed up or drop altitude - no response. I tried to cancel RTH with the button on the controller. It stopped beeping for about 5 seconds, then started beeping again. RTH continued. So I let it come back. (I hacked the RTH speed to be faster than stock so I was feeling that would help.)

My concern was what would happen when it came back and did autoland. I wasn’t in an open field. I was on the edge of a lake with benches and a road. And some grass. Could I take control and land it myself?

No.

It got overhead at about 350 ft or whatever alt it was flying at last I had control and started autoland. It was coming down in an OK spot. Not over the bench I launched from but a few feet away over some grass. I still wanted to catch it if I could because some rock sticking out of the ground a foot away. But I had no control.

It got to about 9 ft (eyeball estimate) off the ground and stopped - warning that it was an unsafe area to land. And it wouldn’t land. And I couldn’t force it to. I figured I’d wait for critical battery to force a land and I’d catch it because the ground below wasn’t perfect. edit: obstacle avoidance was off. There may be a setting to disable the safe landing. I’ll have to check and memorize that.

I waited for it to hover from about 25% battery all the way down below 10%. Then 5%. I got warnings saying it was landing due to critical battery.

It wasn’t landing.

It continued to hover. I killed the app and restarted. I restarted the RC. It reconnected fine as far as downlink. But still no control.

Continued to hover. So I figured it would hover till the battery died and shut the motors off. Didn’t think it would completely survive a 9+ ft fall so I waited to catch it in free fall.

Much to my relief it start a slow descent at 1% batt or less. So I gently caught it by the landing gear and it shut off.

The drone had a mind of its own. I’m just glad it was a sane mind. But now I need to figure out what happened.

Any ideas would be appreciated. I’m charging the battery now to see if the problem persists.

Here is the airdata link of the main flight (there is a separate one for the landing but I doubt it’s interesting):

Airdata UAV - Flight Data Analysis for Drones

Here is the phantomhelp upload of the main flight from Go4:

DJI Flight Log Viewer - PhantomHelp.com

I’ll post more info from the power up when that happens.

When all else fails, throw the RC in ATTI mode. 100% of the time this has allowed me to take over the AC when apps wouldn't "let go."
 
  • Like
Reactions: Timinator
I always recommend updating when possible. The issue is to go on the DJI site and determine ALL the latest levels ... firmware/software, drone/controller/DJI Go 4 App ... and keep them in sync. If you decide not to update or to fall back to a previous level, you also need to assure that the levels in ALL devices are at the level they were when tested together and released.

Meanwhile, 16,000 feet VLOS ... amazing ... but incredible.
 
Unfortunately, I'm afraid your instructions from DJI support staff have been what may be considered a default response to questions they have no factual resolve.
If not too much of a bother, could you provide the present f/w versions on both controller and model, as well as the DJI GO version used, out of curiosity.
Maybe, there is some correlation there between you and the OP, particularly if using a recent f/w update, and see how now there are more than one pilot this issue has shown its ugly face to. : )

Sorry for the delay - but I pretty much didn't touch the drone until today.
Aircraft: 01.05.0600
Remote: 01.04.01.00
App (iOS): 4.2.12

Also, I uploaded my flight log to airdata, which I haven't used in a while. It looks like the troubled flight got divided into two logs. In the first flight I took off with a full battery and was getting ready to land around at around 30%. The drone was 65 ft away from me when I received the Command Timeout warning. The log then shut down after a memory loss at 20% battery and then a second log started from the time the drone was not responsive until it auto-landed, luckily on a roof nearby that I could access. Uploaded to screenshots here.

I am probably going to take it for a quick flight soon. I'll recalibrate the IMU and compass. I can say that I was standing behind the village power lines while maintaining eye contact with the drone, when I was moving to land it I walked below the power lines to the street, it could be that I was moving in an area with higher reception area compared to where I usually fly in that area.

Cheers!
Screen Shot 2018-04-21 at 4.03.41 PM.png
Screen Shot 2018-04-21 at 4.05.31 PM.png
 
When all else fails, throw the RC in ATTI mode. 100% of the time this has allowed me to take over the AC when apps wouldn't "let go."
I tried switching modes. I left that out of my initial post but did mention it in post #7. The AC simply was not taking commands or the RC wasn’t sending them. I also killed and restarted the app so it wouldn’t have held on to the RC.
 
I always recommend updating when possible. The issue is to go on the DJI site and determine ALL the latest levels ... firmware/software, drone/controller/DJI Go 4 App ... and keep them in sync. If you decide not to update or to fall back to a previous level, you also need to assure that the levels in ALL devices are at the level they were when tested together and released.

Meanwhile, 16,000 feet VLOS ... amazing ... but incredible.
How/where can I find out what RC version was tested together with my AC version (the 509 version).

And can anyone point me at an RC downgrade procedure?
 
I usually keep all levels up to date. Then it is easy to assure that all levels are in sync and were tested. If you want to fly with back level code, I would advise going to the manufacturer to get documentation on what back levels were tested together. The only thing that I feel is true is that manufacturers don't test ALL combinations of code between drone, RC controller and display device. If you decide not to maintain currency or to take on item's code and back-level it, you are at your own risk. My guess is that many of the "accidents" reported on the site may have been due to inconsistent code levels and that the risk of inconsistent release levels is real.
 
I usually keep all levels up to date. Then it is easy to assure that all levels are in sync and were tested. If you want to fly with back level code, I would advise going to the manufacturer to get documentation on what back levels were tested together. The only thing that I feel is true is that manufacturers don't test ALL combinations of code between drone, RC controller and display device. If you decide not to maintain currency or to take on item's code and back-level it, you are at your own risk. My guess is that many of the "accidents" reported on the site may have been due to inconsistent code levels and that the risk of inconsistent release levels is real.
Thank you for the advice. I am aware of the theoretical risk of running back level code. I am also aware of the very real risk of updating to newer versions due to bugs introduced by DJI - as I have not only read numerous experiences here but have been bitten myself. (Ask the people that lost drones due to the bug introduced in a firmware update that set the home point a couple miles away.) If DJI had better QC I’d be far less hesitant to update.

Having said that, DJI doesn’t have a lock on this type of upgrade risk. As a software professional for years, I’ve had to manage the best time to update professional operating systems and juggle between not jumping onto the bleeding edge and not falling too far behind. As personal computer users I’m sure we’ve all been in that boat with Windows and MacOS. For example, many thousands of users (personal and professional) stayed on Windows XP for years since it was widely considered better than what came after it. So many, in fact, that Microsoft had to extend its service life. MacOS used to be better. But even they seem to have gotten shoddy and I’m more reluctant to quickly update.

The thing with those two examples as well as other professional operating systems like VMS or Unix or IBM operating systems, is that you had more risk if you fell behind because of possibly losing third party software compatibility. This is not so much the case with DJI (with limited theoretical exception such litch or anything using the SDK). Therefore staying on an older version of the AC firmware should carry less risk unless there is a known bug that causes a known serious issue or an API change that affects third party software. Then the risk of staying behind must be weighed more carefully. In my case, the .509 version is widely held to be stable and free of serious bugs, vibrations, video flipping etc.

However, your point about mismatched versions between the controller and AC is a valid one.
 
Last edited:
When all else fails, throw the RC in ATTI mode. 100% of the time this has allowed me to take over the AC when apps wouldn't "let go."

Switching to ATTI mode didn't work. I switched several times. I had time to quit the DJI app, restart it, etc. Nothing worked.
 
Switching to ATTI mode didn't work. I switched several times. I had time to quit the DJI app, restart it, etc. Nothing worked.
When the aircraft burps, not a thing you can really do. The app is only a conduit and if the RC mode changes between P, Atti or Sport modes aren't having an effect the bird is hung at that point.
 
When the aircraft burps, not a thing you can really do. The app is only a conduit and if the RC mode changes between P, Atti or Sport modes aren't having an effect the bird is hung at that point.
It wasn’t really hung in the way that I think of software hanging. It was performing all its normal autonomous functions. Just wasn’t taking any inputs.
 
Well, the good in this is that the AC has doing by it's own mind and it's doing it correct.

Can DJI be so kind and tell us what this "timeout" means !? They are supposed to know it I think.
 
I was in IBM sales for about 15 years. So I am comfortable about being a bleeding edge user. One advantage of being an early user of software is that you can actually get connected to the development lab and create requests for a change or improvements.

I would like DJI to be more responsive to these requests, however. An example is using a time/date stamp appended to each file name so that files which are saved on your computer you don’t have the same name. This will happen if you reformat your chip which I do often to a sure full chip capacity when I fly.
 

Members online

No members online now.

Forum statistics

Threads
143,066
Messages
1,467,358
Members
104,935
Latest member
Pauos31