Autonomous Navigation for Deep Space Missions Downloaded by NASA JET PROPULSION LABORATORY on November 27, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.2012-1267135 Shyam Bhaskaran 1 Jet Propulsion Laboratory, Pasadena, CA, 91109, USA Autonomous navigation (AutoNav) for deep space missions is a unique capability that was developed at JPL and used successfully for every camera-equipped comet encounter flown by NASA (Borrelly, Wild 2, Tempel 1, and Hartley 2), as well as an asteroid flyby (Annefrank). AutoNav is the first on-board software to perform autonomous interplanetary navigation (image processing, trajectory determination, maneuver computation), and the first and only system to date to autonomously track comet and asteroid nuclei as well as target and intercept a comet nucleus. In this paper, the functions used by AutoNav and how they were used in previous missions are described. Scenarios for future mission concepts which could benefit greatly from the AutoNav system are also provided. I. Introduction F or over 40 years, nations have sent spacecraft to visit other natural bodies in the Solar System. The mission profiles have included high speed flybys, rendezvous and orbit, and landings. One of the challenging aspects of flying deep space missions is navigation, that is, knowing where the spacecraft is at any given time (orbit determination), and controlling its path to achieve desired mission objectives (maneuver control). For the vast majority of deep space missions, this process is performed on the ground using standard radiometric tracking data (two-way Doppler, two-way range, Delta-DOR), and, when required, onboard optical data (images taken by the spacecraft camera of nearby target bodies). This combination has worked well and resulted in remarkably accurate navigation over the years. Despite its success, one of the inherent drawbacks in ground-based navigation is the delay caused by the roundtrip light-time – the time it takes for a two-way radio signal to be transmitted from an Earth ground station, received by the spacecraft and retransmitted back to Earth, and finally received by the Earth. For Earth orbiting missions, this delay is negligible, but for interplanetary missions, this can be several tens of minutes to many hours long. Thus, it is always necessary that the delay be accounted for in performing navigation functions. In addition to this physical limitation, there is also the delay needed to process the data once it gets to the ground which includes the time needed to perform the orbit determination and maneuver calculation computations, analyze the results, convene meetings and make decisions on what to do, implement the decision in terms of spacecraft commands, and finally transmit the commands and execute them on the spacecraft. The end-to-end process can be very time consuming and typical mission scenarios call for many days to over a week to perform these functions for non-time critical maneuvers or sequence commanding, down to many hours for very critical events. Even best case scenarios require over eight hours for the process. As a result, the latest and best information about the spacecraft’s location is not used to execute the current event; the net loss could be for mission parameters such as fuel needed for the mission, or for science as the instruments aren’t pointed exactly where they should due to imprecise knowledge of where the spacecraft is. Often, it’s a loss for both, such as not having the best spacecraft control of atmospheric entry parameters to achieve the most accurate landing on a planetary body such as Mars. One obvious way to overcome this limitation is to perform some, or all, of the navigation functions onboard the spacecraft. This not only eliminates the light-time delay but also circumvents the human-related delays for performing the navigation functions as described above. Thus, the turnaround time can be theoretically reduced to minutes, or even seconds, for reacting to late-breaking navigation information. A system to perform the navigation function autonomously onboard the spacecraft can enable certain classes of missions and greatly enhance science return on others. At JPL, we have developed such a system, called AutoNav, and applied it to several missions. A 1 Supervisor, Outer Planet Navigation Group, Mission Design and Navigation Section, MS 264-820, 4800 Oak Grove Dr., Pasadena, CA 91191. Copyright 2012 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner. Downloaded by NASA JET PROPULSION LABORATORY on November 27, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.2012-1267135 particularly useful application of AutoNav has been in the small body (asteroids or comets) flyby scenario, where the ephemeris of the target body is a major source of error. Using standard ground navigation techniques, the sequence of pointings to track the object through closest approach must be designed ahead of time, and the knowledge of the target-relative state of the spacecraft is not accurate enough to point the narrow angle cameras exactly at the target. Thus, mosaics were used to cover the uncertainty ellipse of the position estimate by rastering the camera across it, resulting in a substantial portion of the images being of empty sky. Onboard updates of trajectory knowledge enable rapid turnaround for closed-loop control, and in all the flybys that used AutoNav, most or all of the images taken had the target body in the camera FOV. If the objective is to impact a small body (as in the case of the Deep Impact mission), the mission simply could not have been accomplished without AutoNav due to the same lack of accurate target-relative navigation information as in the flyby case. In this paper, we will describe the basic functions and algorithms used by AutoNav, its use to date, and present cases where it can be very useful in the future. II. AutoNav Overview Although in principle AutoNav can be used with any data type, in practice it is most straightforward to use data that are self-contained onboard the spacecraft. Radiometric data requires either a link with stations on the Earth (and thus having to deal with issues such as scheduling the station, and modeling time varying atmospheric delay effects on the radio signal), or other spacecraft (thus having at minimum some knowledge of where the other spacecraft is). Self-contained data, on the other hand, only requires controlling instruments on the spacecraft itself and includes such data as optical images, lidar, or radar altimetry. The current AutoNav system relies exclusively on optical images as the data type, so the remainder of the paper will focus on the use of this data. The principle behind an optical-based navigation system is that the images taken of a natural body, either from a distance, or close-up, provide one or more line-of-sight (LOS) vectors to that body, or to locations on that body. So, for example, to navigate a spacecraft in an interplanetary cruise scenario, images can be taken of visible asteroids or the planets. By using a centerfinding technique, the brightness center of the unresolved (the extent of the target body is less than a CCD pixel) target object provides the inertial LOS vector. The inertial pointing direction of the camera is obtained from the stars in the frame. A succession of these images provides multiple LOS vectors which are then input into a non-linear least-squares filter to estimate the spacecraft’s position and velocity. The accuracy of this method depends on many factors, including the camera system parameters, the distance to the target objects, the frequency of the images, and the knowledge of the ephemerides of the targets. An example of the accuracy of this technique as it was used on the Deep Space 1 (DS1) mission will be given later. For the flyby or impact scenario (which forms the bulk of AutoNav use to date), the images taken are solely of the target body, starting minutes to hours before closest approach. In this scenario, any error in the heliocentric trajectory of the target body and spacecraft are folded into the spacecraft’s trajectory error relative to the target alone. Once again, centerfinding on the body in a series of images provides a sequence of LOS observations. Here, however, the target will become resolved (its extent will be greater than a detector element (pixel)) at some point in the sequence and so the method for centerfinding will be slightly different. The initial images provide a direct measure of the closest approach location in the crosstrack (perpendicular to the incoming asymptote) axes. As the spacecraft gets nearer to closest approach, the changing geometry provides very accurate information about the spacecraft’s location in the downtrack, or time-of-flight, axes. Examples of this use for the DS1, STARDUST, and Deep Impact (DI) missions will be provided later. For the orbiting scenario, the images are of the extended body being orbited, and the body either fills a substantial portion of the camera frame or extends considerably beyond it such that each image only sees a portion of the body. In this case, the objective is to locate landmarks on the body that have been previously identified and whose body-centered position is known to some accuracy. Analogous to the deep space cruise scenario described above, the coordinates of each landmark in the frame provide a LOS vector to that landmark. If three landmarks are available in a frame, then the 3-D position of the spacecraft and the three components of the camera boresight pointing can be solved for deterministically. More than three landmarks in a frame allows a least-squares fit of the kinematic position and boresight pointing vector at each image time. Combining a series of such measurements into a dynamic filter allows estimation of the complete trajectory of the spacecraft. This technique can be especially Copyright 2012 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner. Downloaded by NASA JET PROPULSION LABORATORY on November 27, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.2012-1267135 powerful in the proximity of small primitive bodies (asteroids and comets) where the gravitational pull is weak and therefore provides little signature in radiometric data; the geometric information provided by landmark tracking is essential to determining the orbit. The main restriction is that an a priori shape model with known landmark locations must be constructed prior to invoking AutoNav. Such techniques are available and documented1. All the above techniques can obviously be performed on the ground, with the penalty of turnaround time to get the solution. At its core, AutoNav simply takes the processes typically done by ground navigation teams and places these onboard a spacecraft. Thus, AutoNav must perform the following functions without human intervention: (1) process raw images into a form that can be used by the orbit determination filter, (2) perform orbit determination using the processed data by applying appropriate edits and weights and feeding the data into a least-squares filter, and (3) computing and executing maneuvers at appropriate times to guide the spacecraft to its destination. The product of these steps is the current, past, and predicted ephemeris of the spacecraft that can be used by other spacecraft subsystems, such as the Attitude Control System (ACS) or science instrument subsystems. Each of these AutoNav functions will now be described in detail. A. Image Processing The first step in AutoNav is to process images and convert them into an observation data point that can be input to an orbit determination filter. The images are obtained from an onboard camera whose various physical parameters (e.g., focal length, aperture) are determined by a combination of science and navigation requirements. In modern camera systems, the light is focused onto a Charge-Coupled-Device (CCD) mounted on the focal plane. The size of pixels in the CCD array, combined with the camera focal length, determine the resolution of the image and hence, the metric accuracy obtainable by the camera data. The number of pixels determines the total field-ofview. A filter wheel is often mounted in front of the lens to get color images, but for navigation, the clear filter is always used to maximize the light throughput and get the highest signal with the shortest integration time in order to reduce smear caused by spacecraft motion, as well as to reduce the exposure to cosmic rays and camera noise buildup. The dynamic range of the camera is determined by the digitization level, which in the past has varied from 8 to 12 bits per pixel for missions that used AutoNav. Regardless of the type of image being processed (unresolved object centroid location, resolved object centroid location, or landmark location), the optical observation data used by the OD filter are the (x,y) coordinates of the location in the detector, here referred to as the sample and line coordinates, in the camera frame. The basic steps used to determine the coordinates is the same as it is for ground-based optical navigation processing and depends on the image type2. 1. Unresolved Objects For unresolved objects (which include the stars and solar system bodies when they are distant), the signal from the light emanating from the object is effectively convolved with the pointspread function of the camera optics to create an image which extends over several pixels. The pointspread function can be approximated by a Gaussian function; by measuring the pointspread of bright, known stars, the parameters of the Gaussian function can be estimated. This information can then be used to locate the position of other stars and target object by overlaying the Gaussian function on the image and adjusting its position in a least squares sense to best match the image. For ground processing, the initial locating can be done by eye; onboard, the a priori location of the stars and object can used to determine an approximate location, and then a brightness centroid in the local vicinity can be performed to get a rough location. The Gaussian fit is then applied to fine tune the center location; the resultant accuracy is typically 0.05 to 0.1 pixels. It may turn out, however, that the exposure duration needed to for stars and/or Solar System objects to have a sufficient signal is longer than the ability of the spacecraft to maintain a stable attitude. In this case (as it was for DS1), the images are smeared such that the signal no longer appears as a Gaussian. A more sophisticated centerfinding method was developed for this purpose, originally to support the Galileo flyby of asteroid Gaspra3. In this method, a multiple cross-correlation method was used to accurately determine the pixel/line coordinates of the target relative to the stars. Copyright 2012 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner. 2. Resolved Objects Downloaded by NASA JET PROPULSION LABORATORY on November 27, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.2012-1267135 During flybys or the early phases on approach, the target object at some point becomes resolved. If the shape and orientation of the body is known, then a predicted image, given an initial guess of the location of the body relative to the spacecraft and the shading, can be generated and compared against the actual image. By correlating the predicted and observed image, the sample/line coordinate of the body can be determined as the point where the correlation is maximized, and this can be done to sub-pixel accuracy. In typical flybys or approaches for primitive bodies, however, the shape and orientation are not known. In this case, a brightness centroiding method can be used to determine a less accurate center location. The process must be robust such that the centroiding does not pick up extraneous bright spots, such as stray light or cosmic rays, so we have developed methods to mitigate these failure modes. One method in particular is dubbed the “blobber”. The blobber searches the image for all contiguous bright spots that are between a minimum and maximum brightness threshold4. Each “blob” is then listed and ordered in terms of size. Since the approximate size of the object is known, any blob which falls outside the range of possible sizes is deleted. The largest remaining blob is picked as the target, and a simple brightness moment algorithm is applied to the circumscribing box around the blob to get the centroid. This process has been found to be very robust in numerous simulations and in actual flight. The accuracy of the centroid in determining the center of the target body can range from a sub-pixel level when the object is small in the FOV, to several tens or even hundreds of pixels as the object gets large. The reduced accuracy is still sufficient, however, to get accurate determination of flyby parameters. 3. Extended Object Landmark Tracking During extended operations in the proximity of a target, landmark tracking techniques can be used in an AutoNav system to get very accurate orbit information. The first step is to create a detailed shape and albedo model, which must be done on the ground. A technique developed recently (called OBIRON – OnBoard Image Registration and Optical Navigation) uses stereo-photoclinometry to generate the shape and albedo model, and tested on the asteroid Itokawa during the Hayabusa mission1. Once this shape model is created, for onboard use either part or all of the model parameters can be stored. As images are taken during the spacecraft’s path around the body, the scene in the image is compared against a computed scene based on the model; OBIRON will then locate and correlate landmarks on the surface. Each identified landmark then becomes a LOS vector, which as described above, can be input into an OD filter. This technique has yet to be demonstrated onboard, but has been used successfully on the Dawn mission for ground navigation. Prototype versions of AutoNav that include OBIRON have also been extensively tested in ground-based simulations. B. Orbit Determination Orbit determination is the process of combining a set of measurements to estimate the spacecraft’s trajectory (position and velocity) in a least-squares filter, as well as any ancillary parameters that affect the observations or the trajectory. Examples of the former are spacecraft attitude or camera bias errors; the latter includes such things as solar pressure scale factors, or miscellaneous un-modeled accelerations. The OD process in standard ground-based navigation is well known and documented5, but there are some factors to consider when applying it to an onboard system. The important ones will be described here. 4. Data Editing Large outliers in the measurement data set, whether random or systematic, can corrupt an OD solution if not removed prior to filtering. Thus, instead of using data immediately as they become available, we first store a series of measurements. After a predefined set of measurements have been taken, the data are statistically analyzed to remove outliers. If, after some length of time, enough data has not been accumulated for whatever reason, the filter is not invoked, with the philosophy being that it is better to stick with a previous, known good solution that might be stale as opposed to risking getting bad data into the solution. The parameters chosen for the data editing are mission and scenario specific, and are usually determined by running numerous Monte Carlo simulations on the scenario to see what parameter set yields the highest probability of success. Because the optical data set is very sparse (data appears at the rate of one every several minutes as opposed to 1-10 Hz for radiometric data), the choice of editing Copyright 2012 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner. parameters is crucial and a good portion of ground testing is devoted to this task. Once the data passes the statistical tests, they are passed to the orbit determination filter. Downloaded by NASA JET PROPULSION LABORATORY on November 27, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.2012-1267135 5. Force Modeling For ground-based navigation, the force models that describe the trajectory of the spacecraft are chosen to be as high fidelity as possible since radiometric tracking data are of very high accuracy. Also, with modern computer systems, the speed of the numerical integration (both trajectory and state transition matrix) and partial derivative generation is not usually a constraint. Onboard, however, speed does become an issue since spacecraft processors are not generally as fast as the latest available on the ground, and rapid turnaround is important for certain scenarios, such as high-speed flybys. We thus limit the force modeling for AutoNav to include central and third body point mass gravitational accelerations, simple flat plate or sphere model for solar radiation pressure, and instantaneous ΔVs for chemical propulsion maneuvers, and linear polynomials for low-thrust maneuvers obtained from ion propulsion systems6. To get the latest information about thrusting events in the past, thruster activity is converted to a “non-grav history file”, which accumulates and records the ΔV as a function of time; this file is read into the trajectory propagation as discrete events which change the instantaneous velocity at the recorded time. A faster AutoNav version was also created specifically for use on comet and asteroid flybys, and used on DS1 and STARDUST. This version, dubbed the Reduced State Encounter Navigation (RSEN), simplified the trajectory by modeling it as straight line motion past the body. At the time AutoNav was initiated (tens of minutes prior to encounter), the trajectory was initialized with the best ground-based position and velocity, and the velocity was not updated through the flyby. For these effectively massless bodies, this model has sufficient accuracy, as was proven in flight7. 6. Filtering Filtering is the processing of obtaining a least-squares fit to the trajectory using the available data. For many applications in the Aerospace field, a Kalman filter formulation is used, where, as each data point becomes available, it is used to update the filter. This works well for situations where very high frequency data are available and rapid filter updates are needed, such as for attitude control or missile guidance, but for most deep space applications, this speed is not necessary. Furthermore, as was described above, optical-based AutoNav has a sparse data set and needs to be pre-edited. For this reason, we chose a batch filtering approach, where data are stored, edited, and then input to the filter. The filter uses variations on the batch formulation which solves for the state at some epoch time. After iterating the filter to convergence, the epoch state solution is integrated forward to get the complete trajectory from epoch to some future time. Details on the filtering method used by AutoNav are provided in Ref. 6. C. Maneuver Planning and Execution Once an OD solution is performed and the current best estimate of the trajectory available, it must be evaluated to see if the predicted path satisfies the mission requirements. If it doesn’t, then maneuvers are needed to re-target the course. The current version of AutoNav can handle two types of maneuvers, low-thrust (such as for an ion propulsion system), and near instantaneous (for standard chemical propulsion systems). In both cases, the optimization of the maneuvers needed to minimize fuel consumption, flight time, or other parameters, is done on the ground. Thus, the times and (in the case of low-thrust) overall duration of the burn is pre-planned. AutoNav will then perform adjustments to the nominal burn in a linearized fashion; the partial derivative of the burn parameters with respect to the target parameters are evaluated on the pre-defined reference trajectory. This Jacobian matrix is inverted to get the values of the burn, with several iterations being necessary to converge the solution. It is possible that the solution will not converge if the deviation from the reference is large, and in this case, the ground must intervene. It is envisioned that future versions of AutoNav will have the ability to do its own re-optimization of the trajectory if the course has strayed far from the reference. For low-thrust maneuvers, the ΔV imparted can last anywhere from many hours to several months, depending on the mission phase and time to go relative to the target condition. The approach used was to break up the ground optimized continuous thrust profile into linear segments, with each segment consisting of the Right Ascension (RA) Copyright 2012 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner. and Declination (DEC) of the thrust vector, and the magnitude of the thrust. Using the linearized method described above, the RA/DEC of multiple segments were adjusted from the nominal, based on the current best OD solution8. Impulsive burns are much simpler. Each maneuver can be solved for independently, with the three parameters of the burn able to control two or three target parameters. For flybys of primitive bodies, the target parameters are the location in the “B-plane” – a plane perpendicular to the incoming trajectory and centered on the body – and the time of closest approach. If the encounter time is not critical (such as for an impact), then just the two parameters in the plane can be targeted9. For proximity operations scenarios around a body, the target parameters can be waypoints along a reference trajectory or the landing location on the body10. Downloaded by NASA JET PROPULSION LABORATORY on November 27, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.2012-1267135 III. Mission Results AutoNav has been used successfully on five missions: Deep Space 1, STARDUST, Deep Impact, EPOXI (the follow-on mission to Deep Impact), and STARDUST NExT (the follow-on mission to STARDUST). A brief description of these missions and how AutoNav was used on them will be given in this section. Since fast flybys were the main use of AutoNav in these missions, Table 1 provides a concise tabulation of the various parameters of the flyby, including the approach phase angle, flyby velocity, and flyby distance. Table 1. Summary of flybys which have used AutoNav to date. Mission/Target DS1/Borrelly STARDUST/Annefrank STARDUST/Wild 2 DI/Tempel 1 EPOXI/Hartley 2 STARDUST NExT/Tempel 1 Flyby Radius (km) 2171 3076 237 500 694 182 Flyby Velocity (km/s) Approach Phase (deg) 16.6 7.2 6.1 10.2 12.3 10.9 65 150 72 62 86 82 D. Deep Space 1 DS1 was the first mission in the NASA’s New Millennium Program. This program was intended to fly unproven, high-risk technologies and validate them in flight so that subsequent science-focused missions could then use these technologies. Twelve such technologies were flown on DS1; among them were the first deep space ion propulsion system, a low mass combined visible/infrared/ultraviolet imaging system (named MICAS – Miniature Imaging Camera and Spectrometer), and the first onboard autonomous navigation system (AutoNav). The spacecraft was launched in October 1998, and the original mission plan included flybys of the asteroid Braille and the comets Wilson-Harrington and Borrelly. During flight, however, the failure of the only onboard star tracker following the Braille encounter resulted in a long period where onboard software was modified to fly the spacecraft without the star tracker, resulting in the loss of the Wilson-Harrington encounter. DS1 flew by Braille in July 1999 and Borrelly in September 2001. For AutoNav, the original plan was to use it to navigate the cruise and flyby portions of the mission. OD for the cruise portion would be handled by using bright asteroids in the asteroid belt as beacons as described in Section II. The choice of which asteroids to choose was done on the ground and uploaded to the spacecraft. At roughly weekly intervals, a 4-6 hour block of time would be used to cycle through a list of pre-planned beacons and image each of them. The centroiding of the stars and asteroid provided the raw data for the OD filter, which then computed the spacecraft’s trajectory. Weekly segments of ion thruster pointing direction vectors for the future were then computed by the maneuver planner. Pre-flight analysis of this process indicated that the accuracies obtainable from the system were sufficient to guide the spacecraft to the vicinity of the next flyby target body6. These plans had to be abandoned after the initial images from MICAS revealed several unforeseen camera problems that affected how it could be used by AutoNav. The three biggest issues were that the pictures were Copyright 2012 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner. Downloaded by NASA JET PROPULSION LABORATORY on November 27, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.2012-1267135 heavily corrupted by stray light, the sensitivity of the camera was not at the expected level, and the camera distortions were unusual and proved to be difficult to model11. This resulted in many months of reprogramming AutoNav to handle these problems. As a result, the validation of onboard OD did not occur until the summer of 1999, a few months prior to the encounter with Braille. From June through end of July 1999, until preparations for the encounter were started, AutoNav was performing OD and maneuvers and the results sent to the ground. Since standard radiometric ground-based navigation was being performed concurrently, we could compare the results of AutoNav with the ground “truth”. The accuracy of the solutions as compared to the ground is plotted in Fig. 1, which shows the OD was good to roughly 500-2000 km, and 0.2-0.8 m/s. The formal uncertainties of the solution are also plotted, indicating the error was at the level of the uncertainty, or as good as can be expected. However, due to the camera anomalies, this wasn’t as good as the pre-flight planning had indicated, so some of the targeting maneuvers were done with ground intervention in order to achieve the Braille flyby. The Braille flyby also was problematic. Due to an AutoNav software error, the spacecraft experienced a safing event 18 hours before encounter. After recovery, maneuvers were planned from the ground to retarget the flyby. At about 30 minutes prior to closest approach, the RSEN version of the code was initiated to begin closed-loop tracking of Braille. RSEN was, at that point, updating the OD after every image, but using images from a not-well calibrated alternate APS (Active Pixel Sensor) detector. In the first image taken of the asteroid, the asteroid itself was too dim to detect, but a random cosmic ray was and resulted in RSEN updating the spacecraft state from erroneous data. This effectively took the asteroid out of the camera field-of-view; no further updates occurred since no asteroid was Figure 1. Orbit determination results from DS1 cruise11. subsequently detected, and the closest approach images were lost. A major outcome of this failure was the restructuring of the code so that rigorous error checking was performed before ingesting the data. It was also subsequently determined that the APS detector was non-functional for anything but the brightest signals Following the flyby, AutoNav was once again put in control of the low-thrust “cruise” to the next encounter. However, in August 1999, the sole onboard star tracker failed. Since the spacecraft relied on the star tracker to provide attitude knowledge, the mission had to be put on hiatus until a workaround using MICAS as an alternate star tracker could be found. The mission was restarted late in summer of 2000, but the Wilson-Harrington encounter was lost and AutoNav could no longer be used for cruise. By the summer of 2001, the revised RSEN AutoNav code was ready for the Borrelly flyby planned for September. Among the revisions was a change to accumulate data in batches and pre-edit data before use by the filter, robust error checking, and the use of the “blobber” to weed out random cosmic rays and identify the actual target. The flyby itself occurred on September 22, 2001. RSEN was initiated at Encounter (E) – 32 minutes and initialized with ground-based navigation information from E – 12 hours. The uncertainty in the spacecraft’s comet- Copyright 2012 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner. relative position was roughly 15 km the cross-track directions, and 200 km (or equivalently, 12 seconds) in the downtrack directions. Unlike the Braille encounter, AutoNav performed as expected, capturing the nucleus in 45 out of the 52 total images shuttered. The closest image was taken at E – 2 min, 45 sec, at a distance 3556 km and resolution on the surface of 46 m/pixel (these were the highest resolution images of a comet taken to date). After this time, the comet drifted out of the camera FOV due to known limitations in the spacecraft’s ability to turn the spacecraft at a fast enough rate. Following the flyby, both the mainline and RSEN AutoNav were validated as part of DS1’s technology demonstration. Downloaded by NASA JET PROPULSION LABORATORY on November 27, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.2012-1267135 E. STARDUST STARDUST was the fourth mission in NASA’s Discovery Program. The primary goal of the mission was to fly through the tail of comet Wild 2 and return samples of the coma back to Earth, with a second goal to also capture high resolution images of the comet’s nucleus during the flyby. The spacecraft was launched on February 7, 1999, encountered Wild 2 on January 4, 2004, and successfully returned a coma sample to the Earth on January 6, 2006. En route to Wild 2, the spacecraft also flew by asteroid Annefrank, which was used as an engineering demonstration to practice the Wild 2 flyby. As for DS1, the RSEN flavor of AutoNav was used for closed loop tracking of the nucleus during the flyby. The development of AutoNav for STARDUST closely matched that of DS1, and the lessons learned from the Braille and Borrelly flyby’s were incorporated into STARDUST. Algorithmically, the code was nearly identical to the final DS1 version, with the primary difference being that STARDUST used a unique camera/scan mirror combination for imaging. The camera itself was fixed along one of the spacecraft axes, but a mirror was placed in front of the camera lens that could rotate about 180 deg about the boresight axis. This allowed the camera FOV to sweep along a plane from the front to the rear of the spacecraft and thus, the spacecraft attitude to remain fixed while the mirror handled the motion of the comet, provided the comet was in the sweep plane7. The modifications in the code from the DS1 version were mainly for accommodating this camera geometry. The opportunistic encounter with Annefrank occurred in November 2002 which allowed a practice run for AutoNav before the main event. This was in some ways more challenging than Wild 2, primarily because the approach phase angle to the asteroid was 150 deg, resulting in poor visibility on approach. In fact, the asteroid was never seen in ground processed approach Optical Navigation images, and AutoNav was initiated at E – 20 minutes with no ground updates to the target-relative ephemeris. Nevertheless, AutoNav did successfully track Annefrank through the flyby, providing extra confidence that Wild 2 would also be successful. For Wild 2, AutoNav was initiated at E – 30 min using the best ground-based target relative trajectory solution at E-48 hours. The cross-track uncertainty was around 5 km, and the downtrack was 2000 km (or equivalently about 50 seconds). The large downtrack uncertainty was a consequence of poor ephemeris knowledge of the comet from Earth-based astrometry, due to the large distance to Earth at the time of encounter (> 2 AU), and the low elevation, resulting in poor astrometry. After initiation, AutoNav took images at 30 second intervals; the first OD update after accumulation of the data was at E-10 min. In order for the flyby plane to be aligned with the mirror sweep plane, the OD from AutoNav was used at Figure 2. Sequence of STARDUST AutoNav images of Wild 2 surrounding E-4 min to perform a spacecraft encounter. Copyright 2012 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner. Downloaded by NASA JET PROPULSION LABORATORY on November 27, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.2012-1267135 roll to make this alignment. Following the roll, the images were taken at a faster rate, every 20 seconds, to better capture the close approach images. AutoNav was terminated 8 minutes past the nominal time of closest approach. Examination of the post-encounter telemetry and images indicated AutoNav had successfully tracked Wild 2, with 114 total images taken and all capturing the nucleus. The closest image was shuttered at E – 4 seconds at a distance of 239 km and a resolution of 14 m/pixel. Fig. 2 shows a sample of the sequence of images surrounding closest approach. F. Deep Impact DI, the eighth mission in NASA’s Discovery Program, had the most challenging use of AutoNav Figure 3. Impact points after each maneuver on DI to date. The goal of the mission was to perform a Impactor spacecraft9. high speed impact of a comet with one spacecraft while observing the event with another. The flyby/impactor combination was launched on January 12, 2005 for a 6 month cruise to impact comet Tempel 1 on July 4, 2005. Several maneuvers in the weeks leading up to encounter targeted the dual spacecraft for the impact. Twenty-four hours before encounter, the impactor separated from the flyby spacecraft; the latter then performed a large deflection burn to target a 500 km altitude flyby and slow the spacecraft down so it would arrive at closest approach 10 minutes prior to the impactor. Both spacecraft performed their functions successfully and images from the impactor as it approached Tempel 1 and the flash resulting from the impact were sent to the ground for analysis. DI used standard ground radiometric and optical navigation techniques for the cruise and approach phases of the mission. AutoNav was used only in the hours prior to the impact event and had dual roles. On the Impactor, AutoNav needed to use its own onboard calculated maneuvers to guide the spacecraft to a sunlit area on the comet nucleus, and bias the impact site towards the side where the flyby spacecraft had its closest approach. On the Flyby spacecraft, no maneuvers were computed but AutoNav needed to maintain camera lock on the nucleus and predict where the impactor would hit, as well as determine the time of closest approach and initiate a highrate imaging sequence. Since maneuvers were needed on the Impactor, the full AutoNav version was used, and then to maintain consistency, the same version was used on the Flyby. The bulk of the computational elements of the DS1 AutoNav code was used without modifications on DI. One component that changed was the maneuver computations on DI were impulsive chemical burns, rather than the lowthrust maneuvers on DS1. The impulsive ΔV logic was simpler than that for low-thrust, so this modification was relatively simple. DI also had a few additional capabilities needed. These included code to perform: (1) “scene analysis” – selecting the actual impact site to be on a lit area of the nucleus, (2) time-of-impact and time-of-imaging updates – these synchronized the timing of the imaging sequence starting on the flyby based on the Impactor’s expected impact time, and (3) autonomous coma cutoff – a modification to process the comet images for ensuring that the brightness centroid is on the nucleus and not corrupted by coma12. Because AutoNav was critical to the Figure 4. Impact as viewed from DI Flyby spacecraft. Copyright 2012 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner. Downloaded by NASA JET PROPULSION LABORATORY on November 27, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.2012-1267135 success of the mission, extensive ground testing was performed to verify that AutoNav would work as planned. Since the lack of knowledge of what the comet nucleus would look like was a large error source, much of the testing involved simulating all types of comet nuclei to see how AutoNav would respond. One result of the simulations discovered after the spacecraft had launched was that subtle interactions between the attitude estimated by the Attitude Control System and AutoNav estimates of the comet-relative velocity could cause the targeting maneuver to behave somewhat erratically. Nevertheless, overall, the simulations indicated that, barring an unforeseen failure in the flight system, the probability of success for the impactor was greater than 99%12. Based on these results, the scenario for AutoNav on the Impactor was baselined. AutoNav was initiated at E – 2 hours, with images taken at a rate of 4 images per minute. After 10 minutes of accumulating data, the first OD was performed; subsequent OD solutions were computed every minute. Three targeting maneuvers were executed at E – 90 min, E – 35 min, and E – 12.5 min; their magnitudes were 1.27, 2.26, and 2.29 m/s, respectively. Post-flight reconstruction showed that, as was predicted, the first maneuver actually moved the spacecraft further away from the target than prior to the maneuver, but subsequent maneuvers successfully targeted to the nucleus, as can be seen in Fig. 39. The Flyby spacecraft also performed as planned, imaging the flash as the Impactor hit the nucleus (Fig. 4). The image was taken at a distance of 887 km at E – 72 seconds. AutoNav was terminated at E - 50 seconds so that the spacecraft could go into “shield mode” to protect the instruments from comet dust impacts through closest approach. G. EPOXI EPOXI was the follow-on mission to DI. It was selected as a NASA Discovery Mission of Opportunity flight in the summer of 2007. With the announcement of the selection, the DI flyby spacecraft, which had been placed in hibernation following the Tempel 1 encounter, was reactivated for a planned flyby of comet Hartley 2 in November 2010. Once again, ground-based navigation was used for the cruise and approach, and AutoNav was used just to track the nucleus on the flyby. Originally, it was assumed that running AutoNav for EPOXI would be relatively simple since there was no longer an Impactor spacecraft, the Flyby had performed successfully on the Tempel 1 encounter, and no code modifications were needed, only parameter updates. However, the detailed analysis of the changes needed in the Figure 5. Hartley 2 close approach image taken by EPOXI. Left panel shows the nucleus taken by the medium resolution imager, right panel shows an enhanced view from the high resolution imager that reveals the particles ejected from the nucleus. parameters to accommodate the different flyby geometry revealed some unforeseen complications. In particular, for the DI case, AutoNav was not engaged through the point of closest approach since the spacecraft went into shield mode. For Hartley 2, the minimum flyby altitude was roughly 700 km; any closer and the spacecraft ACS could not keep up with the turn rate. At this distance, analysis indicated that comet dust impacts were not of high concern, so the instruments could keep taking data throughout the encounter. Simulations of AutoNav performance in this time period showed that the same ACS/AutoNav velocity estimate interactions that were problematic for the Impactor on Copyright 2012 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner. Downloaded by NASA JET PROPULSION LABORATORY on November 27, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.2012-1267135 DI also caused problems when the spacecraft went through a 180 turn through encounter. Furthermore, the interactions with the spacecraft Fault Protection software also had to be carefully choreographed so that unintended behavior did not occur. Details of these issues and how they were resolved can be found in Ref. 13. The thorough analysis paid off in the end and AutoNav successfully tracked Hartley 2. One final surprise was that in the images nearest periapse, Hartley 2 was offset by almost a third of the camera frame from the center. The telemetry from AutoNav and the ACS, however, showed that everything had worked smoothly and the offset errors should have amounted to far less. It was finally discovered that the biasing on the DI Flyby to account for the Impactor hitting on the lit hemisphere was still resident in the spacecraft’s memory and had never been cleared. Fortunately, this bias was relatively small compared to the flyby distance; had it been larger, the close approach images might have been lost. In the end, the bias turned out to be fortuitous for science; the discovery of large chunks of ice ejected from the comet was found due to the offpoint14. Fig. 5 shows the closest image and an enlarged image of the ice discovery. H. STARDUST NExT NExT was the follow-on mission to the STARDUST mission. It was also a Discovery Mission of Opportunity, selected at the same time as EPOXI. NExT’s purpose was to revisit comet Tempel 1 and image the crater that DI created since the flash caused by the Impactor obscured a clear view of the impact site from the DI Flyby spacecraft. Another mission goal was to image more of the surface of Tempel 1. This would mark the first time in history that the same comet was visited more than once, and viewed before and after a perihelion passage. The mission used ground navigation for cruise and approach, and the same AutoNav code used on Annefrank and Wild 2 for Tempel 1. Because, unlike on EPOXI, the system was used in nearly identical fashion to the earlier encounters, analysis for the Tempel 1 encounter was straightforward. This flyby was considerably faster (10.9 vs 6.1 km/s), and was targeted to be a little closer (180 vs 250 km altitude), and so the parameter settings were adjusted to optimize the probability of success. Figure 6. Tempel 1 close approach image The two primary concerns were that the low flyby was at the taken by STARDUST NExT. limit of the scan mirror’s fastest rate, and the image rate after the spacecraft alignment roll turn was more rapid in order to get high resolution stereo images of the impact site. The former was a problem in that, if the rate exceeded the mirror’s capability, the images would be smeared and corrupt the AutoNav solution. The latter concern had to do with the ground navigation ability to predict and control the time of closest approach; if the error in the predicted periapse time was larger than +/- 2 minutes, it would be beyond the high rate imaging sequence and much of the stereo information would be lost. As it turned out, the timing was only off by 15 seconds, but the final radius was at 181 km and thus, one of the near images was slightly clipped as the mirror did not quite keep up. Nevertheless, AutoNav performed as expected and all science imaging requirements were met. Fig. 6 shows the closest approach image, shuttered at E + 3 sec at a distance of 184 km. IV. Future Mission Uses for AutoNav The original AutoNav code developed on DS1 has proved to be quite versatile, working successfully on five missions and four different spacecraft built by three different contractors. The code, however, is now well over a decade old, and the limitations imposed by the inexpensive, rapid development, needed to be fixed for future uses. Over the past several years, this has been undertaken with the next generation AutoNav in prototype use15.This version builds on the experience gained from AutoNav’s use in the missions described above, and incorporates many enhancements. The major ones are: (1) a new interface that is written in the Virtual Machine Language (VML), which allows for greater flexibility and ease of use, and (2) the addition of attitude guidance and control Copyright 2012 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner. merged with the current translational navigation capabilities, and (3) the landmark tracking capability using a flight version of OBIRON. This new version is now called AutoGNC to reflect the enhanced capability, and enables AutoNav use for scenarios where the translational and rotational motion are tightly coupled, such as landings or atmospheric flight. The code, however, is modular and flexible so that only the computational capabilities that are required for any specific mission need to be used. The following subsections describe possible missions where the use of AutoNav can be valuable. Downloaded by NASA JET PROPULSION LABORATORY on November 27, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.2012-1267135 I. Asteroid Deflection The possibility of a Near Earth Asteroid impacting the Earth and causing large scale destruction is of low likelihood, but very high consequence should it happen. One realistic option for mitigating this threat is to deflect the asteroid well before its Earth impact. The DI mission demonstrated that the technology is already available using AutoNav. The modifications needed to hit a much smaller target (potentially hazardous asteroids are typically in the 100s of meters or less in diameter, as compared to the 7 km diameter of Tempel 1), and at potentially higher velocities (perhaps as high as 20-25 km/s) represents an evolutionary, not revolutionary improvement. A point solution analysis for a specific example has been performed16. A full system trade study, simulating the range of possible asteroid sizes and shapes, would help to define the spacecraft and AutoNav performance necessary to execute the deflection reliably. J. Small Body/Lunar Pinpoint Landing The NEAR and Hayabusa asteroid landings demonstrated that such missions are quite feasible using ground-inthe-loop navigation at the tens of meters accuracy17,18. For future landings on asteroids or comets, it may be necessary to achieve accuracies of less than 5 m or better, either because of the lack of safe landing spots at larger scales, or to target very specific regions for science. Furthermore, it may also be necessary to tightly control the velocity at touchdown for spacecraft safety. This combination of requirements is very difficult, if not impossible, to do open loop from the ground due to the light time and other lags between the navigation knowledge update and control. AutoNav could be ideally suited for this type of mission, and Monte Carlo simulations have been performed that demonstrated this, achieving position control to within 3 m and horizontal velocity control better than 2 cm/s10. Simulations have also been performed for precision landings on the Moon, which show that landings to within 20 m are possible19. K. Aerobraking Aerobraking has been used on several Mars missions to modify the orbit of the spacecraft from its initial capture orbit to the final desired science orbit. The process is very operations intensive, and towards the end game, the frequency of atmospheric passes and maneuvers becomes very rapid, on the order of several hours. This requires large staffing to maintain round-the-clock coverage. Onboard AutoNav, using acceleration data from an onboard Inertial Measurement Unit, could reduce the staffing needed by maintaining the knowledge onboard and using it to control the drag corridor. AutoNav could also be used as a monitor to ensure spacecraft safety and perform an abort in case the orbit gets too low in the atmosphere. L. Outer Planet Satellite Tour The complex dynamics of the large satellite systems of Jupiter and Saturn allows for unique mission possibilities that can be enabled by AutoNav. By exploiting some of these dynamics, the delta-v can be reduced substantially for capture, or more satellites can be visited in a shorter amount of time20. These options do require, however, short turnaround times between successive satellite flybys. These types of missions would be difficult to do from the ground, making them another candidate for onboard automation. V. Conclusions Copyright 2012 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner. AutoNav is a technology that has matured to the point where its capability has been demonstrated in real-world applications repeatedly over the last decade. This paper described the basic workings of the system, and the examples of where it has been used. Some examples of future uses were also described, but there are many other situations that can be envisioned as well, and it is quite likely that descendants or variations on the system described will expand along with the range of mission possibilities. Downloaded by NASA JET PROPULSION LABORATORY on November 27, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.2012-1267135 Acknowledgments The development of AutoNav would not have been possible without the contributions of a number of people. I am indebted to the following people who made substantial contributions to the concept, design, testing, and operations of AutoNav and which resulted in its successes. These include: Matt Abrahamson, Shailen Desai, Don Han, Brian Kennedy, Dan Kubitschek, Nick Mastrodemos, Bill Owen, Ed Riedel, Steve Synnott, Mike Wang, and Bob Werner. The research described in this publication was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. Copyright 2012 California Institute of Technology. Government sponsorship is acknowledged. References 1 Gaskell, R. H., et al, “Characterizing and navigating small bodies with imaging data,” AIAA Meteoritics and Planetary Science, Vol. 43, 2008, pp. 1049-1061. 2 Owen, W. M., “Methods of Optical Navigation,” AIAA/AAS Spaceflight Mechanics Conference, AAS 11-215, New Orleans, LA, February 2011. 3 Vaughan, R. M., Riedel, J. E., Davis, R. P., Owen, W. M., and Synnott, S. P., “Optical Navigation for the Galileo Gaspra Encounter”, AIAA/AAS Astrodynamics Conference, AIAA 92-4522, Hilton Head, S. C., August 1992. 4 Russ, J. C., The Image Processing Handbook, CRC Press, 1999, Chapter 7. 5 Tapley, B. D., Schutz, B. E., Born, G. H., Statistical Orbit Determination, Elsevier Academic Press, San Diego, CA, 2004. 6 Bhaskaran, S., et al, “Orbit Determination Performance Evaluation of the Deep Space 1 Autonomous Navigation System”, AAS 98-193, AAS/AIAA Spaceflight Mechanics Meeting, Monterey, CA, February 1998. 7 Bhaskaran, S., Riedel, J. E., and Synnott, S. P., “Autonomous Target Tracking of Small Bodies During Flybys”, AAS-04236, AAS/AIAA Astrodynamics Specialist Conference, Maui, Hawaii, February 2004. 8 Desai, S. D., et al, “The DS1 Autonomous Navigation System: Autonomous Control of Low-Thrust Propulsion Systems”, AIAA 97-38819, AIAA Guidance, Navigation and Control Conference, New Orleans, LA, August 1997. 9 Kubitschek, D. G., et al, “Deep Impact Autonomous Navigation: The Trials of Targeting the Unknown”, AAS 06-081, AAS Guidance and Control Conference, Breckenridge, CO, February 2006. 10 Bhaskaran. S., et al, “Small Body Landings Using Autonomous Onboard Optical Navigation”, Journal of the Astronautical Sciences, Vol. 58, No. 3, 2012. 11 Bhaskaran, S., Riedel, J. E., Synnott, S. P., Wang, T. C., “The Deep Space 1 Autonomous Navigation System: A Post-flight Analysis”, AIAA 2000-3935, AIAA/AAS Astrodynamics Specialist Conference, Denver, CO, August 2000. 12 Mastrodemos, N., et al, “Autonomous Navigation for Deep Impact”, AAS 06-177, AAS/AIAA Spaceflight Mechanics Conference, Tampa, FL, January 2006. 13 Abrahamson, M., Kennedy, B. M., Bhaskaran, S. B., “AutoNav Design and Performance for the EPOXI Hartley 2 Flyby, SpaceOps 2012 Conference, Stockholm, Sweden, June 2012. 14 a’Hearn, M. F., et al, “EPOXI at Comet Hartley 2”, Science, Vol. 332, No. 6036, 17 June 2011, pp. 1396-1400. 15 Riedel, J. E., et al, “Configuring the Deep Impact AutoNav System for Lunar, Comet and Mars Landing, AIAA 2008-6940, AIAA/AAS Astrodynamics Specialist Conference, Honolulu, Hawaii, August 2008. 16 Bhaskaran, S., et al, “Navigation Challenges of a Kinetic Energy Asteroid Deflection Spacecraft”, AIAA 2008, AIAA/AAS Astrodynamics Specialist Conference, Honolulu, Hawaii, August 2008. 17 Antreasian, P. G., et al, “The Design and Navigation of the NEAR/Shoemaker Landing on Eros”, AAS 01-372, AAS/AIAA Astrodynamics Specialist Conference, Quebec City, Canada, July 2001. 18 Yano, H., et al, “Touchdown of the Hayabusa Spacecraft at the Muses Sea on Itokawa”, Science, No. 5778, 2006, pp. 13501353. 19 Riedel, J. E., et al, “Optical Navigation Plan and Strategy for the Lunar Lander Altair, OpNav for Lunar and other Crewed and Robotic Exploration Applications”, AIAA-2010-7719, AIAA GN&C Conference, Toronto Canada, August 2010. 20 Lynam, A. E., Kloster, K. W., and Longuski, J. M., “Multiple-satellite-aided Capture Trajectories at Jupiter using the Laplace Resonance”, Celestial Mechanics and Dynamical Astronomy, Vol. 109, No. 1, 2011. Copyright 2012 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner.