Kalman Filters Replaced? Biquad+FIR: New Hype or Same Old.

Literally the same day that I released my video about Betaflight 3.3's Kalman Filters, a post on Facebook announced that Betaflight had moved to a different type of filter (biquad + FIR). People were quick to ask: HOW DOES IT PERFORM?

The answer is: exactly the same.

If you tried out the Kalman Filter version of Betaflight, you know that you have to overclock your F4 processor to use it at 32 kHz, and F3 processors struggle to run it at all. This is okay for pre-release testing, but the BF devs don't want to release code to the world in this state. The biquad+FIR filter produces the same effect as the Kalman filter, it's just easier on the processor. Meaning that it can run on F4 without overclocking, and F3 can breathe a little easier.

But the biquad+FIR filter is not exactly identical to the Kalman filter. The Kalman filter has some "advanced options" that the code is not currently using. That's why it can be simplified and reduced to biquad+FIR. In the future, a version of Kalman may come back that takes advantage of these "advanced options" and performs even better.

Some Raceflight supporters have interpreted the move to biquad+FIR as a slap in Kalyn's face. It's not. It's a normal part of team-based code development to have ideas examined and refined by the team. It also highlights a core difference between Raceflight and Betaflight, and why Raceflight contributing code to Betaflight doesn't threaten Raceflight's continued existence. Betaflight must support a wide variety of hardware. Raceflight is tailored towards exactly one flight controller. Betaflight is a team-based approach where no idea is sacred and no individual contributor is supreme. Raceflight is more like Kalyn's personal playground, where anything he says, goes.

Kalman Filters bring RaceFlight handling to Betaflight?

Kalyn Doerr, the original creator of RaceFlight, has been contributing code to the Betaflight project. Since Betaflight is open source, there's nothing unusual about it taking contributions from wherever. But given Raceflight's history of going closed-source specifically to avoid others "stealing" their ideas, the situation is at least a little bit noteworthy.

In a vibration-prone environment like a multirotor, filters are perhaps the single biggest contributor to good handling. Filters are mathematical algorithms that get rid of the frequencies we don't care about, so that the PID controller can focus only on the frequencies we do care about. Because the PID controller has to act in real-time, and has limited processing power, tradeoffs have to be made in what the filters do.

Kalman filtering is uniquely suited for multirotor use because it is designed specifically to deal with very noisy sensor data, such as occurs in a mini quad with motors screaming. They are capable of estimating the entire state of a system based on a few measurements. They also provide uncertainty metrics, so that more certain information can be weighted more heavily than less certain information. Kalman filters are also specifically designed to work in a real-time environment.

There is a lot more to this topic that I not only don't have the space to cover... I'm not even academically qualified to cover it. There are all kinds of arguments why 32 kHz sampling shouldn't actually be better than the 8 kHz sampling most of us are using now. There's an argument that multirotors are actually not well suited to Kalman filters because the motor noise is not Gaussian distribution. There is even an argument that what Kalyn's filter is doing actually isn't a full implementation of a Kalman filter, and misses out on Kalman magic.

The bottom line is this: lots of people feel that Raceflight flies awesome; and some people who have tried the pre-release version of Betaflight, say that Kalman filtering makes Betaflight fly awesome too.

So then, is the promise that Kalman filters will bring Raceflight's magic to Betaflight, allowing pilots to have the best of both worlds? It sure seems that way.

If you want to try out the pre-release version of Betaflight with Kalman filters built in, here's a link to show how to get it. But please be aware that this is not even alpha code. Anything could happen. When you install it, imagine that your quad went full throttle as soon as you plugged in the battery, and refused to failsafe or disarm. That probably won't happen, but if you imagine that it might, you'll be at the appropriate level of safety for using pre-alpha code.

Betaflight Yaw Spin To The Moooooooon

Some flight controllers running Betaflight are subject to a condition known as "Yaw Spin To The Moon" (YSTTM). YSTTM usually happens when a racer clips a gate at high speed. The quad goes into a climbing yaw spin that can't be stopped except by disarming.

The root cause of YSTTM is a bug in the gyro chip's firmware. When the angular rate exceeds the maximum value that the gyro can measure, a programming condition known as a "2's complement overflow" occurs. The effect is that the gyro reading flips over from +4000 degrees per second to -4000 degrees per second. The PID loop perceives that the quad has gone from spinning 4000 dps to the left, to 4000 dps to the right.

When YSTTM occurs, the gyro is giving incorrect information to the PID loop. So the PID loop's response is also incorrect. Garbage in = garbage out, as they say in programming. The PID loop perceives that the quad is spinning very fast to the right, so it gives the motors maximum yaw to the left, to counteract the spin. But because the gyro's output has inverted, the PID loop actually makes the quad spin faster.

The way to break out of YSTTM is to allow the angular rate to go below 4000 dps, but since the PID loop is reinforcing the spin, this will never happen. This is known as a "latching condition". Once it occurs, it will never stop occurring without external intervention.

