ESP32C3 Flight Controller Debugging – Part 1

ESP32C3 flight control board was sent for sampling before the National Day holiday. After returning to work, I received the sample, but I didn’t start debugging for a long time. I finally took some time to debug in the past two days, and the debugging process went quite smoothly without encountering any major issues. Below is a record of the debugging process.

Schematic Diagram

One more atmospheric pressure sensor was added compared to the plan, used for altitude measurement. Main features:

• Powered by a single lithium battery, maximum operating voltage 5.5V
• Power voltage and current sensing
• Lithium battery temperature sensing
• DCDC buck power supply, efficiency over 90%
• 3-axis accelerometer, 3-axis gyroscope
• Barometer, height accuracy 10cm
• 2 motor channels, supports current sensing
• 2 digital IO channels
• USB Type-C interface for debugging and program flashing
• 1 serial port, can be used to connect GPS

PCB

The board shape is mainly designed to fit with the 3D printed cockpit:

This mounting base fixes the flight control circuit board underneath and mounts the battery on top:

Except for the ESP32C3 WiFi module and the barometer, the circuit board was directly pasted after sampling. After receiving the board, there was a slight issue with soldering the ESP32C3 module; only one out of five samples lit up on the first try.

I was still careless! I used a hot plate for soldering, and without low-temperature solder paste, I used medium-temperature solder paste. I set the hot plate to 200°C, and the main issue with the boards that did not light up was that the module pads were not pre-tinned. This LGA pad has many pads, and there are many GND pads. When using the hot plate, it can cause the pads on the module to not reach sufficient temperature and not tin. After pre-tinning the pads, I placed it back on the hot plate, and once the solder melted, I pressed the module slightly, and it was OK.

Debugging

In the past two days, I ran the ADC, I2C, PWM, and WiFi separately, and started to integrate them. Today, I will record the debugging of the motor.

The program mainly involves initializing the ADC and PWM, along with functions for setting the PWM duty cycle and obtaining ADC readings, which are relatively simple. After connecting the WiFi module to the local area network, the duty cycle is controlled by the PC through UDP communication, and ADC readings are obtained.

The PWM duty cycle resolution of the ESP32C3 is still very high, with 13 bits at a frequency of 5kHz, which is 8192. In my upper computer program, I send data every 0.1s, increasing the duty cycle by 100, and after reaching 4000, decrease it by 100 each time.

In the terminal window, the left side shows the debugging output of the ESP32C3, displaying the UDP communication source address and the received duty cycle value; the right side shows the output of the control program, with three columns representing the duty cycle, ADC reading of motor channel 1, and ADC reading of motor channel 2.

From the video, it can be seen that a single motor at a 50% duty cycle has a static thrust of about 14g, and the ADC current value has not been calibrated yet, displaying the raw reading, with a precision of 12 bits, which is 4096.

Here is the test program:

import socket
import time
import struct

client_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

server_ip = '192.168.1.79'
server_port = 3333
server_address = (server_ip, server_port)

while True:
    for i in range(80):
        if i > 40:
            pwm = 8000 - i * 100
        else:
            pwm = i * 100
        client_socket.sendto(pwm.to_bytes(4, "little") + pwm.to_bytes(4, "little"), server_address)
        data, _ = client_socket.recvfrom(1024)
        data1, data2 = struct.unpack("<ii", data)
        print(pwm, data1, data2)
        time.sleep(0.1)

client_socket.close()