INAV: how to setup asynchronous gyro

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.

When it is worth to enable asynchronous processing

In general, async gyro can be enabled when:

  • Flight controller does not ave enough processing power to run control loop faster than 2000us (500Hz mode). This is the case for all SMT32F1 boards like Naze32, Flip32 or CC3D
  • Flight controller is powerful enough to process PID control loop faster than ESC protocol (PWM, Oneshot125, Multishot) transfer commands to ESC and servos. This is usually true in case of all STM32F4 boards
  • INAV is setup on a “racer” machine that requires the best gyro signal possible

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

Read More

MPU6000 vs MPU6050 vs MPU6500

MPU6000 and MPU6050

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.

mpu6000

MPU6500

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.

rp-mpu-6500

MPU9150 and MPU9250

What are those two MPUs? It’s rather simple this time.

  • MPU9150 is a MPU6050 with integrated AK8975 magnetometer
  • MPU9250 is a MPU6500 with integrated AK8963 magnetometer

Images: 1 2

Read More

UART1 and PPM on Airbot F4 / Flip32 F4 Flight Controllers

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.

Airbot F4 and Flip32 F4 PMM and UART1

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…

Read More

How much power flight controller consumes?

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.

flight controller power usage

Measured current required by flight controllers I had on hand:

  • Flip32+ 7DOF (special version of 10DOF without magnetometer): 44mA
  • SPRacingF3 Acro (chinese clone): 55mA
  • Airbot F4 / Flip32 F4: 93mA

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.

Read More

INAV for Airbot F4 / Flip32 F4 flight controller

INAV 1.3 has been released few hours ago, now I would like to do unofficial release of Flip32 F4 / Airbot F4 target of INAV 1.3. Target was flight tested last weekend.

Airbot F4 / Flip32 F4 reporting for navigational duty, sir!

What is inside:

  • Full 6 motors support
  • 2 motors / 4 servos support, so it can be used on airplanes
  • RSSI ADC on dedicated pin
  • Current meter ADC on dedicated pin
  • S.Bus and PPM working
  • I2C bus works, it is possible to attach external barometer and magnetometer. Tested hardware:
    • Barometeres: BMP085, BMP280 and MS5611
    • Magnetometers: HMC5883l
  • I2C is not initialized when UART3 is configured
  • GPS over UART. Supported protocols: UBLOX, NMEA and NAZA

The only think that is not working, is LED strip support. Looks like there is generic STM32F4 LED strip issue in INAV and we will be able to fix it in reasonable future.

HEX file of INAV for Airbot F4 / Flip32 F4 can be downloaded here.

Read More

INAV 1.3 has been released

I'm happy to announce new version of INAV ready do download from official repository.

What is new in INAV 1.3? Quite a few thinks. No "revolutions", more like steady progress. From most important things:

  • INAV now supports PWM, OneShot124, OneShot42 and Multishot ESC protocols and asynchronous motors and servos updates
  • Something for airplanes with a lot of servos: INAV can now supports PCA9685 PWM drivers and drive up to 16 servos plus motors! Although mixer can not yet support as many servos, this will change in future releases. I will try to write few words on this topic in a near future
  • FlySky I-Bus telemetry
  • Airplane auto arming with throttle option
  • In case of airplanes (again airplane improvement!), I-term of PID controller is constrained to about 30% of max servo throw. This prevents from servo saturation that can happen in some cases before take off
  • I2C improvements for STM32F1 and STM32F4 targets. This solves the problem of undetected BMP085, BMP180 and HMC5883L on Naze32, Flip32, OpenPilot Revolution and other boards
  • Code cleanups, including removal of unused or very rarely used flight modes like SERVO1-3, GOVERNOR, LEDMAX and CAMTRIG

All users are advised to use latest INAV Configurator and reconfigure flight modes is configuration is to be restored from files! Owners or STM32F1 boards should consult hardware support map if features they are using are still supported.

Read More

Flip32 F4 / Airbot F4 : Pinout

There is very little reliable information about Flip32 F4 / Airbot F4 on the internet, so I've decided to fix it. Today, pinout map for Flip32 F4 (Betaflight 3.0.1) and some additional notes:

Flip32 F4 Flight Controller pinout

  • Betaflight 3: use REVO target
  • UART1 is only UART with inverters, so S.BUS can be connected only here
  • S.BUS / PPM pin is connected to UART1 RX
  • To use PPM, UART1 can not be used
  • To use S.Bus, UART1 has to be used as SerialRx
  • FrSky S.Port can be used only with UART1 (inverters)
  • UART3 is shared with I2C. I2C can not be used when UART3 is enabled
  • external I2C is not tested ATM
  • Both Vbat lines are connected to onboard 1.5A voltage regulator (BEC)
  • Onboard BEC has to be powered if voltage monitoring is used
  • Onboard BEC will be disabled only if voltage supplied to ESC lines is higher than BEC output! This is a design flaw! There is no way to force usage of external BEC and still use voltage monitoring!
  • I suggest not to supply 5V to OSD from UART header but use external BEC with common ground

