ESP-FC: a DIY flight controller firmware for the ESP32

What the project is and why it mimics Betaflight

ESP-FC is described as the mini, DIY, low cost, ESP32 based, high performance flight controller for hobbyists. The repository description puts it more plainly: flight controller software for hobbyists, build your own flight controller.

The firmware itself is the project. There is no board design in the repository, so this is software you run on hardware you assemble, and the wiring guide in the documentation is where you find out which pins to connect to what.

The design decision that makes it usable is compatibility with Betaflight 4.2. The README says the firmware mimics Betaflight 4.2 compatibility so that it can be configured using betaflight-configurator, and that the online blackbox-log-viewer can be used to analyse blackbox logs. In most respects it is similar to Betaflight, so that many configuration and tuning advices are helpful here too.

The README then puts the caveat immediately after that, and it is an important one: this software is not the same as Betaflight, there are some limitations and differences in functionality and performance. Later, the note about the configurator says that not all functions displayed in the configurator are available in the firmware, and that the rule of thumb is if you cannot change a specific option in Betaflight Configurator, that means it is not supported, and it usually rolls back to the previous value after save.

That is a sensible compromise for a hobby project. You get the configuration tool and the log viewer, which are the two pieces of tooling that take the longest to build, and you accept that some of the options will silently not apply.

The hardware it supports and the parts you need

The supported module list is explicit about confidence levels, which is unusually useful information when you are choosing a chip.

The ESP32 and the ESP32-S3 are both recommended. The ESP32-S2 is marked experimental. The ESP32-C3 is experimental and lacks performance and has no FPU. The RP2350 is experimental and only partially works. The RP2040 is experimental, lacking performance and with no FPU. The ESP8266 is obsolete and no longer developed.

The absence of an FPU on the C3 and the RP2040 is the concrete reason for the performance note. A flight controller runs a gyro filter and a PID loop at kilohertz rates, and the floating point work is exactly what a missing FPU makes expensive.

The required parts list is short. An ESP32 or ESP32-S3 board, an MPU9250 on SPI or an MPU6050 on I2C as the gyro, with the GY-88, GY-91, GY-521 or similar modules named as examples, a power distribution board with a 5V BEC, and optionally a buzzer and some electronic components.

The broader sensor list is wider. Gyros supported are the MPU6050, MPU6000, MPU6500, MPU9250, ICM20602, ICM42688 and BMI160. Barometers are the BMP180, BMP280 and SPL06. Magnetometers are the HMC5883, QMC5883, AK8963 and QMC5883P. Receivers cover PPM, SBUS, IBUS and CRSF/ELRS, and ESC protocols cover PWM, brushed, Oneshot125, Oneshot42, multishot and bidirectional Dshot at 150, 300 and 600.

GPS support is listed for the M8, M9, F9 and the dual-band M10, with all constellations configurable through the CLI.

The wire between the parts is the hardware list of a fairly conventional modern build, with the ESP32 as the only unusual choice.

The feature list, and where the performance comes from

The features list covers the things that make a flight controller usable rather than merely flyable.

There are three flight modes, ACRO, ANGLE and AIRMODE, and one frame type, Quad X. There are configurable gyro filters, with LPF, dynamic notches, dTerm and RPM filters, and the repository topics name dynamic-notch and rpm-filter directly.

The filters are where the tuning effort actually goes on a multirotor. The low-pass filter smooths the gyro signal, the dynamic notches chase the resonant frequencies of the frame as the motors load it, dTerm is the derivative term of the PID loop, and the RPM filter uses the motor RPM signal to target the right frequency rather than a fixed guess.

Blackbox recording supports OpenLog, OpenLager and flash. In flight PID tuning is included, and there is a buzzer, LED and voltage monitor.

The performance claim is that up to 4kHz gyro and loop is possible on ESP32 with an SPI gyro. That figure is the reason the SPI requirement is on the parts list rather than the I2C one, since I2C is not fast enough to read a gyro at that rate.

There is a built-in ESP-NOW receiver and WiFi configuration, with its own documentation page, and the protocol list also includes MSP and CLI. The topics list ESPNOW, ELRS, DShot, MSP and rp2350, which is a reasonable summary of what the firmware speaks.

Failsafe mode is listed among the features, which on a hobby build is one of the more valuable of them.

Flashing the firmware and the first configuration steps

The quick start is a five-step flashing procedure that uses a browser rather than a command line tool, which is a deliberate simplification for people who have never flashed a microcontroller.

Download and unpack the selected firmware from the releases page, visit the ESP Tool Website, click Connect and choose the device port in the dialog, add the firmware file and set the Flash Address to 0x00, click Program, and power cycle the board after success. The README includes a screenshot of the tool at the Connect step.

The software prerequisites are Betaflight Configurator at version 10.10 and the CH340 USB-serial converter driver, which is needed because the ESP32 boards in this class typically present as a CH340 serial device.

After flashing there are four configuration steps, and their order matters. You configure the pinout according to your wiring, especially the pin functions, using the CLI reference as the source. Then you connect to Betaflight Configurator and set it up to your preferences. Then you test the motors without propellers. And then the README says to have fun.

That third step is the one not to skip. A misconfigured pinout on a board with the wrong pin functions can send a signal to the wrong motor, and testing with propellers fitted is the way to find out.

The README points at a wiring diagram page in the documentation for the pin assignments, and at the setup guide, which it strongly recommends following rather than improvising.

Development setup: PlatformIO in VS Code, and a container option

The development requirements are a short list: Visual Studio Code, the PlatformIO extension for VS Code, and Git.

That combination is the standard embedded C workflow and it means the build is defined in platformio.ini at the repository root, along with the include/ directory for headers, src/ for the implementation, lib/ for vendored dependencies, test/ for the test suite, bin/ for build output, and a docker/ directory with a docker-compose.yml.

The compose file shows the containerised build and its configuration:

services:
  espfc:
    image: espfc-builder
    build:
      context: docker
    hostname: espfc
    network_mode: "host"
    user: "1000:1000"

Two details in it are deliberate. The network mode is host, so the container can reach the serial device or the network without extra plumbing, and the user is pinned to 1000:1000 rather than root, which is the usual PlatformIO arrangement because the toolchain writes into the home directory. The device passthrough lines for ttyUSB0 and ttyACM0 are present but commented out, with the volume mounts for the working directory and for the platformio directory, and a named volume for the platformio cache so a rebuild does not refetch the toolchain.

There is also a partitions_4M_nota.csv file at the root, which is the flash partition layout for a 4 megabyte module without OTA support. The filename says what it is: a fixed 4 MB partition scheme, and no over-the-air update capability.

The other root files are the ordinary ones: a .clang-format and .clangd for the C formatting and language server configuration, a .github/ directory, an esp-fc.code-workspace for VS Code, and an AGENTS.md.

Limits: one maintainer, a version 0.x release, and an unfinished feature list

The limits are visible in the repository and the README.

The first is that this is one person's project. The README asks for donations to a Bitcoin and a Litecoin address, with the plain statement that if you like the project and want it to be still developed you can support me a little, and the licence section is the standard MIT text. Development happens on a Discord channel. The code style is enforced through a .clang-format file, and there is an AGENTS.md at the root.

The second is the version line. The tags are v0.2.1 from 2025-02-04, v0.2.0 from 2025-01-23 and v0.2.0-RC7 from 2025-01-13. A version 0.2 with a release candidate in its history is an early project, and the last push was on 2026-10-19, so the code moves while the tags lag behind it.

The third is the todo list, which is short and revealing. Altitude hold, GPS navigation, MS5611 barometer support and a balancing robot controller are all listed as not yet done. A flight controller without altitude hold is a legitimate thing, since many pilots fly in angle or acro mode without it, but it does mean the feature set is smaller than a commercial controller's, and the README's own list of differences from Betaflight is a pointer to where the gaps are.

The fourth is the hardware support matrix. Only the ESP32 and ESP32-S3 are recommended, and the ESP8266 is obsolete. The dual-band GPS support, the MS5611 barometer, and the balancing robot controller are all absent. The configurator compatibility cuts both ways as well: the fact that an option rolls back after save is a reasonable way to signal that it is unsupported, but it is a way to signal it that a new user will read as a bug.

The fifth is the safety framing. This is hobby firmware for hobby aircraft, and the README's instruction to test motors without propellers is the one line in it that reflects that.

ESP-FC against a commercial flight controller and against building on Betaflight itself

Two comparisons make the choice clearer.

The first is against buying a commercial flight controller, which is the default choice and the right one for most people. An ELRS or FPV flight controller from an established vendor has been tested, has a warranty, has a community, and has a known-good configuration for your frame. The difference in approach is that ESP-FC gives you a board you built yourself, on a chip you chose, with the wiring under your control, at a cost of a few dollars in parts.

What you get for that is a genuinely different build. The ESP32 is a WiFi and Bluetooth microcontroller with far more processing power and memory than the STM32 or AT32 in most flight controllers, which is why the ESP-NOW receiver, the WiFi configuration and the in-flight PID tuning are possible at all on a board this cheap. And Betaflight Configurator works on it, so the learning curve from an existing Betaflight setup is close to zero.

What you give up is the assurance. One person's firmware, an early version line, a hardware matrix where most chips are experimental, and no support when the quad flips over at 3 am.

The second comparison is against forking Betaflight itself. Betaflight is the reference implementation and it has decades of collective work behind it, so forking it gives you every feature including the ones ESP-FC has not implemented. The difference in approach is the hardware target. Betaflight runs on dedicated flight controller MCUs, and the ESP32's advantage is precisely that it is not one of them, with enough headroom for WiFi, for a web-based configuration interface, and for on-device analysis.

So the honest framing is that ESP-FC is an experiment in what a flight controller can be when the compute is nearly free. If you want the best firmware, use Betaflight on a proper board. If you want to understand the firmware, or you want a controller with WiFi on a five dollar module, ESP-FC is the more interesting place to be.

Editorial conclusion

Adopt ESP-FC if you are building your own multirotor board on an ESP32 and want the familiar Betaflight configuration workflow without a commercial flight controller. Do not adopt it for an aircraft where a proven controller is the point, since it is one person's hobby firmware with a documented list of unsupported areas. Verify first which MCU you have, since only the ESP32 and ESP32-S3 are recommended and the rest are experimental or obsolete, and that your gyro is on the supported list before you order hardware.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. rtlopez/esp-fc on GitHub