- Joined
- Mar 12, 2016
- Messages
- 3,920
- Reaction score
- 2,626
CRITICAL UPDATE
The brains at 3DR along with several volunteers found a bug in the firmware that was causing these incidents. That bug has been removed from a firmware update released yesterday evening. Firmware version 2.4.1-6 is now out and every solo should be updated prior to your next flight.
important firmware update
The issue was unrelated to moving the solo around prior to takeoff. You still need to leave it still while it is powering up and initializing, which is stated in the manual as well. But once it is powered up and initialized, you can safely move it around,.
Everything below this line is superseded by the above.
---------------------------------------------------------------------------------------------------------------------------
This topic has been coming up in the FB groups after several recent crashes. They had a very similar pattern of events and some common denominators. What initially looks like a solid hardware failure is actually a series of events that weren't explicitly wrong, but led to a this pattern of malfunctions. So I'm posting this as caution to everyone, hopefully to avoid further issues.
Short version: If magnetic interference or false calibration data is introduced between powering on the solo and arming for takeoff, you will be taking off with bad compass data. In flight, as you move around and make turns, that compass variance will increase. Eventually, the compass data will be so out of whack, the Solo can't make heads or tails of it's horizontal position anymore. It will end up a fly-away situation, taking off in some random direction and not responding to any user inputs. A+B+Pause kill switch might still work since it is commanding a flight maneuver, but nobody has ever had the opportunity to test that. But basically nothing else will work.
Conclusion: Find your suitable taking location, put the solo down, and power it on at that location. For example, do not turn it on over by the car or the house to give the GPS a head start, then carry it out to the middle of the yard. If you must move it, it apparently would be best to power cycle it. I know it's annoying, but it's better than having to retrieve the solo from your neighbor's tree or living room. This all goes for any Arducopter based drone, not just the solo.
RTFM: The solo manual from 3DR says not to move the solo during startup while the sensors and flight controller are initializing. There is no duration or indicator associated with that instruction. IMO, most reasonable people would take that to me a very short period of time while it's fir powering up and beeping/blinking. But after seeing what several people are experiencing, this should include the entire during from power on to arming.
Disclaimer: This isn't an official instruction from 3DR. But several very smart people with intimate knowledge of the pixhawk flight controller have reviewed the videos and log files and come to this conclusion. Some in DIY community have known this best practice for years, but it's not something "everyone but you" knew. So, call it a serious recommendation backed up by lots of evidence.
Any of you smart dudes, feel free to chime in if I missed anything.
The brains at 3DR along with several volunteers found a bug in the firmware that was causing these incidents. That bug has been removed from a firmware update released yesterday evening. Firmware version 2.4.1-6 is now out and every solo should be updated prior to your next flight.
important firmware update
The issue was unrelated to moving the solo around prior to takeoff. You still need to leave it still while it is powering up and initializing, which is stated in the manual as well. But once it is powered up and initialized, you can safely move it around,.
Everything below this line is superseded by the above.
---------------------------------------------------------------------------------------------------------------------------
This topic has been coming up in the FB groups after several recent crashes. They had a very similar pattern of events and some common denominators. What initially looks like a solid hardware failure is actually a series of events that weren't explicitly wrong, but led to a this pattern of malfunctions. So I'm posting this as caution to everyone, hopefully to avoid further issues.
Short version: If magnetic interference or false calibration data is introduced between powering on the solo and arming for takeoff, you will be taking off with bad compass data. In flight, as you move around and make turns, that compass variance will increase. Eventually, the compass data will be so out of whack, the Solo can't make heads or tails of it's horizontal position anymore. It will end up a fly-away situation, taking off in some random direction and not responding to any user inputs. A+B+Pause kill switch might still work since it is commanding a flight maneuver, but nobody has ever had the opportunity to test that. But basically nothing else will work.
Conclusion: Find your suitable taking location, put the solo down, and power it on at that location. For example, do not turn it on over by the car or the house to give the GPS a head start, then carry it out to the middle of the yard. If you must move it, it apparently would be best to power cycle it. I know it's annoying, but it's better than having to retrieve the solo from your neighbor's tree or living room. This all goes for any Arducopter based drone, not just the solo.
RTFM: The solo manual from 3DR says not to move the solo during startup while the sensors and flight controller are initializing. There is no duration or indicator associated with that instruction. IMO, most reasonable people would take that to me a very short period of time while it's fir powering up and beeping/blinking. But after seeing what several people are experiencing, this should include the entire during from power on to arming.
Disclaimer: This isn't an official instruction from 3DR. But several very smart people with intimate knowledge of the pixhawk flight controller have reviewed the videos and log files and come to this conclusion. Some in DIY community have known this best practice for years, but it's not something "everyone but you" knew. So, call it a serious recommendation backed up by lots of evidence.
Any of you smart dudes, feel free to chime in if I missed anything.
Last edited: