I had a disturbing experience yesterday. I was test flying my Hex and after a few successful hovers, a little PID tuning, and running through a few flight modes, I decided to let it stretch it's wings a little more.
On a fresh charge, I put it into Loiter, took it up a couple hundred feet, did a slow 360 and then slowly moved it forward.
Then, All of a sudden, the Hex sped up, headed toward the river, then banked to the right, spun around and put itself into a field about a quarter mile away.
Fortunately, no-one was hurt, and the Hex itself only suffered a couple broken arms and a prop - but needless to say, I'm quite concerned and want to get to the bottom of this before taking it out again.
I've uploaded the flight video to youtube at http://youtu.be/sc4UqOOiUUQ
I'm also attaching the flight log files.
I don't doubt it's related to something I did (or failed to do) and any insight would be greatly appreciated.
Cheers,
Adam
In case it helps - here the vehicle specs
-----------------------------------------------------
Tarot 680 (Carbon) Hex frame.
Sunnysky V3508 380KV motors
5S 4000mah Zippy Lipo
3DR Pixhawk, 3DR 915Mhz Telemetry & 3DR GPS unit
Futaba 14GS Radio
Mavlink connection to Droidplanner 2 on a Nexus 7
Replies
Other flyaway events, diagnoses, and resolutions on DIY Drones can be found consolidated as links here.
Big difference with the segway though. Two dimensional space vs three dimensional space. And when the segway detects a malfunction, it can just stop. We need to detect a problem and keep going.
I would suspect that a resonant frequency was hit from looking at the sudden vibration. Have you flown this bird with these motors before?
It was actually the first significant flight of any kind on it. Prior flights had been limited to short hops & hovers.
Hopefully it'll be rebuilt by this weekend, when I plan on doing some tethered testing followed by a lot more close range testing.
Adam,
Tridge (Ardplane dev) and I had a closer look at your logs. In particular we were wondering if the next version of the code, AC3.2, or the next version of the attitude + position estimation (Extended Kalman Filter) would have done better. We strongly suspect that it would have but we can't be sure.
How are you mounting the Pixhawk? My guess is that the vibration dampening isn't sufficient.
Joe, Thomas,
We could add more vibration check on the IMU but I've been holding out hope that these problems will be solved with the arrival of the EKF (Extended Kalman Filter). It will be running in parallel with the current IAV and the EKF apparently creates a "covariance matrix" which has a number for each sensor (and/or each derived value?) indicating how much it can be trusted. It then reduces it's dependence on those sensors for the final solution. So we have a solution coming but it's unclear whether it will be ready for AC3.2 or not.
Is this Extended Kalman Filter coming to the APM version of AC3.2 or only to the Pixhawk?
Only for processors significantly faster than the AVR on APM2.
@randy I am seeing a common cause in at least some of these out of control cases vs APM/PIXHAWK that seems to be the Flightcontroller coming loose from its mounts or excessive transmitted vibration. As the IRIS uses sticky foam for mounting I am wondering if a 3D printed and vibration isolating mount properly mechanically affixed to the top deck MIGHT be good insurance against class of outcome/crash? Just trying to stay ahead of this game:)
HZL
I think any flight controller (APM or Pix) should be on vibration dampening mounts. I don't see how it could operate properly without it?
Well, that's very scary and I'm sorry for your loss.
The issue appears to be vibration. I suspect some kind of mechanical malfunction of a motor or propeller because both accelerometers on the vehicle go nuts. That's 6G to 8G of vibration on the MPU6k accelerometers (top) and a much more reasonable 1G ~ 2G on the backup accelerometers. This completely messes up the inertial nav position and loiter does very bad things.
So clearly we need to make ArduCopter more capable of dealing with this kind of situation. AC3.2 will use the accelerometer that is more reasonable. So in this case it would use the backup instead of the main one. That would have helped but it still would have flown off I suspect. We will run the logs through the Extended Kalman Filter "replay" to see if it would have done any better.
-
1
-
2
-
3
of 3 Next