FPV Terminology - Part 2 - Software

When it comes to the software side of FPV, things are much simpler than the hardware.

On our flight controllers, we need to run some firmware to do all the hard work. There are a number of common options to choose from. But first, a bit of history.

In the beginning there was MultiWii, which literally was designed to use Wii controllers as a gyroscope. From there, we moved to Baseflight which essentially was MultiWii ported to STM controllers (the same line that we use today).  Differences in opinion caused a fork of Baseflight to be made which then was named Cleanflight. This was pretty popular for a while, but development for new features was slow, given the booming industry and so many requests. So ANOTHER fork was made called Betaflight to be on the bleeding edge of features.

Betaflight is the most common and pretty much the default that most FC's come with. Major versions are few and far between, but smaller updates are quite frequent. One major feature Betaflight has over other firmwares is RPM filtering which allows the motors to feed back through the ESC into the FC as to how fast they are spinning, allowing filtering of vibrations out of the signal to make a smoother flight.

So with filtering, that's pretty much the major reason why modern FPV drones fly so well. No longer are we limited to the basic PID controller (this is a tech used everywhere BTW, but I'll explain it later on), but the filters allow us to remove vibration data that is coming in from the gyroscope, focusing on what the drone is actually doing in the air.

Betaflight (and other firmwares) allow us to control things like what is shown on the OSD, what peripherals are connected and the protocols to control them (GPS, LED's, Radio Receivers, Video Transmitters, etc).

What is a PID controller? PID stands for Proportional-Integral-Derivative.  Yeah, no clearer, I know. Think of it this way, if you have a heater at home, and you are trying to keep the room at a particular temperature, you could just have it turn on and off at particular thresholds. However, this gives a large swing in temperature, or a lot of on/off/on cycles depending on how far apart the thresholds are. What a PID controller allows you to do, is measure how quickly things change and react according to that, whether overshooting a bit to smooth things out, or oscillating around the desired value.

In our drones, what is this for? It's the main thing that keeps them flying. It allows the drone to react to external inputs whether that be from the radio telling it where to go, or wind and being able to compensate from being blown around. You'll notice in the GIF above, the plate will lean backward even before the ball crosses the middle, to slow it down to stop right in the middle (with only a small amount of overshoot)

The really smart thing this allows is you could potentially have totally different ESC's, props and motors on each arm, and the thing would still fly. The FC basically says "oh, I need to give this motor a bit more juice to keep the thing level", it doesn't care that they're mismatched.

HOWEVER. PID's can vary wildly from drone to drone, and person to person as this is one way to adjust how the drone feels on the sticks, whether it's smooth between your movements, or reacts immediately. Different people have different needs and preferences. Incorrect PID settings can cause the motors to heat up and burn out also.

Since Betaflight 4.2 (4.2.9 is the current at the time of writing) however, PID tuning is less necessary than before. The defaults work pretty well, and we tend to tune the filters for the feel now.

So beyond Betaflight, there are two main forks from it that are currently popular. One is iNav, which is used for autonomous drones and planes (basically setting waypoints, and missions for a drone to fly) and the other is Emuflight (which as an Aussie I find hilarious because Emu's don't fly) - which came about from a disagreement with certain filters that the developers wanted in Betaflight.

However neither of these have RPM filtering. Is it necessary? No. Is it nice? Certainly.

There are other firmwares out there that are more commercial. In the drone space, you're looking at FlightOne (which used to only work on certain FC's, but they've opened it up to many more now) and KISS (which only works on a couple of FC's).

One particular annoying feature that Betaflight has over the other firmware is having to set up VTX tables. When controlling your VTX from the FC (using Smart Audio or IRC Tramp protocols), the FC needs to know which frequency to tell the VTX to transmit on, along with the power. This used to all be handled by Betaflight, but they removed that. Partially because of so many new VTX's coming out with varying power levels, and different protocols running them. But also one theory suggests they're doing it for legal reasons, due to certain channels not being allowed in certain countries, and hiding themselves from legal liability.

On to ESC's.  Yep, the bit that controls our motors has firmware also. There are three main firmware versions for modern ESC's.

BLHeli_S is the most common due to it being free and open source. It only requires 16bit hardware to run. When configuring these, there are only a handful of changes to make. The big one being motor direction.  Yes, when building our drones, it doesn't matter which way we wire up our motors, because we can just change it in software.

BLHeli_32 is the other extremely common firmware. It's developed by the same developers as BLHeli_S, however, it's closed source. Essentially it's how they get paid. When looking at the configurator, there are a MASSIVE amount of options that can be changed, but unless you know exactly what you're after, the defaults work pretty well. You can also have the motors play music on startup if you wish (I have the sound of Mario picking up a mushroom on mine).

KISS is the final firmware.  Yes, the same KISS that is on FC's. They're a combination that you run together. Some swear by it, others think it's overpriced and Betaflight/BLHeli_32 is just as good.

So when configuring our FC to talk to our ESC's, we have to set the protocol. They used to use various analog and/or PWM methods to talk to each other, however these days, everything just uses a digital protocol named DSHOT.

Depending on Firmware and Hardware, you can set how fast DSHOT will communicate back (and forth when using RPM filtering). Essentially, just set DSHOT300 for F4 flight controllers and DSHOT600 for F7. If you run into trouble, drop it down a notch (DSHOT150 for F4, DSHOT300 for F7).

Traditionally only BLHeli_32 supported bidirectional-DSHOT (used for RPM filtering). Then popped up a paid firmware for BLHeli_S. These days however, if you flash the beta version of BLHeli_S, you'll get bidirectional-DSHOT for free.

The last piece of software you'll need to concern yourself with is what runs on your radio. And to be honest, if you're just starting out, get an OpenTX based radio. More professional pilots will go with Futaba or Spektrum radios which have their own firmware, but many stick with OpenTX.

As the name suggests, OpenTX is open source, and is used on many FrSky, TBS, Radiomaster, Jumper and BetaFPV radios (I'm sure I've missed some brands in there also). Originally it was only used on FrSky, but then there has been an explosion of radios using it, much to the dismay of FrSky (they even put out a statement about it, turning many people off FrSky - along with a number of other shady things they did around the time).

OpenTX isn't the easiest thing to use or set up, however it is very powerful. You can map any switch or axis to a channel, or even set up logic on a switch. For example, you could have a throttle limit on an axis (eg. one of the knobs on the radio), that is only active if a switch is toggled (and you could even have the radio announce to you that it has done so).

Or even send different values to the FC based on a combination of switches (it's possible to get all your auxiliary functions on to a single channel if required - however this is a pain to set up).

So that's a reasonably quick run through of the software side of things. In the future, I'll put up a bit of a rundown on configuring Betaflight from scratch and how you go about it and what the various settings screens are about.

In the final part of this series, I'll cover things not mentioned in the first two parts such as terms we use while flying our drones.