ESP32 Forum

This is maybe a question that is very wide but I see that many drones have STM32 (F3-F4 ARM) MCUs but they are not so great comparing to ESP32.
So I am just curious if there is any drone that has ESP32 flight controller or any project/kikstart to do that...
It would be nice to see how esp performs when it comes to drone controll.

Deouss wrote:but they are not so great comparing to ESP32

Can you expand?

BuddyCasino wrote:

Deouss wrote:but they are not so great comparing to ESP32

Can you expand?

Well mostly it is the 2-core feature, hardware SPIs/I2Cs, higher clock speed, higher DMPS (600). The mystery is power consumption but we are talking about miliamps here.

Deouss wrote:This is maybe a question that is very wide but I see that many drones have STM32 (F3-F4 ARM) MCUs but they are not so great comparing to ESP32.
So I am just curious if there is any drone that has ESP32 flight controller or any project/kikstart to do that...
It would be nice to see how esp performs when it comes to drone controll.

I am developing a flight controller for quadcopters but it is still long way to go. Acro mode works fine, in stab mode quad keeps drifting to one side.

You can check it out at https://github.com/michprev/flyhero-esp32

michprev wrote: I am developing a flight controller for quadcopters but it is still long way to go. Acro mode works fine, in stab mode quad keeps drifting to one side.

You can check it out at https://github.com/michprev/flyhero-esp32

That is awesome. Have you tried rev-eng. Betaflight or Butterflight open source FCs ?

https://github.com/betaflight/betaflight
https://github.com/ButterFlight/butterflight

It is extremely interesting. I want to buy a drone that would allow easy customizations of FC on different MCUs.

Sure, I know betaflight very well. I would like to make my flight controller compatible with betaflight ones as much as possible.

Currently I am using ESP32 this way:

Core 0 (PRO CPU) takes care of WiFi related stuff. It reads TCP commands (calibrate accelerometr, download flight log fil) and UDP datagrams in flight (currently I send throttle and PID parameters).

Core 1 takes care of all time critical tasks. In this way FreeRTOS is quite a big opponent as it slows down everything. I am even thinking of implementing basic peripheral drivers (I2C, SPI, UART,...) myself without FreeRTOS. I have implemented basic PWM (1 ms - 2 ms), OneShot125, OneShot42 and I am currently working on DShot600 (using RMT peripheral).

I decided to write everything in C++ to make the code cleaner (well I am not quite sure that it is right now cleaner than betaflight code ).

In the repository there are also docs of my current flight controller - it is just DevKit C with some extra components.


I have also designed a brand new flight controller schematic based on ESP32 Pico but as I am not an analog guy and this project is only my hobby I am not quite sure if it is worth to invest into it.

Of course this all is worth investing. I would try to overclock a bit the CPU. Not sure what is the nominal value but specs say it can go up to 240MHz. Also as it comes to cores - try doing opposite thing with cores. Put criticals on 0 and network stuff on 1. You want fast calculations to be disattached from main os pump-loop. I wonder if it is possible to connect 2 mcus to work together )

I am running CPU at 240 MHz. With this frequency I could achieve 8 kHz gyro update rate (I don't think that 32 kHz is possible as FPU is not the fastest viewtopic.php?t=800 and it is not even probably worth it - I always had to run low pass filter on gyro to get good results).

According to https://github.com/espressif/esp-idf/issues/968 you cannot change on which core system tasks will run. This is why I have chosen core 1 (the second column is CPU core id): As FPU should be able to attach to any task / CPU core it does not mind that all computations run on core 1 I believe.

Why would you connect 2 MCUs together?

Sounds like OS has very limited operations. Maybe a different lightweight OS should be used. FPU low performance is probably related to how the compiler optimizes the fpu code. LX6 is a 5 or 7 stage pipeline RISC - e.g. for best calculations it needs very good instruction pairing and alignment.
If it has so many pipelines it basically means it can be super optimized and achieve crazy performance. I'd use ASM for heavy FP calcs.
Xtensa should update their compilers and add some more lightweight maybe non-os framework. I am reading LX can operate at even 350MHz with 130nm process. So this is just amazing. Should beat ARMs in the same price range.
Apps like Betaflight are just in their first stages before they reach 64bit CPUs or future low power fpgas.
I know they optimize them for F3/F4 STM cpus. For higher performance I think you have to go ASM.

As I am reading further...:

"5.3.3 Inter-Processor Communication
The 32-bit load and store instructions L32AI and S32RI add acquire and release semantics
to the Xtensa LX processor. These instructions are useful for controlling the ordering
of memory references in multiprocessor systems, where different memory locations
can be used for synchronization and data and precise ordering between
synchronization references must be maintained. Other Xtensa LX load and store instructions
may be executed by processor implementations in any order that produces the
same uniprocessor result."

That means LX6 is capable of working in multi-processor architecture !!

Working directly with Xtensa is probably out of my scope. The main problem of ESP32 is that WiFi drivers are closed source and they are using FreeRTOS. I will post another topic here if we can do anything about that. From my point of view ESP-IDF should be written more in HAL or StdPerip style. FreeRTOS should be optional.