I have seen recently a lot of threads about sudden fly-aways occurring on previously rock solid platforms, and I feel it necessary to share my experience. I have an SK-450 quad with Ardupilot 2.5+ that has over 100 flight hours on it currently, and a few weeks ago, I had a fly-away. I throttled up, and instantly had absolutely zero control. It just lazily hovered and drifted into a tree, luckily, where it refused to respond. The motors refused to stop spinning until I unplugged the main battery. I replaced the props, checked every wire, checked every setting, re-flashed the firmware, re-calibrated, and set out the next morning, with the same result. 

I began tearing the quad apart the next day, trying to replicate the results without props, and much to my delight and annoyance, I found the problem. The 900MHz 3DR telemetry cable I was using was fine, but when the motors began to spin up, the slight high frequency vibration from the motors very momentarily disconnected one of the pins hooking into the radio, which caused the APM to reset immediately, leaving the output pins locked with whatever output they had at the time of reset. To make matters worse, the APM will not re-initialize until the power is reset. I was able to replicate this by just slightly tapping on the header, and every time, the APM lit up in orange and the RX/TX LED's both stayed solid on. Of course, the problem was solved by soldering the wiring harness to the air module, but needless to say, I ALWAYS add a little bump of throttle after initializing and arming on every flight, just so that the throttle is low in the event it happens again.

If anyone has any ideas as to what causes this reset, I would be most interested in hearing it. I would love to be able to add some protection in if possible, as I demonstrate this quadcopter for representatives from the Airforce, generals from the Army, and executives from Boeing, Northrop, Bosh Global Services, and several other companies. Having a quadcopter uncontrollably drifting through a window or onto a runway would not exactly be the best way to demonstrate Ardupilot :) Also, if anyone has any experience they want to add, or any other cause they've found, please add it!

Views: 577

Reply to This

Replies to This Discussion

Follow Mil Standard 810c it will reveal any weakness like this good luck!!

@Austin,

Are the APM and the telemetry radios genuine 3DR products or are they clones?

What version of the Arducopter firmware are you using?

Do you have tlogs or dataflash logs available to help troubleshoot your issue?

Regards,

TCIII Admin

Duely noted ;)I've been going through the hardware schematics for the board trying to figure out what would cause this, to no avail... Guess it's time for more testing :)

I have had similar issues from my own and a clients machine due to telemetry glitches.

Client in the field, 3.01FW, APM2.5+, XBee/adaptor from 3DR. They phoned me when they were having trouble because they kept getting 'failed to set home' from Mission Planner and the copter would then disarm every time they tried to arm it. When I got them to bring the copter closer they were able to arm and started the mission, whereupon the copter went wild including a flip to upside down. The operator switched to stabilise and saved the craft. When I received the copter I found the telemetry cable had come adrift and was only touching the ends of the pins on the telemetry board. Secured them in place and she flew reliably again.

I was testing 3.1beta's and was trying to use a couple of cheaper XBee's I had purchased by mistake. The telemetry was established, but proved to be very flaky. The copter was flying ok but on occasions would dive off in random directions. Replacing the XBee modules with ones purchased from JDrones (Pacific 3DR reseller) and all problems went away.

I have been unable to open logs for the past couple of iterations of Mission Planner so I am unable to provide any here.

So two different scenarios both involving telemetry causing APM to go askew.

As you raised the subject I am just adding my experience to indicate it is not isolated.

@Austin,

I have been operating a number of rover chassis that have employed APM2.5/.6s and accompany 3DR telemetry radios and I have yet to experience a telemetry radio causing the issue that you have described.

I have had my rover chassis get flipped over by curbs and hit by a rover on the side the telemetry radio was on and have never lost the telemetry connection nor had the APM reset.

I have had APM resets due to an instantaneous low battery caused by fast chassis motor accelerations when the battery was near its end of charge. Otherwise my APM2.5/.6s and telemetry radios have performed to expectations.

Regards,

TCIII ArduRover2 Developer

I agree. The telemetry is rock solid, as you described. Genuine, 6 month old APM 2.5 with a one month old perfectly flawless air module, with standard headers, not the new module, arducopter 2.9.1b. I am currently on a road trip, I'll dig out my logs tonight, but simply unplugging the header at an angle from the module would disconnect the correct pins to lock up the ardupilot and make it impossible to regain control without a reboot. 

Allow me to elaborate. I have always used genuine 3DR hardware, and replaced the air module due to the pads for the headers lifting when I tried to re-solder them. The air module worked perfectly before, and the new one works perfectly. I have plugged and unplugged the telemetry with the APM on before without problems, but a particular combo of pins being pulled or vibrated loose triggered the reset. I have yet to figure out the combination, I will try to replicate the problem later and get a clean data flash log of it, as well as upload pictures. Thanks!

@TCIII: Do you use the stock header, or do you solder your connections?

@Austin,

I presently use the stock cable from the APM2.5/.6 telemetry connector to the 6 pin header connector on the 3DR 915MHz telemetry radio. I have never had the 6 pin in-line connector separate from the 6 pin header connection even in the worst rollover or broadside hit. After each field use I detach the 6 pin in-line connector from the radio so that I can use the USB connection for downloads and bench testing.

If you are lifting the header pads when attempting to resolder them, then you are using too much heat on the pads. I use a Weller temperature controlled solder station with a tip temperature of 680 deg F for small pad soldering and seldom if ever lift a pad during rework.

Regards,

TCIII ArduRover2 Developer

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service