“Let’s do the news….” and INAV 1.7.2 has been released yesterday. Besides new targets (MATEKF405, Alienflight F7, SP Racing F3 NEO) there are few quite important changes:
- ADC channel to function mapping is now configurable. Any ADC using function (battery voltage, current, RSSI) can be assigned to any ADC pin. You smoked Current pin? No problem, now you can use RSSI for that. It can be done using
airspeed_adc_channel CLI commands
- Support for analog pitot tubes, based on MPXV7002DP, known as APM Airspeed Sensor. It requires some hacking, but is pretty simple. I will publish detailed instructions in a next few days
- Servo handling improvements:
- servo min and max now do what they are supposed to be doing: output is scaled to reach them on max/min input, not just clip. And that means, that aileron differential is not super simple to archive
- servo rule speed is now defined as
1 speed = 10 us/s. So,
speed 100 means that full servo sweep will be done in 1 second.
speed 50 means full servo sweep in 2 seconds and so on
smix min and max parameters were removed
- Support for eLeReS receivers built into KFC flight controllers
- Total flight statistics via
stats_total_dist CLI commands
- AnyFC F7 improvements:
- buzzer on output #9
- SD card detection is now configurable via
- support for external barometers using ANYFCF7_EXTERNAL_BARO target
- Fixed wing landing after RTH that I already described here
Full list of changes is available here.
One of the things that INAV was missing, was a decent support for Pitot tubes, or more generally speaking, airspeed sensors. Autonomous flight, or landing, without knowledge about airspeed can easily lead to a stall. Stall can lead to crash. A crash leads to rebuild. Rebuild of big airplane is a nightmare. Although, for some time now INAV was able to use digital PX4 Airspeed Sensors (I2C, based on MS4525), but they are quite expensive and airspeed was only reported in blackbox logs. Not very useful, right?
Now, this is changing. Next release of INAV (1.8 probably) will bring at least support for much cheaper, analog, APM Airspeed Sensor based on MPXV7002 chip. Although some simple additional electronics (2 resistors to be precise) will be required, but this pitot tube should be available for all flight controllers with free ADC input (Current or RSSI). Fancy ADC remapping will allow to use any ADC without built in dividers (Vbat has dividers so can not be used) as pitot input.
More than that, INAV 1.8 will (or at least should) bring PID scaling according to airspeed for fixed wings. This should result in better handling on both low and high speed.
As you can see on the picture above, APM Airspeed Sensor is already installed on my small flying wing and is waiting for first flight tests this weekend. Logging only for now…
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
- and more…
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).
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:
- Cleanflight lost all it’s uniqueness and is Betaflight under different name
- Pilots that were using Cleanflight on airplanes or big multirotors are left alone. Betaflight aims on mini-quads, not airplanes!
- 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…
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!
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
- 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 (
- 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
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_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
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.
- 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…
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.
- 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
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
- 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!