Autonomy

1
Autonomy

• Model-based Embedded and
• Robotic Systems Group (MERS)
• Aero/Astro Graduate Open House
• March 18, 2005

2
The Need for Autonomy

• Space systems must handle
• Faults and anomalies
• Cooperative exploration
• Long-term science operations
• Increasingly ambitious goals

Europa Probe
MER Memory Leak
Apollo 13 quintuple fault
Mars Outpost
Earth Imager
Mars Polar Lander failed due to a faulty sensor.
3
Future Autonomous Vehicles
Space Technology 3
Europa Hydrobot
In-Situ Propellant Plant
Orbital Space Plane
Mars Life Support Facility
2009 Mars Science Lab
4
Mission Collaboration
MER Shadow Mode
Orbital Express
MIT SPHERES
Earth Observing-1
Mars Science Laboratory 2009
Images courtesy of NASA JPL
5
Robust Systems Should beFully State Aware

• Embedded programs interact withplant sensors and
  actuators
• Read sensors
• Set actuators
• Complexity Programmer must map between state
  and sensors/actuators.

• Model-based programs interact with plant state
• Read state
• Write state
• Simplification Model-based executive maps
  between state and sensors/actuators.

Embedded Program
Model-basedEmbedded Program
Observations
Command
S Plant
S Plant
6
Example Orbital Insertion Scenario
Engine Model
(thrust zero) AND (power_in zero)
Off
0.01
off- cmd
Failed
standby- cmd
(thrust zero) AND (power_in nominal)
0.01
Standby
fire- cmd
standby- cmd
EngineA
EngineB
EngineA
EngineB
0.01
(thrust full) AND (power_in nominal)
Firing
Science Camera
Science Camera

• Engineers Think in Terms of State Evolution
• One of the two engines must be firing
• Set both engines to standby.
• Prior to firing an engine, camera must be off.
• Once the camera is off and the primary engine is
  on standby, the primary engine should be fired.
• In case of primary engine failure, the backup
  engine should be fired instead.

Camera Model
Off
(power_in zero) AND (shutter closed)
turnoff- cmd
turnon- cmd
(power_in nominal) AND (shutter open)
On
7
Model-based Program

• Control program specifies state
• trajectories
• Concurrency
• Preemption
• Queries hidden state
• Asserts (assigns) hidden state

OrbitInsert() (do-watching ((EngineA
Firing) OR (EngineB
Firing)) (parallel (EngineA
Standby) (EngineB Standby)
(Camera Off) (do-watching (EngineA
Failed) (when-donext (
(EngineA Standby) AND
(Camera Off) )
(EngineA Firing)))
(when-donext ( (EngineA Failed) AND
(EngineB Standby)
AND
(Camera Off) ) (EngineB
Firing))))

• Plant Model describes behavior of
• each component
• Nominal and off-nominal
• Qualitative constraints
• Likelihoods and costs

Models are reusable and easy to articulate at the
conceptual stage
8
Titan Model-based Executive
Model-based Executive
RMPL
Control program
Sequencer / Planner Generates target goal states
conditioned onstate estimates

• Executes concurrently
• Preempts
• Queries (hidden) states
• Asserts (hidden) state

State goals
State estimates
System model
Mode Estimation tracks likelyplant state
Mode Reconfiguration tracks least costgoal states
Commands
Observations
Plant
9
Example The model-based program sets the state
to thrusting, and the M-B executive . . .
Fuel tank
Oxidizer tank
Plans actions to open six valves
Deduces that thrust is off, andthe engine is
healthy
Deduces that a valve failed - stuck closed
Determines that valves on the backup enginewill
achieve thrust, andplans needed actions.
10
Mode Estimation

• Purpose Ideal mode estimation would maintain a
  complete belief state
• Belief State Probability distribution across
  all combinations of possible states in the system
• Challenge Combination of states is exponential
  in the number of modes
• Solution Tracking only an approximate belief
  state containing k estimates (shown below)
  reduces the space requirement to linear while
  maintaining the majority of probability density!

Concurrent Constraint Automata
Switch and OR-Gate System

• Tracking the most likely system states over time

t0
t1
t2

• cmd sw1-turnOn
• Obs LED-off

• cmd sw2-turnOn
• Obs LED-off

