PhD Defense

1
PhD Defense

• An Adaptive Planning Framework for Situation
  Assessment and Decision-making on an Autonomous
  Ground Vehicle
• November 2, 2006
• Bob Touchton, P.E.

2
Outline

• Introduction and Background
• Adaptive Planning Framework
• Reference Implementation
• Field Testing
• Future Research and Conclusions
• Questions and Discussion

3
Objectives of this Presentation

• Describe the Adaptive Planning Framework (APF)
  concept and its Reference Implementation
• Demonstrate that the APF is a new and unique
  approach to intelligent behavior and that the
  research results are meaningful and useful
• Reinforce how the APF makes an important
  contribution to the autonomous robotics research
  community

4
Motivation andStatement of Problem

• Real-time (re)planning and decision-making is a
  daunting issue, especially for complex missions
• Deliberation time vs. reaction time conundrum
• Specific robotic technologies and specific
  autonomous behaviors are becoming reasonably
  robust
• Deriving situational knowledge from dynamic
  inputs and autonomously selecting, sequencing,
  and controlling behavior based on that
  situational knowledge are essential capabilities
  for advanced applications
• A disciplined way of thinking about, organizing,
  and applying situational knowledge to high-level
  planning and decision-making is needed

5
Thesis of Research

• A well-organized, disciplined 3-stage, real-time
  process that enables an AGV to
• Understand the current situation
• Understand the suitability and viability of
  available behavioral capabilities given that
  situation
• Make and execute plan-related decisions
• provides new levels of intelligence and autonomy

6
The Adaptive Planning Framework (APF)

• A skeletal structure for enhancing AGV behavioral
  intelligence
• Situational knowledge bridges the gap between
  changing input data and AGV response
• Represented in terms of Findings
• Reported in terms of Conditions, States,
  Events, and Recommendations
• Organized by virtual Situation Assessment
  Specialists, Behavior Specialists and a Decision
  Specialist
• Empowered to manage the execution and
  modification of the AGV high-level behavior

7
APF Specialists

• Situation Assessment Specialists convert raw
  input and derived knowledge (i.e., prior Findings
  of itself and others) into new Findings
• Behavior Specialists each paired with a
  behavioral component to render Recommendations on
  its suitability, capabilities, dependencies and
  status
• Decision Specialist a Decision Broker charged
  with governing high-level AGV behavior based on
  Findings and Recommendations

8
?
9
APF Knowledge Flow
Data
Finding
Recommendation
SA S p e c
B e h S p e c
D e c S p e c
Finding
Recommendation
Data
Recommendation
Data
Finding
Action
Recommendation
Finding
Data
Finding
Data
Finding
Data
Data
Finding
?
10
Inspiration REALM Expert System and its
Cooperating Experts

• Reactor Emergency Action Level Monitor
• Developed for Electric Power Research Institute
  to Assist in Nuclear Power Plant Emergency
  Management in late 1980s
• Expert System that used Collaboration of Experts
  Modeled After the Technical Support Group
• Fielded at Indian Point 2 (ConEdison) with
  Real-time Sensor Feed from Plant Computer
• Demonstrated During Emergency Exercises

11
Solution Metaphor
12
Literature Review

• Architectural Compatibility
• Situation Assessment
• Behaviors
• Decision-making
• Knowledge Representation

13
Publications

• Journal of Field Robotics (3rd author) Sept 06
• IEEE Computer (1st author) Dec 06
• Journal of Field Robotics (1st author) planned
  summary of this dissertation
• Influence JAUS Mission Generation Component and
  Ontology initiatives currently under way at the
  JAUS Working Group

14
Research Milestones

• The Adaptive Planning Framework Initial Design
• Proof of Concept Prototype
• Early Implementation on the DGC2005 NaviGATOR
• The Adaptive Planning Framework Final Design
• Reference Implementation based on Milestone I of
  the Team Gator Nation Urban Challenge Project
  Plan
• Field Testing of Reference Implementation

15
The Adaptive Planning Framework Final Design

• Findings
• Specialists
• Decision Broker Protocols
• Knowledge Engineering Tools
• Run-time Implementation of Design-time Features

16
APF Findings

• Conditions, States, Recommendations, and Events
• Derived or inferred using raw data, refined data,
  Meta Data, command inputs, previous Findings
• Must be uniquely named within their namespace
• Must be assigned to exactly one Specialist

17
APF Conditions

• An independent, ongoing circumstance whose value
  is either present or absent
• Only prove present
• Think of medical diagnostics if what you care
  about is whether a particular symptom is present
  (like a rash), then make it a Condition
• Examples
• Close-Range-Obstacle
• Excessive-Roll
• Adjacent-Lane-Safe

18
APF States and Recommendations

• Finding that has exactly 1 of 2 or more
  enumerated values
• The value of a State only changes when conclusive
  evidence of another value is found (i.e., focus
  on state transitions)
• A Recommendation is a special type whose output
  is in the form of advice, especially regarding
  its associated Behavior
• Prioritization and a default value are allowed if
  that helps to avoid/resolve ambiguities

19
APF States and Recommendations

• State Examples
• Terrain is Smooth Rugged Very-Rugged
• Mission-Status is Ahead-of-Schedule Nominal
  Behind-Schedule
• Mission-Mode is Optimize-Speed Optimize-Risk
• Mobility-Mode is Low-Speed High-Speed
• Recommendation Examples
• Passing-Behavior is OK Not-Appropriate
  Not-Legal Unsafe
• Roadway-Navigation-Behavior is OK Blocked
  Stuck Unsafe

20
APF Events

• Finding whose mere occurrence is of interest
• Its value is set to true, with a time stamp
• The Event would still be reported as true _at_
  timestamp, even after the evidence of it
  occurrence is no longer available
• Needs an expiration time or event reset rule to
  set it back to false
• Allows reasoning about occurrences after their
  evidence is gone and about the duration-of or
  time-since an event
• Examples
• Enemy-Fire-Detected
• Air-Conditioner-Failed
• GPS-Signal-Lost
• Intersection-Became-Clear

21
APF Situation Assessment Specialists

• Organized into categories
• Must have a unique name
• Must be responsible for one or more Findings
• Purpose is for discipline and team assignment

22
Example Situation Assessment Specialists
23
APF Behavior Specialists

• A Behavior Specialist (BS) is allocated for each
  distinct Behavioral Component
• Each BS renders Recommendations and other
  Findings regarding the performance and
  suitability of its assigned Component
• It thus must understand the Behavior Components
  constraints, requirements, strengths, and
  weaknesses
• Typically will be embedded into its assigned
  Behavior Component

24
APF Decision Specialist

• The Decision Broker assumes ultimate authority
  over AGVs autonomous behavior (called Subsystem
  Commander in JAUS)
• Makes decisions about AGV behavior based on
  Recommendations and other inputs
• Uses (currently 7) Decision Primitives to execute
  Decision Protocols
• Monitor a behavior
• Verify a behavior
• Enable a behavior
• Disable a behavior
• Set (maximum) travel speed
• Wait
• Execute another Protocol

25
APF Decision Broker Protocol

• As an example, here is a Protocol for getting
  unblocked

1. Set Travel Speed 0 mps
2. Verify Reactive Reverse is Safe
3. Disable Receding Horizon Planner
4. Enable Reactive Reverse
5. Set Travel Speed 1.5 mps
6. Monitor Receding Horizon Planner for success

1. Monitor Reactive Reverse for unsafe conditions
2. Set Travel Speed 0 mps
3. Disable Reactive Reverse
4. Enable Receding Horizon Planner
5. Set Travel Speed (per speed protocol)
6. Execute High-Level Monitoring Protocol

26
Knowledge Engineering Tools

• Behavior Use Case
• Findings Worksheet
• Decision Broker Protocol Worksheet
• We will look at examples of these tools as part
  of the Reference Implementation

27
APF Run-time Concept of Operation

• Each Specialist Executes Independently
• Processes Algorithm/Rules
• Produces Findings/Actions
• Centralized Repository
• Blackboard
• Knowledge Store
• Decentralized Repository
• Broadcast
• Publish/Subscribe (point-to-point)
• May be event-driven/change-driven

28
APF Run-time Reasoning and Control Strategy

• Asynchronous
• Distributed
• Iterative
• Forward-chaining
• May require output dampening or hysteresis to
  avoid thrashing

29
Reference Implementation

• Sketch out initial design for the DARPA Urban
  Challenge behaviors
• Design/Develop/Deploy First Phase of DARPA Urban
  Challenge deliverable
• Autonomously select between basic Roadway
  Navigation behavior and n-Point Turn behavior
  (addresses a blockage of the preplanned route)
• Add Specialists and their Findings as required
• Create a JAUS Subsystem Commander component and
  incorporate the Decision Broker into it
• Modify/extend JAUS infrastructure and messaging
  system accordingly

30
The APF Conceptual Model
?
31
APF Initial Design for DGC2007
32
Scope of Reference Implementation

• Minimalist approach to Knowledge Representation
• Remain JAUS-compliant via creation of
  User-defined messages for transmission of
  Findings
• Use the DGC2005 NaviGATOR as a surrogate
• Simulate Perception Element as needed
• Adapt Tom Galluzzos Receding Horizon Planner to
  serve as initial Roadway Navigation behavior
• Implement n-Point-Turn behavior on NaviGATOR
  (Greg Garcia, Lead)

33
The APF Conceptual Model
Simplified NaviGATOR Architecture for a
2-Behavior System
?
34
The NaviGATOR AGV
35
Knowledge Representation

• Appendix C
• Behavior Use Cases
• Roadway Navigation
• n-Point Turn
• Findings Worksheets
• Roadway Navigation Behavior Specialist
• n-Point Turn Behavior Specialist
• Close-Range Safety Specialist
• Decision Broker Protocols

36
(No Transcript)
37
Portrayal of safety buffers for the three n-Point
Turn Reactive Actions
reverse right
forward left
reverse straight
38
JAUS Meta Data Concept

• Data about the data
• Needed a mechanism to transmit Findings (in the
  form of strings) in a fashion consistent with
  JAUS
• Can be used for transmitting any valid JAUS data
  type
• Reserved for data that is not addressed by an
  existing JAUS message (violating this rule will
  cause the system to be deemed out of compliance
  with JAUS)
• Introduced Meta Data Element to refer to an
  individual Meta Data entity
• Namespace integrity is maintained via unique Meta
  Data name publishing Component ID

39
Implemented Meta Data Message Set

• Report Meta Data Message - Automatically sent to
  subscribers whenever there is a significant
  change to the publishers Meta Data (at
  publishers discretion)
• Extremely flexible ? complex
• Each Meta Data Element in the message can have a
  distinct data type ? JAUS Variant data type
• Publish/Subscribe Handshake Messages
• Meta Data Changed Event Setup
• Meta Data Changed Event Confirmation
• Developed Supporting Structures and Utilities

40
Report Meta Data Message

• Currently, all Meta Data from a given publisher
  is sent to all its subscribers it is up to the
  subscriber to filter it
• Requires one field to state the number of Meta
  Data Elements are bundled in the message
• Requires four fields per Meta Data Element
  included
• Meta Data Element Name
• Time Stamp of its Current Value
• Data Type Code of its Current Value
• Current Value

41
Meta Data Publish/Subscribe Handshake Messages

• Meta Data Changed Event Setup message
• Sent by each subscriber to the publisher of the
  Meta Data Element(s) of interest
• Can be used to start or stop the subscription via
  a subscription flag
• Publisher will add (or remove) that JAUS
  component to its list of subscribers
• Meta Data Changed Event Confirmation
• Sent by the publisher in reply
• Confirms action taken (stopped, started,
  rejected) via a confirmation flag

42
JAUS Variant Concept

• Builds on JAUS Type Code concept originated for
  interoperability experiments (to support
  extemporaneous Payload to Human Interface
  interaction)
• The Type Code byte tells the messaging
  infrastructure how to treat the data element that
  is about to be processed
• The Value of the data element is then of type
  Variant

43
JAUS Variant Type Codes
EnumValue JAUS Type Code JausVariant Element Name C-language Data Type
1 Short shortValue short
2 Integer integerValue int
3 Long longValue long
4 Byte byteValue unsigned char
5 Unsigned Short uShortValue unsigned short
6 Unsigned Integer uIntegerValue unsigned int
7 Unsigned Long uLongValue unsigned long
8 Float floatValue float
9 Double longFloatValue double
19 String stringValue char
20 Unsigned Byte Tuple uByteTuple unsigned char
21 Unsigned Short Tuple uShortTuple unsigned short
22 Unsigned Integer Tuple uIntegerTuple unsigned int
44
Variant Structures and Utilities

• JausVariant structure
• typeCode
• Union of possible values (e.g., shortValue,
  byteValue)
• newJausVariant()
• Constructs a JausVariant structure with all zeros
• jausVariantToBuffer()
• Packs a designated JausVariant structure into a
  JAUS-style serialized byte stream
• jausVariantFromBuffer()
• Parses a JAUS-style serialized byte stream and
  populates a designated JausVariant structure

45
Meta Data Structures

• JausMetaDataElement structure
• Unique key of metaDataName and componentID
  (enforced in add utility)
• For APF, a distinct Finding of a distinct
  Specialist
• timeStamp
• elementData (as a JausVariant)
• Has a local changedFlag
• JausMetaData structure
• A collection of JausMetaDataElement structures
• Implemented as a JausVector of pointers
• Has a collection-wide changedFlag

46
Meta Data Utilities

• Constructors and Destructors for JausMetaData
  collections and JausMetaDataElement structures
• Functions to Set and Clear ChangedFlag
• Functions to Set and Get Timestamp
• jausAddMetaDataElement()
• Creates JausMetaDataElement structure with a
  given metaDataName, componentID and typeCode
• Adds it to a given JausMetaData collection
• Returns a pointer to the new structure
• jausCopyMetaDataElement()
• Same as Add plus copies the content of a given
  source element into the new element
• jausGetMetaDataElement()
• Returns a pointer to the JausMetaDataElement that
  matches a given metaDataName and componentID
  within a given JausMetaData collection

47
Meta Data Message Set Implementation

• reportMetaDataMessage
• Added setupFlag to generic JAUS Message
• metaDataChangedEventSetupMessage
• Added confirmationFlag to generic JAUS Message
• metaDataChangedEventConfirmationMessage
• Added numberMetaDataElements and
  jausMessageMetaDataCollection to generic JAUS
  Message
• Created message-specific versions of
  dataFromBuffer() and dataToBuffer() functions for
  each message

48
Adding APF capabilities to a Component

• Add basic Meta Data capability
• Add Specialist code for Publishers of Findings
• Modify Behavioral components
• Incorporate Decision Protocols into Subsystem
  Commander component

49
Implementing Decision Protocols in the Subsystem
Commander

• Functionalized each Protocol
• sscSelectBehavior()
• sscResumeRN()
• sscPauseRN()
• sscResumeNPT()
• sscPauseNPT()
• Orchestrated and designed to achieve desired
  behavior while avoiding wait states and deadlocks
• sscSelectBehavior()
• Called at each iteration of the component
• Serves as the executive
• Calls one of the other four protocols

50
Other Reference Implementation Details

• Added associated Behavior Specialist and
  simulated blockage to the Roadway Navigation
  behavior
• Removed nudging sub-behavior from the Roadway
  Navigation behavior
• Incorporated a simulated Close Range Safety
  Specialist into the Subsystem Commander component
• Created the n-Point Turn Behavior and associated
  Behavior Specialist (Greg Garcia, Lead)
• Modified the Primitive Driver (Eric Thorn, Lead)

51
Testing the Reference Implementation

• Unit Testing (with GPOS/VSS simulation)
• On blocks (with GPOS/VSS simulation)
• Gainesville Raceway
• UF Solar Park
• UF IFAS Research Farm near Citra, FL

52
Testing Sites
UF IFAS (Citra)
Road Course at Gainesville Raceway
53
Test Plans

• Ensure proper coverage of test cases to bound
  experimentation
• Test Plan contains
• Scope and Objective
• Preconditions, constraints, test bed
  requirements, and situational artifacts
• Safety, equipment and crew requirements
• Data, measurements, logs and readings to be
  captured and how
• Steps for conducting the experiment
• Anticipated results
• Built a software tool to present Test Plans

54
Test Plans

• Devised Test Plans that avoid route re-planning
• Inverted Start
• Temporarily Blocked
• View in Test Control Unit

55
Test ResultsInverted Start at Solar Park
Launch
56
Test ResultsNormal Start at Citra
Launch
57
Test ResultsNormal Start at Citra (with
visualizer)
Launch
58
Future Research - Theoretical

• Advanced Conflict Resolution Strategies
• Truth Maintenance (viability and shelf life of
  Findings over time) Techniques
• Explanation Facility (e.g., The forwardLeftSafe
  Condition is Present)
• Behavior/Action Transition Assurance (continuity,
  stability, safety)

59
Future Research - Implementation

• System-wide Temporal Instrumentation Scheme
• Meta Data Manager
• APF Visualization and Validation Toolkit

60
Conclusion

• The Adaptive Planning Framework is an important
  contribution to the AGV research community
• It represents a new and unique approach to
  achieving AGV intelligent behavior
• The goals of the research were achieved as
  demonstrated in the Reference Implementation
• The results of the research will have a positive
  impact on the JAUS Working Group and Team Gator
  Nation going forward

61
Questions and Discussion
62
Backup Slides

• DGC2005 NaviGATOR Design
• Traversability Grids
• DGC Event Overview
• Desert Testing
• Qualification Event at California Speedway
• Grand Challenge Race Day
• Why Not Multi-Agent?
• Lexicons, Taxonomies and Ontologies
• World Model Knowledge Store
• Literature Review
• Earlier Prototypes

63
Vehicle System

• rock crawler vehicle platform
• transverse Honda engine/transaxle mounted
  longitudinally
• locked transaxle that drives front and rear
  Detroit Locker differentials
• hydraulic steering
• two independent 24V alternator systems 5600 W
  continuous power
• air conditioned and vibration isolated
  electronics enclosure

64
Sensor Systems

• design of sensing system
• pose
• Starfire GPS
• Smiths Aerospace IMU
• obstacles
• bumper height ladar
• long range radar
• terrain
• two stationary ladar
• image processing
• implementation of sensorarbitration via
  traversabilitygrid

monocular vision
ladar
radar
ladar
65
NaviGATOR Component Diagram
66
60 m ? 60 m grid with grid resolution of 0.5 m ?
0.5 m
67
obstacle detection sensor(s)
sensor aribiter
68
DARPA Grand Challenge

• Build a system to travel up to 200 miles in 10
  hours in a desert environment for a prize of 2M.

69
DARPA Grand Challenge

• What to expect in the MOJAVE

70
DARPA Grand Challenge

• Created in response to a Congressional and DoD
  mandate, DARPA Grand Challenge is a field test
  intended to accelerate research and development
  in autonomous ground vehicles that will help save
  American lives on the battlefield.
• DoD has goal of having 1/3 of all military
  vehicles unmanned by 2015.

71
DARPA Grand Challenge

• 1st event held in March 2004
• 90 teams applied
• 25 teams selected to attend QID
• 15 teams in race
• furthest distancetraveled was 7 miles

72
2005 Team Selection

• 195 initial applications
• 140 video submissions
• 118 received site visits in May
• 43 teams selected to attend NQE at the California
  Speedway
• 23 teams advanced to the 8 Oct 05 race

73
2005
74
Topics

• Event Description
• Team Selection
• Team CIMAR
• team members
• vehicle system design
• System Testing
• NQE Qualification at California Speedway,27
  Sep to 6 Oct 05
• Grand Challenge Race, 8 Oct 2005

75
Desert Testing
Barstow, CA, 40 mile test course
76
Desert Testing
77
Topics

• Event Description
• Team Selection
• Team CIMAR
• team members
• vehicle system design
• System Testing
• NQE Qualification at California Speedway,27
  Sep to 6 Oct 05
• Grand Challenge Race, 8 Oct 2005

78
NQE Course
completed entire course 3 of 5 times
79
NQE
80
Topics

• Event Description
• Team Selection
• Team CIMAR
• team members
• vehicle system design
• System Testing
• NQE Qualification at California Speedway,27
  Sep to 6 Oct 05
• Grand Challenge Race, 8 Oct 2005

81
course map supplied two hours before vehicle
start time
start / finish
82
(No Transcript)
83
(No Transcript)
84
Grid at Start
85
(No Transcript)
86
Hugging Right Side of Road
87
Navigating a Very Cluttered Path
88
(No Transcript)
89
Why Not Multi-Agent?

• Agents in multi-agent systems usually act
  independently and display emergent behavior,
  whereas APF entities are fully orchestrated
• Multi-agent decision-making is typically via
  negotiations, whereas the APF will have one
  entity in governance
• Agents in multi-agent systems often are clones of
  one another, whereas in APF, each is designed and
  tuned to do one specific job
• Note that a Planning Specialist may be overseeing
  a component that is participating in multi-agent
  behaviors
• These APF entities will be referred to as
  Specialists

?B/U
90
Lexicons, Taxonomies and Ontologies

• Lexicon domain-specific dictionary of terms
• Taxonomy logical ordering/categorization
• Ontology formal specification of entities and
  their relationships/interpretations
• Ontologies are a rich source of Knowledge
  Representation content (entities/relationships)
  and ideas (how to represent knowledge)
• General Ontologies general purpose or common
  sense, e.g., OpenCyc (www.opencyc.org/) and
  DARPA Agent Markup Language (www.daml.org)
• AGV domain Intelligent Systems Ontology underway
  at NIST (Schlenoff 2005)

?B/U
91
World Model Knowledge Store

• AGVs representation of data, information,
  knowledge, and meta-knowledge (knowledge about
  the knowledge)
• May be a priori, perceived, inferred, or received
• Each entity must have a precise definition and
  format
• Relational or object-oriented data bases are
  often used
• Much content is geo-spatial in nature? extensions
  for GIS, topographical, polygonal objects
• May be centralized (JAUS), distributed (4D/RCS),
  or localized (publish/subscribe)
• Some (e.g., NIST) extend WMKS concept to include
  simulation and prediction

?B/U
92
Architectural Compatibility

• Compatibility with emerging standards is
  important to ensure interoperability and consumer
  adoption
• Examined three mainstream standardization efforts
  plus one lesser-known, but relevant architecture
• Joint Architecture for Unmanned Systems (JAUS)
• NIST 4D/RCS
• Service Oriented Architecture (SOA)/Component
  Oriented Architecture (COA)
• Distributed Architecture for Mobile Navigation
  (DAMN)

93
JAUS

• CIMAR work based on version 3.2 of the JAUS
  Reference Architecture with extensions under
  investigation by the JAUS Working Group
• Defines components and their interfaces
• Defines messaging construct (header and content),
  legal data types and all messages
• JAUS Tenets include
• Vehicle platform independence
• Mission isolation
• Computer hardware independence
• Technology independence
• Allows for User-defined Components and
  Experimental messages

94
NIST 4D/RCS

• Real-time Control System architecture under
  development since early 90s
• Defines functions and interfaces
• Defines 8 hierarchical temporal regimes (5 shown)
• Defines distributed, functional decomposition

50s
10min
5Km
1Hz
5s
50m
(source NIST)
95
SOA/COA

• SOA
• Industrial standard driven by W3C and Web
  Services
• Provides loose coupling and anonymous
  interoperability via strict interface compliance,
  high granularity, and self-disclosure of service
  capabilities
• XML is the messaging language of choice
• COA
• Predecessor to SOA
• Pre-assigns capabilities to components
• Multiple services per component allowed
• Focuses more on functional decomposition and
  loose coupling, less on interoperability

96
DAMN

• 1997 Ph.D. dissertation by J. K. Rosenblatt
• Scope limited to navigation and obstacle
  avoidance
• Supports distributed, heterogeneous entities
• Blends centralized and decentralized processing

(source Rosenblatt 1997)
97
Situation Assessment

• Defined as transforming raw data and stored
  information into into more general situational
  conclusions, usually via inference
• Numerous situation assessment nuggets mentioned
  in the literature that can be harvested
• Differentiate use of term when alluding to human
  situational awareness in the context of manned
  combat systems

(source NIST)
98
Behavior

• Sense-Plan-Act
• Creates a plan/updates world model based on
  perception
• Puts that plan into motion
• Uses perception of world to correct differences
  between planned results and perceived results
• Most deliberative planners begin with this
  planning style
• Widely used, including the NaviGATOR
• Reactive Behavior
• Based on Brooks Subsumption Architecture
• Perception maps directly to behaviors (no
  localized planning)
• Possible Behaviors are prioritized into levels
• Higher levels subsume the behaviors below them
• Emergent behaviors result due to extemporaneous
  blending
• Juxtaposition of extremes ? Hybrids

99
Decision-making

• Decision Theory insights provided by classical
  approaches
• Collaborative Decision-making via Argumentation
  (Karacapilidis 2001)
• Decision modeling, e.g. planning trees
  (Rauenbusch 2003)
• 3-step decision-making process (Hoffman 2005)
  e.g., Situation Assessment, Planning, and
  Commitment to a course of action
• Behavior Arbitration each behavioral component
  delivers its vote on control action and a
  Behavior Arbiter fuses them into a single command
• Key element of DAMN concept
• Extended to utility fusion based on utility
  theory

100
Decision-making

• Action Selection intelligent choice from menu of
  behavioral actions
• Survey of 10 approaches by 8 criteria (Pirjanian
  1998)
• One level of abstraction deeper than APF, but
  quite informative
• Used by NIST 4D/RCS
• Adaptive Planning altering a plan already in
  progress based on new information or a new
  situation
• Field began as an Expert System for military
  planners (Seares 1987)
• Hayes-Roth (1995) developed an adaptive planning
  architecture addressing 5 areas of adaptive
  behavior based on situation
• Altering planning time or Quality of Service
  (Hassan 2001) based on situation
• Used by NIST 4D/RCS

101
Knowledge Representation

• Schemas and constructs used to document,
  standardize, normalize and utilize domain
  entities
• Must address semantics/meanings of relationships
  among entities
• Must capture their names, descriptions,
  attributes and mechanism for determining their
  state or value
• Lexicons, Taxonomies and Ontologies
• World Model Knowledge Store

102
NIST Knowledge Representation Scheme for on-road
Driving
Task decomposition decision tree. (source
Barbera et al. 2004a)
Hierarchy of agent control modules
103
NIST Knowledge Representation Scheme for on-road
Driving
? Situational Conditions Tree
Behavior State Transition Table (source Barbera
et al. 2004a).
104
Proof of Concept Prototype

• LISP-based Intelligent Situation Assessment
  System (emphasis on Situation Assessment)
• Modeled 12 inputs, values are manually entered
• Determined 5 Conditions and 6 States owned by 3
  Specialists
• Used 20 generalized production rules and a
  Blackboard architecture
• Provided concept clarification and validation

105
Implementation for DGC2005

• Simple APF-based Speed Limiter implemented on the
  NaviGATOR
• Modeled 2 Conditions related to possible
  obstacles beyond the planning horizon and 1 State
  related to terrain ruggedness
• Data feeds from the PLSS (long-range ladar data)
  at 35 Hz and the VSS (roll rate, pitch rate) at
  20 Hz
• Output JAUS Set Travel Speed message with one of
  4 maximum speeds running at 20 Hz
• Top speed (25 mph)
• Caution speed (20 mph)
• Obstacle Avoidance speed (16 mph)
• Low speed (4 mph)

106
SA Implementation for DGC2005