Configuring an ESC with BLHeli firmware using an Arduino Uno

The Importance of Motor Direction

In order to stop our drone spinning like a top, it is important that the four motors turn in a particular direction. As shown in figure 1, we want the motors to alternate spinning clock wise and counter clockwise. This arrangement causes the torque from the spinning motors to cancel out and the quad only yaws when we want it to.

Figure 1. Required Motor Directions for the Magpie Drone.

We wired up all our motors to the RacerStar Quad ESC in the same way as we assumed that the default arrangement would give us the correct spin direction. It doesn’t. Two diagonally opposed motors are spinning in the wrong direction (M1 and M3). We could fix this by swapping any two wires from the ESC to the motor but it is easier to do this in software.

ESC Firmware

In the beginning, ESC’s came with firmware from the manufacturers, and they were rubbish. So 3rd party firmware came to be. The two originals were SimonK and BLHeli. SimonK is no longer supported so BLHeli has become the defacto (Open Source?) standard.

BLHeli has continue to evolve and now comes in BLHeli_S and BLHeli_32 flavours. As you can guess, BLHeli_32 is targeted at 32 bit ESC hardware and performs better than its predecessors.

Figure 2. The RacerStar 20A Quad ESC.

The RacerStar ESC (Figure 2) we are using is not 32 bit compatible and comes standard with BLHeli_S.

The majority of multirotor ESC’s on the market use processors (MCU’s) from ATMEL, Silabs and ARM. The different MCU’s have different specifications and features, and are supported by different firmware:

• ATMEL 8-bit MCU’s are compatible with both SimonK and BLHeli ESC firmware;
• SILABS 8-bit MCU’s are supported by BLHeli or BLHeli_S only; and
• ARM Cortex 32-bit MCU’s (e.g. STM32 F0, F3, L4, F4) can run BLHeli_32.

Arduino Pass through Sketch

In order to communicate with our ESC we need some middleware, as the only way to communicate with the RacerStar Quad ESC is via the motor control…