Betaflight 4.0 – improved dynamic filtering on 7 inch quad

The next major release of Betaflight will be 4.0 with new and improved Dynamic Filtering. For now, today I only did a quick test of **Betaflight 4.0** running on my TBS Source One 7-inch FPV drone. No tuning, no playing with settings. I only flashed, set modes and radio and that's all. I pretty much like how it feels. This quadcopter was mainly doing cruising, no freestyle, and it felt good to put those props into more demanding use. Yes, Betaflight 4.0 has a good chance to be just awesome…

Hardware

A note about the sound. It indeed sounds like a V8 engine. Bear in mind, that those are default settings and Gemfan FLASH 7042 props are light and do not like to have too much D gain.

This is why YOU SHOULD use only 8 channels in Betaflight!

When two weeks ago I said that you should only 8 channels when using FrSky SBUS I meant it and you just had to take my word for it. Today a small proof how Betaflight 3.5 feedforward component looks on the Blackbox with 16 channels and 8 channels. Of course, in both cases, RC smoothing type FILTERING was chosen.

Get your Blackbox logs from SD Card with a USB cable – Betaflight MSC

SD cards are cool: cheap, reliable, a lot of space and you can remove them from the drone and read on a PC. But sometimes, it's really hard to take them out. Either SD slot is in a strange place, or FC is oriented in a strange way or an FC designer has put an SD slot in a most stupid place of them all…

You can use Betaflight 3.4 as an SD card reader (MSC standard compatible) and either use it do get your blackbox logs via USB cable or use it, if you really want to, as a pendrive. With drag and drop and all that stuff. All you have to do is to go to CLI and type "msc" and hit enter. That's all! It's not perfect, but works!

What is Betaflight 3.5 Feedforward and how to use it

Betaflight 3.5 is just around a corner and it brings new cool things. There is no more Dterm setpoint weight and Dterm setpoint transition (relaxation ratio). They all were replaced by easier to understand Derivative and Feedforward (Feed Forward when you refer to the control theory tho).

Betaflight Derivative and Feedforward parameters are the new way of controlling "damping force" of the Dterm and responsiveness of a drone. The more Derivative gain you set, the more "damped", "delicate" and "swooshy" drone will be. The more Feedforward gain you apply, the more responsible to the sticks it will be. It's almost the same as with Dterm setpoint weight, but in my opinion, made simpler and can be set separately for each axis.

Betaflight 3.4 – how to get it and what changed

Competition from Butterflight changed the game. I might not be the biggest fan of Butterflight, but one thing is sure: thanks to it, Betaflight took a big lead forward. The best example of it is Betaflight 3.4 that currently is in Release Candidate stage.

The most important changes, that really influences flight (there are more not flight related changes, I will cover them separately) are revisited filtering and PID defaults:

  • Dynamic filtering enabled by default
  • Antigravity enabled by default
  • Gyro stage 1 LPF bumped to 100Hz
  • Gyro stage 2 LPF (not) Kalman FIR2 filter set at 300Hz
  • Dterm filter type set to PT1
  • Gyro notch filters disabled
  • Dterm notch filter disabled
  • Revisited PID gains

Now, it flies wonderfully!

Betalight 3.3 and Kalman filter (BiQuad+FIR2 to be precise) situation

Betaflight 3.3 RC1

Betaflight is at the end of next release cycle. Betaflight 3.3 RC1 has been released only 2 days ago and that brought us a (not) Kalman filter! Long story short:

  • Raceflight was using Kalman (Fast Kalman Filter – FKF)
  • RS2K left RF and brought FKF to Betalight
  • Betaflight did some changes and replaced Fast Kalman with BiQuad + FIR2 (Finite Response Filter) equivalent that gives more less the same results (same response) as Fast Kalman

Unfortunately, someone at Betaflight forgot that users will want to use it and the process of setting up (not) Kalman filter (I will be calling this (not)Kalman because it just sounds better than BiQuad+FIR2 and says all you need to know) is at least stupid. The filter is gyro update frequency dependent and instead of setting up a cutoff frequency, it has to be tuned using gyro_filter_q and gyro_filter_r CLI settings that you have to guess or compute somewhere else. How awesome is that!

Anyhow, to make life a little easier I prepared an online (not) Kalman filter calculator for Betaflight 3.3 RC1 that allows computing filter cutoff frequency based on gyro_filter_q, gyro_filter_r and gyro update frequency.

Also, here is a YouTube video that shows how to use it and configure BF 3.3 RC1 for (not) Kalman:

And another video that shares some more general thoughts on the topic:

Betaflight 3.3 RC2 (upcoming)

