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.

NDDS is network middleware aimed at simplifying the development of distributed, real-time applications. Its publish-subscribe architecture removes the complexity from many-to-many communications. Its delivery system distributes time-critical data quickly, efficiently and deterministically. NDDS is the communications engine for RTI’s WaveWorks product family of middleware and tools for real-time networking. WaveWorks is designed specifically to help developers through the full develop, debug and deploy process.

Publish-Subscribe Approach

The publish-subscribe model for messaging is shown in Figure 3. Nodes that produce information (publishers) create “topics”—such as temperature, location or pressure—and publish “issues” of that topic. The issues are then delivered to all subscribers that have declared an interest in the topic. The middleware handles all the transfer chores: message addressing, data marshaling and demarshalling, delivery and flow control. Subscribers can even be on different platforms than the publisher.

In the case of the Georgia Tech helicopter, differential corrections were labeled with the topic gs.diff and published to the middleware. Any other system, either local or on the network, simply subscribed to the gs.diff topic and received new issues automatically as they were published. Both intertask communication and ground-station-to-helicopter telemetry systems utilized NDDS middleware.

To minimize software development time, the team knew that once they established messaging between software subsystems, it never had to bother with it again. It saved the project weeks, or perhaps even months, of development time. Although a lot of data was sent to and from the aircraft over the wireless network, NDDS overhead was never a concern. In fact, NDDS overhead remained negligible while handling data at a rate that, in one test, neared the physical limits of the wireless hardware.

By using off-the-shelf publish-subscribe middleware, the Georgia Tech team was able to meet a very aggressive software development schedule. There was still plenty of work to be done when the team arrived at the 2000 International Aerial Robotics Competition, but debugging communications software was not a part of it. As might be expected, a number of aircraft in the competition crashed during the test flights that preceded the final competition. However, the Georgia Tech UAV was one of only two crafts to fly completely under computer control and make it through to the final stage of the competition. As a result of this success, the Georgia Tech UAV Research Facility is using NDDS on new research projects—and, of course, any future aerial robotics competitions.

Association for Unmanned Vehicle Systems International
Arlington, VA.
(703) 920-2720.
[www.auvsi.org].

Real-Time Innovations
Sunnyvale, CA.
(408) 734-4200.
[www.rti.com].