BLHeli_32, should I care?

Looks like BLHeli team is not wasting their time and is preparing something new for our multirotors. After BLHeli_S, we will also have BLHeli_32.

According to an announcement posted on RCGroups, new software for ESCs (and new ESC of course, since it will not be compatible with current Atmel and SiLabs MCU) will be:

  • Running 32-bit MCU, Cortex-M0 at 48MHz (STM32F0 ??). Which, in my opinion, is a very logical step to take. Please remember, that all SiLabs (Silicon Labs) MCU powering most of our ESC, are under the hood old Intels 8051. And please remember that Intel 8051 was created in 1980. 37 years ago…
  • There are few places where additional computational performance can be spent. For example:
    • Programmable PWM frequency up to 48kHz
    • Auto timing for better efficiency
    • Programmable brake on stop power, very useful for folding propellers
    • Voltage and current limiting
    • DShot1200
    • and more…

Airbot Wraith32 Plus

ESCs with BLHeli_32 are not available yet, but Airbot already announced Wraith32 Plus (with voltage and current limiting) and Wraith32 Mini (without voltage and current limiting).

Read More

Cleanflight is dead…

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.

It was announced on Facebook:

Cleanflight v2.0.0-RC1 is out now, with all the new features from Betaflight v3.1 – please share this post!

Thanks to the hard-working betaflight developers especially Boris B, Jason Blackman and Martin Budden who have been doing fantastic work for us all!

Also, all GitHub Issues and Pull Requests were deleted.

What does that means? More less the following:

  1. Cleanflight lost all it’s uniqueness and is Betaflight under different name
  2. Pilots that were using Cleanflight on airplanes or big multirotors are left alone. Betaflight aims on mini-quads, not airplanes!
  3. Why anyone would want to use CF when BF is there and this moment it offers better community support?

The way I see it, it was a nice ride, but now it is over and Cleanflight is dead. Too bad, since it had a huge impact on multirotor community over last few year…

Read More

Mechanical Bat: Bat Bot B2

Nature gave ability to fly to birds, insects and some mammals quite some time ago. We, as a species, learned how to fly only very recently. And let's be honest here. We are not very good at it. We need machines to fly. Any our machines are not very efficient at that task. They require huge amounts of energy to do it, need maintenance and make a lot of noise. Look at birds and bats. They fly for longer using less energy. And they do it with grace.

This is project that caught my attention only today: mechanical bat from University of Illinois called Bat Bot B2.

Bat Bot, from Caltech von PopSci

Take a look at that video. Maybe it's not stable or capable of longer flights yet, but I'm really, really impressed. One day I would really like to have an UAV like that!

Via Hackaday

Read More

What’s new in INAV 1.4

Although INAV 1.4 was not released yet, it’s going to happen very soon. When? Probably in the beginning of a next week. Release Candidate is already available and until now, there are no major bugs discovered.

So, what’s new in INAV 1.4? Quite a few…

  • IMPORTANT: by default, motor output is disabled after flashing. This is to prevent servos from being damaged with too fast PWM rate. User has to enable motor output using Configurator (version 1.4 or newer) or with CLI command feature PWM_OUTPUT_ENABLE
  • Asynchronous gyroscope processing. I’ve described some time ago why this is good idea to have something like this. With 1.4, asynchronous gyroscope is available, but not enabled by default yet. I will try to write a longer article how to set it up later (I hope at least I will find time for it). Until then, this entry in INAV docs is all that has been written on the topic
  • Airplane launch assistant. Launching an airplane with INAV is almost as easy as it can be! You can read documentation on this feature on INAV Wiki
  • Improved throttle PID attenuation (or rather PID scaling) for airplanes. Read documentation on the topic
  • Emergency landing for airplanes
  • Experimental Pitot tube support (logging only) compatible with Pixhawk PX4 Airspeed Sensor
  • Improved handling for GPS+MAG and GPS+BARO configurations. With INAV 1.4 it should be not required to disable MAG and BARO when GPS is used
  • Improved failsafe
  • New targets: Airbot F4 / Flip32 F4, Omnibus F4 and YuPiF4
  • Multiple bugs fixed

Additionally, new version of INAV Configurator has been already released. All users are advised to update! With Configurator 1.4.1 and firmware 1.4 following new features will be available:

  • Possibility to enable motor output
  • Gyroscope hardware filtering (gyro_lpf) and syncing PID loop with gyroscope (gyro_sync) setup
  • Advanced PID tuning now allows to set:
    • Gyroscope software LPF cutoff frequency
    • Accelerometer software LPF cutoff frequency
    • D-term cutoff frequency
    • Yaw P-term cutoff frequency
    • MAG_HOLD yaw rate limit
    • Axis acceleration limits
    • Yaw P limit and yaw jump prevention limit
    • I-term ignore rates

Read More

INAV 1.2 RC1 has been released

