Planning and Execution for Rover Missions

Autonomous control software uses models to reason about the system that it controls and the environment it is in. It accomplishes a set of goals extended during a period of time, and it is able to reason about failures without or small human supervision.
Given the initial state and external goals, it generates a set of synchronized low-level activities that, once executed, will achieve the goals. If any action is not executed as expected, the system is able to recover in order to achieve the pre-defined goals.

So far, the use of autonomous control software has been limited to controlling research rovers and some satellites such as EO-1. The biggest obstacles to its deployment in high-profile missions are its lack of real experience (despite the DS-1 experiment) and the apparent difficulty in validating it. Testing effective and robust control strategies requires dealing with any path of execution in any component and any module. In traditional systems, this already implies searching through a huge state space. Because of their flexibility and their reactivity to unpredictable events, autonomous systems generate even bigger state spaces; and, unpredictability makes mission managers nervous. Yet there is no denying that autonomous control software could be bring greater flexibility, and most probably result in greater science returns than traditional control software. So what should we do? The answer is simple: we need to design architectures for autonomous control software with validation in mind.

This is the procedure followed in IDEA (Intelligent Distributed Execution Architecture).
IDEA is based on Multi-Agent system, where each agent relies on a domain model, a plan database, a plan runner, and a reactive planner. As part of the postdoct at NASA Ames under the supervivion of Dr. Nicola Muscettola, I present the procedure followed in IDEA to validate the whole system behaviour.