WiFi telemetry for Cleanflight with EZ-GUI and ESP8266

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.

ESP8266 ESP-01 Version 2

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

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

iNav: Cleanflight learned how to do missions

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.

Requirements

  • 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

Continue reading “iNav: Cleanflight learned how to do missions” »

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.12 released

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

Read More

What is Betaflight Air Mode?

Better late than never, so here is mine explanation what is AirMode implemented in Cleanflights fork Betaflight and hopefully soon available also in Cleanflight. Before we will go to any details, please read this to understand how PID controller works. If you know, you might skip it.

In normal flight mode, No Air Mode, flight controller is not using I term from PID controller when throttle stick is low. Why? To make landing nice and easy. It zeroes it. If it would not do it, drone would want to fight pilot attempts to land. That makes sense, right? I term is also not desired during take off. Why? Gyro error might accumulate in I term even before drone takes off, that would result in spinning motors faster and faster (since machine can not correct anything while still on the ground) and in worst case scenario, drone might flip before going into the air. So, zeroing I term on low throttle is good. Or is it not?

Continue reading “What is Betaflight Air Mode?” »

Read More

Cleanflight 1.12 is coming to town…

Looks like Cleanflight release cycle is speeding up. Last stable version, 1.11.0, was published in the beginning of December 2015, next stable release, 1.12, can appear any day now. Its Release Candidate is available for testing for more than a week now.

So, what can we expect? First of all, bad news: no improved GPS navigation from iNavFlight yet. iNavFlight is not ready and looks like it’s too big to fit all targets, specially F1 processors. So, we will have to wait a while for it. In the meantime, iNavFlight 1.0 RC4 is ready for testing. And it is very promissing. I’ve been able to do only a few test flights on it before winter, but results were very nice.

In Cleanflight 1.12.0 we can expect few quite important new features:

  1. Looptime sync to gyro readouts. This is something that Betaflight users knows very well. No more looptime as we know it. Control loop processes data as soon as it have it from gyros. Approximately every 1000us, since gyro updates with 1kHz frequency. But, that does not mean that we all will be using looptime of 1000. Not all hardware targets with features like GPS have enough computing performance to handle that. This is why CLI command gyro_sync_denom has been introduced. It tells CF every which gyro update control loop should be executed. Value of 1 results of looptime around 1000us, value of 2 give looptime of 2000us and so on. Important note: by default gyro sync is disabled and CLI set gyro_sync=ON command has to be executed to enable it.
  2. Improved task scheduler. Task scheduler in revious versions of Cleanflight was rather simple. This new implementation will allow for better processing of pheripherials like GPS. Users probably will not see much (if any) difference, but this is required for future features like better GPS navigation,

In addition to that: faster computations and better gyro filtering, bugfixes, documentation updates (to which I contributed too) and smaller improvements. See release notes for full list.

Read More

Cleanflight software low pass filters

Back in version 1.9, Cleanflight introduced new software low pass filters for gyro readouts, P term and D term of PID controller. They are designed to smooth control loop output and filter gyro inputs from undesired high frequency noise. Unfortunately, Cleanflight documentation was not yet updated and says very little about them. Here are few things that I was able to find out about them.

gyro_cut_hz

This low pass filter (LPF) is a software filter for gyroscope readouts. Most probably the less useful from software LPF filters in Cleanflight. Why? It duplicates (sits on top) of hardware gyro_lpf LPF filter build into MPU6050 or other gyroscope used in flight controller. The only advantage of gyro_cut_hz is a possibility to set any frequency while gyro_lpf accepts only limited set of frequencies. Can be left at 0 (disabled) unless there is a good reason to use it.

To enable it and set cutoff frequency to, for example, 64Hz, enter CLI mode and type:

set gyro_cut_hz=64
save

pterm_cut_hz

This LPF is slightly more useful than gyro_cut_hz since P term of PID controller depends on both gyro readout (filtered by hardware gyro_lpf) and user input. So, in some cases P term frequency can be higher than gyro trace. On the other hand, frequency change is so small, that gain from using pterm_cut_hz is minimal. Setting it below gyro_lpf or gyro_cut_hz will make PID control loop react slower than expected and decrease flight performance. Can be left at 0 (disabled) unless there is a good reason to use it.

To enable it and set cutoff frequency to, for example, 32Hz, enter CLI mode and type:

set pterm_cut_hz=64
save

dterm_cut_hz

Finally something useful! 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 and 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.

Limit how much? I have no idea, since it all depends on a machine PID controller is trying to stabilize. Betaflight (Cleanflight fork aiming at 250 and smaller racers) sets it at 42Hz. My personal experience with big and prone to vibration Reptile 500 frame ended at dterm_cut_hz at 14Hz. 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. On the other hand, I was using dterm_cut_hz at 16Hz on a 250 quad and was happy with results.

To enable it and set cutoff frequency to, for example, 16Hz, enter CLI mode and type:

set dterm_cut_hz=64
save

This entry is outdated, please refer to June 2016 update

Read More

Detecting Cleanflight PID tuning issues with Blackbox: not enough P

This is third part of Cleanflight PID tuning tutorial with Blackbox. Previously I’ve showed examples of:

This time it is time for something slightly different: not enough P gain. Usually this problem can be identified without any log analysis. Symptoms are quite visible: multirotor is sluggish during maneuvers, has a tendency to change attitude on its own, constant course corrections are required. In worse cases, it is unflyable. But how does it look like on Blackbox logs.

First of all, symptoms are not so clearly visible. There are no huge oscillations for example. Zoomed out log might event look good on a first glance. For example like this:

blackbox pid tuning not enough P overview

Continue reading “Detecting Cleanflight PID tuning issues with Blackbox: not enough P” »

Read More