Welcome DJI Spark Pilot!
Jump in and join our free Spark community today!
Sign up

Uncommanded/uncontrollable climb

Burdman44

Active Member
Join
Nov 3, 2017
Messages
37
Age
39
Hi All - I'm well into this on the DJI forum/support, but figured I'd post here too as a heads up of something to watch out for, and/or to give those who enjoy troubleshooting something to chew on :)

Just got back from my first trip with the new-ish Spark, and ran into some issues flying in Punta Cana, Dominican Republic.

The scariest issue was when she was well within range (flying almost directly overhead at 50-ish ft altitude), then started a rapid/uncommanded climb through about 82 ft. I was pushing full down on the left stick during most of this climb, had connection, GPS, and live video feed (was watching the altitude climb in real time throughout), but it did not respond to any stick movements whatsoever. At 82 ft, I hit RTH out of desperation, and thankfully, she responded as expected thereafter - climbing to assigned RTH altitude and landing normally. (climb begins at about 2:53, RTH pressed about 3:05).

.DAT here:
Dropbox - 2017-12-09 18_10_29-0BMCE67001003T.dat

Log viewer here:
DJI Flight Log Viewer - PhantomHelp.com

Granted, I knew from flying closer to our resort earlier that day that interference in this area was absolutely savage. We had walked down the beach to this location (about 500 yards from our resort in the hopes it would be better - this location was inbetween resorts, and much further out on the water (end of pier w/no electronics on it save for our phones). Still encountered a couple of split second disconnects with go 4 citing interference as the issue, but drone always returned to hover as expected, and controller reconnected immediately without a problem.

Obviously, the scary part is that is was climbing all on its own - while fully connected to the RC, but ignoring the RC's commands. Disconnects due to interference I can understand, but not responding while connected, and ESPECIALLY not simply returning to hover when it decides to either disconnect or ignore RC commands is unacceptable. All I could think of was 'what if that thing had only been 5 ft off the ground and decided to fly forward/backward/sideways on its own instead of straight up...?'. So, we went ALL the way out on the pier to get as far away from anyone else (only 2 other people on the beach at the time) as we could and tried again with a different battery. This time the flight went perfectly for 12 minutes, but as I was certainly not going to risk ruining anyone else's vacation by flying a rogue drone into their head, Sparky was grounded for the rest of the trip unless we were in a relatively secluded/unpopulated area like this one.

In case it helps, the issues we were experiencing earlier when closer to the resort were mainly failure to maintain altitude problems, but nothing as pronounced/uncontrollable as this. Instead of hovering after takeoff, it would move up and down by itself about 18 inches repeatedly. Touch the sticks, it'd stop doing it/respond appropriately, but let let them go again and it was back to the 18 inch up and down thing. It did this both near our resort AND when we tried it again latter in the week when were out on a private island quite far away from any possible interference/people (I can upload those logs too if they'd help, but didn't want any confusion with the original/most serious issue).

So....thoughts? Can interference be strong enough to send phantom (no pun intended) signals to our drones such that they believe those signals are coming from the controller itself, or does my Spark have deeper issues?

Original DJI forum thread URL in case you'd like to see the comments so far:
Spark does the DR - scary issues...
 
Hi All - I'm well into this on the DJI forum/support, but figured I'd post here too as a heads up of something to watch out for, and/or to give those who enjoy troubleshooting something to chew on :)

Just got back from my first trip with the new-ish Spark, and ran into some issues flying in Punta Cana, Dominican Republic.

The scariest issue was when she was well within range (flying almost directly overhead at 50-ish ft altitude), then started a rapid/uncommanded climb through about 82 ft. I was pushing full down on the left stick during most of this climb, had connection, GPS, and live video feed (was watching the altitude climb in real time throughout), but it did not respond to any stick movements whatsoever. At 82 ft, I hit RTH out of desperation, and thankfully, she responded as expected thereafter - climbing to assigned RTH altitude and landing normally. (climb begins at about 2:53, RTH pressed about 3:05).

.DAT here:
Dropbox - 2017-12-09 18_10_29-0BMCE67001003T.dat

Log viewer here:
DJI Flight Log Viewer - PhantomHelp.com