This firmware bug is exclusive to the newer ICM206XX series of gyros. The MPU6000 is immune, which is one reason why I selected it for use on my JBF4 AIO flight controller.

Even though the MPU6000 doesn't have the overflow bug, it still can sometimes experience YSTTM. Because YSTTM can be caused purely by physical conditions. If the quad is spinning fast and also wobbling a bit, the PID loop can simply get "behind the curve" and not be able to cancel out the unwanted motion. You know that thing that happens where you're trying to pass someone in a hallway and you both move left, then right, then left again, repeatedly failing to get out of each other's way? It's kind of like that. In some extreme spin/wobble states, the PID loop can accidentally reinforce the spin. The difference is that the overflow bug on the ICM206XX series of gyros is 100% guaranteed to cause a YSTTM every time the gyro exceeds 4000 dps. Whereas the MPU6000 will only experience it rarely.

Betaflight devs are working hard to come up with a software solution to address YSTTM, regardless of its cause. YSTTM is pretty easy to detect. Any time the yaw gyro reads more than a "sane" value, the code can assume it's in a YSTTM condition. The current approach simply disables the PIDs when the yaw angular rate is too high, which allows the quad to slow down. You're probably not doing much flying anyway when you're spinning at 2000+ dps, so the lack of PID controller shouldn't affect you too much.

Of course, the real answer should be for Invensense to fix the bug in the gyro itself. Or for FC designers to use the MPU6000!

Shake-up in the Ultimate FPV Shopping List motors section

The Motors section of my Ultimate FPV Shopping List is one of the hardest ones to keep up to date. Here are some new motors that I've added, and a few that I've let go.

The Armattan Oomph seems to be out of production. Armattan's new 2306 Titan motor is probably solid, but ... I don't know. I'm just not feeling it. In the same vein, the Returner R3 has been cut because it doesn't seem to be made any more. This one hurt because I really loved that motor for racing, and at around $17 it wasn't too expensive.

The RCX NK2306 replaced the Returner R3 as my mid-price racing motor. The RCX was one of the only race-focused motors I could find that fit into the $14-$20 range that I consider mid-priced. RCX motors have traditionally performed on par with much more expensive ones. Ryan Harrell showed me a response curve for the RCX2206 vs. the HypeTrain, and ... they were literally the same. I'm really looking forward to seeing results for RCX's new 2207, because my gut feeling is that the response curve of the 2207 is better for racing than 2306. But you take a 2700kv version of either motor and it's going to rip.

T-Motor released an updated version of their F40 Pro, which is my top-of-the-line racing motor. The F40 Pro II has an open bottom to save weight, and a few other cosmetic improvements, including three different colors.

I was thrilled to learn that RaceDayQuads' BadAss 2205/2450kv was an OEM version of the Returner R2. I flew the R2 on the Catalyst Machineworks Norris Superlight and was amazed at the 6 to 7 minute flight times I got.

Finally, I found an excuse to add a Hyperlite motor to the Shopping List. Piroflip is an amazing vendor and you could literally find a Hyperlite motor for any of your quads, from 4" to 6" props. The specific one I picked is the V2 2205/2300kv, as a mid-priced all rounder.

Links to all these motors are in the Ultimate FPV Shopping List.

I interviewed Ryan Harrell again and it was awesome

Ryan Harrell is one of my favorite people to interview. He's so knowledgeable about motors, it just seems like every time we talk I learn so much. And you guys obviously agree, because his videos get tons of views. In case you didn't watch the whole interview, here are some key points that we discussed.

Think of motors in terms of weight and power, not in terms of size. Today, you can buy a 2306 or 2207 sized motor that weighs around 28 or 29 grams. That's equivalent to what a 2205 or 2206 motor used to weigh (and some still do).

A few grams of weight at the end of the arms makes a difference. You might be tempted to shrug off the difference between a 29 gram motor and a 34 gram motor. What do 5 grams matter if the motor is making 1.5 kg of thrust? Trust me. It matters. First because 5 grams times 4 motors = 20 grams, and that's a fair amount of weight to remove from a quad. But also because weight at the end of the arms has a more pronounced effect on handling (especially very abrupt maneuvers) than weight near the center of gravity.

It's difficult to generalize about motors based purely on size and kv. Motor performance has a lot to do with the overall design, including the windings, the stator laminations, the magnets, and the air gap. There is no reason to assume that two different motors of a given size and kv will perform the same. Real world test results matter.

Of course, we talked about a whole lot more so if you want to see it all, check out the full interview here: https://www.youtube.com/watch?v=J-OFDWGztYo

Does Wire Gauge Matter?

What wire gauge do you use for your battery leads? Most people use either 14 gauge or 12 gauge. You probably know that thinner wire has more voltage drop and delivers less power. But how much does this effect actually matter? Tonight, I did a test that might answer that question.

For all the details, you'll have to wait for the video. But as a newsletter subscriber, I'll give you the preliminary conclusions.

