Home        Store        Docs        Blog

When 25 usec is not enough

(Richard) #1

The following information may help you if you are experiencing erratic motor behavior, especially when in automatic control:

The BR ESC’s have a +/- 25 usec deadband built into the firmware. In the case of using an Adaruit Metro-Mini Arduino processor to interpret joy-stick position, the +/-25 is not enough. I suspect this may be the case for other processors as well.

My measured noise from the the A/D conversion of 0-5 volts to 0 - 1023 at the joy-stick mid-point position is 480 +/- 7. Mapping that to 1100 - 1900 gives an ESC input of 1489 - 1529 (measured), due to system noise. Even though the 1529 isn’t much outside the deadband, it is enough to cause trouble with heading-hold applications. My LSM303 has a measured variation of +/- 2 degrees. Using a Kp of 15, which seems to work best, and add to that the processor noise of above, you can see a big problem can arise. If the system happens to see a + 2 compass variation and a + 7 noise spike from the A/D converter at the same time, the ESC can receive a very large pulse width signal. It happens, and has happened to me on numerous occasions. I feel it can be damaging to the motor bearings when instantly accelerating from a dead stop to high RPM, plus it drives me crazy when trying to record video footage, or hold course when in heading hold. I can reduce the Kp, to minimize the problem, but then my heading drift increases to undesirable levels.

For non-heading hold (manual) steering it is easy to build a larger deadband into the control program to avoid erratic motor action when the joy-stick is centered. I haven’t figured out how to do that for auto heading work.

I would like to hear if any of you have worked with this issue and what solutions you came up with.



(Rusty) #2


Very interesting. I glad you found this. I have a few suggestions:

  1. As you mentioned you can add deadband to the joystick input. If you use the right range, they will always be zero at center.

  2. Alternatively, you could apply a “exponential” curve to the input like is commonly used on RC radios for smoothly control response. The exponential response is flat near the center and strong when moved to either extreme. That would reduce the noise in the center. We’ve done this on ArduSub and it helped a lot.

  3. You can add a software low-pass filter to the input to smooth out any spikes that might cause issues.

I hope this helps.


(Richard) #3

Thanks, Rusty, I like the idea of the exponential response. I will work on that.

(Rusty) #4


Here’s an equation you can use for that:

float expo = -0.35;
x = -expo*powf(x,3) + (1+expo)*x;

I also made an animation to show what the curve looks like for values of “expo” from 0 (flat) to -0.5 (strong expo). It’s attached.


expo-qgc-20160528 (306 KB)

(Richard) #5

This simple “spike” filter works well on the bench with ‘a’ set to o.5. I’m going out for a reef mission next week, we’ll see how it works.

output = (1 - a)input + aprevious_output;


(Rusty) #6


Cool. That’s a low-pass filter, and exactly what I would have tried.


(Richard) #7

I’ve added this as an additional attempt to smooth out noise:

prev_out = output;

if ((input - prev_out) > 10) {a = 0.7;}
else if ((prev_out - input) > 10) {a = 0.3;}
else {a = 0.5;}

output = (1 – a) * input + a * prev_out;

It is just about impossible to bench test this without a means of recording every pulse, so I just have to wait for a water test next week.

(Richard) #8

@ Rusty - Do you guys use a serial recording/graph program for testing that works with the Arduino IDE?

(Rusty) #9


In the past I’ve used the one that’s built into Arduino and I’ve also just copy and pasted to Excel. Sorry I don’t have anything better than that!