Hardware
APM 2.5 with external compas and GPS, latest stable firmware.
Quad with 94 flights at 487 minutes in the air uneventful in this configuration.
Summary:
Second flight directly after fully successful flight in windy conditions. (6 m/s at ground level)
During level, constant input Loiter flight, my quad suddenly increase “cyclic forward”/increase forward tilt and throttles up to max limit. Moments later, it starts yawing to the left, spinning that way whilst loosing forward momentum and altitude with violent roll and pitch all the way down to a surprisingly soft impact in a tree.
Handling:
When the quad entered spin, I selected Stabilise mode without any change of events. I immediately switched back to Loiter thinking it might handle the leveling better than me and I gave full throttle to ease the fall (which actually worked).
Post flight analysis:
FlashLog shows roll, pitch and yaw as described above. Input for the same channels are also coherent with my given inputs as far as I can see.
These log values are interesting to look at:
-ThoOut goes to maximum just prior loss of yaw stability
-NLoop has a spike just prior loss of yaw stability
-HDop increse stepwise through the whole flight with satellite count of 8 with a few spikes of 7, as supposed to the prevoius flight minutes earlier with constant HDop.
My own conclusion, that needs feedback from someone that fully understands this…:
As I fly around with maximum forward speed for Loiter (1000 cm/s) and turn into wind, the quad might have encountered rather strong gusts, and as my Loiter speed is ground/GPS speed, the quad has to fight to keep the speed, thus hitting the ceiling of the motors/ecs/APM. That itself leaves no thrust/rpm margin for attitude adjustments. HOWEVER, the GPS speed plotted shows no real deviation at the point where my quad departs stable flight compared to previous seconds of stable flight.
I would highly appreciate any ideas in this matter! Please see attached log file of the flight.
Unfortunately, I can’t tell you much because not much is being logged. You may’ve sent the wrong log - I don’t see ThrOut go to maximum ever - I do see the described step increase in HDop, but it stays within reason. HDop is based on the geometry of satellites - most likely, a satellite was changing position in the sky. NLoop is unrelated. INAV velocity matches GPS velocity.
Fixed the parser. Man, that thing spins pretty fast.
Unfortunately, still can’t tell you much without motor and IMU logging. I’d have to say some sort of motor failure… I don’t see how a compass failure or vibrations or GPS failure would cause this. Maybe a gyro failure? Unlikely, would almost certainly cause a very immediate crash. There’s the possibility that it is a bug, but it is very very unlikely and still impossible to diagnose without motor logging.
Yup, lucky to be on ground that day ok, but I’ve flown with this exact craft, same firmware for about 20 missions after the crash with nothing strange at all. Today in windy conditions, and it don’t like it… but it could handle it (Flew not that fast this time…)
What about my theory that I just overridden the ability to keep 10 m/s speed in loiter with hefty headwind and gusts? Some sort of saturation of the cpu ability and it got behind actual world inputs? Is there an input stack order in the system, that HAS to be done before executing a new command, even though that new command has actually gone old?
By the way, why does the wiki tell you to turn off IMU logging as default (something about saving cpu or memory) With it on always, will it limit the APM in some way?
[quote=“Flyhard”]Yup, lucky to be on ground that day ok, but I’ve flown with this exact craft, same firmware for about 20 missions after the crash with nothing strange at all. Today in windy conditions, and it don’t like it… but it could handle it (Flew not that fast this time…)
What about my theory that I just overridden the ability to keep 10 m/s speed in loiter with hefty headwind and gusts? Some sort of saturation of the cpu ability and it got behind actual world inputs? Is there an input stack order in the system, that HAS to be done before executing a new command, even though that new command has actually gone old?[/quote]
No, it has a basic real-time scheduler. It guarantees the main stabilization loop runs on time iff scheduled tasks don’t exceed their time limits.
Well, IMU logging runs at 50hz and eats up dataflash and CPU. APM is completely out of time when in a navigation mode (like loiter) and so more low-priority tasks will get pushed off the back of the scheduler.
So, there is no real obvious reason here why the it trotted up and tilting forward, then started spinning.
Due to the impact, lots of things got loose (3M wecro many parts to save it from ripping at impacts). However, one velcro cusion tape the APM casing was loose, not the other tree… but APM was still in the same orientation as designed after impact. A loose and wobbling APM in the wind can maybe be the culprit? (making it like a broken gyro)
Then it was this Hdop “climb” - haven’t sen that before?
Oh, and I actually armed the quad while holding it in my hand for launch - can that mess things up for the system, not being completely still? (power on was on ground)
Final word - would you say the PixHawk is a better choice for standard flight? Can it handle more flight related issues, not just more peripherals?
So, there is no real obvious reason here why the it trotted up and tilting forward, then started spinning.
Due to the impact, lots of things got loose (3M wecro many parts to save it from ripping at impacts). However, one velcro cusion tape the APM casing was loose, not the other tree… but APM was still in the same orientation as designed after impact. A loose and wobbling APM in the wind can maybe be the culprit? (making it like a broken gyro)[/quote]
Wouldn’t cause it to spin.
Like I said, HDop relates to the position of satellites in the sky and a gradual change is expected.
Yeah, that could cause issues, but they’d be immediately apparent and gone within a couple minutes.
Yes, PixHawk is much faster and runs a 24-state extended kalman filter to estimate states like orientation.
)
ok, but I’ve flown with this exact craft, same firmware for about 20 missions after the crash with nothing strange at all. Today in windy conditions, and it don’t like it… but it could handle it (Flew not that fast this time…)