CC BY
184
Creating a Navigation and Autopilot System
for Unmanned Aerial Vehicles Using NI Single-Board RIO
and NI LabVIEW
у
ГГ NATIONAL INSTRUMENTS
Keywords: navigation, autopilot system, unmanned aerial vehicles, flight control computer.
Onboard avionics systems within unmanned aerial vehicles (UAVs) are complicated, especially for automatic flight. Due to operation in 3D space, the system is subject to crash when it loses stability. Remote UAV (RUAV) system dynamics are inherently nonlinear and unstable. To create an onboard navigation, guidance, and control system, we needed a highly reliable, real-time embedded system with sufficient computing capacity. From a functional point of view, precise yawing (directional pointing) under stabilization and trajectory-following capabilities are essential, so the main flight control computer (FCC) had to integrate various navigation sensors; data acquisition; a PWM servo control; and a fast data processing unit. For flexible communication with the ground control station (GCS) and flying UAV, we needed a communication data network. The fundamental considerations for this project included a high-performance, easy-to-develbp embedded system; real-time monitoring to prevent accidents; high-rate sensor data acquisition for high-dynamic RUAV control; latitude control and an autopilot system for operation without a trained RC manual pilot; and lightweight hardware.
Byoung Jin Lee,
Konkuk University, Seoul, South Korea
System Overview
ANSI C-based digital signal processing (DSP) or ARM processors are popular in embedded systems, but they are not easy to create. The ANSI C development tool is generally difficult for beginners and the library is not well-supported or easy to use. For more simple and convenient access to embedded system development, we chose NI SingleBoard RIO and a virtual instrumentation-based platform.
We programmed our NI Single-Board RIO device with LabVIEW. LabVIEW made it easy to develop the algorithm and use haidware and software libraries with sufficient toolboxes. Using this
system, we saved more time and reduced the number of students engaged in embedded development. As listed, only two students with the advisory professor worked on this project.
We needed a GCS to control the vehicle's flying path, command operations, and acquire data from the UAV in real time for the developer or commander. The GCS was critical in constructing the flight system. We used the LabVIEW front panel to easily develop the GCS panel and required interfaces. The front panel shows all of the RUAV flight data and provides an interface to change the settings and command values. It responds quickly, so we used the front panel function for in-flight proportional-integral-derivative (PID) controller gain tuning in the early test phases. The graphical interface is very simple and easy, which is a fundamental reason we chose LabVIEW.
И LabVIEW
Though NI Single-Board RIO has a fast main processor (400 MHz), too much sensor data can create congestion. To control a high-dynamic system, we needed frequent sensor data updates. In our flight system, the inertial measurement unit (IMU) is the most essential sensor. The IMU outputs data packets at a high rate (up to 100 Hz), and each packet contains about 100 bytes of data. For realtime operation, the IMU requires a very high processing capability with a big packet size, which takes up many resources in the NI Single-Board RIO main processor. Therefore, we reduced main processor sensor data calculations via packet processing optimization for guidance, navigation, and control calculations. Most importantly, NI SingleBoard RIO has field-programmable gate array (FPGA) capabilities, which makes high, fast logic gate calculations. Using FPGA, we can share the data handling burden in the main processor.
To use sensor data, we need several low-level calculations. Most of the calculations are bit or single-byte tasks, so these low-level signal processing parts operate on the FPGA side. Using this method, the real-time OS in the main processor only converts the rearranged bit data into informative data used in the high-level logics, which reduces the total main processor computing burden.
Weight is a critical parameter in aerial vehicles. The NI Single-Board RIO was a great choice because it weighs less than 200 g. Additionally, we reduced the weight of the other devices, used wood
Figure 2. GCS Front Panel
for the case, and cut all of the cables shorter. We only used devices essential to automatic flight in the case. For low power consumption, we detached all optional parts, such as LED and sound.
The flight system needs approximately 20 W of power to operate. According to the onboard device specifications, we designed the power supply to convert battery voltage (22.2 V) to 12 V, 5 V, and 3.3 V. To make only needed voltage and amperes, the power supply we designed successfully saves power so we could use a flight control system (FCS) with a smaller battery capacity.
The NI Single-Board RIO is installed in the bottom layer of the case. In the top layer, we installed an NI 9870, a wireless LAN access point (WLAN AP) and a power supply. The NI 9870 communicates with sensors via RS232. An off-the-shelf WLAN AP module connects to the GCS. An auto/manual switch module converts the actuator signals between auto and manual commands. If the RUAV is in a dangerous situation during autopilot mode, an operator can control the vehicle using the auto/manual switch.
The NI sbRIO-9602 does not include an A/D converter, so we added an Amtel AVR to sense the battery analog voltage. The NI sbRIO-9612 does have this function, but is 70 g heavier than the NI sbRIO-9602 and consumes more power. The preprocessed FPGA data is sent to the real-time OS in the main processor. The real-time OS controller runs various high-level algorithms such as coordinate conversion; trajectory generation; guidance logic calculation; proportional-integral derivative (PID) controller output generation; and data communication transmit and receive control. The UAV latitude and motion control generated control signals are sent to the FPGA to invoke the PWM actuator-driving digital signal. PWM signals are input to the main rotor motor or servo motors. Finally, all necessary flight control information is transmitted and monitored at the GCS display.
Flight Test
Takeoff and landing are dangerous operations for all flight vehicles. For the safety of the vehicle frame and FCC board during VTOL operation, a
Figure 4. Sensor Data Flow From FPGA to Real-Time OS in Main Processor
Figure 3. Flight Data Display Window
human pilot controls the RUAV during takeoff and anding. Except for these two operations, the autopilot function controls all vehicle movements. For analysis, all necessary sensor data is saved in the NI Single-Board flash memory. At the same time, essential navigation data such as position, latitude, and velocity is sent to a ground station so a GCS computer can show the flight path and vehicle latitude in real time. Using the additional GCS data interface, we observe the RUAV conditions and command the operations to the RUAV.
For autopilot demonstration, we show the fol-owing three flight test results:
• Hovering and yawing flight (latitude stabi-ization)
• Low altitude, droplet flight (latitude control + altitude control + waypoint guidance)
• Infinity flight (latitude control + altitude control + waypoint guidance)
The first result shows rotary UAV hovering and yawing motion control. The yawing motion at a fixed position is the key exclusive functionality of the rotor compared with a fixed-wing aircraft. Yet, as the rotor dynamic model is inherently unstable, it is difficult to keep an aerial vehicle stabilized. The hovering and yawing flight is the most fundamental requirement during rotary UAV development. After applying a PID control to roll, pitch, and yaw dynamics, we achieved successful results with stabi-ization under windy conditions (7 to 9 m/s wind speed).
The next figures show the water droplet flight path and its path error from a programmed reference trajectory. This operation is repeated four times. The average path error from reference is about 2 m, which demonstrates excellent RUAV position accuracy. In this case, flight trajectory is relatively smaller and altitude is lower than other paths, which helps us more easily observe the flight.
Power Supply Figure 5. Total Hardware Configuration (1)
Figure 6. Total Hardware Configuration (2)
Figure 7. FCS Data Flow
Figure 8. Heading Control and Turning Order
Figure 9. Water Droplet Flight Path (1)
Figure 10. Water Droplet Flight Path (2)
Conclusion
Finally, the figures above show the infinity symbol flight path and path error. We repeat this operation twice. The average path error is about 3 m, with a maximum of about 8 m. The paths are much bigger than in the water droplet flight path. In this path, the scheduled flight velocity is faster than the previous droplet case (10 m/s). We used this path to observe the control logic performance during high-speed flights while simultaneously orienting performance during circular interval flight.
References
1. http://www.ni.com/singleboand.
2. http://www.ni.com/singleboard/applications.
3. http://www.ni.com/singleboard/whatsnew.
4. http://www.ni.com/labview.
5. http://www.ni.com/labview/applications/ embedded.
6. http://sine.ni.com/nips/cds/view/p/ ang/en/nid/11834.
7. http://www.ni.com/white-paper/14336/en.
Conax and Anevia bring together advanced service protection and streaming solutions to facilitate feature-rich OTT deployments
For operators seeking to monetize multiscreen services in the fast-paced OTT world, an integrated content security and video streaming solution opens up the horizon for fast deployments and new business opportunities.
NAB Show, Las Vegas, March 27th, 2014: Anevia, a market leader in video streaming and infrastructure solutions for OTT, live TV and Video on Demand (VoD) today announced a new collaboration with Conax, a global leader in total service protection for media and entertainment services over multiple devices and networks. Integrating Anevia's ViaMotion Plus and CDN solutions with the Conax Contego Unite™ content protection platform, this collaboration simplifies the OTT equation for operators worldwide: they can now accelerate and monetize the deployment of OTT services over a wide range of devices and formats while ensuring optimal content, service and device protection.
Anevia is a leader in software infrastructures for the delivery of live television and video-on-demand services. Renowned for its performance and flexibility, ViaMotion is a complete multiscreen Over-the-Top (OTT) video solution for telcos, broadcasters and content owners. Designed to empower next-generation video content delivery networks (CDNs), Anevia's OTT solution includes the Viamotion Plus server for multiplexing and streaming live on-demand content over the internet using adaptive-bitrate streaming.
A leader in content security, Conax protects content for over 380 pay-TV operators, representing 140 million households in 85 countries around the globe. Conax Contego Unite™ is a unified and flexible multiscreen platform for premium content, service and device protection. The combination of its flexible multiCA/DRM, united back-end system and best-in-class secure clients creates a seamless multiscreen experience for both set-top-boxes and devices.
"We are proud to partner with such a highly regarded security solutions provider", says Damien Lucas, ANEVIA EVP and Co-Founder. "The Conax Contego™ feature set is extremely rich and therefore highly invaluable to customers looking to build and monetize advanced multiscreen services. And while this partnership clearly benefits the many customers we have in common, it also creates a natural opportunity for our joint partners to develop new business around OTT."
"We are pleased to announce that Anevia is one of the newest partners leveraging the Conax Connect Partner Program to achieve fast integration and testing through the Conax Connect Integration Lab. The joint solution with Anevia offers hard to beat flexibility and cost efficiency", Tom Jahr, EVP Products and Partners at Conax, explains. "For operators, it doesn't just mean complete freedom of choice when assembling ecosystem components; it also enables operators to monetize new services such as time-shift and nPVR through the rapid deployment of advanced OTT/IPTV ecosystems."