Granted, I knew from flying closer to our resort earlier that day that interference in this area was absolutely savage. We had walked down the beach to this location (about 500 yards from our resort in the hopes it would be better - this location was inbetween resorts, and much further out on the water (end of pier w/no electronics on it save for our phones). Still encountered a couple of split second disconnects with go 4 citing interference as the issue, but drone always returned to hover as expected, and controller reconnected immediately without a problem.

Obviously, the scary part is that is was climbing all on its own - while fully connected to the RC, but ignoring the RC's commands. Disconnects due to interference I can understand, but not responding while connected, and ESPECIALLY not simply returning to hover when it decides to either disconnect or ignore RC commands is unacceptable. All I could think of was 'what if that thing had only been 5 ft off the ground and decided to fly forward/backward/sideways on its own instead of straight up...?'. So, we went ALL the way out on the pier to get as far away from anyone else (only 2 other people on the beach at the time) as we could and tried again with a different battery. This time the flight went perfectly for 12 minutes, but as I was certainly not going to risk ruining anyone else's vacation by flying a rogue drone into their head, Sparky was grounded for the rest of the trip unless we were in a relatively secluded/unpopulated area like this one.

In case it helps, the issues we were experiencing earlier when closer to the resort were mainly failure to maintain altitude problems, but nothing as pronounced/uncontrollable as this. Instead of hovering after takeoff, it would move up and down by itself about 18 inches repeatedly. Touch the sticks, it'd stop doing it/respond appropriately, but let let them go again and it was back to the 18 inch up and down thing. It did this both near our resort AND when we tried it again latter in the week when were out on a private island quite far away from any possible interference/people (I can upload those logs too if they'd help, but didn't want any confusion with the original/most serious issue).

So....thoughts? Can interference be strong enough to send phantom (no pun intended) signals to our drones such that they believe those signals are coming from the controller itself, or does my Spark have deeper issues?

Original DJI forum thread URL in case you'd like to see the comments so far:
Spark does the DR - scary issues...

Drones don't do very well when they are directly above the antennas -- it's kind of a dead zone, unless you tilt the controller so that the antennas are parallel to the ground.

That may have had something to do with it.
 

Attachments

  • spark antennas.png
    spark antennas.png
    5.5 KB · Views: 41
Drones don't do very well when they are directly above the antennas -- it's kind of a dead zone, unless you tilt the controller so that the antennas are parallel to the ground.

That may have had something to do with it.
Great tip - thanks!!! Will definitely keep it in mind going forward, but still doesn't explain why it started climbing so fast all by itself. If the antenna/drone position was at fault, I'd expect the drone to just hover and wait for its next command as opposed to going on its own joy ride, lol.
 
Great tip - thanks!!! Will definitely keep it in mind going forward, but still doesn't explain why it started climbing so fast all by itself. If the antenna/drone position was at fault, I'd expect the drone to just hover and wait for its next command as opposed to going on its own joy ride, lol.

Check out the flight log here: Airdata UAV - Flight Data Analysis for Drones

It might provide a little more information as to what happened.
 
Check out the flight log here: Airdata UAV - Flight Data Analysis for Drones

It might provide a little more information as to what happened.

Very interesting - thanks! Never seen that site before - bookmarked! Looks like it switched modes to "GPS Atti" mode right after the speed error/before the uncommanded climb. Still not clear on what a "speed error" is, or what "GPS Atti" mode means. Usually it's either GPS or ATTI, never seen both together in the same mode. GPS also shows solid 14-16 satellite lock for the whole flight, so I'm relatively sure that doesn't indicate the standard ATTI mode that it defaults to when GPS lock is lost/causes fly aways if beyond LOS.

Great info, but still very confused as to why it would climb on it's own like that (when connected to RC/not in any of the other automatic RTH conditions). Even if it did for some reason start RTH'ing automatically, that might explain the rapid climb, but not why I wasn't notified on the app it was doing so/why it doesn't show that mode switch on the flight log, or why I wasn't able to stop it by pushing the throttle down. I've always been able to stop/control even a critical battery auto-RTH to adjust landing point/whatever - this thing didn't even blink at control inputs during that climb, but had enough RC connection to receive and execute my manual RTH command a split second later....ugh...my brain hurts, lol).
 
Just a thought...

Are the weather conditions favorable for moisture to condense on the bottom sensors?

There are posts in this Forum about the Spark flying in fog and it thinks the fog is a solid surface and ether rises above or tries to land, on the fog.

All it takes is a little bit on the sensors.
 
Just a thought...

Are the weather conditions favorable for moisture to condense on the bottom sensors?

There are posts in this Forum about the Spark flying in fog and it thinks the fog is a solid surface and ether rises above or tries to land, on the fog.

All it takes is a little bit on the sensors.

Good idea, but no - was a beautiful 85 F degree/dry day in the Caribbean. Winds also negligible: 15-17 mph @ 500 ft per UAV forecast (seemingly confirmed by what we could feel on the ground).
 
So, interesting update on this one: Just got the status update on the case, and they're replacing the Gimbal and Camera module under warranty. Kinda surprised by that as I expected it to have something to do with one of the sensors that control altitude and/or the drone's interface with the controller......but I've read in a few places that the main camera is used in conjunction with the downward facing VPS cameras to maintain altitude - anyone know if that's accurate/potentially the reason they think this module caused the uncommanded/uncontrollable climb?
 
I would have to think they are combing data since there is NOT any redundancy with the sensor system. If they can leverage theain camera to help with altitude hold why not?
 
I would have to think they are combing data since there is NOT any redundancy with the sensor system. If they can leverage theain camera to help with altitude hold why not?

Absolutely! If they use the main camera for altitude hold - fantastic. I just wasn't sure if the definitely did or didn't. If it's not used for altitude hold, while I'm happy to be getting a brand new camera/gimbal under warranty, I'd be concerned that the actual problem wasn't addressed as I didn't have any issues with the camera or gimbal when I sent it in.
 

Members online

No members online now.

Forum statistics

Threads
14,601
Messages
118,823
Members
18,012
Latest member
Dayanadiast