Mars Exploration Rovers

MAPGEN: first AI based system to control a spacecraft on the surface of another planet on January 15, 2004

Motivation for MAPGEN

"What the MER rover can do in a Sol, a human field Geologist can do in 30 seconds"

"We need a tool that provides a level of abstraction for acivity planning so scientists can focus ont he science" - Steve Squyres, MER PI

Squyres wanted a human in the loop, didn't want automated planner -> had to build a mixed-initiative system

NASA/Autonomy overview

Expanding range of NASA goals/missions: Earth and LEO -> Earth's Neighborhood -> Accessible Planetary surfaces (Europa) -> Sustainable Planetary surfaces -> Go anywhere, anytime

Reasons for autonomy:

• round trip delay times
• more optimal use of Deep Space Network (DSN) coverage
  • hardware is getting cheaper, but bandwidth is getting constrained
• robust sequences generate on-board
  • anticipate faults and use software to reconfigure
  • faster and more robust response to faults
  • can close loops on-board (e.g. navigation)
• doing serendipitous science
  • machine learning will be instrinsic, though notion of machine learning within NASA raises alarms because you can't fully characterize the system
• finding requisite skill-set in NASA's workforce
• Errors are endemic to human control (humans drove pathfinder into a rock)

Traditional view of software:

• defined input/output behavior
• complex software built by joining boxes with well-defined interfaces

Model-based autonomy: all detailed knowledge of the world is encapsulated in the software

Build models, not software

Autonomous systems * Base: Planning/Scheduling + Fault Diagnosis & Recovery + Execution * + Agent architectures * + Knowledge acquisitin * + Verification & validation

History

Remote Agent Experiment (RAX) * May 17-21, 1999 * 65 million miles from Earth * During Ballistic Cruise * Remote agent on DS1 won NASA's 1999 Software of the Year * Recover from errors through planning/re-tasking (planner on board was novel introduction)

MER Mission * simple pathfinding on-board * much-larger MER had to fit in same packaging as pathfinder * very complex vehicle, didn't fully know how to operate until close to actual surface operation

Mission: increase mission return and reduce risk

DEVISER (Vere), 1982 * Voyager * Chronological backtracking search with simple pre/post conditions * shortcoming: very high level of abstraction * no heuristics * lesson: search not feasible in real-time environment

PLANIT-2 (mittman, Eggemeyer) 1999/JPL * Pathfinder * Lander operations commanding every other day * Shortcoming: no search * used an algebraic formulation for maintaining consistency * 7-30 plan horizon

Approach

• automatically encapsulate/enforce rules
• auotmatically remove resource conflicts under supervision
• allow human operator to have full control of the plan and planning process
• capture scientific intent of the planning process

Challenges * limited time to perform scientific activity planning * large science team with diverse requests * sequences can have 100s of science & engineering activities * large space of possible sequences * limited rover resources (data, energy, time) * large number of constraints in activity sequence * evolving knowledge of rover and environment (didn't really know how the surface operations would work) * worried about failures of past Mars missions, wanted to be conservative

Manual planning * No time to consider many alternatives * Limited feedback * Reduced science return and increased risk

Tactical overview (for one Sol): Downlink -> Sleep -> Science Planning -> Sequence building/validation -> Wakup -> Uplink * multiple people sitting in large room, deliberating what to do (SRWG meeting) for two hours * start building plan of how to do it afterwards. Tactical Activity Planning Room. Given list of what scientists want to accomplish, how do we do it? MAPGEN on the screen, examining plan, wondering why plan did what it did.

Started off with APGEN (JPL/TMOD multi-mission planning tool). Timelines with subsystems. Flags resources and activity temporal violations.

Added planner to APGEN to make MAPGEN. Operators see APGEN UI, with MAPGEN in the back. * Added a button for "Turn MAPGEN off" -- requirement imposed by mission manager

Plannier runs for about one minute on a Sun Blade (2000)

Interesting visualization with the UI: * plan timeline in top half of display that was interactive * visualization of battery/resource consumption graphs below along same timeline

Reduction of a 4 hour activity planing into 1/2 proposed by MAPGEN team

Started off using own research dollars to convince MER that their technology should be used.

Descope: NASA terminology for getting thrown out of mission

Avoided first descoping b/c they were using own research dollars

First GDS thread-test: planner performance abysmal

NASA Ames HCI team redesigned front-end

Didn't know requirements, who users would be until very close to actual launch.

PORT-3: first ORT * Run through of actual 19 1/2 operations process * Cassini takes 2 weeks to build mission plan, for Mars they wanted 19 1/2 hours * First ORT was disaster process-wise * Contingencies for running rover once every three days, figuring out once rover landed

Announced bake-off between pencil and paper vs. automated process (4/03) * MAPGEN outperformed manual approach by 20% (# tasks performed) * qualitatively the MAPGEN plans were judged to be better

Lessons learned

• Having requirements to design off of can be a myth.
• Often the problems we'd like to solve (as researches) are not considered important, others are
• Model-based systems good with evolving requirements.
• All or nothing approach = nothing. Adjustable autonomy was meaningful.
• Human factors related issues are critical to deal with to give the end-user the "warm fuzzies". causal explanation of what the system is doing and why. Information overload is a barrier for human 'validation' of system performance (incremental plan building versus all at once).
  • preference (or soft) constraints
  • rules are meant to be broken
• Optimality in problem solving is not necessarily an important practical consideration.

The Secret of Apollo: Systems Management in American and European Space Programs by Steven B. Johnson

NASA learned the lesson of ethnography/work practice

*Planner has never been turned off *