I was flying today and all the sudden my quadcopter just took off. I was testing altitude hold mode and it took off. I immediately switched it to stabilize mode, but it was totally unresponsive. It was probably up 300 ft. and drifting, so I cut the throttle, still with no response. About 500 ft. away it crashed and I broke all 4 arms. It can be repaired, but it was very unnerving. Could someone take a look at my logs and see what went wrong, so this does not happen again.
You need to be a member of diydrones to add comments!
Replies
The issue with IMU logging is that it is quite resource intensive. In fact, not recommended at all for octos on Atmel boards unless specifically for testing and it involves some risk.
Or so I thought?
With 3.2, can we have the factory-default log set include IMU, CURRENT (and the other useful debugging data)? I've lost track of the number of maidens which I had to repeat because some of the seemly-obvious log data wasn't being recorded.
The response in this forum is way better than in the APM forum. Why is it we need the APM forum?
I only had one response to a similar post in the APM forum, and none in another post in the APM forum.
This one had 1 response:
http://ardupilot.com/forum/viewtopic.php?f=21&t=7057
This one had no response:
http://ardupilot.com/forum/viewtopic.php?f=80&t=6989
i imagine it was because moderators wanted to increase the signal/noise ratio on diydrones (where peoples problems are noise), but there just aren't enough knowledgeable people hanging out on ardupilot.com to make it useful - so the problem continues.
Hi! I am pretty new at this, but I am interested in such events and the risk of fly-off.
Here is what i see when i load the logs:
I've added in the yellow lines and superimposed some boxes. Looking directly at the log, I see a switch to the stabilize mode at line 5847. Then, the trustworthy altitude (barometer) levels off, and the ThrIn is shown to be at zero (someone more knowledgeable - is this actually throttle into the receiver, or is this somehow affected by the mode?). Then, at line 5885, the throttle shoots up to full scale.
Based on this (possibly outdated?) description of datalogging, the CTUN log is executed at 10Hz - and because there are 15CTUNs between datalog line 5847 and 5885, that leads me to believe that after switching into stabilize, the throttle was 0 for 1.5 seconds. Is this kind of math and reasonable estimate, or is there some lagtime that I don't know about?
Then, the throttle is thrown around into various states from line 5885 to 6100 (about 5 seconds), and then it is set to zero and the craft takes 5 or 6 seconds to gracefully hit the ground.
In these panic states (i've only had one bad crash, so maybe i'm just full of crap), we tend to overestimate timescales and underestimate the responsiveness of our aircraft.
Then, the throttle is thrown around into various states from line 5885 to 6100 (about 5 seconds), and then it is set to zero and the craft takes 5 or 6 seconds to gracefully hit the ground.
Lol - he broken 4 arms...if this was graceful, I'd hate to see how you defined a "hard" hit...:-)
Rather than counting CTUNs, you should just be looking at the GPS time. The time entries are in milliseconds. Just look for the nearest GPS entry to the point your are interested in, then do the same for the ending point.
In this case I see a GPS time value of 56389000 at line 5849, then at line 5887 the GPS time value is 56390400. Subtract the first from the second and you get a difference of 1,400 milliseconds, or 1.4 seconds. So you were close.
Oh, and ThrIn is the value coming out of the RC receiver and being fed into the APM. ThrOut is what the APM decides to do with that input and what it feeds to the motors. In Stabilize or Acro modes, ThrIn and ThrOut are usually the same. But in AltHold or Loiter they are usually different.
At this point in software development, with the GPS glitch protection, flyaways due to bad GPS are essentially eliminated. Weirdness can sometimes still occur in the case of bad vibration, but that can be stopped immediately by switching into Stabilize. Stabilize will cure just about anything short of a mechanical or electrical failure.
What Andre said. Below is a plot of your BaroAlt against your RelAlt. In a well set up aircraft the lines should match. Yours don't, and they don't by a lot. This is almost always caused by vibration and comparing these two values is an easy check, even if you don't log the IMU values.
You can see toward the end of your flight the RelAlt was going down. This is a combination of baro and accelerometer data. Because your APM thought it was descending, it applied power to counteract it. That's shown in your baro altitude, so the two measurements of altitude go in opposite directions.
You said you switched to Stabilize and it was completely non-responsive. That's not true. You can see that when you switched into Stabilize your climb stopped. The problem was you did a lot of very large swings in your throttle in, and it started climbing up again. Had you not done that it would have sat there quite nicely at 46 meters and you could have easily brought it down.
So I'm not sure if it is the same problem, but it wouldn't surprise me. When I was playing around with the fusion algorithm used in the ardupilot code, I found that certain initial conditions would cause the solution to diverge. This is concerning, because it means that possibly that happens in flight. With a reasonably fast time constant, I could not replicate this - so it seems to be parameter dependent.
Even with sufficient accel noise, a robust algorithm shouldn't allow the altitude to diverge beyond a certain amount of the measured baro position.
I would love to see a mathematical derivation of the complementary filter used. Then it would be possible to analyze it's convergence and stability properties.
I am an incompetent programmer with one undergraduate course in feedback & controls under my belt, so i'm your man.
I think the magic happens here: https://github.com/diydrones/ardupilot/blob/2ddc414f4d29ca1c6ea3adb...
Really, if you'd like to start up another thread to talk about it, I'm game.
-
1
-
2
-
3
of 3 Next