AirNAV at the Controls: Keeping Survey Pilots on the Straight and Narrow

Paul Benford, Cogent Real-Time Systems Inc.

Imagine this. You're flying along in a helicopter 100 feet off the ground and the landscape below you bears no resemblance to the map you hold in your hands. You know roughly where you are - after all, you're being paid to fly a mineral survey for an exploration company. Trouble is, you can't tell one lake from another. And since helicopters are very costly to operate, you can't afford to spend too much time searching for the right spot. If you do miss part of your target area (and possibly vital data), your customer might make you fly the survey again - this time at your own expense!

X marks the spot

Survey pilots face a number of challenges quite apart from flying their aircraft. Given an area to survey and a route to follow, they must try to maximize the range of their aircraft, and minimize the chance of data being missed, by flying a consistently smooth line along the defined route.

Early survey techniques had pilots looking for features on the ground and trying to match them to landmarks on a map. They could only guess at the location and direction of the survey lines. This technique often required a second person to help with the guesswork; but with two people onboard, operating costs increased.

More recent techniques use Global Positioning Satellite (GPS) receivers and embedded computers to display navigation information. Data from various measuring devices, such as magnetometers, electromagnetic spectrometers, and radio- metric tools, can now be combined to produce maps of the area being flown. Unfortunately for the manufacturers of survey equipment, this was not the case when they were developing computer systems to support their hardware. The high sampling rate of the data acquisition systems and the cost of expanding on their original design leaves them with little choice but to look for another solution.

We recently completed a system that represents a significant advance in software-based navigation tools. Survey pilots now have enough information to fly unassisted over remote areas.

Our mission

• Deliver an intelligent, hands-off navigation engine that recognizes the position and heading of the aircraft in relation to the route, and provides realtime information to keep the aircraft on an optimum flight path
• Provide a system that reliably gathers, timestamps, logs, and filters a variety of data streams
• Include a GUI with easy, distraction-free access to options
• Log survey data on a selective basis depending on the aircraft"s proximity to the survey area
• Provide an open, modular basis for future expansions
• Deliver the application on a platform that can be easily secured to, and removed from, the cockpit of the aircraft

Flight of the navigator

From our partner's guidelines, we built AirNAV in approximately seven months. A state-of-the-art navigation system, AirNAV is based on an earlier Windows- based prototype that was plagued with speed and stability problems and therefore was never commercialized. The system reads, timestamps, and stores data from radar altimeters and other devices that monitor flight speed and direction. The speed at which data is generated and the speed of the aircraft itself means that AirNAV must handle information with millisecond accuracy.

Since the pilot relies heavily on the information being displayed, there is absolutely no room for error. The reliability and performance of AirNAV was, in fact, such a priority that it governed the selection of the OS for the project. Our only viable choice was to use QNX and the Photon microGUI. Networking proved to be another key feature in our choice of QNX. We saw the ability to effortlessly attach network nodes running other data-gathering processes as a major advantage over other operating systems.

AirNAV uses realtime GPS information to display the position of the aircraft at all times. From the moment the system is turned on, the pilot can see exactly where the aircraft is on the surface of the earth, with an accuracy of ±16 feet (the current accuracy limit imposed by the US government for satellite data).

The system, mounted in the helicopter cockpit, displays a home base, a number of waypoints, and one or more survey areas. Each survey area contains survey lines that a pilot uses to ensure the entire target area is covered. The area around the survey, called the "vicinity," marks the region within which the data acquisition system begins to log data. On a long flight from home base to the survey area, the system displays navigation information en route, so the pilot can fly the shortest path.

As the aircraft approaches a survey line, the system decides which line the pilot is approaching and highlights it to aid navigation. A sophisticated set of rules governs how AirNAV decides which line to highlight. The screen can be configured to automatically zoom in on the line the pilot is attempting to follow. Although it may seem trivial, this feature has allowed the AirNAV system to be virtually automatic, requiring very little input from the pilot.

AirNAV also keeps track of which lines have been flown in both the current flight and any previous flights in this area that used the same survey map. At any time, the pilot can click a button on the screen to re-fly a line, move to the next line, or lock on a line (to override the one selected by the navigation engine).

The AirNAV display features a number of graphical elements:

• current aircraft location coordinates
• aircraft altitude
• north indicator
• a reticle or crosshairs, showing how close the aircraft is to the line (both horizontally and vertically)
• distance from home base, allowing the pilot to estimate fuel requirements for the return trip to base camp

