Compact code, a short development cycle and enough reliability to keep an unmanned helicopter flying—the combination of those three seem outside the realm of possibility. Engineers at the Georgia Institute of Technology’s Unmanned Aerial Vehicle Research Facility (UAVRF) were recently faced with just such a situation. They were developing a small, autonomous, radio-controlled helicopter to fly in the International Aerial Robotics Competition (IARC) and they had only a short time to put it all together.

One of the critical components was the software that their unmanned helicopter would use for communications with their ground station. The communications software had to be small, simple, intuitive to use and available off the shelf. Using off-the-shelf software the Georgia Tech team was able to get its helicopter flying under complete computer control in time for the competition.

Competition Ignites Innovation

With sponsors including the Association for Unmanned Vehicle Systems International (AUVSI) and the U.S Department of Defense, the IARC captures the competitive spirit of graduate engineering students from many of the top universities around the world. The AUVSI sponsors annual autonomous robotics competitions in aerial, ground and undersea categories. These competitions require undergraduate and graduate students to design and build unmanned vehicles that attempt to complete a predefined mission. The competition also helps spur innovation and advanced knowledge in unmanned aerial vehicle technology.

An IARC mission is often very complex. For example, this past year’s competition required the unmanned aerial vehicles (UAVs) to complete a search-and-rescue mission over a five-acre area that simulated an urban natural disaster. This simulated disaster area included hazards such as natural gas leaks and broken water mains—where actual flames and waterspouts were shooting into the air (Figure 1). For the mission, the UAV was required to locate simulated survivors of the disaster and identify various hazardous materials strewn throughout the area.

Preparation for such a mission can take years. The problem for the graduate students at the Georgia Tech UAVRF was that they did not have years; they had only five months to put together a working helicopter from scratch. They had to select the hardware components, build the helicopter, write and test the software and fine-tune the flight controls. Even though autonomous aerial flight was not new to the Georgia Tech team, the task was still daunting.

Choosing Hardware and Software

First, the team selected the various hardware components. In addition to normal helicopter equipment, the UAV was equipped with a small circuit board containing an AMD 486DX5-133 processor, 128 Mbytes of RAM and 64 Mbytes of flash memory. It also was given a Global Positioning System, a SONAR altimeter and an Attitude and Heading Reference System.

Communications between the helicopter and the ground station were provided over wireless Ethernet. While some members of the team worked on integrating the various hardware components, others selected the software components used on the project. RT-Linux was chosen as the operating system for the embedded processor on the helicopter, and Red Hat Linux was selected as the operating system for the ground station computer.

To shrink software development time, the team knew they needed to use as many off-the-shelf software components as possible. “We found that a good mix of the right software tools and middleware cut development time and minimized confusion,” said Aaron Kahn, chief designer of the Georgia Tech helicopter.

The first step of the software development process was to design a communications subsystem (Figure 2). This would ensure that all the various software systems could communicate in an easy, scalable and flexible way regardless of whether the systems were local or across the wireless network. The team decided to use off-the-shelf communications middleware to save both time and resources. “Using off-the-shelf middleware helped us to focus more completely on our overall objective rather than on the details of message-passing algorithms or network programming idiosyncrasies,” said Kahn.

Several off-the-shelf options for middleware were considered. “We looked at CORBA, but not only was it too large for our embedded application,” said Suresh Kannan, chief software architect for the project, “but the ramp-up time to use it was prohibitive. Just to send a few data values from one system to another required too many rules, conventions and standards for us to figure it out expediently.” The team ultimately selected Real-Time Innovations’ NDDS, a real-time, publish-subscribe middleware that required virtually no ramp-up time.