STM32 F1, F3, F4, G4, F7 and H7 flight controllers

STM32 F1, F3, F4, G4, F7 and H7 flight controllers

Currently, almost all flight controllers we use on our multirotor FPV drones and airplanes are powered by microcontrollers from an STM32 family. When we say about flight controller families or generations, we refer to them by the family of the MCU. For example:

F1 flight controllers are no longer supported


You should get F7 to do it


Historically speaking, F1 were the first flight controller boards for MultiWii derivatives based on STM32 MCU. All the F1 boards like Naze32 or CC3D (ok, this one is from OpenPilot family) were equipped with STM32F103 chips. Currently, F1 boards are not supported by any major flight controller firmware. Reasons are simple: low speed, lack of hardware floating-point acceleration, very little RAM and Flash memory, only a couple of UARTs. They were not powerful enough and as a result, had to die.

Do not buy and if you have one, just keep it somewhere in a drawer as a souvenir of good old times. Read More

inav sensors

All the INAV sensors: are they required or optional?

INAV can use various sensors to fly drones and airplanes: gyroscopes, accelerometer, magnetometers, barometers, GPS, OpFlow, rangefinders, and airspeed. Some of them required some are recommended and some are a purely optional piece of hardware.

Here is the full list:

INAV Sensors:

Gyroscope and accelerometer

Required. The flight controller will not boot without a gyroscope and accelerometer. They are usually 2-in-1 devices (MPU6000, MPU6500, etc) that contain gyroscope and accelerometer in one package. Read More

Betaflight vs EmuFlight vs INAV

Which flight controller software flies better out of the box? You know, the stock, default settings, no tuning. Just flash and fly. Betaflight, INAV or maybe EmuFlight? I decided to test it on one of my 5-inch FPV drones and compare: Betaflight vs INAV, Betaflight vs EmuFlight and EmuFlight vs INAV.

The results are divided into 2 separate videos. In the first one, I explain all the rules and present all 3 flight controller software flying the same kwad.

Read More

matrix filter

EmuFlight and INAV Matrix Filter

Matrix Filter will have its premiere together with EmuFlight 0.3.0 and INAV 2.5. Which of those two will happen first is still unknown. After originally developing Matrix Filter for INAV, I also ported it to EmuFlight code and already some time ago they accepted my code proposal and merged it.

You have to admit, that the name is quite catchy. Matrix Filter for sure sounds very sci-fi. It’s not that sci-fi tho. It’s just an evolution of dynamic gyro notch filters known from Betaflight for quite some time. Instead of having a one-dimensional filter structure, it is a 3×3 filter matrix that works like this: Read More

INAV and DJI HD FPV system – there is a light at the end of the tunnel

When DJI did not decide to add INAV and Ardupilot to the list of the supported flight controller for the HD FPV system, some people were, at least, disappointed. Long story short: DJI OSD works only with Betaflight. Period.

DJI HD FPV system

Until today, DJI avoids the answer to the question if INAV and Ardupilot will be supported. I know there are some talks and there is a chance for native support for INAV and Ardupilot, but the timeline is not revealed.

Read More

DJI FPV System & INAV – current situation

DJI FPV System

When DJI released updated firmware for their DJI FPV system with improved OSD, Betaflight users started cheering. The move to add OSD with elements like GPS position, the artificial horizon, etc is kind of puzzling. It works only with Betaflight flight controllers and a typical user of Betaflight does not really need it. After all, Betaflight concentrates on racing and freestyle on 5-inch mini-quads, not long-range.

On the other hand, users INAV, that concentrate on airplanes and long-range flights, can not use new DJI FPV OSD. Pilots immediately started to ask INAV developers to implement DJI FPV support. The problem is, that it's not working like that.

  • Support for Betaflight is built-in into DJI Air Unit, not another way around.
  • DJI FPV seems to be actively checking if the flight controller it talks to is Betaflight or not
    INAV and Betaflight support the same serial protocol: MSP. This means DJI FPV is capable of talking to INAV, it just refuses to do so
  • INAV and Betaflight use the same OSD positioning protocol using the same MSP frames. Still, DJI FPV refuses to talk to INAV
  • We have no idea what DJI Air Unit expects from a flight controller since it is the closed source!

All of that means that INAV developers can not fix something that is not within the code of INAV. For INAV support, DJI has to implement it. Not the other way around.

The best flight controllers for INAV – 2019 Q4 edition

Believe it or not, but choosing the right flight controller for your next airplane or a drone build is quite important. Yes, I know that some of you might say that hardware does not matter and your kwad will fly as good with the latest F7 flight controller as it would fly with Naze32. It is, not true. It would fly with Naze32, but do not even try to compare modern flight controllers with more advanced filtering, inputs, outputs, and peripherals.

Best flight controllers for airplanes

Matek F722-WING

Matek F722-WING

Matek F722-WING is the second generation of a big WING flight controllers started by a famous F405-WING. Comparing to the original, F722-WING offers more input/output options, including dedicated airspeed port, switchable camera inputs and switchable power supply for FPV installation. Read More

The future of F3 board in INAV

It’s time to start saying goodbye to F3 boards in INAV. History repeats itself and after we let F1 boards go, the same fate upon F3. Why? STM32F303 does not have enough RAM to handle everything that is demanded of it: OSD, telemetry, GPS, navigation, etc. INAV already is not enabling the majority of new functions on F3 based boards!

What will happen next? Most probably, F3 boards that fail to build due to lacking memory will be removed from the official release process. The code that drives them will stay, but if anyone will want to compile INAV for them, they will have to find missing memory by himself.

So, do not expect INAV 2.4 running on Omnibus F3. On the other hand, SP Racing F3 will probably stay with us for a little longer. Lack of OSD is a huge advantage in this case.

INAV secondary IMU with Bosch BNO055

INAV is great, but INAV is not the best in everything. For example, INAVs internal IMU (Inertial Measurement Unit) algorithm is suffering from the infamous artificial horizon drift. I explained this phenomenon already in one of the videos, you can watch it over here. We somehow mitigated this on fixed-wing airplanes in INAV 2.2.1, but it’s not gone yet and there is no fix for multirotors for example.

Last weekend I started hacking something that might, or might not, help. Technology progressed quite a lot in the last few years, and right now we have much more advanced all-in-one IMU chips than when the workhorse MPU6000 changed RC hobby forever.

The idea behind the hack is simple: use secondary, hardware IMU, to help INAV correct horizon drift and some of the magnetometer related problems as well. There are pretty amazing IMUs like Vector Nav VN-100, VN-200, and VN-300. But they cost more than most RC hobby airplanes. The cheapest VN-100 is $500 for the chip only. Or $800 for a ready to use version. Nobody would buy something like that for a foam airplane. There are, however, much cheaper (and less capable) integrated IMUs. One of them is Bosch BNO055.

Bosch BNO055 has an integrated accelerometer, gyroscope and magnetometer. It allows getting data from each sensor separately or to use sensor fusion (probably relatively simple Kalman) to combine data from 3 sensors into roll, pitch and yaw (including absolute magnetic heading) Euler angles or quaternions.

So far, so good. After a few days of work, I was able to connect GY-955 which contains BNO055 plus some extra electronics to INAV via I2C and get basic data from it. The next step is to check is this whole secondary IMU idea makes sense. The idea is to switch the OSD artificial horizon and heading to a new data source. If it will work and data obtained from BNO055 will be good quality, to switch other navigation-related functions of INAV to secondary IMU. Bear in mind that stabilization and main PID look will still be fed by the data obtained from primary IMU.