Home        Store        Docs        Blog

BasicESC R3 trouble with arming sequence


(Christian) #1

I have recently switched my marine robotics project over to use the basic ESC. I was previously using the integrated BlueESC via i2c so this is the first time iv used PWM to control a thruster.

I’m using a raspberry pi, and as the pi only has one usable PWM output im using the Adafruit PCA9685 16 channel PWM board (i2c). My project is Java based and I use the Pi4J library. Ive integrated directly with i2c control values based on examples in github. I’v also found that Pi4j has built in PCA9685 support. I mention this because I’v been concerned im not setting up the right frequencies, but using the PCA9685 provider in pi4j i’m pretty sure im getting it right. I don’t have a scope to test.

Anyway, my issue is I cant seem to get the arming sequence right. The example code on the blue robotics shows a simple 1500 us pulse for 1 second to arm, then switch to 1700 to drive. When I do this I get the low tone for arming start but only get the high tone when i switch to 1700. but this becomes the throttle zero. The motor spins faster the further i move back to 1500.

So I tried starting low at 1000 and moving up to 1500 but it won’t arm with these combinations.

The advanced documentation says while arming throttling up and down can be used to calibrate the max thrust. I’v tried various combinations of values and timing and can’t get it right. I also read someone it was important to scale up the max while arming so Iv tried ramping the values up and down rather than an abrupt change, but this hasn’t seemed to change much.

The pertinent config values are as follows…

    // This would theoretically lead into a resolution of 5 microseconds per step:
    // 4096 Steps (12 Bit)
    // T = 4096 * 0.000005s = 0.02048s
    // f = 1 / T = 48.828125
    BigDecimal frequency = new BigDecimal("48.828");
    // Correction factor: actualFreq / targetFreq
    // e.g. measured actual frequency is: 51.69 Hz
    // Calculate correction factor: 51.65 / 48.828 = 1.0578
    // --> To measure actual frequency set frequency without correction factor(or set to 1)
    BigDecimal frequencyCorrectionFactor = new BigDecimal("1.0578");
    // Create custom PCA9685 GPIO provider
    I2CBus bus = I2CFactory.getInstance(I2CBus.BUS_1);
    final PCA9685GpioProvider provider = new PCA9685GpioProvider(bus, 0x40, frequency, frequencyCorrectionFactor);
    // Define outputs in use for this example
    GpioPinPwmOutput[] myOutputs = provisionPwmOutputs(provider);
    // Reset outputs
    provider.reset();

    provider.setAlwaysOff(PCA9685Pin.PWM_00);
    delay(2000);

    provider.setPwm(PCA9685Pin.PWM_00, 1500);
	
    etc...

(Adam) #2

Hi Christian,

You are correct, this appears to be the throttle calibration feature of BlHeli kicking in when you are switching this quickly after the default neutral signal.

All you should need to do to initialize the Basic ESC R3 is give a 1500µs neutral signal until it beeps initialization confirmation (long tone). This may take longer than the one second listed in the documentation. Thank you for pointing this out, I missed updating this from the R1 and R2 documentation!

-Adam


(Christian) #3

Iv tried leaving it at 1500 for several seconds before switching to 1700 (with a ramp). Only then do I get the second beep and it seems 1700 becomes throttle zero. I’ll keep hunting around in the documentation and perhaps try to find code from other projects where people have integrated with this controller. I’ll post back here with anything I learn.

I also plan to add a thruster controller class to my B9 project as I did for the BlueESC.


(Rusty) #4

Hi Christian,

From that explanation, it sounds like your PWM output may be off and the 1700 is actually coming out closer to 1500. Our ESCs don’t have any calibration so the center point is always at 1500 regardless of the inputs at any point.

Do you have any oscilloscope to check that out?

-Rusty


(Christian) #5

I had a suspicion that this might be the case. The frequency counter on my multi meter is showing the base frequency about 10 hz higher than expected. I wasn’t sure if this was because it was a PWM that it was mis-reading. A friend is going to lend me his scope and I’ll be able to check it out.

I just did a test where i started at 1600 and get the low tone followed immediately by the high tone (arming complete), then was able to throttle up and down around that range! hoorah! :slight_smile: Thanks for your help


(Christian) #6

I believe I have found the root cause of the issue. The adafruit driver does the same calculations as the code I was using but they found that the base frequency is overshot by about 10%. So they compensate by multiplying the frequency by 0.9

So Im not sure if this is a fault with the PCA9685 or Adafruit’s implementation.