After 3 month from previous release, INAV is preparing for a new version. INAV 1.2 will be quite massive, with a lot of new features and improvements. Full change list is available here. I will only describe the most important and “visible” changes.

  • Rates are no longer stored in arbitrary units like 0.4. Who knows what 0.4 means? How fast UAV should rotate when this rate is set? Is 0.8 twice as fast as 0.4? (The answer to that question is “No”) To solve this problem, INAV uses degrees per second [dps] to define maximum rotation speeds. INAV Configurator provides nice and simple user interface for that. The ones who uses CLI has to remember, that INAV stores rates in dps divided by 10. So, set roll_rate=72 means that roll rate equals 720dps. GitHub INAV Wiki has a page that describes how to convert INAV 1.1 rates to new system. Also, RC Rate setting, as obsolete, has been removed.
  • FP-PID has been rescaled to match LuxFloat and MWRewrite PID controllers. That means, if you have tuned drone in either Cleanflight or Betaflight, you can just use the same PID settings in INAV now, without a need to retune. That also means, that tunes from INAV 1.1 will not work in 1.2. This page or this Google Docs Spreadsheet can be used to convert INAV 1.1 PID to INAV 1.2
  • Just like latest Betaflight 3.0, INAV 1.2 has a feature that allows to limit angular acceleration. This might be very useful when tuning big and heavy frames with a lot of inertia. They are just not capable of angular acceleration that operator might require from them even with stick movements. If frame oscillates/shakes during stops, that means that it is unable to satisfy required acceleration/deceleration, Iterm winds up and as a result, frame overshoots target only to try to correct that fractions of a second later. To get rid of that effect rate_accel_limit_roll_pitch and rate_accel_limit_yaw CLI variables can be used. They represent maximum angular acceleration/deceleration in degress-per-second^2 [dps2] UAV operator can request. By default it is disabled for roll and pitch and set to 10000dps2 for yaw.
  • Improved MAGHOLD controller that results in much smoother yaw movements in RTH and WAYPOINT flight modes. New mag_hold_rate_limit setting limits yaw rotation rate MAGHOLD controller can request. Default of 90dps is enough for agile UAVs. For slow, cinematic, turns, value of 25dps generates good results. I already described this improvement here
  • Flaperon flight mode. Available only on fixed wing (not on flying wing) platforms. When enabled, both ailerons will be deployed down to act as flaps. Flaperon behavior is driven by 2 CLI variables:
    • flaperon_throw_offset determines how far ailerons will be deployed
    • flaperon_throw_inverted allows to invert aileron throw in Flaperon mode. Can be used to create spoilerons instead of flaperons
  • Greatly improved GPS performance
  • Maximum climb/descend rate in WAYPOINT mission flight mode is now limited by nav_max_climb_rate setting (in centimeters per second)
  • More precise expo curve resulting in smoother UAV behavior near sticks center positions
  • Greatly improved landing detection mechanism that can effectiveness detect landing and disarm motors in RTH mode
  • Just like Betaflight, INAV saves configuration (PIDs, rates, etc.) with Blackbox logs. Both Betaflight and INAV blackbox viewers can be used to get config from logs. Great for tuning, since log contains both flight data and configuration used to obtain this data
  • Turn assistant flight mode – when enabled, yaw movement will be done in parallel to ground plane, not UAV plane
  • Full stick range is now used in ANGLE and HORIZON flight modes
  • More data reported via LTM protocol
  • Initial MAVLink support. It is far from completed, but MAVLink enabled ground stations should be able to receive telemetry from INAV.
  • Support for nRF24L01 transceivers. Fly Naze32 with Syma radio? Now it will be doable
  • Multiple bugfixes and other improvements

Read More

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

iNavFlight 1.1 has been released

Few hours ago official release of iNav 1.1 has been published. Comparing to few month old version 1.0, there were many changes, including few very very important. In my personal order of importance they are:

  • Default settings for Position Hold and Return To Home has been retuned, so they behave almost perfectly. Take a look at videos I’ve been posting here from time to time. Outstanding performance on defaults!
  • There is only one PID controller now. It’s is called FP-PID and I already wrote few words about it here
  • GPS signal handling has been greatly improved. Both number of satellites and well as HDOP should be rock stable now. Previous versions had a tendency to loose signal from time to time
  • Fixed Wind airplanes support
  • Waypoints
  • Surface Following mode using Sonar.
  • Single page OLED Display showing useful data instead of many screens showing all available data
  • HeadingLock mode that helps UAV to keep desired heading even with external forces and applied. It does not require magnetometer! I will try to write few words on this topic soon
  • New 4-way BLHeli passthough interface
  • Cleanflight Configurator reports HDOP fix quality instead of number of satellites now
  • GCS NAV Follow me mode to be used together with EZ-GUI
  • Many, internal changes and small features that makes iNav experience really incredible!

Happy flying everyone!

Read More

Drone vs. passenger airplane

Let’s be honest here: some drone pilots are stupid and fly very close to airfields. Big commercial airfields with tons of passenger traffic. Why? Ignorance, lack of knowledge, craziness, lack of imagination or just plain stupidity. On the other hand, commercial airplane pilots see drones everywhere. Few weeks ago grand hysteria: drone hit a plane at Heathrow. Who did it? Why? Laws should be more restrictive! Two days later: do, drone did not hit anything. So, what pilot reported? Probably it was white plastic bag. Eh…

The main problem with drones and commercial air traffic is that nobody know what would happen if for example DJI Phantom would hit Boeing 747. We more less know what happens when a goose hits one. It happens quite often. We also know when happens when a turtle hit and airplane on runway. Yes, it happens too. Hey, we even knows what happens when frozen chicken hits windshield. But drone? “Keine Ahnung” like Germans would say.

Now there is chance our knowledge on that topic would improve. EASA, European Aviation Safety Agency, decided to create a task force that will investigate potential results of drone-airplane collision. It will:

  • investigate incidents
  • analyze existing research
  • investigate weak points of airplanes: windshields, wings, engines in context of UAV collision
  • consider the possibility to do further research and perform actual tests

First results should be available at the end of July.

Read More