The AirNAV system allows the pilot to display up to four realtime strip-chart trends of the data coming into the system. Trends can be opened or closed in the air with minimal effort.

Route information is compiled on the ground in a Windows application file. Once in the air, the system reads these files and sets up its own display and logic parameters from the information. After the flight, the system saves the survey data to a file format that a second Windows application can use to draw maps of the survey data.

Although our initial system was designed specifically for our development partner's survey equipment, AirNAV is set up to allow any hardware device to serve as a source of data.

The heart of the system

We wanted to provide a robust solution that could easily handle the addition of new data streams. With the Cascade Database and the QNX OS, we were able to do this easily. AirNAV has a modular architecture that allows new device drivers to be easily incorporated into the system as extra processes.

The heart of the system, Cascade acts as the common data storage facility that all other programs interact with in order to send and receive data. We used a Name Server module (nserve), that provides extended process name services, and a Queue server (qserve), that provides asynchronous message passing. Both the qserve and nserve programs give the Cascade Database a guaranteed non-blocking communications mechanism.

The Cascade Database automatically notifies a number of clients when a data change (or exception) occurs.

These include:

The graphical user interface

The GUI was written using our own Slang programming language and was delivered on the Photon microGUI platform. Special coordinate conversion routines were embedded into the Slang engine. We also embedded a number of 3-D matrix transformation routines that allow us to present accurate mapping information to the pilot. The GUI is fully customizable, and pilots can configure displays and other parameters on the fly.

Because we used Slang to build the GUI displays, it's possible to have the AirNAV engine directly influence what is displayed onscreen. As mentioned previously, when the aircraft enters a survey area, the AirNAV engine triggers the display to zoom in on a more detailed display of the survey line. Photon provided us with an unprecedented level of interaction that allowed the GUI to change automatically as the pilot traveled from home base to each point along the survey and then back home again.

AirNAV Engine

The AirNAV Engine is a sophisticated module that makes many of the decisions about what the aircraft is doing, and how information is presented to the pilot. Written in Slang, the engine recognizes the position and movement of the aircraft with respect to the predefined survey route, and provides the pilot with a wide range of realtime information concerning distances to survey lines and waypoints. The engine also generates the data used in the rules that govern when data is stored to disk.

We interviewed pilots and engineers from several exploration companies to help us develop the operating procedures defined in the AirNAV Engine. Within the first few weeks of development we had used PhAB to create a large number of screens that we fully animated using Slang. This rapid prototyping actually changed the course of the project because it generated so much input from both our partner and our own development staff. With Slang, you can interact with and debug remote programs live, or download small changes to code quickly without restarting or interrupting an application, so it was a simple task to correct any problems.

Slang allowed us to rapidly develop a full-featured working version of the AirNAV model that we used to refine and expand upon our initial ideas. We were able to deliver ideas and alternatives for comparison and modify any aspect of the system while we tested it with live data. Most of the code from the early prototype screens was retained in the final delivery system.

We designed geo-referencing routines that were compiled into the Slang runtime engine, which allowed us to deliver accurate positioning data to the pilot in real time. And we are able to offer a Slang development system that contains optimized routines for calculating reference information such as closest-point-to-a-line, great-circle-distance-to-a-line, and support for latitude/longitude, UTM, and XYZ coordinate systems.

The Data Logger

The Data Logger is a dedicated module designed to write data to the survey log files. To prevent the system from logging unwanted data as the aircraft goes to and from the survey site, there's an option to prevent logging until the AirNAV Engine indicates the aircraft is close to the target area. The Data Logger program is implemented in C.

Device drivers

All QNX-based modules in the system, including the device drivers and logger, have an ASCII communications interface that allows the developer to configure, query, and operate the module through a separate command-line "portal" program.

PPDC program

We also developed a DOS-based utility called the Post Processing Data Correction (PPDC) program. This program is run from a DOS shell inside Microsoft Windows to provide ground-based technicians with a tool to correct airborne survey data and prepare the data for the Windows-based mapping software.

Software solutions

During development we had some application-specific challenges:

Ensure accurate timestamping

To solve this we designed a special hardware-multiplexing unit called the MUX box. This device synchronizes itself, as needed, with a time signal from the GPS receiver. All current data values are stored in the Cascade Database, which carries a timestamp for each data point. When the MUX box is unable to synchronize with the time on the GPS receiver (i.e. when fewer than four satellites are in view), the MUX continues to timestamp data based on an internally-generated time that"s synchronized to its last valid time signal.

