Flyinglemon AIR32 STM32F3 flight controller

It was a good week for flight controllers from Poland. Few days ago ROTORACER showed his RACEBASE FC, yesterday Flyinglemon showed his AIR32 STM32F3 board. Comparing to RACEBASE F3 it is maybe less advanced in terms of integration, but not always more is better.


AIR32 features:

  • integrated 5V step-down 600mA BEC compatible up to 6S
  • SPI connected MPU6000
  • 2 external UARTs
  • Spektrum Satellite connector
  • hardware FrSky S.BUS inverter
  • VBAT, RSSI, WS2812 LED output,
  • Boot tact switch

Board is supported by latest Betaflight 3.0 (still in RC phase) and special build of Betaflight 2.9.1.

Now, I'm waiting for a week of new F4 boards…

Read More


Only a few days ago I’ve written, that new STM32 flight controllers are appearing every few weeks. Weekend goes, and here we go again, this time it’s a STM32F3 (STM32F303CCT6 ) based board from my Polish compatriots from ROTORACER called RACEBASE FC.

racebase f3

Main features:

  • SPI connected MPU6000 gyro (allows 8kHz update frequency)
  • 36x36mm form factor
  • integrated BEC allows 2S-4S battery direct connection* integrated power filter (LPF) for noiseless FPV setup
  • integrated MAX7456 based OSD with RSSI, battery level and PID tuning capabilities
  • 64Mbit flash
  • runs Betaflight

rotoracer racebase f3

Read More

Chickadee Polystack Flight Controller

Usually I do not write about new flight controller boards. Lately, new models appears very often and in most of the cases they are, more less, the same. OK, they differ in layout, sometimes slightly in factor and sometimes in available ports. But they are far from being a brand new approach to the problem.

chickadee stack

But now, there is something new in the topic: Chickadee Polystack flight controller family. What is new in Chickadee? Instead of trying to put everything on one board, Chickadee uses multiple stackable extension boards connected with Polystack connector. You want only flight controller? You have it. You want flight controller and FrSky receiver cradle? You have it. You need MinimOSD? You have a cradle for it.

Scott Shawcroft, author of this system describes it as:

Its a modular microcontrol system called Polystack. There are two Flight Control boards, the F3FC and F4FC they both have the MPU-6000 connected via SPI. Whats makes this different is that the microcontroller IO is connected to the Polystack connector which allows for mods to be stacked on top to expand functionality. So its both for racing and for big GPS machines.

Currently, there are following modules in Polystack family:

  • F3FC flight controller with STM32F3 CPU
  • F4FC flight controller with STM32F4 CPU
  • FrSky D4R-II cradle
  • FrSky X4R-SB cradle
  • Serial breakout
  • MicroSD board
  • micro MinimOSD cradle
  • Pololu Power Cradle
  • Generic receiver cradle
  • Testing and debugging boards

Interesting, but it has a problem: it is rather pricey. Prepare above $100 for a fully functional stack ūüôĀ

Read More

Which sensors drones use to fly?

Modern drones utilize many different sensors to archive flight. Some of them are required to fly, some are only optional and they can only improve flight performance. This entry will be a summary of those sensors, with short description and information how UAV utilizes data from them.


Gyroscope, or shorter gyro, is the only sensor that drone really needs for stable flight. It feeds flight controller with extremely important information: how fast aircraft is rotating around its own axises: roll, pitch and yaw. Inner loop of PID controller utilizes his information to stabilize the craft.

When pilot is not applying any deflection to roll, pitch and yaw control sticks (they are in neutral positions), drone should not rotate. It should keep current attitude, do not wobble, do not have rotation drift. If it starts to rotate, this information is taken from gyros and counteraction is applied to stop unintended rotation and event to rotate back to desired attitude.

Continue reading “Which sensors drones use to fly?” »

Read More

Setting up iNav on 250 class racer

Although iNav (iNavFlight) with advanced GPS and navigation support is best suited for larger, GPS equipped drones, there is absolutely no reason not to use it on something smaller like 250 racer. Why? Well, why not? Basic flight mechanics is the same like in Cleanflight or Betaflight. FP-PID is brand new PID controller, not very popular and not very well documented, but in many ways superior to LuxFloat. The way it handles D term is just outstanding. It can be pushed very, very high without introducing noise.

OK, it has a drawback. High computational requirements and floating point logic causes users of STM32F1 based flight controllers like Naze32 or CC3D can forget about looptime 1000us. 1400us is all those boards can do. On the other hand, looptime 1000us (or even 500) is quite new thing introduced and made popular only about half year ago. And people were racing before that somehow… So, 2000 is not that bad after all. Good thing SMT32F3 board are strong enough not to have to worry about this issue. So, let’s go! Continue reading “Setting up iNav on 250 class racer” »

Read More

New PID controller for iNav

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.

Read More

Better GPS for Cleanflight: iNav

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” »

Read More

Smartport telemetry for Cleanflight

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.

Continue reading “Smartport telemetry for Cleanflight” »

Read More

Cleanflight 1.11 is on its way

Looks like there will be a new release of Cleanflight flight controller software before Christmas 2015. Version 1.11.0-RC1 has been tagged 10 days ago. So, maybe even this week if there will be no bugs. What’s new in 1.11? No, no Betaflight yet, and no iNav (Navigation Rewrite). Some improvements, new supported hardware (Naze32 Rev6 and RMRC DoDo), some bugs fixed. But with 1.11 some features will be removed as well.

First of all, number of PID controllers has been cut in half. PID Controller 0 (MultiWii), 4 (MultiWii 2.3 Hybrid) and 5 (Harakiri) has been removed and will be no longer available. Why? They were not very popular (maybe besides default PID 0) and they were using precious space in flash memory. This is the most important signal that lifetime of STM32 F1 based flight controllers is coming to an end. Naze32, Flip32 and others does not have enough flash memory to fit all functions.

Second, Autotune has been replaced with G-Tune. I did not tried G-Tune yet, so I have nothing to say about it. I’ve tried Autotune few times as was not very happy with results. Not only it did not supported PID controller I prefer (LuxFloat), but I also noticed that tuned P value was too high for my needs. So, bye bye Autotune, I will not miss you…

Read More

PWM, PPM, and Serial RX explained

When speaking about radio systems for remote controlled models, multirotor, airplanes, gliders, there are some shortcuts that might be unknown for beginners. Those are: PWM, PPM, Serial RX, S.Bus. Today I will explain basic concepts behind them, and when they are used.


PWM, as Pulse Width Modulation, is something a standard for controlling different devices onboard remote controlled model. Almost all servos, ESC, flight controllers and radio receivers can work with PWM signal. There might be some exceptions, but they are so rare, that we can skip them.

Stick (switch, POT) position in PWM signal is encoded as length of signal. Signal that lasts 1000us encodes minimum stick position, and signal of 2000us encodes maximum stick position.

3 PWM channels connected to FlySky FS-iA6BIn PWM, each¬†channel is available as separate port of 3 pins (Ground, +5V, Signal).¬†So, if receiver has 8 channels in PWM mode, that means that it has at least 8 ports of 3 pins. 24 pins, 24 cables, lots of mess. And this was great for airplanes, where each control surface is¬†controlled by separate servo¬†connected directly to the receiver. But is not so great for¬†quadcopters and event airplanes with flight controller. Not only it requires a lot of cables, but also complicates things on flight controller’s end. It requires an interrupt for each channel, takes a lot of space and to be honest, it’s completely not needed.¬†Why? Because we have something better…
Continue reading “PWM, PPM, and Serial RX explained” »

Read More