STM32F7 CPU family present in newest, experimental, flight controllers like AnyFC F7 (as well as upcoming AnyFC M7 with smaller STM32F722) simplifies many things. For example, comparing to F4 boards, SmartPort or S.Bus connection is extremely simple and can be done on any free UART. No more hardware hacks, external inverters and other “special” ways of doing things.
It’s super simple again, and here is how to do it in Betaflight (Cleanflight 2.x) and INAV
The only required hardware is a cable to connect SmartPort enabled receiver with free UART port on F7 board. This will work on X8R, X6R, X4R, X4RSB, XSR and any other. The trick is to connect S.Port pin with UART TX pin only.
Only 5 weeks ago I’ve written that Cleanflight has a problem. Looks like, the problem was much bigger than I expected. Today in the morning, Dominic Clifton aka. Hydra essentially killed the project by resetting GitHub repository to Betaflight 3.1.
While STM32F4 family processors installed in newest flight controllers are superior to STM32F3 (and F1 of course) in terms of raw speed, they are inferior to F3 family in terms of IO handling capabilities. For example, F4 family is not equipped with UART port inverters. And that creates a series of problems when it comes to connecting various serial RX receivers and telemetry systems.
The most popular FrSky (Futaba) S.Bus serial RX protocol and FrSky SmartPort telemetry require inverted UART signal. If there is no hardware inverter on hardware UART port, they will not work. While S.Bus requires only one data line, external inverter is not a big issue. Some time ago I’ve published The Simplest Harware Inverter. One MOSFET transistor, one resistor and that’s all.
In case of SmartPort, it’s slightly more complicated. Not only signal is inverted, SmartPort also combines TX and RX UART line into single wire. That means the following:
More complicated inverter is required
Software has to support this case and fallback to unidirectional UART mode
Last 18 months was an extremely good period of time for all mini-quad enthusiasts. Progress, hardware and software both, was just incredible. Who could have guessed that in less than 2 years mini-quads will evolve into main group of drones with such excellent flight characteristics. Just take a look at looptime. When I entered the hobby, standard looptime was 3500us (285Hz). Then, someone noticed that mini-quads fly much better when looptime is lowered and it started. Right now, standard looptime is 2000us (500Hz), while Betaflight starts with 1000us (1kHz) or even 500us (2kHz) in case of faster flight controllers.
Just by looking at numbers one might come to a conclusion, that looptime should be kept as low as possible and higher control loop frequency is better. Hey, 2kHz should be twice as good as 1kHz, right? One might even thing that it’s really about frequency. Well, this is both false and true: sometimes it is not about frequency, sometimes it is about frequency after all.
Latest Betaflight 3.0 is a new quality for flight controller software. It brings many new, cool, features comparing to previous versions. If you fly mini-quad or micro-quad, you have to check what Betaflight 3 has to offer.
This tutorial will show how to install Betaflight 3 and how to configure it so mini-quad can go into the air in under 20 minutes.
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.
Until recently, INAV concentrated on GPS and navigation support. Comparing to Betaflight, or even Cleanflight, its acro capabilities were rather limited. Flyable, but limited. Now we are trying to catch up. While upcoming INAV 1.2 will rather not change much in this topic, there are few experimental code versions that might greatly improve INAV acro capabilities. One of them is separation of gyroscope readouts from PID loop.
INAV and FP-PID with extensive floating point logic are rather slow. Looptime 2000us (500Hz update rate) is a limit for F1 targets and 1000us (1kHz mode) is barely reachable by most F3 targets. Version from mentioned above pull request separates gyroscope readouts and filtering from main PID loop. Thanks to that, gyro is updated much faster (up to 2.6kHz in case of F3 with I2C gyro). Faster gyro update means better signal signal quality, lower delay, better filtering and less aliasing. One the other hand, motors does not have to be updated that often. Not only they are unable to change rotation speed as fast as we can drive them, they are unable to notably change thrust as fast as we would like them to.
Let's do some math: what will the distance that tip of a 5" propeller running 12,000PRM will travel during 500us (2kHz update frequency)? About 40mm. More less 10% of a circuit. Not much distance to change generated thrust…
This might sound strange, but looks like it is working. Below is a short video of my 3S 250 quad running gyro loop at 2kHz and PID loop at 666Hz. Honestly? This quad never flew better! Please ignore my lame flying skills 🙂
If anybody would like to try asynchronous gyroscope on INAV, please drop me a message, I will compile and share this special version.
INAV: unsynced gyro updates was last modified: July 29th, 2016 by Dziku
This video was taken last weekend during tests of latest changes implemented in iNav, as well as new GPS module Beitian BN-880 I shortly described here.
Take off in Angle mode,
Engage 3D Position Hold
Fly away 100m
Return to Position Hold
Engage Return To Home mode
Beitian BN-880 performed well. Quadcopter returned home with 1m accuracy. Constant fix on 15 sats all the time and HDOP at 1.2
No problems with magnetometer inside GPS module
No bigger problems during whole mission. I still have to work on yaw behavior. At the moment FP-PID and linear mixer from Betaflight can cause some strange yaw behavior on bigger quads. Fix should be available soon
iNav: RTH with land mission was last modified: April 13th, 2016 by Dziku
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
Cleanflight 1.12 released was last modified: February 23rd, 2016 by Dziku
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?