Read More

Hand on: Flip32 F4 Flight Controller

Yesterday I've received new flight controller for my Reptile X4R 220 quadcopter: Flip32 F4 from ReadyToFlyQuads. This is my first contact with STM32F4 based flight controller and I'm really looking forward to see if it really puts a difference comparing to F3 boards like SPRacingF3 I've been using last few months.

Some features:

  • STM32F405 CPU running at 168MHz
  • MPU6000 gyro connected via SPI interface
  • Integrated 1.5A voltage regulator
  • VCP port
  • 3 UARTs

Flip32 F4 Flight Controller

Flip32 F4 (and Airbot F4 which is exactly the same board) is supported by Betaflight, RaceFlight (that due to some GPL violations I'm boycotting) and INAV (at the moment of writing this post INAV support is not complete) and REVO target. Well, basically, this board was designed based on OpenPilot Revolution stripped from radio modem, barometer and those JST connectors (pin headers rules!). There are some differences between Revolution and Flip32 F4 in terms of hardware (voltage regulator for example) or separate LED header (which does not work).

There are two "problems" I've discovered so far:

  1. Whole board is getting very hot. Looks like it's because voltage regulator and battery monitoring are connected. You can not have one without the other even when you have BEC somewhere else
  2. STM32F4 does not have built in inverters. That means, S.Bus has to be connected to UART1, since this is the only UART with external inverter

Although I've been able to install it on Reptile X4R 220 already, I have no idea how it flies yet. Weather outside is very rainy…

Read More

PWM, OneShot125, OneShot42 and Multishot comparison

Two years ago it was simple: you wanted to connect ESC to Flight Controller or radio receiver, you were just doing it. There was only one (maybe 2) protocols that allowed to pass information to ESC. It was standard PWM protocol. And it was enough. No, with faster hardware, mini or even micro quads, this one protocol is not enough. So, we also have OneShot125, OneShot42, and Multishot. Should we care? A little.

  • Legacy ‘Analog’ PWM signal – this protocol is not used in multirotor world. It is supported only by extremely limited number of ESCs and radio receivers. 0% PWM duty cycle means ‘Stop’ and 100% PWM duty cycle means ‘Full power’. Modern UAV pilots/builders should not take about it at all. Interesting fact is that BLHeli supports it as PWM Input option that is disabled by default.
  • ‘Standard’ PWM signal – I’ve previously described this protocol here. To recall: protocol encodes requested output as a length of a pulse. Pulse length of 1ms means ‘Stop’ and pulse length of 2ms means ‘Full power’. Because of this, maximal theoretical update frequency is 500Hz (490Hz in practical applications). Signal delay in case of PWM protocol is 2ms. It means, that ESC can start to update output 2ms after flight controller started to send this information. All of that makes PWM rater slow, and using looptimes below 2000us (refresh rate 500Hz) makes no sense.
  • ‘OneShot125’ protocol – this protocol uses 8 times shorter pulses than standard PWM protocol: from 125us (stop) to 250us (full power). That means 2 things: it allows for 8 times faster PID control loop update rate (looptime 250us / 4kHz update rate). It also has 8 times shorter signal delay: only 250us instead of 2000us. Currently, OneShot125 is the minimum for mini quads. Even bigger machines will appreciate smaller delay. Supported by most flight controllers and ESC (SimonK, BLHeli, KISS, other). If both Flight Controller firmware and ESC supports OneShot125, it should be used.
  • OneShot42 is 3 times faster version of OneShot125. Max 12kHz update rate and 42us signal delay. It was developed by Flyduino as part of KISS FC and ESC ‘program’. Not widely supported yet.
  • Multishot – the fastest ESC protocol in this comparison, developed by RaceFlight, allows for 32kHz update rate. It is almost 10 times faster than OneShot125 (80 times faster than PWM). Requires both fast FC (preferably STM32F4) and fast ESC (Silabls F390 preferably). Not widely supported mainly because of limited number of ‘Multishot ready’ ESCs. And it has fancy startup melody too… man….

Read More

INAV 1.1 for Naze32 with working telemetry

As long as Naze32 / Flip32 are decent flight controllers for those who does not demand too much, they share very big flaw: low flash memory size. While even a year ago 128kB of flash was enough, times changed, and limited flash makes a problem for advanced flight controller software like INAV. Starting from INAV 1.1, STM32F1 flight controllers started to pay a penalty of disabled features. That time it was "only" telemetry providers other than LTM. Next time it might / will be more.

During last few weeks I've received few request to compile INAV 1.1 with enabled FrSky and/or SmartPort telemetry on Naze32 target. While I have nothing against doing that on request, I've decided it would be better to just prepare special version of INAV 1.1 for Naze32 users with all telemetry providers enabled. Link to ZIP file is at the bottom of this post.

  • This version has LTM, FrSky, SmartPort and HOTT telemetry enabled
  • To fit telemetry in limited flash memory, following features has been disabled:
    • OLED display support
    • DJI NAZA GPS module support

INAV 1.1 for Naze32 with telemetry enabed

Read More