Solo Submarine - Awaiting 3DR response.

Gambledog · Feb 12, 2016

I lost my Solo, along with a gimbal and a GoPro Hero 4 Silver in the Pacific today. I was flying off a rocky coastline/cliffs, so it's definitely not recoverable. I maintained line-of-sight except to check controller signal at the start of the unplanned descent. I did not see the actual crash as the drone dropped below my line of sight.

-I definitely did not initiate landing, rtl, or any kind of control input that should cause a descent.
-I was flying in "normal"/loiter mode with a good GPS lock.
-Conditions were slightly windy, but well within acceptable limits
-I was flying at max speed towards shore when the descent/crash occurred, about 200m offshore.
-Battery was around 70% at the time of the crash.
-There were no nearby obstacles (open ocean in every direction except back to me) and I was flying at about 20m (60 feet) so there is no way a fish/wave/etc made contact with the drone.
-I do not have video from this flight as I was planning to record on my approach inland, and the descent/crash happened just before I would have started filming.

I'm waiting to hear from 3DR to see if my equipment will be covered. They can get tlogs from my support ticket, but without the drone, I can't connect via mission planner to review them myself. Will post an update when I hear back from them.

Anyone have any idea as to what might have gone wrong?

Daryl Sargent · Feb 12, 2016

If you logged the ticket on Android the logs will still be on your phone / tablet. Search the forums for the file location.

Sent from my SM-N910G using Tapatalk

Gambledog · Feb 12, 2016

Thanks! Found it!

See the attached tlog. extension changed to txt to allow uploading.