sw1off, sw2off, orbkn
likelihood
sw1bkn, sw2off, ornom
sw1off, sw2off, ornom
sw1off, sw2bkn, ornom
sw1bkn, sw2bkn, ornom
sw1off, sw2off, orbkn
sw1bkn, sw2bkn, orbkn
k3
sw1bkn, sw2bkn, ornom

11
Compiled Mode Estimation
Compiled Mode Estimation
Online
Offline
Projected Prime Implicate Generation
Best-First
Dissents
Partial
Conflicts
Belief
Most Likely
System
Diagnosis
Diagnosis
State
Model
Trigger
Enabled Modes
Enumeration
Compiled Transitions
Discrete
Continuous
Monitors
Observations
Observations

• Off-line Operations (Removes the need for
  NP-complete online satisfiability)

• Dissent A mapping from observations to conflicts

(LEDoff) ? sw1on ? sw2on ? ornom ....
Model Compilation

• On-line Operations (Reduced to an optimal search
  instead of OCSP)

• Most Likely Diagnosis
• Or-gate Nominal
• Switch1 On
• Switch2 Broken

Partial Diagnosis Trigger
(LEDoff)
12
Hybrid Mode Estimation

• failures can manifest themselves through coupling
  between a systems continuous dynamics and its
  evolution through different behavior modes
• must track over continuous state changes and
  discrete mode changes
• symptoms initially on the same scale as
  sensor/actuator noise
• need to extract mode estimates from subtle
  symptoms

old estimate Xk-1mi,xk-1
new estimate Xkmj,xk
Xk-1mj,xk-1
yc(k)

KalmanFilter Bank

Xk
Mode Estimation
xci(k)
Hybrid Mode Estimation tracks a set of
trajectories
Pi(k)
uc(k-1)

• Methods
• K-best filtering,
• Rao-Blackwellised particle filtering

Ck
13
Application Gesture Recognition

• Robonaut
• EVA astronauts assistant
• Humanoid design requires no specialized robotic
  tools
• Controlled by teleoperator, but autonomous modes
  under development

• Gesture recognition
• Stereo vision system
• Tracks head and hand motion of human associate
• Hybrid model supports Robonauts recognition of
  human gestures
• Gestures of interest include pointing to a tool,
  holding hand up to indicate stop, come closer
  gestures, etc.
• Continuous dynamics model of human arm includes
  inertial and damping terms
• HMM model takes output of stereo vision system as
  observation
• Transitions between motion control point states

14
Mode Reconfiguration

• INPUT
• Configuration Goal
• Thrust on
• Current State
• Tank full
• Pressure nominal
• Driver off
• Valve closed
• Thruster off

• OUTPUT
• Command
• Turn driver on

15
Goal Interpreter

• INPUT
• Current State
• Tank full
• Pressure nominal
• Driver off
• Valve closed
• Thruster off
• Configuration Goal
• Thrust on

• OUTPUT
• Goal State
• Tank full
• Pressure nominal
• Driver off
• Valve on
• Thruster on

Generate optimal goal state that achieves the
Configuration Goal!

• Goal Interpreter

• Compiled Goal Interpreter

Minimize online deduction by generating all
partial goal interpretation offline! Online
Goal State
Goal Configuration
Partial Goal Interpretation
Best-first Kernel Goal State Generator
16
Reactive Planner

• INPUT
• Current State
• Tank full
• Pressure nominal
• Driver off
• Valve closed
• Thruster off
• Goal State
• Tank full
• Pressure nominal
• Driver off
• Valve on
• Thruster on

• OUTPUT
• Command
• Turn driver on

• Planner guarantees to
• Only generate non-destructive actions
• Never propose actions that lead to dead-end plans
• Ensure progress toward the goal
• Operate at reactive time scale

Valve
Driver

• Reconfiguration
• Order
• Tank full
• Pressure nominal
• Valve on
• Thruster on
• Driver off

Goal
Goal
Current
Current
Open
Closed
On
Off
idle
driver on cmd close
idle
cmd off
Open
On
driver on cmd open
idle
cmd on
idle
Off
Closed
fail
fail
cmd reset
cmd off
Stuck
Resettable
17
Verification of RMPL Programs

• Motivation
• Want robust autonomous systems.
• Extend traditional scenario-based testing to
  verification and validation (VV).

Approach

• Goals
• Verify RMPL model-based programs (control program
  plant model) against goal specification.
• e.g., ((EngineA Firing) OR (EngineB Firing))
  for OrbitInsert()
• Extract probabilistic information about programs
  possible executions.

18
Heterogeneous Robots

• Orbiter
• Earth Com link,
• Large scale feature detection
• Science observation
• Tethered Blimp
• Reconnaissance Rover tracking, feature
  detection, local map generator
• Sensor network deployment
• Rover Com link
• Smart Mobile Lander
• Slow mobile base station
• Orbiter Com link
• Large science package
• Scout Rovers
• Fast agile rovers
• Sensor package for identifying science objectives
• Terrain mapping functionality
• Sensor Network
• Highly constrained sensing/effecting
  communication array
• Science sensing

High Tier
Mid Tier
Low Tier
19
Programming Cooperative Teams

• Realistic science objectives require multiple
  vehicles
• Mission controller specifies abstract set of
  goals for a robot team

Collection Point
Rendezvous
Diverge
Science Area 2
Science Area 1
Science Area 3

• Challenges
• Dynamic environments
• Limited communication between robots
• Hardware failure

• The system must handle
• Task allocation between robots
• Planning of activities and vehicle paths
• Robust execution

20
Programming Teams in RMPL

• RMPL Programs
• Describe concurrent sensing, actuation and
  movements activities.
• Choose specifies redundant strategies and
  contingencies.
• A,B Specifies timing constraints.

Corridor 2
Rendezvous
Rescue Area
Corridor 1
Enroute

• (Group-Enroute() l,u (
• (sequence
• choose (
• (do-watching (PATH1OK)
• ((Group-Traverse-Path(PATH1_1,PATH1_2,PAT
  H1_3,RE_POS))l90,u90)
• )
• (do-watching (PATH2OK)
• ((Group-Traverse-Path(PATH2_1,PATH2_2,PAT
  H2_3,RE_POS))l90,u90)
• ))
• (parallel
• ((Group-Transmit(OPS,ARRIVED))0,2)
• (do-watching(PROCEEDSIGNALLED)
• ((Group-Wait(HOLD1,HOLD2))0,u10))
• )))

21
Planning and Execution
Mission Specification
RMPLCompiler
Planning and Execution
RMPLProgram
Temporal Planner
Temporal Plan Network
(choose (parallel ((power high) 5,30)
(goTo(rockA) 10,30) ) (if-then-else
(camera on) (takePicture() 5,5)
(powerOnCamera() 6,8) ))
Temporally Flexible Solution Plan
Plan Runner/ Dispatcher
Represents all possible contingencies, with
non-deterministic choices and temporal constraints

• Challenges
• Synchronization
• Robustness
• Real-time control of dynamic systems

HardwareCommands
Hardware
22
Path Planning through Disjunctive Programming

• The input plan includes logical (discrete)
  decisions, such as task selection, temporal
  orderings, and obstacle avoidance.
• Vehicle/Terrain models involve mathematical
  (continuous) constraints.
• Our goal is to output for the vehicles a
  trajectory and schedule plan that optimizes the
  total fuel use, based on the discrete and
  continuous constraints.
• It is formulated in Disjunctive Programming
  (DP), which can be viewed as Linear Programming
  constrained by disjunctive clauses.

Vehicles have to go from point A to C, without
hitting the obstacle B, while minimizing the fuel
consumed. The disjunctive clause comes from the
fact that the vehicles can be above, below, to
the left or right of B. Minimize f(x)
Subject to g(x) 0

xi xL V xi xR V yi yB V yi yT ,
? i 1, , n
A simple example
23
Distributed Planning and Execution

• A Distributed System
• Eliminates dependency on a single robot for
  planning and execution
• Shares computation to allow execution on groups
  of robots where each has limited computational
  resources
• Allows coordination under limited communication
  availability
• Scales well to large groups of robots

mission

• Challenges
• Coordination and synchronization
• Maintaining temporally flexible plans
• Adaptation to loss of a robot
• Adaptation to changing communication availability

24
Mars Shadow Mode Project
Analyze this rock!

• Simulate Mission Objectives of Mars 03
• Use NASAs MERBoard to visualize the environment
  and control the rovers.
• Demonstrate the ability to achieve mission goals
  autonomously

• Rover Sensors
• Stereo camera head
• Laser range scanner
• Sonar array
• DGPS
• Digital compass
• Inclinometer

Remote operations center
Mars yard