Synchronize the OS clock to GPS time

The computer running AirNAV software is synchronized to the time signal sent with each data value from the MUX box. The software is designed to ignore inaccurate satellite time and rely on its own CPU clock whenever GPS lock is unavailable.

Get survey results from QNX to MS Windows

We used a Jaz_ drive from Iomega_ to transfer data between QNX and the MS Windows analysis software. The 1G storage capacity can easily store the results from several large survey flights. The Jaz_ platter is DOS-formatted and we use Dosfsys to transfer flight data files from QNX to the Jaz_ media.

Provide support for data from multiple devices

The AirNAV system is built around a modular system architecture that allows new devices to be added to the system as needed. Using the Cascade Database as the central data-handling module allowed us to develop specific drivers for the new hardware devices we incorporated (i.e. the magnetometer and the MUX box). Once the data resides in the database it is available to any other process in the system.

Integrating latitude/longitude to UTM conversion routines

surveying uses a number of different mapping projections. Often the traditional latitude/longitude coordinate system isn't suitable, especially in locations far from the equator. Universal Transverse Mercator (UTM) is the most commonly used projection in modern surveying. We developed a set of optimized UTM conversion routines and embedded them into a special version of Slang.

Hardware hurdles

During AirNAV's development we had to deal with a number of hardware issues:

Small footprint computer

Getting FAA approval for a system is a lot easier if it"s not a permanent fixture inside the cockpit of an aircraft. We selected a small-footprint computer that could be removed after each flight. AirNAV's platform consists of a mouseless, keyboardless, 100MHz Pentium industrial PC with 16M of RAM and a Cirrus Logic VGA controller.

MUX development

The physical dimensions and circuitry of the MUX box were continually being redeveloped until our partner arrived at a hardware platform that addressed our timestamping and multiplexing requirements.

Touchscreen options

We evaluated several makes of touchscreens, but most lacked visibility in strong sunlight. We settled on a Dolche 9.4-inch, flat-panel, monochrome, transflective display with an anti-glare touchscreen from Intellitouch.

The AirNAV system also incorporates other assorted hardware including a Terra 3500A radar altimeter, a GEM Systems potassium magnetometer, and a Novatel ISA GPS card.

By land or by sea

Most of the fun came when we got to do AirNAV's field testing. Because we had GPS receivers on ISA cards inside the computer, we were able to test the navigation features early in the development cycle. We spent several afternoons driving around Toronto collecting data and viewing our progress on the touchscreen display. Back in the office, we replayed the journey, zooming in and out to see every twist and turn we had taken.

The second phase involved testing the system in a boat in Ontario's cottage country. This proved useful because we could predefine a survey route that tied into real coordinates that represent landmarks on a map of the area. Once we input the survey route information, we went out in the boat traveling along the imaginary lines of the survey, testing the logic in the AirNAV engine as we went.

The testing in the car and in the boat proved extremely valuable for our development team because it allowed us to see the real-world behavior of the system without incurring the expense of a helicopter flight!

Running the system in playback mode allowed us to feed actual survey data into the AirNAV system and observe how the GUI and logging facilities reacted to data from a real flight. But it became clear that we also needed a way to simulate a test flight so that we could really stress the system. To do this, we created a flight simulator that allowed our developers to fly an imaginary helicopter from the keyboard and put the system through many different scenarios.

The result was that we were able to thoroughly test all aspects of the system before we actually took it up for a test flight. During our first test flight from Toronto's Buttonville Airport, we were encouraged to find that the problems we encountered were either hardware-related (which could be fixed) or display- related (which were even easier to fix).

AirNAV in action

AirNAV is currently enjoying its first success in Alaska - an environmental company is using it to locate abandoned waste dumps. After fixing a few minor glitches related to extremely cold temperatures, we are pleased to say that the system has met all its goals.

We think several factors have contributed to AirNAV's success. First, thanks to QNX, the modular architecture allows for additional measurement devices to be added with minimal effort and with no significant effect on the performance of the current system. (The computer running the AirNAV system remains at around 70% idle even when all data streams are being used.) Second, the set of tools used to develop the AirNAV system are established products. With QNX and Cogent software, we"ve raised the performance and flexibility of navigation systems to a new level.