I wanted to report a potential problem and maybe see what can be done to fix it, or if it solely my fault, what I can do to avoid it in the future.
I just installed a new receiver (Hitec Optima 9) and calibrated my radio. Next up was calibrating the ESCs. I proceeded to plug the signal wires (going to the ESCs) into the APM, plug in USB, flipped the APM into CLI mode and hit reset. Immediately the channel 1 motor began to shake violently and smoke poured out.
I recognized this symptom from my reading of the manual, so I went to read up on what went wrong. (See http://code.google.com/p/arducopter/wiki/AC2_Troubleshooting , Section - One of my motors started shaking and then burned out!)
I had heeded the warning and only plugged in the wires for essential testing (I don't see how this warning would prevent this problem, as I followed it and the problem occurred). The description on the troubleshooting page clearly states that this problem only occurs with APM1280, certain ESC types, and the older Arduino bootloader. I am running an APM 2560 provided by jDrones along with jDrones 30A ESCs and jDrones 880kv motors. So the scope of the problem is clearly not limited to just that hardware.
Does anyone have any insight as to what happened? Can someone provide any technical detail on what exactly causes this to happen? If this is a common problem with only certain ESCs, should the community not adopt different official ESCs?
Can anyone tell me what the likely extent of the damage is? Do I need to replace both the ESC and the motor?
Normally you can't do that, except if the BEC manufacturer do permitt to do it.
A solution is to use a dual shottky diode or two shottky diodes.
You will loose 0.2 or 0.3V through those diodes.
Do you have a schematic of how to set that up? I've never felt comfortable with only one BEC. :-/ I use a 10A Castle which should be robust enough but I like the idea of having a backup :)
Just take the +5V output of each BEC, take two shottky diodes (strong enough) and connect each diode anode to each BEC output.
Then connect the diodes cathode together and you have a redondant power supply.
If you are not confortable doing this, you can buy a ready made shottky module.
How do you match the 2 BECs?
Puting together straight away? or any diode in between?
You need to check with the BEC manufacturer. Some BEC can be connected together at their output, other cannot.
If they are not designed for direct connection, you will still be able to add a shottky module at their outputs.
You mean putting a schotky diode in series with each BEC output and shorting all of them right?
Wish the PwrDistro board do this with the 4 ESC with integrated BEC, the set sould be quite reliable that way I think.
Hi Al, I remember you now. I use these BECs. They have always worked for me with 2x9g servos and everything else. They have a 3A one if you need it.
I load code and power up the boards probably more than anyone and most combined. I've never had this issue for one reason. I never press that damn reset button. NEVER. And I never have the USB plugged in and Lipos connected at the same time. I don't know that much about the hardware (I'm the polar opposite of an EE,) but I've seen the CH1 output on the scope and nothing can be done about it on the SW side. It's an AVR quirk, I guess.
I only have three APMs and I am not nearly as active as Jason, but I maybe have a couple thousand USB/battery connects already, more than your average bear because I also use a HAM power rig, so "battery" or servo power is trivial to me when testing at home (props removed or tethered.)
I have castle creations ESCs, but by now at least 1/2 of my power cycles/connects are on jDrones, since I have two quads w/ jDrones 20A, and I retired my quad that uses the CC ESCs.
I have not once (so far, knock on wood) experienced this burn out, and I am quite/too cavalier w/ USB vs Servo order, and reconnects. But I can easily report that I have used the reset button on an/any APM only once, and it was curiosity, not need, when I did it.
I'm thinking that avoiding the reset button may just well be a good practice. It might not prevent this issue, but it certainly seems to happen more frequently to people who use the reset than to those who do not.
I regular run code that I just wrote so I'm religious about the absolute safest route. Just sayin....
Be careful about plugging the USB in, it will reboot the APM.
And use care with the mini USB; I've "lost" one IMU due to lifting the connector off the board. I plan to make a second attempt to reflow it to the board, but in my first attempt, I did not remove the "broken" solder, and it worked electrically, but failed again mechanically.
I've reinforced one of my other IMUs, but left one untouched. I'm not certain if I helped or compounded the issue, and did not want to risk damaging a nearby SMD weld.
I'm curious, Jason, if you do anything special to avoid this issue? I expect you connect via USB more often than nearly everyone, but expect that you might mainly leave the mini-USB connected to the IMU you use for most code-reload, and only remove from the computer? I tend to keep use whichever aircraft is seeing the least amount of work connected to the miniUSB, and perform any experiments on it (for example, last night I was using ArduPlaneHIL on one of my quad-mounted APMs because I do not have to unplug/attach the miniUSB needlessly - and I do not plan to use the quad in the next few days.)