Ah yes, there was a small change… Looks like BF guys decided to make life a little easier for us after all, and sped up a small but very important change. Starting from Betaflight 3.3 RC2 (or today's nightly build), (not) Kalman filter cutoff frequency can be specified with a single CLI setting: gyro_stage2_lowpass_hz. More than that, gyro_filter_q and gyro_filter_r are removed and not available at all.

I always knew that developers need some proper motivation, but why could this not be like that from the beginning?

Standalone Betaflight Configurator, since Chrome Web Store apps are dead

Google finally did what they announced last year: Chrome Packaged Apps for Windows, Mac, and Linux are dead. OK, maybe not 100% dead, but they were removed from search and browse in Chrome Web Store. If you still have link, you can install (no idea for how long tho).

So, how to live with that? Our hobby is driven by Chrome Packaged Apps. Betaflight Configurator, INAV Configurator and Cleanflight Configurator are all Chrome Packaged Apps. Did we lose the ability to set up our drones? Luckily no. Thanks to fantastic project NW.js, chrome apps can be packed together with Chromium and distributed as a single file without dependencies. I've prepared a short video how to install Standalone Betaflight Configurator, for INAV it's the same procedure. And for Cleanflight… well… Cleanflight is dead. Or rather dying…

RaceFlight One source code has been published and what does that mean

In the beginning of time, there was MultiWii and it was good. But then times moved on and 8bit ATmegas were end-of-line for flight control. So, Baseflight was created. In the beginning, it was supposed to be only a MultiWii port to support STM32f1 flight controllers in a for of Afroflight Naze. And it was good for a while. But the guy that was running this show turned out to be a prick and one of Baseflight developers forked everything and called it Cleanflight. One might want to say "Hail Hydra" but let's try to be serious here.

Anyhow, everything was great again. No pricks anywhere and Cleanflight was growing. People started to fork Cleanflight. Betaflight, INAV and Raceflight were created. No problems anywhere, one big happy family.

It did not take long for things to change. Someone decided that he can make money by making code closed-source and run only selected, sold by them hardware. It was RaceFlight by the way and this is a reason I'm not writing much about them. There real problem is that you just can not make an Open Source code under GPL license Closed Source just like that. It is virtually impossible since all commiters would have to agree to that. All of a few hundred. Good luck with that. INAV tried to change license once (and still be Open Source) and it failed. Few devs just said no. End of story.

Back to Raceflight. When in late 2016/early 2017 Raceflight went Closed Source. Some devs decided to check this and that, decompiled RF firmware and compared that with CF/BF. Surprise, surprise, decompiled code for gyro initialization looked exactly like in CF/BF. Raceflight was violating GPL license! They had no rights to close the code of Raceflight. Period. RF team defended themselves as they could but IIRC finally published source code for Raceflight (not RF One) like GPL required. Joshua Bardwell did a video on that topic you might want to watch BTW.

You might think this is the end of a story, but not. Raceflight announced RaceFlight One and claimed that RaceFlight One is 100% their doing, rewritten and does not contain absolutely no code from Baseflight/Cleanflight/Betaflight. So it does not fall into GPL at all. They were more less believed and most of pilots forgot about the whole thing.

Until yesterday. Because yesterday, Kalyn Doerr aka rs2k (one of creators on RF) published the full source code of Raceflight One on GitHub and posted something interesting on Facebook too:

(…) I don't want to say much publicly right now. I have kept quiet as I have been in fear for my safety for some time now. Over the last several months I have documented Preston Garrison's business dealings as he has tried to keep me away from the business. I have had no success in reasoning with him. I created it originally to share with the community and I have poured my lifeblood into it. It will not die here. I am RaceFlight.

Pretty scary, isn't it? Drama and stuff. But what happened is that RF One source code is on GitHub. Take it while it's fresh since it might be removed due to DMCA soon.

Let's leave the drama and see what mentioned Prestion aka proggod posted:

Well apparently Kalyn decided to release our code to the public without consent from me. I have no idea what his intentions are, or why he would decided to do this, last time I communicated him he was working on his home life. I can say he doesn't own the code, and it certainly can't be licensed as GPL, especially since he was not the only contributor to the code base. (…)

In other worlds "_I have no idea what happened but this code is private and GPL does not apply". Well… Betaflight community decided to check again an they found out something very interesting:

//TODO REwrite this better
char *ftoa(float x, char *floatString)
{
    int32_t value;
    char intString1[12];
    char intString2[12] = { 0, };
    char *decimalPoint = ".";
    uint8_t dpLocation;

//TODO REwrite this better is nothing strange. But, exactly the same ftoa implementation can be found in Cleanflight, Betaflight and INAV source code. And by exact, I mean exact. not similar. Exactly the same. It was committed by hydra in April 2014 under GPL license. And that means one thing: whole RaceFlight One is GPL. This is how GPL works. They did not rewrite it from the scratch, they took some elements of GPL code and continued from there. GPL is very intrusive license: if you use anything licensed under GPL, your whole project is automatically GPL too. Period.

I have no idea who is lying. But someone on the RaceFlight side is lying. Why? If you do not know why it's because of money. An old universal truth. And I suspect this whole thing might have legal repercussions and someone will meet someone in a court. Is that good? No idea. Bottom line is: RaceFlight One is violating GPL license of a code it was based on.

Ah, there is one more small thing. According to some RF/BF devs and users, Preston Garrison always stated that RF One is not using Kalman filtering. More, users were apparently banned from Slack for suggesting RF One was using Kalman filtering. Guess what… The published code suggests RaceFlight One is using Kalman filtering… Funny….

I will try to keep my eye on it and if I will keep you posted in case of any major developments (if any)…

Update #1

No, there is no Kalman filtering in RaceFlight One after all. All occurrences of Kalman filtering are commented out

Update #2

After all, there is a Kalman filter in RaceFlight One. The commented out code refers to multi-state Kalman filter. Method PafUpdate that is used for gyro filtering is 1-state Kalman filter. Thanks DigitalEntity for discovery

Follow up for 2017.12.07