Everyone who has spent anytime in the RC hobby knows the feeling you get when your model fails to respond to your controls... it happened to me yesterday.
It was a great day for flying and I decided to take my Quad out for a mid day spin. Flew an entire 5000MAh without incident after upgrading to 2.8. I few stable mode, Alt Hold with simple Mode, and Loiter....all was working really well. I had never really flow in simple mode before but I thought I would give it a try. It seemed like a stress free way to wing the quad around.
For the next battery I made no config changes and was generally flying around spending some time in loiter mode as it was a little breezy and it was a good test. All was working fine. I then went to Alt Hold with simple mode turned on and was doing a typical circuit. On the return leg I felt disconnect from the model. I was giving it left input and it was not responding. The quad then banked a bit and I needed to give it forward and left input to correct... no response. At this point it was moving at a very high rate.. I tried bumping the throttle to climb out of harms way.. again nothing. Then it all ended with a ~25 mph smash into the back of my SUV.
Quad was in a few pieces nothing than cant be repaired... truck now has two dents in the back.
Obviously I am upset but I want to understand what happened. I have not used with any degree of success the logs or telemetry that this thing stores and I want to ensure I get something that someone knowledgeable can help troubleshoot.
Assuming my APM turns on.. can someone give me the idiots guide to what is needed. I have pulled logs off the dataflash before but never really understood how to use them in detail.
Please attach your logs here, that's the first step.
What radio equipment are you using, and how do you have the failsafes set up?
Do you feel the quad was simply not responding to your commands, but was otherwise holding some sort of level? Or was it completely locked up, not seeming to do anything and falling completely out of control?
I will get the logs and upload them tonight. I know last time I looked there were several different file extensions.. which one is the most useful?
I am using a Hitec Aurora 9 and I had not set any fail safe functions in the radio for this model. For the APM software I also have not set a fail safe as I was not presently comfortable with the performance of the quad to enable advanced fail safe features. I have never attempted an autonomous mission or any flight more than 50 yards away.
My interpretation of the behavior was that it was holding some type of stabilization and/or altitude. It was however otherwise unresponsive to my controls. It did not fall out of the sky indicating a complete system lock up but did take a gradual decent at a high rate of lateral movement. When it crashed all the motors were running until the battery became disconnected. The quad was never more than 50 yards away at all times and it all happened very fast ( less than 5 seconds)
If I had to guess it was something with simple mode. I'm not sure if its coincidental that this was the first time I extensively flew it. Also for full disclosure and troubleshooting, I have never been able to get RTL to work properly. It always had a mind of its own when enabling that so I gave up on it. Not sure that will be helpful in addition to the log files.
Did you happen to have telemetry running?
Any logs you can pull out of mission planner will definitely help figure out what happened. Just post them here and we can sift through them.
You'll probably always set and test a fail-safe from now on as well I would imagine. =)
Glad it was just the quad and a little sheet metal, and not something more fleshy. Also be glad you still have the pieces! Not everyone is so lucky.
There's a lot of people here to help, post up what you can get!
Not having any failsafe programmed... well it could lead to this. At the very least, you should program the Rx failsafe to output stabilize mode, with all stick centered and throttle at 1/4. Worst case, this should have it level out, and descend slowly. That's best case when all else fails.
I think .log is the what you're looking for.
I believe these are the logs. I took the log with the highest number.
This sort of thing is why I'm tempted to write an 'Remote Kill' extension to the Jdrones IO board that would use a spare radio channel, or a whole other radio altogether.
Still 5 seconds - that's not a lot of time to press the red button.
Can someone with appropriate skills / knowledge take a look at these logs. Hopefully it sheds some light on what happened to help both myself and others.
Hey...I'm moving these over to another computer to try some other stuff, but just wanted to check some basic logic first.
Can you describe the flight real fast? This is what I see...you were in stabilize for a while (pink) but then spent a good deal of time in RTL (red) and then went back into stabilize where it looks like you crashed (orange). Does this coincide with what actually happened?
I've experienced a very similar flight, although it was several months back with version 2.6.X or 2.7.X. I was flying in stabilize mode when the input channels on the APM froze (we verified this by looking at the logs and saw the inputs stayed at the current position at the time of the hang as well as testing of the RC system separately to rule it out). We almost regained control by issuing commands from the Mission Planner software, but ended up hitting a side of a building at about 15mph. We've not had this problem repeat, but it did drive us to implement a Termination System that uses a RC channel to switch a mux (avail from the DIYDrones store) that changes control of the motors from the APM to a static low value that turns off the motors. This solution doesn't address whatever problem the APM had, but at least allows us to avoid hitting things and keep the vehicle from "flying away".
I'm thinking brownout. Was this an APM 2 or APM 2.5 board? APM 2.5, which has a lot of power protection circuitry (which also drops the voltage a bit) needs a very reliable 5v+ supply. If it gets less than that, the PPM encoder can brownout before the Atmega2560, which can lead to a result like you've described. In that case, the solutions are:
1) A stand-alone BEC
2) An ESC that can be set to generate more than 5v
3) We're going to be shipping a stand-alone power supply (and voltage/current sensor) that will ensure that brownouts never happen. Hopefully in a few weeks.
First thanks for spending the time to help diagnose this log file. I know its probably time you would rather spend doing something else.
To help shed some light from memory. I had stable mode turned on 100% of the time. I had no way to disable stable mode from the transmitter with the configuration I was flying that day.
I took off and few for a while.. then I think I changed to Alt Hold with Simple mode.. then a while in Loiter.. then Alt Hold with simple and it crashed in that mode.
I never engaged RTL and did not have it configured to do so from the transmitter.
If anyone has the ability to help analyze the logs it would be greatly appreciated.