Attached is the pixhawk binary log, hoping for insight in to what went wrong.
Plane is a Skywalker X8 with known good config that has flown previously. I wanted to run autotune and as soon as I flipped in to AT the nose dipped slightly and I was not able to control the plane. From what I can tell, the Pixhawk stopped logging almost immediately after flipping in to AutoTune. After AutoTune wasn’t responding, I went back to FBWA and to Manual to try to recover but to no avail and I watched the X8 nose in to the field (luckily it was safe and in the general flying area, so no one was out there to get hurt)
Fuselage is a loss and battery was ejected on impact so I wasn’t able to check if I had control inputs when I walked up.
Can anyone have a look and give thoughts on what happened, and provide advice on how to make sure it doesn’t happen again when I attempt another flight?
[attachment=0]2014-09-07 18-27-39.bin[/attachment]
Hi Josh,
I just noticed your post, sorry for the delay.
Do you happen to have a telemetry log as well for the flight? As you say, the DF log just stops, which doesn’t give us much information.
Alternatively, was there another DF log immediately after the one you have given already? If the Pixhawk rebooted it may have created a 2nd log.
Cheers, Tridge
Thanks for the reply!! So, I do have the tlog (attached) but it reveals the same thing. The pixhawk went offline and stayed offline enough for the X8 to kiss the dirt and eject its innards all about, so there was no opportunity to see if a completed reboot gave control back. A quick plug in back at the flight station showed everything seemed to perform as expected, but I couldn’t fly to test since the fuselage was destroyed.
A week or so after this happened, my buddy maidened his Anaconda from ReadyMadeRC (re: your story on on the dev call the other day, check it out as a possible OBC airframe along with the Air Titan, both great airframes that support very large payloads on a foam platform) and he had almost the same thing happen, but during the second flight/battery. Flying about, doing its thing, turned towards final and watched it eagerly fly in to the dirt with no control respected from the RC Transmitter. When we walked out, it was also w/o power and when we got back to the flight station and plugged it in, again normal performance.
Growing consensus seems to be that these flights/crashes were both plagued by a lack of the Zener diode on the ESC rail. The BEC going to the rail was not above 5.3v but there were digital servos all over the place on his Anaconda, and a whopping two on my X8. I haven’t found anything definitive that says, “YES, the Pixhawk performed a failover from the power module to the bec where it was then blacked out because that power was considered untrustworthy” but I don’t think that is logged in the ArduPilot logs anyways, isn’t it a lower level operation? Is there a way to measure at all from the pixhawk if the fail-to power is not going to work well due to the digital servo noise?
Would love to hear your thoughts on that, and if you agree its probably the Zener then I’m very happy to close this request for help. If you have other ideas, I’m all ears!
Thanks again sir,
Josh
P.S. Zener diodes on all planes now… trying to determine if they should also be on all multi-rotors
EDIT: Both planes in question had the 3DR pm. My Air Titan with the Atto sensor and Castle 5.3v bec has never had this happen and its chucked full of digital servos as well
@JoshW
Forgive my ignorance but can you please elaborate on exactly how/where this zener diode would be installed and what problem it would be expected to solve?
Oh, and yes I have a long history with electronics so I do know what a zener is.
Sure thing! Keep in mind the diode goes backwards from what you may normally expect, according to the wiki (and maybe this is the right way and I read about the diode wrong on the Internet as I am NOT an EE)
Unfortunately it happened again yesterday… Was in the air and in the FPV system went from seeing data on the screen to seeing the video and then the message “No Mavlink Data” and the airplane went in to a nose-down glide of about -5-7 degrees pitch. Before the plane (Skywalker X8) hit the ground, the GCS started warning that it was also getting no data from the vehicle. Because I had video powered, I was able to painfully watch it go all the way down to the ground and then lost video. I still had video carrier, just no actual video, so this told me I lost the camera itself (which was later confirmed) but still had power to the onboard video system.
I walked out to the plane and it was still powered up. See this video: youtube.com/watch?v=xtDbrV2jJ0U. What does this lighting scheme mean? Is it helpful at all to figuring this out? It can’t really be going in to bootloader mode can it?
I brought the GCS with me to see if it ever regained connectivity on the walk out and it did not. This tells me the Pixhawk “froze” rather than rebooted; this flight was also with the Zener installed and a couple successful flights under its belt since installing.
This is getting pretty frustrating; as you know I’m a pretty avid user of the APM:Plane and APM:Copter software but this has me stumped and I don’t believe I can trust the autopilot in this guy. The Pixhawk, its power module, both GPS units (the secondary isn’t actually plugged in yet, and the primary was still plugged in and just had ejected from its platform on "landing), rfd900u, and minimOSD are all genuine and all new-ish (purchased for this aircraft.) The ESC is an Opto ESC and there is a 5V Castle Creations BEC powering the servo rail. If a component is causing a lot of noise in the system that is tripping the Pixhawk up, I’d love to be able to verify that and troubleshoot it and remove it. I no longer think this is a power fail-over to the ESC rail since when I showed up at the plane it was still powered but unresponsive to controls. I power-cycled the Pixhawk and upon initialization was able to control the servos again.
Any thoughts or guidance on this would be very greatly appreciated! I’ve also attached the .bin from this flight. [attachment=0]7.BIN[/attachment]
I haven’t found anything definitive that says, “YES, the Pixhawk performed a failover from the power module to the bec where it was then blacked out because that power was considered untrustworthy” but I don’t think that is logged in the ArduPilot logs anyways, isn’t it a lower level operation? Is there a way to measure at all from the pixhawk if the fail-to power is not going to work well due to the digital servo noise?