-GPS lock was maintained.
-Flight mode was definitely still Loiter (not alt. hold) so it shouldn't be drifting
-Throttle increased during descent to no effect.
-Density and GPS altitudes appear to agree unless I'm misreading something. I don't think this is the forward-pitch barometer error problem I've read about.
-I don't think there's any negative stick input (but I'm not clear which channel corresponds to which axis in the logs).
-Target altitude continues to be a positive number and doesn't change during the descent.
-Note: I launched from a roughly 10m cliff, so -10m corresponds to the start of the ocean.

Jubalr · Feb 12, 2016

Gambledog said:
Thanks! Found it!

See the attached tlog. extension changed to txt to allow uploading.

-GPS lock was maintained.
-Flight mode was definitely still Loiter (not alt. hold) so it shouldn't be drifting
-Throttle increased during descent to no effect.
-Density and GPS altitudes appear to agree unless I'm misreading something. I don't think this is the forward-pitch barometer error problem I've read about.
-I don't think there's any negative stick input (but I'm not clear which channel corresponds to which axis in the logs).
-Target altitude continues to be a positive number and doesn't change during the descent.
-Note: I launched from a roughly 10m cliff, so -10m corresponds to the start of the ocean.

Sorry about the loss, I will take a look at the log as well. In the other thread you mentioned you maintained LOS. If so, how was it allowed to descend below LOS? If you were in FF flight and saw it descending, did you try to ease up on the speed to recover, hit pause, manual, etc? Just trying to understand the circumstances.

Edit: Looked at the logs for a minute. The little fella was certainly trying! First guess based on the logs is it had a pretty good head wind it was fighting. You were never over 10' above home point and as you went out over the ocean & Solo was traveling at about 14mph but drawing only about 15-17a or just about the same or less than a no wind hover. So the wind was at it's back. Coming back towards land, Solo was pitching forward at 35deg, still doing 14mph but drawing 30a! So yes, it was trying but was limited in the amount of lift it can generate by being in Fly mode and limited by the setting in the turtle/rabbit slider. In order to recover, when you saw it losing altitude you could hit 'Pause' then Manual or manual right away and fly it back. You could also Pause and give it additional altitude margin before returning to Fly mode and return at a slower speed, or RTH, etc.. But it doesn't appear to be a software or HW error. It was just doing what it could under current settings. Below is the image at impact. You can see the angle, speed and amperage draw...

Maddog · Feb 12, 2016

Wonder if he lost altitude because of the forward pitch angle- unable to maintain or increase altitude?
Has been discussed in another thread.

Jubalr · Feb 12, 2016

Maddog said:
Wonder if he lost altitude because of the forward pitch angle- unable to maintain or increase altitude?
Has been discussed in another thread.

That was my opinion above. In fly mode, it was unable to compensate for the wind and pitch angle. Would have been ok in manual or stopping briefly to increase altitude. RTH would have worked too as it would have climbed first.

Maddog · Feb 12, 2016

Jubalr said:
That was my opinion above. In fly mode, it was unable to compensate for the wind and pitch angle. Would have been ok in manual or stopping briefly to increase altitude. RTH would have worked too as it would have climbed first.

Sounds like an issue 3DR should at least make people aware of on the website and in the manual.

Maybe a software/firmware tweak could force Solo to slow down at a certain angle of attack when in Fly to prevent this. Or a screen warning to exit Fly mode?

Jubalr · Feb 12, 2016

Maddog said:
Sounds like an issue 3DR should at least make people aware of on the website and in the manual.

Maybe a software/firmware tweak could force Solo to slow down at a certain angle of attack when in Fly to prevent this. Or a screen warning to exit Fly mode?

They might be able to. It would be a little tricky to do automatically. Solo would have to determine that the decent was not something you wanted or accounted for. But that is what LOS is for. If you see it descending (visually, on the controller, app or though the camera) it is a pilots option to correct.

Maddog · Feb 12, 2016

More about forward flight descent:
Altitude loss after fast forward flight

Gambledog · Feb 12, 2016

Altitude is reported in meters, so that's actually 10m (30ft) above home, close to 60ft above sea level. The sink rate was quite fast ~3m/s (10ft/s) so there was very little time to figure out that this was the problem. Although I had sight of the drone, it was far enough away that I couldn't see pitch angle very well (until I reviewed the logs). I wonder if RTL would have helped, since it generally tries to return home at max selected speed, and I was already nearly 60ft above sea level. It may have climbed initially, but suffered the same problem and crashed slightly later. On the upside, it would be easier to make a case for this being a flaw in the autopilot if it crashed during RTL.

It would be fairly easy to tell that the user didn't "request" a descent if the left stick isn't pulled down, and to limit performance to prioritize maintaining altidude. This wasn't an issue of pitch-induced barometer error, as density altitude and GPS altitude are in agreement, so the AP had all the information it needed to make a better decision. As mentioned in the other thread, it makes sense to allow a speed/altitude tradeoff in flight modes that don't automatically maintain altitude, but "fly" (or even alt. hold) should probably prioritize keeping it in the sky over more forward speed.

I think I'm probably out of luck for my hardware since there was no actual failure, just unexpected flight behavior. We'll see whether 3DR considers a flaw in the autopilot a defect, but it sounds like I might be providing a very expensive warning to others.

j4son · Feb 12, 2016

wow that solo behavior was definitely something i didn't expect. Please post updates when you hear back what 3dr thinks about ur logs

Gambledog · Feb 12, 2016

Jubalr said:
Sorry about the loss, I will take a look at the log as well. In the other thread you mentioned you maintained LOS. If so, how was it allowed to descend below LOS? If you were in FF flight and saw it descending, did you try to ease up on the speed to recover, hit pause, manual, etc? Just trying to understand the circumstances.

Edit: Looked at the logs for a minute. The little fella was certainly trying! First guess based on the logs is it had a pretty good head wind it was fighting. You were never over 10' above home point and as you went out over the ocean & Solo was traveling at about 14mph but drawing only about 15-17a or just about the same or less than a no wind hover. So the wind was at it's back. Coming back towards land, Solo was pitching forward at 35deg, still doing 14mph but drawing 30a! So yes, it was trying but was limited in the amount of lift it can generate by being in Fly mode and limited by the setting in the turtle/rabbit slider. In order to recover, when you saw it losing altitude you could hit 'Pause' then Manual or manual right away and fly it back. You could also Pause and give it additional altitude margin before returning to Fly mode and return at a slower speed, or RTH, etc.. But it doesn't appear to be a software or HW error. It was just doing what it could under current settings. Below is the image at impact. You can see the angle, speed and amperage draw...

LOS lost after the turn. Looked down to confirm heading and check signal. ~4s until drone was below zero (i.e. backed by ocean rather than sky from my vantage point). I lost those seconds looking at the screen. The next 4s were spent trying to reacquire visual. After that it was too late. Had I realized what was going on I would have of course let go of the stick to climb, but there was very little time to sort it out.

I would be interested in seeing whether the solo drops altitude during RTH if set at max speed and flying against a headwind. Can someone with a non-submerged solo check into this?

Gambledog · Feb 12, 2016

My working theory is that the summation of input to maintain position (drift compensation) and pilot input to accelerate forward is not restricted (although both are individually restricted) and this allows the drone to exceed the envelope where it can maintain altitude while flying into the wind under autopilot. If the altitude drop issue can be reproduced under full autopilot (rth) it might be enough to make a case to 3DR to fix this issue.

Jubalr · Feb 12, 2016

Gambledog said:
Altitude is reported in meters, so that's actually 10m (30ft) above home, close to 60ft above sea level. The sink rate was quite fast ~3m/s (10ft/s) so there was very little time to figure out that this was the problem. Although I had sight of the drone, it was far enough away that I couldn't see pitch angle very well (until I reviewed the logs). I wonder if RTL would have helped, since it generally tries to return home at max selected speed, and I was already nearly 60ft above sea level. It may have climbed initially, but suffered the same problem and crashed slightly later. On the upside, it would be easier to make a case for this being a flaw in the autopilot if it crashed during RTL.

It would be fairly easy to tell that the user didn't "request" a descent if the left stick isn't pulled down, and to limit performance to prioritize maintaining altidude. This wasn't an issue of pitch-induced barometer error, as density altitude and GPS altitude are in agreement, so the AP had all the information it needed to make a better decision. As mentioned in the other thread, it makes sense to allow a speed/altitude tradeoff in flight modes that don't automatically maintain altitude, but "fly" (or even alt. hold) should probably prioritize keeping it in the sky over more forward speed.

I think I'm probably out of luck for my hardware since there was no actual failure, just unexpected flight behavior. We'll see whether 3DR considers a flaw in the autopilot a defect, but it sounds like I might be providing a very expensive warning to others.

I wasn't implying you could see pitch angle, just if it was descending and what was in front of it (cliff). Not having visual would be a good reason to stop input, and hit pause or RTL. There are ways that they could certainly improve the AP in these auto modes (they have been and will continue). It has always been a fine line between making it so automated a 'Monkey could fly it' (I hate that they went that route in marketing) and still have the required feel and response for experienced pilots. Reason being, in order for the failsafe to work as you suggest, there has to be a point where the AP is overriding the pilots request. Pilot is giving it full stick but the AP is going to override and say no way, you don't know what you are doing. You then have pilots complaining that their input is being ignored. The safest mode and closest to doing that is the Turtle mode. In that mode you can not put in enough forward to cause it to lose altitude. I did extensive testing on this 6 months ago.

And there is a difference in 'Fly' and guided modes like RTL. In fly you were giving it pretty much full stick. In RTL the speed would have been less per guided mode speed parameters.
Just my opinion. YMMV.

Gambledog · Feb 12, 2016

I was on the cliff. I could see the drone against the sky, but once it dropped below about 1m above launch (3-4s into the descent which I did not see the start of) it was backed by water so I couldn't see it.

Limiting inputs to the point where the parameter the AP is set to maintain is actually maintained seems reasonable. Overriding AP should probably result in some sort of warning at the very least if a specific/decisive input to override is not required (e.g. switching to manual). The unexpected override of the AP's authority over altitude that can be induced with full-speed forward flight is what lead to my crash.

Confusion about exactly what is automated (and the limitations of AP) has caused several major airliner crashes over the years and if 3DR perfected a system it would probably sell for a lot more than a new Solo.

A more experienced pilot with awareness of the limits of the AP could have definitely saved the aircraft. A warning about this issue should really make its way into the "before you fly" documentation though.

Samphoto · Feb 13, 2016

Wow, this was a most useful read! I had no idea that could happen in a headwind. If you have things set to medium (turtle-rabbit) would that pretty much keep you safe?

What I learned from this is that full forward in a headwind can lose altitude and if that happens stop or reduce the forward thrust and allow lift to build and altitude to be gained and then return more slowly.

On a side note, am I the only one who finds it sad that "The little guy" was trying hard to get home? I know it is just a machine but it has become like a pet to me.

Sorry for your loss Gambledog.

PEDRO VASQUEZ · Feb 13, 2016

Sorry to hear that! I lost my Solo with same configuration in CanCun, Mexico in late December when it dived into the sea

Probable causes of my disaster:

1.- My the left-side ALPHA antenna got loose and was swinging from the controller so I had to pay attention to connecting it back and when I looked back up 10 seconds later and tryed to find the drone it was gone

2.- I was flying at only 12 feet over the sea, which makes me think this was a mistake, because if I has lost connection with the drone a higher altitude might have helped me to recover control over the Solo

3.- The other lesson was that I went to fly it on my own. It is always preferable and useful to have someone with you to keep constant sight on the drone

You can actually see the last images of that trip at
Good luck and fly safe!

PD: I bought another Solo vehicle Only without accesories for US$699 from 3DR and kept all my gear

Gambledog · Feb 13, 2016

PEDRO VASQUEZ said:
Sorry to hear that! I lost my Solo with same configuration in CanCun, Mexico in late December when it dived into the sea

Probable causes of my disaster:

1.- My the left-side ALPHA antenna got loose and was swinging from the controller so I had to pay attention to connecting it back and when I looked back up 10 seconds later and tryed to find the drone it was gone

2.- I was flying at only 12 feet over the sea, which makes me think this was a mistake, because if I has lost connection with the drone a higher altitude might have helped me to recover control over the Solo

3.- The other lesson was that I went to fly it on my own. It is always preferable and useful to have someone with you to keep constant sight on the drone

You can actually see the last images of that trip at

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Good luck and fly safe!

PD: I bought another Solo vehicle Only without accesories for US$699 from 3DR and kept all my gear

Sorry to hear you lost one as well, but its good to know I can get a vehicle on its own for a little less if I decide to replace it. The backpack/controller/battery are kind of depressing sitting in a closet by themselves.

Looking at the amount of offshore wind, my margin of safety for battery power was cut close as well. One more mistake I can avoid with the next one.

Soloing · Feb 13, 2016

Sorry about your Solo.

There is a reason why I never fly without recording my screen (AZ Screen recorder does a fantastic job). Once recorded, I have fast access to altitude, distance, amp draw, battery level, flight mode, Sat count and a few other things. All that without pulling any logs. To 90% that's all the telemetry information I need...

Most importantly is the fact though, that if something like this happens, I have done footage too show what happened... On top of providing the logs.

Everyone should at least install a screen recorder and try it.

Speaking of screen recorder... I thought the Solo app offers this feature by now!? I have it enabled, but do not find the footage.

Thanks.

PEDRO VASQUEZ · Feb 13, 2016

Soloing said:
Sorry about your Solo.

There is a reason why I never fly without recording my screen (AZ Screen recorder does a fantastic job). Once recorded, I have fast access to altitude, distance, amp draw, battery level, flight mode, Sat count and a few other things. All that without pulling any logs. To 90% that's all the telemetry information I need...

Most importantly is the fact though, that if something like this happens, I have done footage too show what happened... On top of providing the logs.

Everyone should at least install a screen recorder and try it.

Speaking of screen recorder... I thought the Solo app offers this feature by now!? I have it enabled, but do not find the footage.

Thanks.