Cleanflight / Betaflight / INAV lowpass filter tuning can be a hard thing to do if you have not idea what is noise frequency you want to cancel. Sure, you can blind test or read tutorials. But what if I tell you, you can measure it quite precisely using only Blackbox logs? Or measure rotation speed of motors? That would be nice, isn’t it? The only requirement are few seconds of Blackbox log with visible gyro (it can be also motor output or Pterm or even ACC reading) noise.
Quite a lot things changed in the world of low pass filtering since my previous port on this topic was published. So, here is the updated guide to Cleanflight LPF filters:
gyro_lpf is the most important low pass filter for gyroscope readouts. First of all, it is not part of Cleanflight, but is done by gyroscope itself. Cleanflight only initializes gyro with desired cutoff frequency. Allowed values are:
OFF is selected, gyro offers fastest possible sampling rate (8kHz, new data every 125us) and smaller possible delay. But, it is extremely prone to any vibrations. Any noise from motor or propeller will be visible in gyro output. All other values of this filter allows gyro to provide new data every 1000us (1kHz).
42Hz is lowest 'flyable' cutoff frequency. It does not makes sense to go lower, since signal delay will be too big and filter will attenuate frequencies that are important from 'flight' point of view. So, 188Hz, 98Hz and 42Hz are the ones that are interesting for us. Exact value depends on propellers, motors, balancing, bearings state, frame rigidness and few other aspects. Let's say, that 250mm or smaller frames can use 188Hz, 450mm and bigger frames should use 98Hz or 42Hz.
gyro_soft_lpf is a second state of gyro readout filtering before they are introduced to PID controller. One might ask: why two filters? After all,
gyro_lpf does the same thing. Yes, it does the same thing. But using 2 LPFs in this case has some advantages.
gyro_lpf can not be tuned. It's either: off, 188Hz, 98Hz, 42Hz. But what if, for example, main source of gyro noise is at about 90Hz? Cutoff at 98Hz would be pretty useless. One would have to use 42Hz, loosing a lot of usable frequencies and having to suffer from noticeable (from PID controller point of view) delay. This is why fully configurable second stage of LPF was added.
gyro_soft_lpf should be kept below
gyro_lpf, and below frequency of main noise source. Usually between 50 and 100Hz. Frequencies below 50Hz are too important for stable flight to attenuate them. On the other hand, everything above 100Hz is useless and can be cut off.
This software LPF filter was removed and is no longer available.
Here, let me just quote my previous post:
(..) D term of PID controller, since it is trying to look into a future, can be a source of huge noise and vibrations. After all, looking into a future is always a tricky business. This is why D term can change with totally different frequency than gyro input and there is a very good reason to limit D term change. Too see how excess D noise can affect gyro traces take a look at my Blackbox tutorial.
(…) Rule of thumb is: smaller and more rigid frames allows for higher D term cutoff frequency and 42Hz is a good place to start. Bigger frames might require lower cutoff frequency and 10Hz is lower boundary.
If only frame and noise level allows, D term cutoff frequency should be kept as high as possible. This allows D term to reacts faster to changing flight conditions and can greatly improve UAV behavior in prop wash and rapid maneuvers.
Telemetry link between UAV (drone, airplane, boat) and laptop/mobile/ground station device can be very useful. Not only to get current drone position, altitude or battery level, but also, when wireless link provides such a possibility, to update drone parameters in-flight. Some radio links, like OpenLRS provides such a possibility out of the box. They include transparent serial bridge and almost any kind of device can use it to communicate with flight controller. Unfortunately, most RC radio systems lacks this functionality and additional telemetry links have to be used. Like SiK Telemetry Radio or 3DR commercial version of it.
One can buy or one can build something by his own. Some time ago I’ve chosen the second way and decided to build my own wireless serial link to archive 2 way communication between drone and ground station software. My objectives were:
- 433MHz since it is legal in my country
- has to allow to use my phone with EZ-GUI, since I do not like to carry my notebook to an airfield
- as cheap as possible
To satisfy those objectives I’ve decided as follows:
Keeping constant altitude with a drone is not a trivial task. Specially, if drone is supposed to keep give altitude very precisely few meters above the ground. One of the reasons for it is difficulty of reading precise altitude. Barometer can drift when atmospheric pressure changes and can produce a lot of noise. GPS is very inaccurate when dealing with altitude. One of the options is to use some kind of rangefinder. Ultrasonic for example. Cleanflight and its derivatives supports exactly one kind of those: cheap HC-SR04 sonar. There are plans to integrate different sonars, but none of official builds supports it yet.
Some time ago I have written a tutorial how to setup Bluetooth based telemetry link between Cleanflight and PC or smartphone. It’s simple and it works. But it has some disadvantages. For example, connection is very very slow and has a limited range: up to 10 meters. While it is enough to change PIDs before flight or plan a mission with EZ-GUI, it is not enough to have a real, usable and reliable, telemetry link.
Luckily, Bluetooth is not the only cheap radio protocol we can use for purposes like this. Why not to use WiFi? Since market saw ESP8266 some time ago, cheap programmable WiFi modules became a reality. There are cheap, they are simple to use and can be programmed to do much more than just act as Access Point or network client. There are many alternative firmwares. For example ones that provides transparent bridges via TCP to allow pass serial ports over WiFi. Almost like serial over Bluetooth, but using WiFi instead. In theory that gives more range, higher speed and lower delay. Why not to use it to connect Android smartphone to drone flight controller and have nice an cheap telemetry solution? Exactly, why not. In this example how to do it with Android EZ-GUI and Flip32 running Cleanflight 1.12, but exactly the same trick can be used for Betaflight, SPracingF3, iNav, Baseflight, Naze32, APM, Pixhawx, MultiWii. If anything is using UART, it can also use ESP8266 as serial bridge over WiFi. Continue reading “WiFi telemetry for Cleanflight with EZ-GUI and ESP8266” »
If anybody keeps track of my posts about iNav flight controller software, he or she should notice that I like it very much. Guy nicknamed DigitalEntity did excellent job improving Cleanflight’s navigation modes. Maybe it is still not the same level as Pixhawk or Naza, but with this improvement speed those two are within reach for sure. When few days ago I noticed that he started to work on new PID controller called FP-PID, I’ve decided to take a look at.
Question. What is the worse flaw of all MultiWii inherited PID controllers? No, not the fact that they are using integer math. It might not make much sense on FPU equippent CPU like STM32F3, but it is fine. The biggest problem with them is that they are not based on proven scientific methods. If you read the code, it will look like this: divide this by Y, multiply X, make a strange assumption, instead of running other control loop make another strange assumption. At the end, they work. But hmm… in a magical way… The only PID controller that was written according to “rules” is LuxFloat.
And since I’m not an expert on control theory, I’ve decided to ask DigitalEntity why FP-PID is developed and what new will it bring. Here are the most important fragments of his reply.
I believe that the only real reason to have lots of PID controllers if that some/most/all of them are flawed in some way (from calculus point of view). So instead of having 2-3-4-5 controllers based on coding voodoo I would prefer to have one controller that is based on solid math and well-known numeric methods. The only PID controller in Cleanflight with clear and simple design […] is LuxFloat. That’s the reason to take it as a base for future improvement.
Comparing to LuxFloat, it is designed to improve the following:
- Better integral anti-windup prevention. Instead of hard-limiting integral part […] the FP-PID implements so-called ‘backtracking’ algorithm to keep the PID controller output within limits. Next step […] PID will be aware when the motors are at their limit
- Improved D-term calculation. All fuss around D-term is about noise. D-term tends to amplify high-frequency noise (usually vibration from props/motors) making the quad jitter. Current designs calculate D-term from current and previous readings and implement low-pass filtering and averaging to prevent D from amplifying noise, while allowing it to do it’s job. They all fight the consequence, not the cause – they try to fight already amplified defivative of the noise instead of filtering the noise itself. My D-term code is based on Pavel Holoborodko’s method of noise-robust derivative calculation […]. I also kept BiQuad filter from Betaflight to filter out the remainder of the noise.
- Modifier self-leveling logic. Current approach with self-leveling is to take angle error and feed it to gyro-based controller as if it was pilot’s input in acro mode. However, roll/pitch angles are calculated from the same gyro data, leading to the phenomenon similar to D-term noise amplification – the faster the quad is rotating the bigger is PID response in self-leveling compared to rate mode. What I did is made the self-leveling code behave like human pilot. Human pilot does not correct for each and every slight attitude change, instead he corrects for bigger and slower changes. This is by definition the low-pass filter which is what I did in the code. This change makes self-leveling less jittery which is very evident when doing FPV flights in ANGLE or HORIZON modes.
The way I see it, it sounds super intresting. If time and weather will allow, I will give it a try next weekend on my 250 build. Just for fun.
In my recent post I mentioned that iNav flight controller software (fork of Cleanflight) introduced missions. Missions are preprogrammed waypoints that drone will fly to in specified order and/or do specified action at each of them. For example, if pilot wants to make a video on specified route, he does not have to pilot his drone all the time. He enters waypoints and lets machine do everything else. In this entry I will show how to configure iNav to do missions.
- iNav compatible drone flight controller flashed with iNav software. Currently supported boards are: Naze32, Flip32, CC3D, SPracingF3, Sparky, RDMO
- GPS module connected to flight controller board. This example shows how to do it for Flip32, but it will work for all other boards, only UART pins might be different
- Magnetometer connected and properly calibrated
- Barometer connected
- EZ-GUI Ground Station Android application that will act as Mission Planner. Official Cleanflight Configurator does not support this function yet
- Bluetooth telemetry. Some time ago I have written how to do it for Flip32, but it will work almost the same for all other flight controllers, only UART pins might be different
Cleanflight is an awesome piece of software for STM32 based flight controllers. But Cleanflight has one very serious flaw that makes its usage on bigger drones at least problematic. Cleanflight sucks in GPS and barometer support. Sucks a lot. It can handle Position Hold (somehow), Return To Home (barely) and Altitude Hold (oh man, up and down, up and down) but if you at least one tried that, you should know that is not only not reliable, but also not precise and hard to tune. Personally I gave up after few tires. It was not worth it. Comparing to Pixhawk (not talking even about Naza) it might as well not exists at all. But it has changed recently…. Continue reading “Better GPS for Cleanflight: iNav” »
With their latest transmitters and receivers FrSky changed telemetry protocol. XJT module, Taranis radios, X8R, X4R and X4RSB are using SmartPort telemetry protocol. And that creates few problems. First of all, SmartPort is a serial protocol. That means, flight controller has to have free serial port to connect S.Port device. Second of all, TX and RX lines shares the same wire. The work in half-duplex mode. Third of all, SmartPort signal levels are inverted: logical 0 is in HIGH state, logical 1 is in high state. All of that combined, connecting SmartPort receiver to flight controller and sending telemetry data is not so easy to archive. Specially on FCs without hardware inverters. That applies to most popular STM32F1 devices like Naze32 and Flip32. Not only numer of UARTs there is limited, but also they lack hardare inverters. Of curse, everything is possible and hardware solution for Cleanflight, Naze32 and SmartPort telemetry can be found here.
Luckily, there is simpler solution for Cleanflight that uses SoftSerial and does not require any hardware hacks besides special wire. Requirements:
- Cleanflight capable flight controller (STM32F1 or STM32F3),
- SmartPort enabled receiver: FrSky X8R, X6R, X4R, X4RSB,
- Possibility to enable SoftSerial. Depending on FC type, different fetures like Parallel PWM, Sonar, LED Strip or Current Meter collides with SoftSerial functionality. Check documentation first. In case of Naze32/Flip32 WS2812b LED strips and Parallel PWM can not be used.
3 days ago, new version of Cleanflight, STM32F1 and STM32F3 flight controller software has been released. I already wrote few words about it a month ago, but final list of changes and improvements is bigger. Main changes are:
- Looptime sync to gyro readouts, enabled by default (!),
- New task scheduler,
- Air Mode. Finally this awesome feature was merged from Betaflight. If you want to know more what Air Mode is, read this article,
- Failsafe improvements. And what more important, failsafe can now be configured via Cleanflight Configurator. It has its own tab. To use it you will need Cleanflight 1.12 and Configurator 1.2 or newer,
- MSP telemetry is gone. It’s replaced with LTM telemetry. Important notice: it is not MSP protocol. Only MSP telemetry was removed, not MSP protocol,
- New hardware targets,
- Documentation improvements. OK, this is minor, but I had some input there, and I’m quite pride of it!
I did not installed Cleanflight 1.12 on any of my quads yet, so no idea how it behaves. But 3 days without a path means that there should be no problems. Full release notes are available here