Hands-On Evaluation
Over the past year, Raul has written several articles about drone design. Here, he offers a product review of CUAV Tech’s V5 Plus drone flight controller and its associated NEO V2 GNSS module. Raul dives into specifications and functions of these devices in great detail, then shares the results of some flight tests using the products.
This is a product review article for the V5 Plus drone flight controller and the NEO V2 Global Navigation Satellite System (GNSS) module—both manufactured and distributed by CUAV Tech. The V5 Plus flight controller is promoted by its manufacturer as an advanced drone flight controller aimed at academic research and commercial applications. It is based on the Pixhawk FMUv5 open hardware design standard, and is modular, consisting of a core plus a separate carrier board. It is compatible with PX4 and ArduPilot firmware, supporting a number of vehicle types and configurations. The accompanying NEO V2 GNSS module can concurrently process signals from GPS, Galileo, GLONASS and BeiDou global satellite positioning systems, and includes a digital compass.
In this review, I begin by describing the flight controller and GNSS module’s specifications and functionality in detail. Next, I discuss some introductory concepts about Hardware-in-the-Loop (HITL) simulation, to put in context some HITL tests I carried out with the V5 Plus. I also discuss flight log analysis review as a tool to assess aircraft performance. Finally, I discuss the results of some field flight tests I made with the V5 Plus and the NEO V2 GNSS module, both installed in a test quadrotor.
I received the V5 Plus flight controller and the NEO V2 GNSS module from CUAV Tech for free, to test and evaluate. This review reflects my personal experiences and opinions about these products, in the context of the type of drone applications I normally do as part of my day job: advising undergraduate college students with drone autonomous flight projects.
TECHNICAL SPECIFICATIONS
CUAV Tech is a Chinese company working since 2012 in research and development, production and sales of unmanned autonomous vehicle (UAV) applications and system modules, such as flight controllers, digital radio link systems and global positioning devices. One of their most recent products is the V5 Plus flight controller, designed in collaboration with the PX4 autopilot team. CUAV Tech is a “silver member” of Dronecode—the non-profit organization governed by the Linux Foundation that oversees the development of four open-source projects in the PX4 ecosystem: PX4 autopilot, MAVLink, MAVSDK and QGroundControl.
The V5 Plus is based on the Pixhawk FMUv5 (Flight Management Unit v5) open hardware design standard, and uses Pixhawk standard pinouts to interface with external devices. It comes out of the box pre-installed with PX4 firmware, but is also compatible with ArduPilot firmware. Figure 1 shows the V5 Plus core module (in silver) attached to its carrier board (in black). The detachable core contains the flight controller’s main hardware components (microcontrollers (MCUs) and onboard sensors), and the separate carrier board contains the interfacing connectors to external devices.
That modularity gives you the choice of either using the core with one of the of-the-shelf carrier boards from CUAV Tech, or designing a custom one. CUAV Tech made available an open carrier board reference design that can be used as a starting point to design a custom one. The main processor in the core module is the STMicroelectronics STM32F765 MCU that runs at 216MHz and contains 2MB of flash memory and 512KB of RAM. This improves computation power in comparison with previous flight controllers, such as the Pixhawk V3x, also made by CUAV Tech.
— ADVERTISMENT—
—Advertise Here—
The core module implements multi-sensor redundancy by combining five sets of sensors. It has two TDK InvenSense integrated circuits—the ICM-20689 and the ICM-20602—each of which contain both a 3D accelerometer and a 3D gyroscope. Additionally, it has a Bosch Sensortec BM1055, which also contains a 3D accelerometer and 3D gyroscope. An iSentek Technology IST8310 3D compass and a MEAS Switzerland MS5611 atmospheric pressure sensor (altimeter) complete the set of onboard sensors (the MS5611 is sold by TE Connectivity). The flight controller reads the multi-channel sensor data in real time, and switches to a redundant sensor whenever there’s a failure in the previous one, thus improving safety and reliability.
Figure 2 summarizes the hardware specifications for the V5 Plus flight controller. Additional key characteristics worth mentioning are: a secondary input/output processor (the STMicroelectronics STM32F100 MCU); two battery monitoring systems; support for high-accuracy, centimeter-level, Real-Time-Kinematic (RTK) positioning, with the use of corresponding modules and support for LTE telemetry and video links—which provide a much wider coverage area than conventional ones.
The core module has a built-in damping system that separates the sensors from the main board and provides high-performance shock absorption. This reduces signal noise in the sensors due to mechanical vibration, making unnecessary the use of external anti-vibration systems (Figure 3). The V5 Plus fully adheres to the PX4 official standard, to ensure compatibility and interoperability with other hardware and software products in the PX4 ecosystem. Available V5 Plus carrier boards are also fully compatible with the new X7 flight controller cores announced by CUAV Tech in May, 2020.
The NEO V2 GNSS module has a U-blox M8N, 72-channel GNSS receiver and an iSentek IST8310 digital compass (Figure 4). The M8N sub-module is a dual-mode parallel GNSS receiver than can concurrently process signals from GPS/Galileo and GLONASS or GPS/Galileo and BeiDou global satellite positioning systems. This feature ensures much better positioning accuracy in urban canyons or any environment with weak GNSS signal reception. It has an update rate of 10Hz (maximum), a cold start acquisition time of 26 seconds and a hot start acquisition time of 1.5 seconds.
The NEO V2 module incorporates a safety switch, a buzzer and RGB status lights, otherwise separately added to the drone. I received from CUAV Tech a kit containing the V5 Plus core and standard carrier board, the NEO V2 module, an HV_PM power module, a PW-Link Wi-Fi telemetry module, an I2C expansion board, a USB to UART converter and some additional accessories.
HITL SIMULATION
Hardware-in-the-Loop (HITL or HIL) is a simulation mode in which a real hardware flight controller runs regular PX4 firmware to control a computer modeled vehicle inside a simulated environment. In contrast, Software-in-the-Loop simulation (SITL) is the mode in which the PX4 flight stack is run typically on the same computer on which both the modeled vehicle and virtual world are running. The benefit of HITL over SITL simulation is that HITL allows testing most of the actual PX4 autopilot flight code on the real hardware. PX4 supports HITL simulation for multi-rotor drones with jMAVSim and Gazebo simulators.
SITL and HITL simulation are great tools, not just for development, but also for teaching and learning. For instance, they are useful for autonomous drone application development. You can write, test and debug your autonomous flight code right in front of your development computer, without needing to go outside with a real drone until it is absolutely necessary. This is particularly helpful when you integrate other technologies—such as computer vision and cloud data connections—to your drone application, and you need to do indoor tests simultaneously with your autonomous flight code.
I tested the V5 Plus in HITL simulation by running some MAVSDK-Python autonomous flight code examples I had on hand. For example, it ran well with the write_my_initials.py program example from my previous article “Writing MAVSDK/PX4 Drone Applications” (Circuit Cellar 361, August 2020) [1]. Figure 5 shows a screen capture of the HITL simulation running. As I sometimes do with new drone builds, I also made a couple of HITL tests flying the simulated drone with the real radio control system connected to the hardware flight controller, and it worked well.
In my previous article [1], I discussed the installation procedure of the PX4 SITL simulation environment for developing autonomous flight applications with the MAVSDK-Python library. The same environment works for HITL simulation. If you are interested in autonomous flight application development, check that article for a quick introduction to the subject. Once you have the simulation environment correctly installed, the procedure for running an HITL simulation is as easy as for SITL when using the jMAVSim simulator.
— ADVERTISMENT—
—Advertise Here—
It is somewhat more involved for HITL with the Gazebo simulator. For HITL simulation to work, you typically connect the flight controller with the USB cable to the computer running the simulation, so the flight controller can connect to the virtual environment. You can use a stand-alone flight controller with nothing else connected to it, or one in a finished drone build. The file run_hitl_simulation.md included in this article’s materials details the steps for running HITL with both jMAVSim and Gazebo. The file is available via a link in RESOURCES at the end of this article or via download from Circuit Cellar’s article code and files page. If you’ve tried SITL before, running HITL is almost the same.
FLIGHT LOG ANALYSIS
Pixhawk flight controllers store flight logs on a Micro SD card. These flight logs can be later analyzed to assess the drone’s performance and help debug issues. The flight logs are stored in ULog format and contain data from sensors, actuators, control algorithms, the radio control system, power system, processor and memory and the data logging system itself. Some examples of data stored in log files are: altitude, roll/pitch/yaw angles and angular rate, local position (X, Y, Z) and velocity, manual radio control inputs, actuator control and outputs, raw acceleration, angular speed and magnetic field strength, vibration level, GNSS uncertainty, noise and jamming, thrust and magnetic field (for correlation), power system, health report (estimator watchdog), RC quality, CPU and RAM, sampling regularity of sensor data and logged messages (warnings, errors).
When a flight goes wrong, log analysis is a great tool that can potentially help us find issues in the aircraft build quality, as well as hardware failures, flight controller wrong parameter configuration or even issues with our piloting skills. But even if nothing goes wrong and your aircraft flies well, log analysis can help you assess how well your aircraft is performing.
Figure 6 shows plot examples of data logged by a Pixhawk flight controller. Of the many tools for log analysis, one of the most commonly used is Flight Review. This is a free online tool available on the cloud that doesn’t need local installation and makes it easy to analyze flight logs and share the results over the web. You just need to go to the cloud application web address (https://review.px4.io), upload your flight log, analyze the data and, if you want, share the link with others. Flight logs are also handy when asking for help in the official PX4 support channels. Other flight log analysis applications include pyulog, pyFlightAnalysis, FlightPlot, PX4Tools, MAVGCL and PlotJuggler [2].
Understanding flight log plots isn’t difficult, if you have basic knowledge of how a drone works and what roles are played by sensors and actuators in the system, along with a basic understanding of the main control algorithms involved, such as PID. But even if you know how to interpret the data graphs, it will take a while until you understand what values are acceptable in each case, and which plots are better to look at when dealing with specific problems, such as frame mechanical vibration. The PX4 site has good introductory information on how to analyze flight log plots and identify common problems. In RESOURCES below, I’ve provided links to PX4’s website pages containing more detailed information about flight reporting and flight log analysis.
FIELD FLIGHT TESTS
Figure 7 shows the quadrotor drone I used with the V5 Plus for my flight tests in the field. It has the following hardware:
• An S500 frame
• Generic 2212/920KV brushless motors
• DYS 30A 2-5S Electronic Speed Controllers (ESCs)
• DJI 9450 and Gemfan 1045 propellers
• A generic 5,000mA-hours, 3S, 30C Lithium Polymer (LiPo) battery
• A FlySky FS-I6S radio control transmitter paired to a FS-IA10B 10-channel receiver
• A PW-Link Wi-Fi telemetry module
• The V5 Plus flight controller with the NEO V2 GNSS module
I also made a couple of flights with another quadrotor with the same type of hardware, except for a DJI F450 frame.
For my first flight tests with the V5 Plus, I used the HV_PM (High-Voltage Power Module) that was included in the kit I received from CUAV Tech. This power module supports 3S-14S batteries and voltages between 10-60V. However, from the very beginning I had an interesting issue with this power module. After take-off of the quadrotor, the “low-battery” warning was being triggered in QGroundControl less than a minute into flight, even though the batteries were fully charged.
Looking at QGroundControl’s GUI, I noticed the “battery voltage” indicator was dropping from 12.6V to 10V in just 3-4 seconds, and the “remaining-battery” indicator fell from 90% to 10% in just 8-10 seconds, making QGroundControl emit audible “low-battery” warnings. I tested the quadrotor with three different batteries, which I knew were fine because I had used them previously with other quadrotors of similar configuration without any issues—and got the same results. Additionally, I had an external LiPo battery alarm connected, which never got triggered by the apparent low-voltage condition. I was flying with PX4 firmware, but I also changed to ArduPilot to check if the issue was specific to PX4. I got the same instant “low-battery” warnings with ArduPilot as well.
USER GROUP HELP
The CUAV Tech user group channel at PX4’s Slack workspace helped greatly to determine the cause of the issue. The first hint I was given was that perhaps the power cable connecting the battery to the power module was too long. And it was—around 15cm in length—because of an adapter I was using to connect my T-connector batteries to the XT60 connector in the HV_PM power module. From my own flight logs, it also was brought to my attention that apparently, the power cable length was causing a considerable voltage drop, which in turn was causing more current to be sourced from the battery.
Referring to the gray curve in Figure 8, you’ll notice that the current sourced when the quadrotor is hovering is around 22A on average—with a peak as high as 52A! And the measured battery voltage (the dark-blue curve) drops from 12V to 10V almost instantly. Of course, in reality, the battery wasn’t getting discharged that fast, otherwise my external LiPo alarm would have been triggered as well. It was just that, for some reason, the flight controller was apparently getting erroneous readings from the current and voltage sensors in the power module.
I got rid of the adapter cable and did a flight test again. The flight time improved to around 4-6 minutes, before the warning signal sounded again. It then appeared that the cause for the early warnings was that the voltage and current sensors in the HV_PM power module were not working well with the 3S batteries. I was also told that, apparently for a 3S LiPo battery, a current of around 15A was normally expected for the kind of quadrotor configuration I had, instead of the 22A I was getting in the flight logs. From past logs from other similar quadrotors, I found that currents between 13A to 15A were typical.
It was suggested that I try using a LiPo battery with more cells, so I did tests with 4S batteries; the drone flew well but with a bit of oscillation. Perhaps it would have been fixed by tweaking the default PID calibration, but I didn’t go that route. I always tend to use 3S batteries with quadrotors of this size and configuration, anyway.
Instead, I replaced the HV_PM power module with a regular 2S-8S Pixhawk 1 power module, and the flight time increased easily up to 8-10 minutes with the default battery configuration in the flight controller. This default configuration causes the flight controller to do conservative estimates of the remaining battery power and available flight time. So, after tweaking these battery parameters a bit, the flight time rose a little more.
— ADVERTISMENT—
—Advertise Here—
In retrospect, perhaps the HV_PM module could work well with higher-voltage batteries, but I didn’t test it with more than 4S ones. I had never previously encountered any issue like this before, and it took me some days to understand what was happening. As you know, failure is a master that treats roughly but teaches well. Figure 9 shows the quadrotor during a flight test.
CAN PDB CARRIER BOARD
Figure 10 shows an optional carrier board for the V5 Plus core, also made by CUAV Tech. The CAN PDB carrier board is a combination of a baseboard for connecting external devices, a Power Distribution Board (PDB) and a Power Management Unit (PMU). The PMU part of the CAN PDB has a Universal Battery Elimination Circuit or UBEC (which is really just a voltage regulator) based on an Analog Devices LT8645S 65V, 8A step-down regulator that provides a 5V, 8A output, and a Texas Instruments TPS54561 60V, 5A step-down regulator that provides a 12V, 4A output. Both outputs are convenient to power external devices, such as off-board sensors and actuators, cameras, wireless transceivers and companion computers. Because of their specifications, they are even more convenient for external devices that consume relatively higher power.
The PMU has its own dedicated MCU, a 100MHz STMicroelectronics STM32F412 running CUAV Tech’s Impedance Temperature Tracking (ITT) algorithm. According to the manufacturer, it accurately measures voltage and current in real time, and uses CAN bus communication and the UAV CAN protocol to send power consumption data to the core.
The manufacturer says its ITT algorithm corrects measurement errors caused by impedance changes at different operating temperatures, to maintain consistent high-precision voltage and current measurements. By adopting the UAV CAN digital communication protocol, attenuation and interference errors are avoided. These can be present in regular power modules that feed the flight controller with voltage and current measurements in analog format. To accurately calculate power consumption, the PMU’s MCU samples voltage and current at a rate of more than 100Hz. These data are then passed to the flight controller. The PMU can accurately measure currents between 0-180A.
CAN PDB supports input voltages from 15V to 62V, which roughly correspond to LiPo batteries from 4S up to 15S, and the power distribution board supports up to 180A of continuous current [3]. The baseboard has 13 output channels and several connectors for telemetry, radio control input, GNSS module, ADC, I2C, CAN, UART, and the 5V and 12V high-current outputs, among other things.
The PDB power lines are built with 95cm2 of copper sheeting, which also acts as a heatsink, helping reduce heat caused by the lines’ internal resistance when high currents circulate. The CAN PDB carrier board is compatible with the V5 Plus core and the new X7 flight controller cores from CUAV Tech. Because of their voltage and current specs, CAN PDB can be suitable for big drones carrying high payloads. CUAV Tech also sent me a CAN PDB carrier board to test, but I wasn’t able to do a flight test because of global health emergency restrictions due to the COVID-19 pandemic.
CONCLUSIONS AND FURTHER TESTS
The kit I received came well packed in a fine box. From an aesthetic standpoint, the V5 Plus core, the standard carrier board and CAN PDB carrier board, and the NEO V2 GNSS module seem well crafted and robust, with a nice-looking finish. When powered, both the flight controller core and GNSS module emit an elegant, halo-like status light surrounding their bodies.
After changing the original power module, I had no further “low battery” sudden warnings, and the flight controller performed well in the next flight tests. The sensor’s triple-redundancy gives confidence such that, in the event of an accelerometer or gyroscope failure, there are still two additional redundant ones the flight controller can use to maintain control of the aircraft. This highly reduces the probability of a crash due to multiple-sensor failure. This kind of reliability is important, for instance when your aircraft carries expensive remote sensing equipment, such as professional video cameras, high-end LIDARs or high-resolution thermal cameras. Likewise, it is important when the drone has been given a highly sensitive task and can’t afford a failure that would lead to a subsequent crash.
Currently I’m planning to test the V5 Plus with some autonomous flight applications that integrate computer vision for object detection and tracking. I tested the V5 Plus mainly with PX4, because it’s the platform I generally use for autonomous flight development, but I flashed it with ArduPilot firmware as well and made a couple of flight tests. The configuration process is equally easy with both platforms.
With a price tag of around $358 for the complete kit (flight controller core plus standard carrier board, GNSS module, power module, Wi-Fi telemetry module and accessories), the V5 Plus is not cheap. But whether you work with drones professionally, or you are a drone enthusiast always eager to try new things, perhaps you should take a serious look at the V5 Plus. It could be just the type of reliable flight controller you are looking for. 
RESOURCES
References:
[1] “Writing MAVSDK/PX4 Drone Applications” (Circuit Cellar 361, August 2020)
[2] Flight Log Analysis, https://docs.px4.io/v1.9.0/en/log/flight_log_analysis.html
[3] CAN PDB Carrier Board, http://www.cuav.net/en/can-pdb/
Flight Log Analysis
https://dev.px4.io/v1.9.0/en/log/flight_log_analysis.html
Flight Reporting
https://docs.px4.io/v1.9.0/en/getting_started/flight_reporting.html
Log Analysis using Flight Review
https://docs.px4.io/v1.9.0/en/log/flight_review.html
Hardware in the Loop Simulation (HITL)
https://dev.px4.io/v1.9.0/en/simulation/hitl.html
CUAV V5Plus & NEO V2 GPS and Compass Product Page
https://store.cuav.net/index.php?id_product=95&rewrite=cuav-v5-plus-autopilot-with-neo-v2-gps&controller=product
CAN PDB Carrier Board Product Page
https://store.cuav.net/index.php?id_product=123&rewrite=cuav-new-can-pdb-carrier&controller=product
Analog Devices | www.analog.com
Ardupilot | https://ardupilot.org
Bosch Sensortec | www.bosch-sensortec.com
CUAV Tech | www.cuav.net
Dronecode | www.dronecode.org
iSentek Technology | www.isentek.com
PX4 Autopilot | https://px4.io
STMicroelectronics | www.st.com
TE Connectivity | www.te.com
Texas Instruments | www.ti.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • OCTOBER 2020 #363 – Get a PDF of the issue
Sponsor this Article
Raul Alvarez Torrico has a B.E. in electronics engineering and is the founder of TecBolivia, a company offering services in physical computing and educational robotics in Bolivia. In his spare time, he likes to experiment with wireless sensor networks, robotics and artificial intelligence. He also publishes articles and video tutorials about embedded systems and programming in his native language (Spanish), at his company’s web site www.TecBolivia.com. You may contact him at raul@tecbolivia.com
