I've also seen the motors act funny in the following situations:
- Using the reset button on the sensor shield or board
- Connecting from USB (in particular with the ArduCopterConfigurator but also the Arduino monitor and CLI)
It doesn't seem to be related to the software code at all since I've seen this happen with both many versions of the old Arducopter code and 2.0.16.
During resets it seems to depend a lot on the ESCs as well. Some of my ESCs (I have different versions of the same no-name thing) first emit a warning saying that the signal has gone out of bounds in the upwards direction right when I press reset, then shortly after it does another warning that the signal was lost entirely (flatlined) and then a notice saying that the signal has been recovered. This happens on every reset, always - easily reproducible - and takes around 1-2 seconds total. Others just move the motor a bit and get hot to touch if you reset 3-4 times in a row (didn't try more than that).
During flashing I have no clue what is going on. I noticed some of the motors moving a bit and getting hot once and tried different things. It seems that setting "soft start" on the ESCs will remove the heat problem but instead it will sometimes randomly spin up a propellar for a few seconds, then lose the signal and spin it down again. Sometimes it works flawlessly, though, and other times it is a weird mess of beeping and spinning propellars. It is not really a problem because the documentation clearly states that powering the motors should be avoided when connected to a computer, but some people seem to take safety warnings as a challenge - in this case me included ;)
In short: For me it works to enable "soft start" until the problem is solved. Most ESCs have different levels of soft start, I just used "quick"... - it doesn't affect flying at all like the "slow" one does.
Yes this is not a code problem.
Nevertheless this is a safety issue and should be corrected. It is not good as well to have burned motors or ESCs. Some motors and ESCs can be higher than 50 or 100 $ each.
It is possible that some users users don't even know that one of their motor or ESC did suffer from a reboot, and could have flight problems because of this. This is a loss of time for developpers, who can try to chase problems where there are not.
So for safety and for cleaner beta reports, this should be corrected. It seems to me that a pre warm boot code or eventually a bootloader change should be able to correct this.
Sorry to be picky but it's still not quite right Chris. If you do things in the order stated in the new yellow box, you will still have the potential problem:
The 4-wire cable disconnection should be first or second I think.
Do you think that the bootlaoder reset PWM and I/O setup registers ?
I'm not sure. If it is not the case, then I/O and PWM registers should be reseted before AVR warm reset.
My workarround is as follows:
- Never connect the LiPo when connecting the USB
- solder a diode between ESC + and APM. This way there will be now powerdrain from your esc and no motorspinning when rebooting at USB connection time.
But I agree, the problem should be resolved for the next APM / Bootloader release.
I think that there is no absolute need for powerdrain sinking to trig problems, because the APM board is outputing PWM signals during reboot or firmware load.
The powerdrain does not cause the problem. With the diodes you just keep the one prop from spinning and prevent from USB power break down.
ACM Issues 110 & 117 describe the problem.