Drone Deep Dive
Raul has written several articles on drone design technologies in recent years. In this article, he reviews two CUAV products: the Nora flight controller and the XunWing X4 quadcopter platform. Raul details the specifications of these devices, and shares the results of his flight tests.
This is a review of the Nora flight controller and XunWing X4 quadcopter platform, both made by CUAV Tech. The Nora flight controller is based on the STMicroelectronics (ST) STM32H7 series processor. It is promoted by its manufacturer as a high-performance flight controller, and integrates high-precision, industrial-grade ultra-low-temperature drift sensors. It is compatible with PX4 and ArduPilot firmware and supports many vehicle types in both platforms. Nora is geared toward academic research and commercial systems integration.
The XunWing X4 is CUAV’s recently launched “Quadcopter Integrated System.” It allows the use of expansion devices, such as high-definition video cameras to transmit real-time video at great distances, with the use of 4G LTE video and telemetry modules and the integration with CUAV’s “CUAVCloud” service. XunWing X4 Integrated System drones are offered with a variety of customizations to fulfill most of the user’s needs.
In this review, I’ll describe the technical specifications of both the Nora flight controller and the XunWing X4 quadcopter platform. Next, I discuss the results of some flight tests I performed, along with concepts about flight log analysis, multi-waypoint autonomous missions and 3D flight path visualization, which are related to some tasks performed in the evaluation process.
CUAV kindly sent me a XunWing X4 quadcopter and a Nora flight controller for free, to test them and discuss my observations. Part of my daily job consists of advising undergraduate college students with drone autonomous flight projects and related hardware/software platforms. This review reflects my personal opinions derived from the type of tests I normally carry out with multirotor drones (multirotors) in that context.
NORA TECHNICAL SPECS
CUAV’s latest line of X7 high-performance flight controllers include the X7, the X7 Pro and the Nora flight controllers. The three are based on the ST’s STM32H743 microcontroller (MCU), which has much better specs than the STM32F765 MCU used in the previous V5 Plus line of flight controllers. For instance, The STM32H743 MCU runs at 480MHz, it has 1GB of RAM and 2GB of flash memory. In contrast, the STM32F765 MCU runs at 216MHz, and has 512KB of RAM and 2GB of flash memory.
The STM32H743 MCU comes with an Arm Cortex-M7 core that includes a double-precision floating point unit. It has 512KB of EEPROM, 16-bit ADCs and several communication interfaces that include, among other things, UART, I2C, CAN, SPI, MDIO Remote and USB. The Nora flight controller includes three onboard sets of 6-axis motion tracking sensors: one Invensense ICM-20689, one Invensense ICM-20649 and one Bosch BMI088. Each one contains a 3-axis accelerometer and a 3-axis gyroscope. The unit also has one RM3100 geomagnetic sensor (digital compass) by PNI Sensor Corp. and two MS5611 barometric pressure sensors (altimeters) by TE Connectivity. Figure 1a shows the Nora flight controller. Figure 1b shows the NEO V2 Pro GNSS module, which will be discussed later.
The Nora comes with a CAN PMU SE power management unit (PMU). This PMU uses CUAV’s in-house developed “Impedance Temperature Tracking” (ITT) algorithm which, according to the manufacturer, accurately measures voltage and current in real time, and uses CAN bus communication and the UAVCAN protocol to send power consumption data to the flight controller. According to the manufacturer, the ITT algorithm corrects measurement errors caused by impedance changes at different operating temperatures, to obtain consistent high-precision voltage and current measurements. By adopting the UAVCAN digital communication protocol, attenuation and interference errors typically found in purely analog power modules are avoided. These analog power modules feed the flight controller with voltage and current measurements in analog format that are prone to attenuation and interference.
The MCU in the CAN PMU samples and processes voltage and current at a rate of more than 100Hz. This data is then passed to the flight controller to accurately calculate power consumption. The CAN PMU measures voltage inputs from 10V to 62V (with 0.15V accuracy), and currents between 0 to 180A (with 0.3A accuracy). It also provides a regulated output of 5.4V, 4A to power-up the flight controller and other off-board modules.
The Nora I received came with a NEO V2 Pro Global Navigation Satellite System (GNSS) module (Figure 1b), also made by CUAV. This module has a U-BLOX NEO M8N GNSS receiver, an RM3100 geomagnetic sensor (digital compass) by PNI Sensor Corp., and its own MS5611 barometric pressure sensor (altimeter) by TE Connectivity. The U-blox NEO M8N has a 72-channel engine that can concurrently receive signals from Beidou, Galileo, GLONASS and GPS satellite systems (three of the four at the same time). It has a navigation update rate of 10Hz (max), a cold start time of 26 seconds and a hot start time of 1 second. The NEO V2 Pro also has integrated status LEDs, safety switch and buzzer (otherwise added separately to the quadcopter). Like the CAN PMU, the NEO V2 Pro also uses CAN bus and the UAVCAN protocol to transmit data to the flight controller.
XUNWING X4 TECHNICAL SPECS
The XunWing X4 Integrated System is an expandable quadcopter platform offered as a ready-to-fly (RTF) system (Figure 2). It can be built and configured by the manufacturer to meet the client’s specific requirements, and is thoroughly tested before shipping. Off the shelf, it comes equipped with a high-definition video camera with 10x zoom capability, a NEO V2 Pro GNSS module, an LTE-Link SE video transmitter/telemetry module, a 16-channel Radio Control (RC) system and a V5 Plus flight controller. This basic configuration can easily be upgraded to a X7, X7 Pro or Nora flight controller and enhanced with a real-time kinematic (RTK) GNSS positioning system, a laser rangefinder, optical flow, radar and ultrasonic sensors.
The XunWing X4 is ideal for any application requiring real-time, high-definition video transmission, such as aerial photography, inspections and live broadcasts. When equipped with an LTE-Link SE 4G video and data transmission module, it can leverage 4G cellular networks to transmit 1080p high-definition video and telemetry data at long distances. Its frame is made of carbon fiber, and the landing gear is made of plastic. Its dimensions are 48.2cm × 53.4cm ×24cm and a diagonal span from motor to motor of 63.8cm. It is equipped with four 3510 KV360 brushless motors and 1655 carbon-fiber propellers. It has a maximum flight speed of 12meters/s and a wind resistance level of 6. The drone is powered with a 22.1V, 6S, 10,000mAhour Li-ion battery for an approximate flight time of 35 minutes. Any of the recommended flight controllers for the XunWing X4 is compatible with both ArduPilot and PX4 firmware.
For the purposes of this review, I received the XunWing X4 platform without the camera and the default V5 Plus flight controller. I reviewed the V5 Plus last year in my article “A Review: V5 Plus Drone Flight Controller” (Circuit Cellar 363, October 2020 ). I separately received the newer Nora flight controller to test and reviewed it along the XunWing X4 platform. So, I had to install the Nora by myself, along with the GNSS module, telemetry module and the radio control system. I also had to burn ArduPilot’s ArduCopter firmware to the Nora and configure its parameters. The process is fairly straightforward if you have previous experience building and configuring a multirotor with ArduPilot or PX4. For a quick introduction to ArduPilot and PX4 quadcopters you can check my previously published article series “Intro to ArduPilot and PX4—Part 1” and “Intro to ArduPilot and PX4—Part 2 ” (Circuit Cellar 357 and 356, April and May 2020) . Figure 3 shows the Nora flight controller installed in the XunWing X4 frame.
The NEO V2 Pro GNSS module, unlike regular UART-interface GPS modules, must be connected to one of the CAN ports (CAN1 or CAN2) available in the flight controller. By using ground-control software such as Mission Planner, CAN drivers must be enabled in the ArduCopter firmware, and the GPS_TYPE parameter configured to UAVCAN, so the flight controller is able to use the NEO V2 Pro. The parameter NTF_LED_TYPES must also be set to the value “231” to enable the status LEDs and safety button integrated in the NEO V2 Pro. I used the PW-LINK Wi-Fi telemetry module that came with the Nora to receive telemetry data from the quadcopter to my laptop. Figure 4 shows the XunWing X4 quadcopter ready for its first test flight.
I tested the quadcopter exclusively with ArduPilot firmware, which comes flashed by default in the XunWing X4 integrated systems. It is possible to flash it with PX4 firmware as well, but PX4’s default PID tuning settings may not work out of the box with the XunWing X4, without adjusting them. At the time of this writing, I didn’t have on hand recommended PID tuning parameters for the XunWing X4 with PX4 firmware.
The flight modes I tested with the quadcopter were the following: Stabilize, Altitude Hold, Loiter, RTL (return to launch) and Auto. For those not familiar with these flight modes, here’s a brief description of each:
Stabilize: In Stabilize mode the quadcopter is manually flown by the pilot, who must constantly adjust altitude, horizontal position and heading, but the flight controller self-levels the roll and pitch axes. In this mode, horizontal position, heading and altitude will usually change constantly due to the wind.
AltHold: In AltHold mode, apart from self-leveling the roll and pitch axes, the flight controller tries also to maintain a consistent altitude by controlling the throttle level, with the help of the barometer (altimeter) readings. The pilot still has to control horizontal position and heading manually, but the drone can also react to altitude input from the pilot.
Loiter: In Loiter mode, the flight controller tries to maintain its current horizontal position, heading and altitude by automatically correcting any drift on them. For this, it needs to have at least a GPS receiver and a digital compass, along with the gyroscope, accelerometer and barometer sensors. The pilot can still change altitude, horizontal position and heading, but in the absence of input from the pilot, the flight controller tries to hold the last commanded ones.
RTL: In RTL mode, the quadcopter will go first to a default RTL altitude (preconfigured in the flight controller), then it will navigate to the takeoff location coordinates and land.
The XunWing X4 with the Nora flight controller performing a test flight is shown in Figure 5.
PLANNING A MISSION
Now, I will talk a bit about planning and executing a multi-waypoint mission with ArduPilot and Mission Planner. I made the quadcopter perform a couple of those to see it doing autonomous flight. Prior to execution, the mission must be prepared by using ground-control software. Figure 6 shows a screen capture of Mission Planner with an example mission. The map shows a Home (H) position marker and four waypoint markers (2, 3, 4 and 5). The list of events below the map, however, shows two additional ones not visible in the map—a TAKEOFF event (#1 in the list) and a RETURN_TO_LAUNCH event (#6 in the list).
After the TAKEOFF command to an altitude of 10 meters (see the Alt column in the list) is executed, the quadcopter will navigate to the first waypoint (#2) with the GPS coordinates shown in the Lat and Long columns and altitude shown in the Alt column (30 meters for this waypoint). Waypoint altitudes are defined as relative to the takeoff altitude above sea level. See the Relative option chosen in the drop-down box above the Delay column. (Other options for altitude are Absolute and Terrain.) Going from waypoint #2 to waypoint #3, the quadcopter will climb to 50 meters. Going to waypoint #4, it will descend to 20 meters, and for waypoint #5 it will ascend again to 25 meters. After reaching waypoint #5, the quadcopter will execute the RETURN_TO_LAUNCH event. For this, it will first go to the predefined return-to-launch altitude set in the flight controller, then it will navigate to the takeoff coordinates and land.
Once the mission plan is ready, it can be uploaded from Mission Planner to the aircraft via USB cable or the wireless telemetry link, after pressing the Write button shown at the right in Figure 6. It then will be executed after the quadcopter is armed and the Auto flight mode is selected from the radio transmitter or from Mission Planner, itself.
For area-surveying missions, Mission Planner can automatically create waypoints that cover a selected area. Figure 7 shows an area defined by the user by placing the red markers. Then, Mission Planner automatically computed and added a number of waypoints (the green markers), based on user-defined altitude and horizontal separation parameters. This type of mission is generally used in aerial photogrammetry and remote sensing to create maps of large areas by stitching together several photos taken at predefined time intervals. Terrain surface 3D models can also be obtained with this technique.
FLIGHT LOG ANALYSIS
ArduPilot’s flight data logging and analysis capabilities are very handy to evaluate drone performance and diagnose problems . ArduPilot has two types of flight logs: dataflash logs and telemetry logs (tlogs). Both types of data logging collect similar data that can be analyzed later to evaluate performance and diagnose problems. Dataflash logs are stored in the flight controller’s dataflash memory, and they are created automatically after arming the vehicle before take-off. They can then be downloaded to a computer after the aircraft lands. Telemetry logs are recorded by the ground station application (for example, Mission Planner) running on a personal computer or mobile device. Telemetry logs are created as long as the drone is connected to the ground station via telemetry link before the flight.
For dataflash logs, in Mission Planner you can set what data you want to record by setting the ‘LOG_BITMASK’ parameter in the flight controller firmware. For instance, some of the following data message groups are worth being recorded :
ATT (attitude information): This group includes some important data messages, such as desired roll, actual roll, desired pitch, actual pitch, desired yaw and actual yaw, among others. Attitude data helps determine how well the PID tuning is adjusted to closely follow the desired input roll, pitch and yaw angles for the aircraft.
COMPASS (raw compass, offset and compassmot compensation values): It includes MagX, MagY, MagZ raw magnetic field values for the X, Y and Z axes, and offset and compensation values. Compass data helps determine the degree of interference caused by the power system (battery, power distribution board, electronic speed controllers, motors and so forth) to the digital compass.
CURRENT (battery voltage, current and board voltage information): This group includes throttle input from the pilot, the sum (integration) of total throttle output, battery voltage, instantaneous current and total current drawn from the battery and measurements of the VCC voltage used to power the flight controller.
CTUN (control, throttle and altitude information): Includes also the throttle input from the pilot, the final throttle output sent to the motors, desired altitude, current altitude inferred by the Extended Kalman Filter (EKF), barometer altitude, desired climb rate and actual climb rate in cm/s, among others.
EKF (Extended Kalman Filter): Extended Kalman Filter (EKF) data contained in the EKF1, EKF2, EKF3 and EKF4 log messages contain estimations of position and orientation in 3D, velocities and auxiliary data that helps improve the aforementioned estimations.
ERR (error messages): Error messages from the radio control system, compass, battery, flight mode change failure, GPS glitches, detected crash or loss of control, EKF health check, barometer, CPU load watchdog, vibration failsafe and so on.
EV (event numbers): The most common are: Armed, Disarmed, Auto Armed, Land Complete and Set Home.
GPA (Global Position Accuracy): GPS vertical dilution of precision (VDOP), as well as horizontal, vertical and speed accuracy as reported by the GPS module and so forth.
GPS: GPS status and time, number of satellites currently being used, GPS horizontal dilution of precision (HDOP), latitude, longitude, relative altitude, GPS altitude, ground speed and heading.
IMU (accelerometer and gyro information): Raw accelerometer and gyroscope values.
Flight log analysis can provide insight about hardware errors—for instance, about mechanical failure caused by broken motors and/or electronic speed controllers (ESCs). It can also help evaluate aircraft performance. An important issue affecting flight performance that flight logs can help analyze is mechanical vibration. Vibration in a multirotor is produced by the moving parts—namely motors and propellers. Out-of-balance motors and/or propellers will induce mechanical vibration in a multirotor, which, in turn, will induce noise in the inertial sensors. Good-quality motors and propellers generally come from the factory well-balanced and with low vibration levels. Lesser-quality ones can be balanced to some extent to reduce vibration. However, some amount of mechanical vibration in a multirotor is practically unavoidable. This is okay, though, as long as it is low enough not to degrade the flight controller’s performance.
High mechanical vibration levels interfere with the flight controller’s ability to keep the aircraft leveled, and can also cause drift in altitude, horizontal position and heading estimates, causing pose-holding problems. The visualization of the VibeX, VibeY and VibeZ data messages from dataflash logs can help evaluate mechanical vibration . These Vibe values comprise the accelerometer’s output standard deviation in meters/s/s. Figure 8 shows these data message values for the XunWing X4 plotted by Mission Planner’s data log review interface. According to ArduPilot’s official documentation, average levels below 15m/s/s with occasional peaks up to 30m/s/s are considered normal. By that standard, the XunWing X4 quadcopter has very good vibration levels. This was also noted in the flight tests, where the quadcopter flew stable, solidly maintaining altitude, heading and horizontal position, even in the presence of reasonably intense winds.
3D FLIGHT PATH VISUALIZATION
After downloading dataflash log files from the flight controller, Mission Planner automatically creates corresponding KMZ files (with the .kmz extension) for each log file. KMZ files are Google Earth session files that store location (GPS coordinates and altitude), along with attitude data, which are useful to visualize flight paths. Figure 9 shows a screen capture of Google Earth Pro PC software, visualizing a KMZ file from a test flight with the XunWing X4. In the left pane, under the Log folder, five flight paths for different flight modes executed in the flight test are listed. Flight paths are visualized in the map drawn with different colors. For instance, the first flight path in Loiter mode (labeled “2 Flight Path Loiter”) is drawn in yellow. The second flight path in AltHold mode is shown in green. The one in dark blue (one of the longest) was made in AltHold mode and the pink one is again in Loiter mode.
Any flight sub-path contained in a KMZ file also can be visualized in isolation. For instance, you can select “4 Flight Path Loiter” in the left pane to visualize just the dark blue one in isolation. Aircraft attitude (roll, pitch and yaw angles) can also be visualized. Figure 10 shows the fifth flight path in pink, along the corresponding attitudes for all data points, which are illustrated by little airplane figures in dark yellow and blue. Each airplane figure along the path shows the aircraft’s attitude at that point.
CONCLUSIONS AND FURTHER TESTS
The Nora-equipped XunWing X4 quadcopter is very stable and enjoyable to fly. Even with moderately strong winds, the quadcopter’s flight is remarkably stable, accurately maintaining position and attitude. Nora’s sensor triple-redundancy makes it ideal for applications, in which reliability is critical—for instance, when the aircraft needs to carry expensive remote sensing equipment, such as professional video cameras, high-end LIDARs or high-resolution thermal cameras. Highly sensitive tasks that can’t afford a failure leading to a crash could also benefit from it, for example, those that imply flying over critical infrastructure, equipment or people.
I use multirotors mainly for autonomous flight projects using MAVSDK and MAVROS software libraries, which are tools from the PX4 ecosystem. Unfortunately, ArduPilot is not officially supported by MAVSDK, so I couldn’t test the XunWing X4 with programmatically controlled autonomous flight. The ArduPilot ecosystem has the Dronekit-Python SDK for autonomous flight. Because it appears not to be actively maintained anymore, it is less attractive for experimentation and development, so I don’t really use it. I still could flash the Nora with PX4 firmware, though its default PID settings probably would not work out-of-the-box with this platform without a careful re-tune. But that’s a task for another time. By no means do I consider myself an expert in multirotor PID tuning!
The purpose of this review was to test and evaluate the platform performance with the firmware it comes with from factory. In the future I would like to change it to PX4 and try to make the best PID tuning possible, if required. I’m eager to try the Nora-powered XunWing X4 quadcopter with some autonomous flight code using MAVSDK and MAVROS.
The frame has reasonable space to accommodate external devices with less than 500g total weight, which is XunWing X4’s maximum payload capacity. They could be powered easily from the quadcopter’s power distribution board, which has auxiliary power outputs. That would make it easy to add some specialized sensors, such as thermal or stereo vision cameras and a companion computer, to experiment with autonomous flight and computer-vision object detection and avoidance.
 “A Review: V5 Plus Drone Flight Controller” (Circuit Cellar 363, October 2020)
 “Intro to ArduPilot and PX4. Part 1″
“Intro to ArduPilot and PX4” (Part 2)”
(Circuit Cellar 357 and 356, April and May 2020)
 ArduPilot – Logs, https://ardupilot.org/copter/docs/common-logs.html
 ArduPilot – Setting what data you want recorded, https://ardupilot.org/copter/docs/common-downloading-and-analyzing-data-logs-in-mission-planner.html#setting-what-data-you-want-recorded
 ArduPilot – Measuring Vibration, https://ardupilot.org/copter/docs/common-measuring-vibration.html#common-measuring-vibration
Downloading and Analyzing Data Logs in Mission Planner:
Diagnosing Problems Using Logs
Planning a Mission with Waypoints and Events
Sources Of Equipment Reviewed:
XunWing X4 Integrated System
NEO V2 Pro
ArduPilot | https://ardupilot.org
CUAV Tech | www.cuav.net
Dronecode | www.dronecode.org
PX4 Autopilot | https://px4.io
STMicroelectronics | www.st.com
TDK Invensense | www.invensense.tdk.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • DECEMBER 2021 #377 – Get a PDF of the issueSponsor 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 email@example.com