The following pages describe the aircraft navigation capabilities developed by the ATM project. The project team has developed a range of techniques which enable NASA to guide a remote-sensing aircraft, and its sensor swath, along a very precisely-defined path. A variety of hardware is used to implement these techniques, including computers, GPS receivers, visual pilot displays and electronic interfaces with aircraft systems. When this hardware is packaged into equipment racks and installed aboard remote-sensing aircraft, it is known as the “GPFMS” system.
Although developed specifically to meet the needs of the ATM project, the GPFMS system has proven to be useful to others in the airborne science community who require precise aircraft steering. Some of the projects which have utilized the system are the 2003 and 2006 Arctic sea ice experiments, the 2003 and 2004 Antarctic sea ice experiments, and the Global Ice Sheets Mapping Orbiter (GISMO) project.
GPFMS System Overview
The ATM sensor was originally developed to measure changes over vast expanses of featureless Arctic ice cover. While many other applications for the ATM have arisen over the years, most of these applications share a requirement with the original one – the need to steer the aircraft, and the sensor swath swept along beneath it, on a precisely-defined path. ATM has mainly been used for change-detection, so typically it is used first to make a baseline measurement, then make a repeat measurement in the same location years later. Thus it is critical that new measurements be geographically consistent with past measurements.
This requirement originally centered around the need to re-occupy long straight survey swaths stretching for as much as hundreds of miles across the Greenland ice sheet. The ATM’s swath at that time was usually about 200 m in width, with the accuracy of the individual measurements better at the center of the swath than near the edges. Thus in order to measure ice surface change with high confidence, it was necessary that the swath of a new measurement set overlap the center of an old swath as much as possible. This translated into a cross-track navigation accuracy requirement of a few 10s of meters or better.
Fortunately in the early 1990s the GPS constellation was becoming operational, and with some advance planning to avoid times of poor coverage it could be relied upon to provide the needed real-time positioning accuracy. But how could the GPS signal be utilized to steer a large aircraft (NASA’s P-3B Orion) so precisely? The NASA-developed CDI system provided the answer. CDI proved to be a reliable tool which enabled the ATM project to conduct the first island-wide multi-year surface change survey of the Greenland ice sheet.
p3 gpfms rack
GPFMS rack aboard the NASA P-3.
As the results of the Greenland change surveys came in, it gradually became clear that most of the change occurring on the ice sheet was happening around the edges, and especially along dozens of sinuous and relatively narrow outlet glaciers. Simultaneously, new applications for the ATM emerged. These included mapping of coastlines and of irregularly-shaped land features. The CDI system, geared toward steering an aircraft along straight lines dozens or hundreds of miles long, was not easily applicable to these kinds of surveys, nor was it ideal for steering an aircraft down a steep, winding glacier. Note that the “straight-line” paths we refer to here are actually segments of great-circle routes, and are treated as such by all of our navigation techniques.
In response to these emerging problems, NASA developed a second, and complementary, navigation technique for the ATM project. This system eventually became known as Soxmap. While both CDI and Soxmap provide visual cues to help a pilot steer an airplane in order to meet its science goals, Soxmap is more suitable for non-straight survey lines and for area mapping, while CDI provides better repeatability and more automation for straight-line surveys. The ATM team often employs the two systems in tandem, with the navigation operator simply switching the flight crew’s display between the two systems, selecting whichever system is most appropriate for a given situation.
Combined GPS/GPFMS rack being installed aboard a commercial Twin Otter.
The ATM project, depending on the application, either utilizes Soxmap as a standalone navigation system (usually on smaller aircraft such as Twin Otters), or packages CDI and Soxmap together in a single equipment rack and uses the two systems as complements to each other (most often on larger aircraft such as P-3s). In whichever form, the ATM’s navigation hardware has become known as the “GPFMS” system. The origins of this name or acronym are unclear. FMS refers to a flight management system, and GP perhaps devolved from the GPS basis of the navigation techniques. At any rate, the term “GPFMS” somehow circulated among NASA’s airborne science community and this generic navigation capability developed under the ATM project now carries the label GPFMS.
The components of the GPFMS system include an equipment rack populated with one or more computers and ancillary equipment which might include an uninterruptible power supply (UPS), signal generator and GPS receivers. It also includes a remote display for the flight crew, and in some cases an electronic interface between the GPFMS rack and the aircraft’s instrument landing system, or ILS.
The CDI System
CDI, or course-deviation indicator, consists of a DOS computer program, GPS serial input, and sometimes a radio-frequency interface with the aircraft’s instrument landing system, or ILS. The CDI program accepts as input an ordered sequence of latitude/longitude waypoints, and NMEA position strings from a GPS receiver over a serial connection. The GPFMS operator selects the current waypoint pair which the aircraft is flying between, and the program computes a great-circle path between the selected pair and the cross-track offset between the current GPS position and this path. This constantly-updated offset is displayed on the computer screen to the operator, and via the remote display, to the pilot. The graphical presentation shows a rudimentary, zoomable “map” of the waypoint geometry, textual information regarding current position, speed, course, and cross-track error, and a series of “needles” which cue the pilot to steer the aircraft onto the desired great-circle path. This “needle” presentation is similar to that provided by aircraft instrumentation such as VORs and is instantly familiar to a pilot.
This graphical presentation to the flight crew can be used by itself to adequately steer an aircraft for an ATM mission. But CDI goes a step further and provides a steering signal which can be used by an ILS-equipped aircraft to steer itself automatically. The system generates an RF signal which can be tuned to the frequency of the host aircraft’s ILS equipment, and the signal can be piped into the ILS equipment by means of a coaxial cable from the GPFMS rack into the ILS antenna cabling. The pilot can select that input to his ILS system, couple the autopilot to it and the airplane will be steered automatically along the desired flight path. For long flights of many hours along straight lines, this automated technique often gives better steering repeatability than flying the lines manually.
So why is the system still DOS-based? Originally developed in the early 1990s, when DOS was a commonly-used operating system, the hardware performed adequately and was easily maintained. Maintenance is now an issue, as DOS has long since been superseded by more modern operating systems, and modern hardware may not operate at all under the old DOS. The code could be ported to a modern Linux or Windows system fairly easily. However, the system can be used to actively steer an aircraft in-flight and is therefore considered relevant to safety-of-flight. As such, a major modification to CDI, such as a port to a new operating system, would probably require lengthy and expensive certification procedures. Thus we have chosen to retain the old DOS systems even though they are becoming increasingly difficult to maintain. Sufficient stocks of spare parts are on hand to keep DOS-based CDI operating for several more years.
The Soxmap System
Soxmap is a Linux-based computer program designed to provide visual guidance to a pilot, helping him steer an aircraft along a flight path of arbitrary shape. This is in contrast to CDI, which aids steering along a straight line (or series of straight lines). Soxmap is also useful for area-mapping applications, where the flight objective is to fill a specified geographic area with parallel sensor swaths. UnlikeCDI, it does not provide an electronic interface with the aircraft systems, just a visual display for the flight crew. The system provides a highly specialized moving map display to the operator and to the pilot, showing a graphical representation of the scan swath currently being laid down by the onboard sensor in relation to the desired position of the scan swath. The scan swath (and the sensor target, if applicable) are drawn to scale on the moving map, which provides immediate visual feedback about whether the desired degree of overlap between sensor swath and sensor target are being achieved. Soxmap can also be configured to display waypoints for the mission, through its intuitive menu-driven interface.
Soxmap screen shot, showing a target path in small white circles, with the current sensor swath shown in green.
An example of an area-mapping application of Soxmap, showing three parallel sensor swaths with approximately 20% overlap.
Soxmap is written in C++, uses the widely-available Qt library for its GUI functionality, and runs readily on modern Linux operating systems. It does not depend on a serial connection with a GPS receiver to provide its real-time position updates. Instead it prompts the user, upon startup, for a network server of real-time position data. In ATM operations, the network service is provided by computers elsewhere aboard the aircraft running GPS data-logging software, but it can be provided in a variety of other ways as well, such as by a standalone program running on any workstation in communication with a GPS unit. This design feature frees the system from the requirement of a direct connection to a GPS receiver, enabling any networked workstation aboard the aircraft to independently run the program. So in addition to being a primary navigation tool for science operations, it is also a useful situational awareness tool for personnel anywhere on board the aircraft, such as a principal investigator or a sensor operator.
Examples of Navigation Performance
How accurately can we steer an aircraft along a desired track, using the GPFMS? We address this question with a pair of example plots, shown below. In these plots, the actual trajectory of the aircraft is compared to a great circle path between pairs of the waypoints used for navigation. The actual trajectory used for the comparisons is the ATM “precise trajectory” product, derived post-mission from GPS differential phase data and accurate to about a decimeter or better. The difference, or cross-track error, between the two is a combination of the real-time GPS positioning error (usually a few meters) and the control error which arises from the attempt to fly the aircraft along the desired track (typically a few 10s of meters).
The plot immediately below shows a typical example of the cross-track error as the CDI system, coupled to the autopilot on the NASA P-3, steers the aircraft along a spacecraft’s ground track for several hours. During this time the error never exceeded (or even approached) 100 meters, and stayed within 50 m for most of the period. The error tends to oscillate within a deadband of a few 10s of meters. In this case the error also contained a bias of 20-30 m, with the aircraft tending to remain slightly to the left of the desired track. This tends to occur when the flight is under the influence of a crosswind.
Cross-track steering error for a portion of the 24 March 2006 NASA P-3 flight, over the Chukchi Sea and Arctic Ocean north of Alaska. This mission utilized the CDI system, which was coupled to the autopilot and thus steered the aircraft directly.
The next plot illustrates the cross-track error for a Twin Otter flight. In this case the aircraft was steered using Soxmap. Many ATM Twin Otter flights take advantage of the slower speed, and hence the additional maneuverability, of that aircraft to concentrate on science targets suitable for Soxmap navigation, such as winding glaciers and coastlines. The 23 May 2006 Greenland flight was a bit different, in that it consisted of a pair of long, straight legs with an inflection point between them. The GPFMS rack installed for that project did not have CDI functionality, so we used Soxmap instead. This makes this mission ideal for this navigation performance comparison ofSoxmap to CDI, since it compares the two in similar applications.
This plot shows roughly similar steering accuracy for Soxmap as the previous plot showed for CDI. The errors lie mostly within a +/-50 m envelope, with a few exceptions. Note that since Soxmap is just a visual guide and cannot automatically steer as CDI can, this plot reflects a few spots where momentary pilot inattention or intentional diversions (for weather, traffic, etc.) took the aircraft temporarily off track. This mission shows no significant cross-track bias, although a cross wind can have a similar effect on Soxmap navigation as it has on CDI.
Cross-track steering for a portion of a 23 May 2006 Twin Otter flight over northwest Greenland, using manual guidance with Soxmap.
Both of these examples show quite typical navigation performance of the respective techniques. Strong crosswinds or turbulence sometimes degrade the steering accuracy somewhat; often the performance is better. For the purposes of the ATM, with its sensor swath of 200 m or more, this level of navigation performance is more than adequate.