In this episode I talk about:
- How Betaflight, Cleanflight and INAV filters gyroscope signals
- What is the difference between LPF and notch filter
- How to setup blackbox logs for precise gyro signal analysis
In this episode I talk about:
I’m not completely sure why, but I’ve been pushing this topic away for quite a long time now. But it’s finally time to present it in this blog too. So, here we go.
Something like 3 month ago I’ve started to record and publish a video series about basics of gyroscope data processing in modern flight controllers (Betaflight, INAV, Cleanflight). It started as a tutorial how to setup notch filters in INAV, but ended up as a much bigger thing. Series consist of 4 episodes where I use Blackbox logs to show gyroscope signal noise and how to fight with it. Over next few days I will be posting links to those videos here, but if you eager to see them sooner, just use this link.
In Episode 1 I talk about:
Ah yes, I’m running a YouTube channel too, feel free to subscribe 🙂
There is still very little about AnyFC F7 on the internet. Especially pinout is kept secret. Without sambas official GitHub repository for hardware projects, there would be nothing at all. I’ve decided to close that gap a little and prepared full pinout for AnyFCF7.
Yes, I know they are hand drawn and scanned, but I have a strong aversion for computer graphics software. I can move a slider left and right, but every time I have to do some creative photoshopping, my head starts to hurt. This is extremely ironic, since my major at university was computer graphics. Heh…
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.
Before we proceed, short clarification. Legal background of AnyFC F7 flight controller from Banggood is
iffy. It’s not that BG ripped the design from Sami Korhonen (sambas). Sambas published design of his AnyFC under Creative Commons BY-SA. So, it’s free to copy this design as long as Sambas is referenced as author, and license is not changed. The problem is that “by attribution” part is not met. Sambas is not referenced as author on BG. Still, Sami wrote that he is fine with it, as long as boards quality is good enough.
Today I have something brand new to write about. Probably the first commercially available flight controller based on STM32F7 CPU: AnyFC F7 from Banggood.
I’m once again realizing, that doing multiple things at once is not a way to work. Something like that happened to my GPS Racer project. According do original plans, week ago I was only supposed to wait for FPV camera.
Instead of that, only yesterday I finished ESC and motor assembly. But OK, it was a little trickier than I expected originally:
Right now, apart from FPV gear, FrSky receiver, GPS mount, SmartPort inverter and final assembly GPS Racer is few steps closer to being finished. With upcoming Easter, it should be functional in April. Can’t wait…
Together with version 1.4, INAV introduced asynchronous gyroscope processing. What is async gyro and why it is useful to have it, you can read here. In short worlds: data from gyroscope is read and filtered faster than PID controller updates motor and servo output.
In general, async gyro can be enabled when:
Async gyro should not be enabled when gyro and control loop frequency are the same. For example, 1kHz gyro and 1kHz control loop would give worse results than 1kHz synchronous processing. Continue reading “INAV: how to setup asynchronous gyro” »
Deep down, MPU6000 and MPU6050 are the same same hardware. They both have the same 3 axis gyroscope and the same 3 axis accelerometer. Both allows max 8kHz gyro sampling rate. From a flight controllers point of view, the only difference between them is bus that connects them to CPU. MPU6000 allows for both I2C and SPI, while MPU6050 has only I2C. That makes MPU6000 better device, but only when SPI bus is in use. I2C is too slow to handle 8kHz gyro updates.
No, MPU6500 is a different monster. It supports both I2C and SPI, allows 32kHz gyro update rate and has much wider gyro signal bandwidth. Is also smaller and consumes less energy. So, in theory, it is much better device than MPU6000. There are some problems with it. First of all, it is much more vibration sensitive than MPU6000. While soft mounting of MPU6000 is usually not needed, MPU6500 will benefit a lot from it. Very often it is even required. Second of all, at this moment, only RaceFlight can utilize 32kHz gyro update rates.
What are those two MPUs? It’s rather simple this time.
Today I've discovered another small but irritation limitation of Airbot F4 / Flip32 F4 also known as CC3D REVO for unknown reason. Looks like, by default, this board is unable to share UART1 RX line and PPM input. So, if you would like to connect, for example, OSD or GPS to UART1, you would have a problem. I've discovered that PPM input does not blocks UART1 totally, but makes UART1 transmission erratic and unreliable.
This is because PPM input pin is connected to both UART1 RX (pin PA10 of STM32F405) via inverter and PPM input pin (PB14) without inverter. Any electrical signal applied to PPM input would also be sent to UART1 RX.
Luckily, there is pretty simple, hardware, solution to allow UART1 and PPM input function simultaneously. Jumper called SBUS located near SBUS/PPM input has to be removed with soldering iron. This operation breaks the connection between PPM/SBUS input and UART1 RX.
There is a drawback of this solution too. If jumper is removed, SBUS will not work. To make SBUS works again, jumper would has to be closed again. With a blob of solder for example…
Year after year flight controllers grow stronger, faster, more powerful. Three years ago we had MultiWii running Arduino. Two years ago it was Naze32 with STM32F1. Year ago it was SPRacingF3 with SMT32F3. This year it is something with STM32F4. Is there a price is power consumption to pay? Should we start using stronger BECs? 1A? 2A or maybe 3 amps are now required? I've decided to check.
Measured current required by flight controllers I had on hand:
So, there is a price to pay in terms of power consumption. But, let's be honest here. Even increase by more than 100% when going from F1 to F4 is not putting much drain on any decent BEC. Good and solid 1A BEC should be more than enough to power most setups.