I recently updated to Copter 3.6.10 and have had an intermittent problem on one of my vehicles (I have two on 3.6.10) where after arming the motors while keeping the throttle stick low, the motors start randomly spiking and causing voltage drops on the main battery of 2.5 to 6 volts. Its almost like the battery is shorting out for a moment. I used a Saleae logic analyzer to monitor the PWM out of one of the motors (it is happening on all of them), and have put some of the results here. Unfortunately I don’t have the associated log file at this time. Below is an image of the Saleae results visualized in matlab and you can see that the PWM spikes up into the 2300 us range even though the max_pwm parameter in AC is set to 1940. Like I said, the problem is intermittent and happens about 1 in 10 arming cycles. Any ideas or thoughts would be greatly appreciated. Next week I’ll try to also upload a log file.
Setup is Cube Black on AC 3.6.10
Motors and ESCs are KDE
@BRiskas I’m following KDE’s instructions which say to program the ESCs to RANGE mode setting the min to 1100 and the max to 1940. Then, also following their instructions, in Mission Planner I’m doing the ESC calibration manually by just selecting ‘OneShot’ and setting the min and max to 1100 and 1940 respectively.
I have flown this power system many times on Pixhawk over the past couple years but am just trying to figure out what’s going wrong now. The Cube is intermittently but clearly outputting some crazy PWM spikes and I don’t know if it is a bad Cube, or if it’s related to the new 3.6.10 firmware. After discovering the problem I swapped in a brand new Cube, flashes the firmware and got it all setup and still observed the same problem. So it’s happening on two Cubes, but I also have a third Cube that is also on 3.6.10 and has an identical KDE power system and so far I can’t recreate the issue on that vehicle after trying a couple dozen arming cycles.
The fact that the PWM output follows the hardware on the first vehicle leads me to believe that there is something in the wiring on the problem vehicle that is different than your second vehicle (that is working well).
Any specs on the power system you are using to power the autopilot?
It could totally be associated with the hardware, however when I swapped in a new Cube I also swapped in a brand new carrier board as well (just the standard ProfiCNC Cube carrier). As far as the two vehicles go, they are duplicates of each other and are 99% identical in all aspects. In fact one is meant to serve as a backup should the other go down.
For powering the Cube I am using the standard ProfiCNC Power Brick Mini here
I would take a careful look at the wiring of the ‘problem’ vehicle, as the fact that the error follows the vehicle independent of the cube/carrier to me suggests that the issue lies in the vehicle hardware and not the autopilot. I would try swapping power bricks out of the problem vehicle and perhaps double checking the firmware and setting on the ESCs themselves
@BRiskas thank you for your thoughts. As it turns out, I have already tried swapping the power bricks, and I have also verified all of the ESC settings (using KDE’s ESC config software). The problem still persists.
Swap the cubes between the working and problem vehicles, if you haven’t. Then you’ll definitely know if it’s the cube or another component in the vehicle.
@wynn4 sounds like you have taken the appropriate troubleshooting steps. I would do as @wicked1 says and swap the working cube into the problem vehicle
Test Procedure:
-Power up the copter and press the safety switch
-Arm the motors by throttle down and yaw full right
-Center the yaw axis with the throttle low and allow the motors to spin until they time out and stop
Following the above procedure through 50 consecutive cycles, we saw the crazy PWM spikes problem 8 times where 3 of the 8 were particularly severe (similar to the plot I posted on Sept 28). We then took the parameter file from our ‘identical’ UAS that doesn’t seem to be exhibiting the problem, and flashed loaded those params onto the problem vehicle. After writing the params we re-did the test with 50 consecutive arming cycles. For this test the crazy PWM spike problem only ocurred 1 time and it was a single spike. Hmmm. So the problem is not completely gone, but this new param file seems to make the problem less likely to occur.
So then I looked at the two param files side by side to see if I could spot any odd differences between them. The parameter that looked most suspicious was the BRD_SBUS_OUT parameter. On the problem vehicle’s parameter set it was set to value 1 and on the parameter set from the other vehicle, the parameter was set to value 0. We then re-loaded the problem vehicle’s original parameters back on to the problem vehicle, and set the paramter BRD_SBUS_OUT = 0 and re-did the 50 arming cycle test. After finishing the test, it had a pwm spike issue 1 of the 50 arming cycles and it was just a single spike. So we’re still not certain about anything here, but it seems like the error is about 5 times more likely to occur when BRD_SBUS_OUT = 1.
@rmackay9 are there any known bugs associated with the BRD_SBUS_OUT parameter?
Below are some files including a copter .bin log from one of the tests where the PWM spikes occurred. Interestingly the spikes don’t appear in the copter log file, but they are definitely present as seen by the Saleae recording.