The worst-case scenario that I considered was a 10 cm wire and 120 amps discharge rate. Based on that assumption, the 12 gauge wire will drop 0.06 volts while the 14 gauge wire will drop 0.1 volts. The 14 gauge wire loses 5 watts more than the 12 gauge wire. If you are using shorter wire than 10 cm, or pulling less than 120 amps, these numbers only get smaller.

You might think that it's obvious that the thicker 12 gauge wire gives higher performance. In fact, I've complained sometimes about high-performance batteries coming from the factory with 14 gauge wire leads. But these results seem to call that into question. Even if we were to double the wire length to 20 cm, we're only losing 10 or so watts, worst-case. When you consider that a quad might pull 3000 or 4000 watts at full throttle, 5 or 10 watts lost to the battery lead hardly seems to matter.

TBS ZeroZero FPV Camera has sub-1ms latency?

For some reason, a few people have started asking me about the TBS ZeroZero camera, with its claim of sub-1ms latency. I am very skeptical of this claim, and here's why.

Everyone I've seen claiming to show sub-1ms latency is using the "point a camera at a stopwatch" method of measuring latency. In this method, you point the camera at a stopwatch app on your smartphone and then you look at the output of the camera and subtract the one time from the other to get latency. 

The problem with this is that the video feed coming out of the camera is either 30 fps (NTSC) or 25 fps (PAL). This means that the absolute maximum precision that method can measure is 1/30th or 1/25th of a second (33 ms or 40 ms). You simply cannot measure with more precision than that if you are basing your measurement on the camera's output alone.

So anybody who shows you a screen shot of a stopwatch and says they are measuring camera latency to a precision of less than 33 ms or 40 ms has immediately lost all credibility. They don't know what they're talking about.

Here's a video I made about that, and some other common sources of inaccuracy in camera latency measurement. 

The best way of measuring camera latency is not the one I show in that video (although I am a bit proud of it) but what Oscar Liang and RCSchim are doing: you light an LED in front of the camera and you measure with a photodiode when the screen lights up, and then you use an oscilloscope or Arduino to measure the time between those two events. You are still affected by the camera's output framerate, but you can do multiple measurements and average around it, as Oscar and RCSChim do.

Racing precision with freestyle rates?

Ever since my epiphany about race rates, I have been thinking about how to get some of the smoothness and precision of low race rates into my freestyle flying. One thing I'm not willing to do is to turn down my rates entirely. For great freestyle, I feel like fast flips and rolls are required. But I still feel like I could benefit from more control at center-stick.

It used to be that if you wanted more center-stick control, you would add Expo. But ever since S.Rates (Super-Rates) got implemented in Betaflight, I've preferred S.Rates to Expo. Both of them add precision to the center-stick in exactly the same way, but the S.Rates curve has a more abrupt transition between center-stick and full-stick deflection that I really prefer.

The problem with S.Rate is that if you add S.Rate because you want more center-stick control, it also changes your full-stick-deflection rate. So if you want 1100 dps at full deflection, you have to sort of shuffle RC Rate and S.Rate back and forth to achieve the desired curve while still maintaining the desired full-deflection rate.

It's only recently that I have re-discovered an advantage of Expo. When you add Expo, the shape of the curve changes, but the full-stick deflection endpoint doesn't. This means that you can use Expo to add just a smidge more control to center-stick without having to re-shuffle RC Rate and S.Rate to keep your overall curve the same.

If you have your freestyle rates exactly how you like them, but you want to experiment with just a bit more center-stick control, try adding 0.10 to 0.20 Expo and see if you like it.

Dshot Motor Beeper Warning!

Betaflight 3.2 lets you use your motors as a beeper, instead of having to install a piezo beeper on your quad. But there are a couple of gotchas.

Some people are smoking their motors by letting the beepers run too long. Using the beeper can make the motors hot, so watch out for this! If you are looking for a lost quad, it's best to beep the motors once or twice then stop, instead of leaving them beeping for a long time.

Some people prefer the standard beeper, and asked for a way to tell Betaflight, "don't do that motor beeper thing." Betaflight RC6 added a CLI option to set Dshot beeper strength, or even disable it completely. This can also fix the "hot motors" problem. The command is:

set beeper_dshot_beacon_tone = 1

A value of 0 disables the Dshot beeper. This is the default. Larger numbers are louder, but are more likely to make your motors hot or even damage them.

1200 Watts for $30? YOU CAN'T BEAT THAT.

I just added a new power supply for your LiPo charger to my Ultimate FPV Shopping List. It costs about $30, and it puts out 1200 watts. In case you don't realize what an amazing deal that is, that's about the exact same price as you'd pay for a 360 watt PSU from Banggood.

This power supply is originally intended for use in a rack-mount server, which means its build quality and design are top-notch. It has short-circuit protection, overheat protection, and low-voltage protection. Basically, it's indestructible (this claim is not intended as an actual promise of indestructibility).

So what's the catch?

It doesn't come with an XT60 or banana plug connected to it, and it doesn't come in a pretty case. But if you are a bit handy with a soldering iron, this PSU is, without question, the absolute best way to power your LiPo charger or other 12v accessories.

Here's the full parts list to complete the build.