Douglas E. Bernard

An autonomous spacecraft agent prototype

This paper describes the New Millennium Remote Agent (NMRA) architecture for autonomous spacecraft control systems. The architecture supports challenging requirements of the autonomous spacecraft domain not usually addressed in mobile robot architectures, including highly reliable autonomous operations over extended time periods in the presence of tight resource constraints, hard deadlines, limited observability, and concurrent activity. A hybrid architecture, NMRA integrates traditional real-time monitoring and control with heterogeneous components for constraint-based planning and scheduling, robust multi-threaded execution, and model-based diagnosis and reconfiguration. Novel features of this integrated architecture include support for robust closed-loop generation and execution of concurrent temporal plans and a hybrid procedural/deductive executive.

Spacecraft Autonomy Flight Experience: The DS1 Remote Agent Experiment

In May 1999 state-of-the-art autonomy technology was allowed to assume command and control of the Deep Space One spacecraft during the Remote Agent Experiment. This experiment demonstrated numerous autonomy concepts ranging from high-level goaloriented commanding to on-board planning to robust plan execution to model-based fault protection. Many lessons of value to future enhancements of spacecraft autonomy were learned in preparing for and executing this experiment. This paper describes those lessons and suggests directions of future work in this field.

Mission operations with an autonomous agent

The Remote Agent (RA) is an Artificial Intelligence (AI) system which automates some of the tasks normally reserved for human mission operators and performs these tasks autonomously on-board the spacecraft. These tasks include activity generation, sequencing, spacecraft analysis, and failure recovery. The RA will be demonstrated as a flight experiment on Deep Space One (DS1), the first deep space mission of the NASAs New Millennium Program (NMP). As we moved from prototyping into actual flight code development and teamed with ground operators, we made several major extensions to the RA architecture to address the broader operational context in which RA would be used. These extensions support ground operators and the RA sharing a long-range mission profile with facilities for asynchronous ground updates; support ground operators monitoring and commanding the spacecraft at multiple levels of detail simultaneously; and enable ground operators to provide additional knowledge to the RA, such as parameter updates, model updates, and diagnostic information, without interfering with the activities of the RA or leaving the system in an inconsistent state. The resulting architecture supports incremental autonomy, in which a basic agent can be delivered early and then used in an increasingly autonomous manner over the lifetime of the mission. It also supports variable autonomy, as it enables ground operators to benefit from autonomy when they want it, but does not inhibit them from obtaining a detailed understanding and exercising tighter control when necessary. These issues are critical to the successful development and operation of autonomous spacecraft.

Infusion of autonomy technology into space missions: DS1 lessons learned

The impact of infusing breakthrough autonomy technology into a flight project was a big surprise. Valuable technical and cultural lessons, many of general applicability when introducing system-level autonomy, have been learned by infusing the Remote Agent (RA) into NASAs Deep Space 1 (DS1) spacecraft. The RAs architecture embodies system-level autonomy in three major components: planning and scheduling, execution, and fault diagnosis and reconfiguration. Lessons learned include: the architecture was confirmed; active participation by nonautonomy personnel in the development is essential; communication of new concepts is essential, difficult, and hampered by differences in terminology; giving a spacecraft system-level autonomy changes organizational roles in operating the spacecraft after launch, and hence changes roles during development; software models supporting functions traditionally handled on the ground must be developed early enough to get on-board; shortfalls in planned features must be technically and developmentally accomodatable, in particular not to threaten the launch schedule; traditional commanding must be supported; testing must be emphasized. These lessons and others, on incremental system releases and use of autocode generation, are based on 16 months of spiral development from start of project through the projects decision to reduce the role of the RA from full-time control of the spacecraft to a separable experiment.

An Almanac of Martian Dust Storms for InSight project energy system design

The power and thermal systems of NASAs new InSight lander must be designed to tolerate Martian dust storms, which have been observed to rise up and obscure much of the planet, approximately once in every three Mars years. To quantify the nature of the challenge posed by dust storms in terms of their seasonal occurrence, range of durations, and intensities, the project has performed an up-to-date, comprehensive assessment and inter-calibration of archived, historic Martian dust storm data. This unique assessment, captured in a new Dust Storm Almanac, combines direct measurements of Martian atmospheric optical depth made by both landed assets and orbital assets, in the Viking era (ca 1976) and also the present era of Martian spacecraft and instruments (1996-2013). The orbital observations of optical depth, which are in infrared, have been scaled based on calibration with contemporaneous visible-spectrum optical depth data made by surface assets. Implications of the observed dust storms for the design and operation of the InSight mission, as well as for Mars surface missions in general, are discussed.