Sections:
RotorFlight Tools:
iKON Tools:
Gen Tuning Tools:
|
|
|
Intro:
With the recent release of RotorFlight V2, choices in the FBL-FC (flybarless flight control) for RC Helicopters market have started to get interesting. We are coming from a scene where private companies offer a product that provided proprietary software & hardware flight control solutions but will now, however - be competing with open source flight control software residing on STM32 drone flight boards.
In the evolving landscape of microcontroller processing units (MPUs) and sensors, the continual enhancement of technology is leading to faster processors and more precise sensors, particularly in gyrometers and accelerometers. This progress is significantly impacting the capabilities of flight controllers for RC helicopters. However, detailed technical specifications for individual flybarless controllers are often limited online, likely due to concerns about software piracy and/or IP security.
Note: This article is loaded with hyperlinks (in blue underlined text). Please check out the links to help you better understand the discussion if you're not familiar with the STM32 ethos.
Audience/Intent:
This is not a guide. This is a technical spec comparison & write-up that focuses on understanding the electronic components used on flyblarless controllers. It is a collection of research and is written for advanced RC Heli pilots with a small background in electronics that tries to answer the question, "What makes this flight controller different from that one?". This article strives to introduce RC Helicopter pilots about the world of "Open Source" software and consider how it might affect or impact Flybarless Flight Control system products for RC Helicopters.
Overview of what's new
There are several factors that make a flybarless control unit perform well. Categorically: hardware and software. From a software perspective: Proprietary software vs. Open Source. Since there is no possible way to compare the software except from an end-user perspective, this article will take a closer look at the circuit components that comprise each of these flybarless controller products focusing on the "big" name brands (ie; Mikado, MSH Electronics, BeastX, etc) and comparing those with some of the latest flight control boards that are hitting the market that are sporting the latest trend in flight control software - RotorFlight:
Note that RotorFlight can be installed on a large number of STM32 boards but this article will focus on the boards that are purpose built for RC Heli flight control.
Unlike these new boards (above) which actually publish the specs of the componentry of their boards, and in order to conduct a thorough comparison of the current market's flight controllers (ie; iKON,VBar,etc), one would need to open the units to identify the specific models and manufacturers of the microcontroller units (MCUs) and inertial measurement units (IMUs) used. This process is essential for understanding the nuanced advancements in each controller's electronic components, paving the way for a more comprehensive assessment of their capabilities beyond current technological constraints.
As we try to discover and find the value of upgraded components used on modern flybarless flight controllers as well as understand the technology advances and electronic components increase in performance (through faster processing speed, higher sampling rates and achieve a higher degree of control via higher precision sensors), it's important to know some basic terms:
Terms to be familiar with:
-
MCU (Micro Controller Unit - In contrast to a CPU): The "brains" of the board.
-
ARM (Advanced RISC Machine): These are the types of processors that are usually found in flight control boards.
-
MPU (Motion Processing Unit): The "gyro" of the board.
-
IMU (Interial Measurement Unit): Another name for the "gyro" of the board.
-
FPU (Floating-Point Unit) - A hardware component integrated into some Microcontroller Units (MCUs) to handle floating-point arithmetic operations with high precision and speed.
-
STM32 (32-bit Arm Cortex MCUs)
iKON2/Brain2 - A closer look into the "Recent Past":
As with most most RC Heli flybarless flight controllers on the market, MSH Electronics does not publish the specs of the hardware of their Flybarless units. Opening one of the units, we can magnify the surface of both the MCU and the IMU to see what model they are:
As you can see we have an ARM STM32F405RGT6 MCU. By following this guide, we can deduce that this chip is a STM32 F-Type ARM Cortex M4, 64-pin, with 1024 KByte flash-memory, LQFP package that can operate in the -40degC - +85degC temp range.
|
Figure 1.1 - Bottom side of iKON's BT HD model exposing the MCU (click to enlarge)
|
Figure 1.2 - IMU of iKON's BT HD (click to enlarge)
|
Moving on to the IMU we notice the markings of the iKON2's sensor module as INVENSENSE MPU 6000. Now according to some sources on the net, this motion sensor is now considered obsolete. In fact, this MPU has been replaced by the ICM-20689. In fact, this post talks about MPU 6000 shortages and that the ICM42688P and ICM42605 sensor modules are work-arounds for such. It goes on to say that some of the primary software (Drone flight control firmware - ie; BetaFlight/iNAV) do not have support for some of the new sensor modules specs - dropping support.. wow.
|
RotorFlight: The new kid on the block
Rotorflight is the new firmware that has been developed to run on STM32 chipsets. It is based on BetaFlight 4.2 - Very popular Flight control software used for extremely high performance drones for Drone Racing. BetaFlight (along with RotorFlight, CleanFlight, iNAV, QGroundControl, etc) is OPEN SOURCE. This is huge. Imagine one, two, or maybe even three software developers at your favorite brand of flight controller versus hundreds of contributing developers that work on BetaFlight providing thousands of software updates - each.
So what's so big about "Open Source" anyways? Since the programming code (aka: Source Code) is publicly available, it means that anyone can download the code off of the internet (GitHub in this case), and if they (you) have coding skills - you can modify it to your needs. Is that really a big deal? Well yes - it is and here's a sample of why: Other than the fact that there will be multiple contributors to the code making improvements (and that they will happen at a faster pace), new features are likely to be introduced faster as well. Take a read at this particular use case I considered a while back:
Example use case:
Most modern flight-boards (beyond those used by current manufacturers) employ a barometer (primarily used for reading altitude in real-time for autonomous flight and monitoring). In the case of the boards we mentioned, they each employ the SPL06 Barometer. Imagine a use-case where we modify the code to have a "Hard Deck Mode" - In this mode, when you flip an assigned switch to activate "Hard Deck mode", the aircraft will not be allowed to fly below a set altitude (as set in the RotorFlight configurator) which would represent the lowest altitude allowed for this flight mode. When the helicopter falls below the "Hard Deck" altitude limit, it automatically invokes "Rescue Mode" (abort input, self-level, & hover for X milliseconds and hand back control) thereby disallowing the aircraft to fly below it and meet an "unscheduled landing".
RotorFlight, as with most Open Source software is designed to work on specific boards. These boards are usually STM32 based chips with a variety of sensors and allocations for input/output. For a list of these boards, please see the Rotorflight Targets Page. In summary, if you own/buy one of these STM32 flight boards, you can visit the RotorFlight GitHub and download/install the firmware onto your board.
Now as a simplification, we can state that all boards in the "RotorFlight Targets Page" could potential be compared with all current RC Heli FBL Controller manufacturer boards (iKON/Brain, V-Bar, BeastX, etc). While this is true, allow me to focus this article on boards that you can currently buy that have RotorFlight installed . This would allow me to position this article for pilots who can gauge a comparison between boards that are purpose built and all effectively have the same install/configuration process. With that said, let look at some charts that compare the various found hardware.
Flybarless Controller Processor/Sensor Specs Comparison:
So as we look at the component specs of each flight controller, let's keep in mind this not a competition but a discovery and awareness excercise. As I've written this article was made aware that the IMUs found in current "consumer available" flight controllers actually deemed, "obsolete" - yet on another hand, another article states that some firmware has no support for further advanced sensors.
Please also note that much of the "not-applicable"/"not-available" (n/a) remarks below were challenged by not having any published data or hardware available for verification (however will be updated if others might help in contributions).
|
Sensor -->
|
MCU
|
MCU Spec
|
IMU
|
Barometer
|
|
Boards supporting RotorFlight
|
|
Matek G474
|
STM32G474CE
|
170MHz Cortex-M4 , 512KB Flash
|
TDK ICM-42688-P
|
SPL06
|
|
FlyDragon F722V2
|
STM32F722RET6
|
ARM® Cortex®-M7 STM32F7 Microcontroller IC 32-Bit Single-Core 216MHz 512KB (512K x 8) FLASH 64-LQFP (10x10)
|
BMI270
|
SPL06
|
|
FlyWing HELI 405
|
STM32F405RGT6
|
ARM® Cortex®-M4 STM32F4 Microcontroller IC 32-Bit Single-Core 168MHz 1MB (1M x 8) FLASH 64-LQFP (10x10)
|
TDK ICM-42688
|
SPL06
|
|
FlyEagle RF2 (F722)
|
STM32F722RET6
|
ARM® Cortex®-M7 STM32F7 Microcontroller IC 32-Bit Single-Core 216MHz 512KB (512K x 8) FLASH 64-LQFP (10x10)
|
TDK ICM-42688
|
BMP280
|
|
RadioMaster Nexus
|
STM32F722RET6
|
ARM® Cortex®-M7 STM32F7 Microcontroller IC 32-Bit Single-Core 216MHz 512KB (512K x 8) FLASH 64-LQFP (10x10)
|
TDK ICM-42688
|
SPL06
|
|
Boards NOT supporting RotorFlight
|
|
BeastX/AR7XXX
|
n/a
|
32-bit ARM Cortex M4 microcontroller, 17 Bit analog processing
|
Remarked as, "6 axis MEMS (Gyro + Accelerometer)" (likely: MPU-6050 MPU-6500 ICM-42688-P or ICM-42670-P)
|
n/a
|
|
Mini VBar
|
n/a
|
n/a
|
ISZ500
|
n/a
|
|
VBar Neo
|
STM32F405 family
|
ARM Cortex-M4, 128 KB RAM 168MHz
|
n/a
|
n/a
|
|
VBar Evo
|
n/a
|
500MHz
|
n/a
|
n/a
|
|
Skokum S540
|
n/a
|
32-bit ARM (likely Cortex M4)
|
ITG3200
|
n/a
|
|
iKON2/Brain2
|
STM32F405RGT6
|
Cortex M4 with FPU and 1MB Flash, 168MHz speed
|
MPU-6000
|
n/a
|
IMU Relative Comparison:
As previously noted, the MPU6000 has been discontinued and is considered obsolete. It was also noted that the ICM42688P and ICM42605 have been optional hardware to use. Although the hidden agenda of this article is to consider if the updated components offer better performance, I bring forward a citation from an engineer with some insight:
By Atomic Skull (02-13-2023):
There really isn't that much difference between gyros assuming the FC is properly designed. The ICM gyros require a very clean power supply compared to the MPU 6000 and BMI270. The only real difference is noise resistance and the BMI270 seems to lead the pack slightly edging out the MPU6000. Rotorflight supports all 4 of them so it's not locked into any specific gyro.
BMI270 runs at 3.2khz vs 8khz for the MPU6000 and ICM gyros, however unless you have an H7 processor you have to run the PID at half the gyro rate on the 8khz gyros with F4 and F7 based FCs, and nothing on a helicopter is happening fast enough to warrant even 4khz, I've run the PID at 1khz to see what happens and noticed no difference.
Nonetheless, here is the output from ChatGPT when asked to compare most of the mentioned gyro sensors in this article:
| Feature |
MPU6000 |
ICM-20689 |
BMI270 |
ICM42688-P |
| Gyroscope Performance |
Good |
Good |
Good |
Excellent |
| Accelerometer Performance |
Good |
Good |
Good |
Excellent |
| Resolution |
Comparable |
Comparable |
Improved (Varies) |
Improved |
| Sampling Rate |
Competitive |
Competitive |
Higher (Varies) |
High |
| Temperature Stability |
Stable |
Stable |
Improved (Varies) |
Improved |
| Noise Level |
Acceptable |
Acceptable |
Reduced (Varies) |
Low |
| Power Consumption |
Standard |
Standard |
Optimized (Varies) |
Optimized |
| Advanced Features |
Standard |
Standard |
Advanced (Varies) |
Advanced |
| Integration Complexity |
Established |
Established |
Varies |
Established |
Comparing the Cortex M4 to the Cortex M7:
Moving on to the MCU, we see the common use of the ARM Cortex processor cores. These are cheaper and energy efficient ICs and are the appropriate device for these microcontrollers that control movement.
Now frankly, the ability to understand coding differences that either or both differentiate or take advantage of an M7 Cortex versus an M4 Cortex are beyond my understanding but suffice it to say that a processor's ability gauges mostly on it's ability to process instructions and math and is apparent when reviewing core differences between the M4 & M7. Other notable differences are speed, FPU (Floating Point Unit), Cache, Memory Spaces (Larger on M7), Pipeline Architecture, and DSP - all of which can be detailed in the ARM Cortex Wiki.
With that, here are a couple charts that can help you understand more about these processors:
| Feature |
Cortex M4 |
Cortex M7 |
| Processor Core |
ARM Cortex-M4 |
ARM Cortex-M7 |
| Architecture |
ARMv7E-M |
ARMv7E-M |
| Pipeline Depth |
3 stages |
6 stages |
| Floating Point Unit |
Optional (single precision) |
Optional (single and double precision) |
| Performance |
Generally lower than M7 |
Higher performance than M4 |
| Clock Speed |
Typically lower clock speeds |
Higher clock speeds (often dual-core) |
| Cache |
Typically no cache |
Integrated cache (L1 and L2) |
| DSP Instructions |
Limited |
Advanced DSP instructions |
| Memory Access |
32-bit address bus |
32-bit or 64-bit address bus |
| Use Cases |
Embedded systems, IoT |
Embedded systems, IoT, Automotive, Industrial Control |
Cortex M4 to M7 Performance Comparisons (via ChatGPT):
Conclusions:
We have arrived at an exciting time for flight controller development. Many people might not realize the impact of the new boards/firmware will have on this sub-industry. I feel we - as a whole - will slowly realize the advantages of using the open-source version of this technology to our benefit and that this will not be a "swooping" event that will destroy the manufacturers creating the current flight boards today but rather expect a small to moderate market share moving towards the open-source versions and the current consumer brands to heed impact.
There are a few features however that will take larger notice that the new boards can offer and so here are some pros and cons to that affect:
|
|
Current Manuf (MSH,Mikado,etc) |
RotorFlight |
|
PID Ctl
|
Yes (iKON/VBar/Beastx etc)
|
Yes
|
|
Wizard
|
Yes (iKON/VBar/Beastx etc)
|
No
|
|
Logging
|
Yes (iKON)
|
Yes (Blackbox)
|
|
Rescue
|
Yes (iKON/VBar[PAID]/BeastX[PAID])
|
Yes
|
|
Altitude
|
No
|
Yes
|
|
GPS
|
No
|
Yes
|
|
Banks/Profiles
|
Yes(iKON/VBar)
|
Yes(CLI Profile)
|
|
Governor
|
Yes
|
Yes
|
|
Motor Tail
|
No
|
Yes
|
|
Telemetry
|
Yes
|
ESC Telemetry
|
|
Vibration Analyzer
|
Yes
|
Yes
|
|
LED Control
|
No
|
Yes (WS2811/WS2812)
|
|
Backup/Restore
|
Yes (iKON)
|
Yes
|
|
LUA Scripts
|
No
|
Yes
|
|
ELRS
|
No
|
Yes
|
|
Feature
|
No
|
No
|
It has been noted on some boards that the difference in sensors is minimal to "microscopic". While this may be true, I bring forward the question of gathering the opinions of those who operate the equipment at exceptional skill levels who may notice these differences and less so at the beginner or intermediate level (not intended to negatively stain the reputation of the author or his abilities). I also would consider that in moving forward, these sensors will develop into more accuracy with higher precision and higher sampling rates and to what degree all of it would add to the flight quality of the aircraft (from a high peformance perspective).
STM32 board management is technical but not terribly difficult to understand. I would note that this particular topic is more familiar to those who are RC Heli pilots that have delved into the world of drones and in particular for those that have actually built a drone from scratch (this is where exposure to the boards, firmware, command line iputs, I/O re-mapping, etc become prominent). This group I could see as "more accepting" to RotorFlight and all of it's advantages.
In parting I would only add that we as model aircraft pilots are in fact involved in a very highly technical activity. We should therefor, as most technologist do - be accepting of new technologies. RotorFlight is no different and although one can choose to remain "old school" and not adapt to the advancement of technology, others will.. and those who don't, will be left in the dark about new things to come.
References:
Major Discussion threads
RotorFlight Resource Links
RotorFlight Configurator Related Videos
Additional/Related Links
Flight Sample Videos:
|
|
