760 likes | 937 Views
DESIGN, IMPLEMENTATION AND TESTING OF A COMMON DATA MODEL SUPPORTING AUTONOMOUS VEHICLE (AV) COMPATIBILITY AND INTEROPERABILITY. CDR Duane Davis, USN. Ph.D. Committee: Dr. Don Brutzman Dr. Robert McGhee Dr. Neil Rowe Dr. Christian Darken Dr. Anthony Healey. Outline. Problem Statement
E N D
DESIGN, IMPLEMENTATION AND TESTING OF A COMMON DATA MODEL SUPPORTING AUTONOMOUS VEHICLE (AV) COMPATIBILITY AND INTEROPERABILITY CDR Duane Davis, USN Ph.D. Committee: Dr. Don Brutzman Dr. Robert McGhee Dr. Neil Rowe Dr. Christian Darken Dr. Anthony Healey
Outline • Problem Statement • Research Overview • Specific Objectives and Implementations • Research Contributions • Recommendations for Future Work
Problem Statement • Examples • Homogeneous vehicle system: Swarming • Programmed compatibility: CJTFEX 04-2 Coordinated MCM Current AV interoperability is limited by vehicle-specific data formats and planning systems. This stovepipe approach to AV command and control inhibits effective multi-vehicle operations and hinders the design of such systems. To date, the preponderance of multi-vehicle research has assumed inherent compatibility: homogeneous vehicle systems or explicitly programmed compatibility.
A Rigorously Defined Common Data Model: Vehicle-Independent Subsumes Vehicle-Specific Data Format Content Extensible Markup Language (XML) Schema Governed Data Model Requirements Mission Specification (tasking) Communications Mission Results Automated Conversions Data Model to Vehicle-Specific Formats Vehicle-Specific Formats to Data Model Exemplar Development and Implementation Data Model Support AAV 1 AUV 2 ASV 2 AAV 2 AUV 1 ASV 1 Research Overview
Research Objective 1 • Accurate Representation of Arbitrary Vehicle Tasking • Leverage Similarities—Similar Vehicles do Similar Things • Identify Activities that Vehicles are Required to Perform • Develop a Set of Task-Level Behaviors Capable of Specifying these Activities
Exemplar Data Model Task-Level Behavior Characteristics • Vehicle-Type Specific • 30 UUV Behaviors • 20 UGV Behaviors • 22 USV Behaviors • 26 UAV Behaviors • Behavior Types (determines behavior termination criteria) • Closed-Loop • Terminating—Implicit Termination Criteria • Open-Ended—Potentially Non-Terminating • Open-Loop • Non-Control-Related • Special Purpose—Effect Other Behaviors • Behavior Activation—Based on the Preceding Behavior Type • Closed-Loop Terminating—Activate Next Upon Termination • Closed-Loop Non-Terminating—Activate Next Immediately • Open-Loop—Activate Next Immediately • Non-Control-Related—Activate Next Immediately • Special Purpose—Activate Next Upon Termination
Research Objective 2 • Develop Translation Mechanisms for Automated Conversion between Vehicle-Specific Formats and the Data Model • Data Mappings Between the Data Model and Vehicle-Specific Formats of Interest • Types of Translations that Must be Supported • Data Model to Text-Based Vehicle-Specific Formats • Data Model to Binary Vehicle-Specific Formats • Text-Based Vehicle-Specific Formats to Data Model • Binary Vehicle-Specific Formats to Data Model
Translation of Data Model Data to Text-Based Vehicle-Specific Formats • Extensible Stylesheet Language for Transformation (XSLT) • Many Well-Proven Applications in Numerous Problem Domains • Relies on Data Mappings from the Model to the Target Format • Exemplars: • Phoenix UUV Scripting Language • ARIES UUV Waypoint Lists (Track.out files) • Seahorse UUV Orders • REMUS UUV Objectives Data Model Message or Script Vehicle-Specific Message or Script XSLT Stylesheet
Parse using a Context Free Grammar (CFG) Chomsky Normal Form (CNF) Cocke-Younger-Kasami (CYK) Algorithm Yields a Binary Parse Tree Translate Parse Tree to AVCL Depth First Traversal Template-Based Translation of Individual Parse Nodes Comparison to XSLT-Based Translations Fixed Order vs. Arbitrary Traversal Arbitrary vs. In-Order Result Output Document Generation Translation of Text-Based Vehicle-Specific Formats to the Data Model Example Chomsky Normal Form Rules: Mission -> LaunchCmd + MissionMiddle Mission -> LaunchCmd + MissionEnd MissionMiddle -> WaypointCmd + MissionMdl MissionMiddle -> SurfaceCmd + MissionMdl MissionMiddle -> WaypointCmd + MissionEnd MissionMiddle -> SurfaceCmd + MissionEnd MissionEnd -> WaypointCmd + RendezvousCmd MissionEnd -> SurfaceCmd + RendezvousCmd Example (Partial) Parse Tree: Mission MissionMdl LaunchCmd MissionEnd WaypointCmd SurfaceCmd RendezvousCmd
JAUS Binary Translation Between Data Model and Binary Formats • XML Encoding of Binary Format • Serialization of XML to Binary • Reading of Binary to XML • XSLT Conversion between Data Model and XML Encoding • Intuitive and Repeatable Implementation • Other Efforts • Distributed Interactive Simulation (DIS) XML • Unmanned Systems Common Service Specification (USCS) • Exemplar: Joint Architecture for Unmanned Systems (JAUS) Messages JAUS XML Schema Programming Object JAXB XML Serializer Reader XSLT XSLT AVCL
Translation Issues • Command Parameter Maintenance • Concurrent Behaviors vs. Self-Contained Commands • XSLT and Side Effects (Immutable Variables) • Simulate Mutable Variables using Parameters and Explicitly Controlled Iteration: begin XSLT processing variable B = sequential list of task-level-behaviors apply template for B1 with default parameters d1 to dn end XSLT processing begin template for task-level-behavior Bi with parameters p1 to pn for k = 1 to n variable vk if Bi updates pk vk = new_pk else vk = pk generate required output for Bi apply template for Bi+1 with parameters v1 to vn end template
Translation Issues (2) • Unmappable Vehicle-Specific Information • REMUS WaitStart Objectives • Seahorse Waypoint Collect Sound Velocity Profile (SVP) Field • … • Applicable Content Translated Accordingly • Irrelevant Content Ignored <UUVCommandScript> … <MetaCommand name=“waitMagnet”/> <MetaCommand name=“collectSVP” content=“true”/> … </UUVCommandScript>
Research Objective 3 • Support for Abstract Task Specification • Goals to be Accomplished • Constraints to be Observed • Specified Declaratively • Intuitive • Incorporation into the Common Data Model • Construction of Task-Level Behavior Scripts to Accomplish Declarative Goals • Inference of Appropriate Goals from Task-Level Behavior Scripts
Declarative Goal-Based Mission Definition • Finite State Machine (FSM) • States (Goals) • Operating Area • Goal Description • Transitions Dependent on Goal Success or Failure • Constraints • Launch and Recovery Positions • Avoid Areas • Ingress Routing • Egress Routing Mission Start Search Area A Fail Succeed Sample Environment in Area A Search Area B Succeed or Fail Fail Succeed Succeed or Fail Rendezvous with UUV-2 in Area C Mission Complete
G G G G Avoid Avoid Avoid Avoid Avoid Avoid Avoid Avoid S S S S Conversion of Declarative Missions to Task-Level Behavior Scripts • Global Path Planning • Transit Between Operating Areas • Observe Routing Requirements • Bypass Avoid Areas • Best-First Search • Shortest Available Path • Each Area Incursion Yields 2 Child Candidate Paths • Local Path Planning (Obstacle Avoidance) Still Required
Generation of Task-Level Behavior Sequences to Accomplish Declarative Goals • Templates for Simple Goal Types • Reposition • MonitorTransmissions • Jam • Illuminate MONITOR TRANSMISSIONS GOAL DEFINITION: <Goal alert="false"> <MonitorTransmissions/> <OperatingArea> <Rectangle> <NorthwestCorner> <XYPosition x="1950.0" y="1975.0"/> </NorthwestCorner> <Width value="100.0"/> <Height value="150.0"/> </Rectangle> </OperatingArea> <Duration value="600.0"/> </Goal> GENERATED TASK-LEVEL BEHAVIOR SEQUENCE: <GpsFix value="true"/> <MetaCommand name="beginGoal" content="monitorTransmissions"/> <Loiter description="Station at area center"> <XYPosition x="1875.0" y="2025.0"/> <Depth value="3.0"/> <MakeSpeed value="1.5"/> <LoiterDepth value="1.0"/> </Loiter> <MetaCommand name="receiverOn" content="true"/> <WaitUntilTime value=“600.0”/> <MetaCommand name="receiverOn" content="false"/> <MetaCommand name="endGoal"/>
Operating Area Coverage Pattern Generation • Decision-Tree Based Pattern Selection • Pattern Options • International Aeronautical and Maritime Search and Rescue (IAMSAR) Manual • Planner Derived • Predicate Values • Operating Area Characteristics • Vehicle Characteristics • Goal Requirements Point Datum Nearly Square or Nearly Circular Small Area Sector Pattern Shrinking Square Expanding Square Nearly Circular Parallel Track Pattern Nearly Rectangular Oriented Expanding Square Nearly Square Planner-Generated Pattern Predicate Nearly Rectangular Expanding Rectangle Search Pattern Type Planner-Generated Pattern True False
Expanding-Square Pattern Point-Focused Search Circular or Square Area Potentially Large Area Parallel-Track Pattern Area-Focused Search Rectangular, Circular, or Convex Polygonal Area Parametrically Specified IAMSAR Pattern Examples
Fast Solution A* Search Coverage-Pattern Generation • Search Definition • Area covered with points spaced at ½ required track spacing • A point is considered “searched” if a search leg passes within ½ track spacing • A pattern leg can end at any unsearched point • The search is complete when all points have been “searched” • Search Metrics • Partial path cost: path length + turn penalty • Remaining cost estimate: unsearched points * trk spacing * 5 • Favors patterns with fewer legs
Hill-Climbing Search Coverage-Pattern Generation • Identical Search Definition • Search Metrics • Partial path cost: path length + turn penalty • Remaining cost estimate: 0.25 * unsearched points * trk spacing • Favors patterns with shorter travel distances • Search Progression • Chooses the “best” available waypoint using an A* heuristic • No Backtracking • Goal state must be reachable from any intermediate state
Traveling Salesman Problem (TSP) Iterative Improvement Coverage-Pattern Generation • Search Definition • Area covered with points spaced at required track spacing • Each point must be used to end exactly 1 pattern leg • Search Metrics • Solution cost: path length + turn penalty • Favors patterns with longer, straighter legs • Search Progression • Start with an arbitrary visit order • Conduct pairwise comparison and swap locations in visit sequence as appropriate • Algorithm ends when no further improvements are obtainable
TSP Iterative Improvement with Simulated Annealing Coverage-Pattern Generation • Identical Search Definition • Identical Search Metrics • Search Progression • Conduct pairwise comparison • Switch order if better (usually) • Probabilistically switch even if worse • Probabilistically don’t switch even if better • Probability of a “bad” swap decision decreases linearly with time • Termination criteria • System cool (Pbad = 0) • No further improvements are obtainable
Comparison of Planner-Based Coverage-Pattern Generation Techniques
Goal Inference from Task-Level Behavior Scripts Overview • Assumptions • No MetaCommand Behaviors • Script Corresponds to a Single Goal • Direct Transit to and from Operating Area • Classification of Scripts as 1 of 5 Goal Types • Point Search • Area Search • Reposition • Patrol • Monitor Transmissions
75-Script Recall Set 15 of Each Goal Type 25 of Each Vehicle Type 15 Characteristics Values from 0 to 1 Weighted Closest Match Wins: CBR Characteristics: Goal Inference Using Case-Based Reasoning (CBR)
Conditional Probability and Bayes Formula: 14 Characteristics Discrete (mostly Boolean) Values Assumed Independence Probabilities 104 Script Recall Set Manual Adjustment in some Cases Maximum a Posteriori (MAP) Classification Wins NB Characteristics: Goal Inference Using Naïve Bayes (NB) Reasoning
Research Objective 4 • Development of a Hybrid Control Architecture Inherently Relying on the Common Data Model • Vehicle Independent • Provides High-Level Direction using the Existing Vehicle Controller • Requires Minimal Modification to Existing Controller • Relies on Previous Research Objectives • Overview • Uses a Declarative Goal-Based Mission Definition • Generates Task-Level Behavior Scripts to Accomplish Goals • Converts Task-Level Behavior Scripts to Vehicle-Specific Commands • Issues Vehicle-Specific Commands to Vehicle Controller • Replans as Required
The Extended Rational Behavior Model (ERBM) • Based on the Rational Behavior Model (RBM) • Three-Layer Hybrid Architecture Analogous to the Command Structure of a Naval Vessel • Strategic Level—High Level Mission Control (CO) • Tactical Level—Implementation of High-Level Direction (watch officers) • Execution Level—Hardware Interface (enlisted watches) • Leverages Other Research Objectives • Declarative and Task-Level Mission Specification • Generation Task-Level Behavior Sequences to Accomplish Declarative Goals • Translation of Task-Level Behaviors to Vehicle-Specific Commands
ERBM Architecture Extended Rational Behavior Model Controller Strategic Level Declarative AVCL Mission Agenda Control High-Level World Model Goal Planner Task-Level Behavior Script Script Status Tactical Level Mid-Level World Model Script Control Task-Level Behavior Translator Command Flow Command Status & Position Update Vehicle-Specific Command Visible Data Communications Execution Level (existing vehicle controller) State and Sensor Data
FSM-Based Strategic Level Control Search Goal FSM start Transit to Area in area, alert=false in area, alert=true target located single target=false activate Search Pattern Set Alert target located single target=true time out pattern complete time out Patrol Goal FSM start Complete Transit to Area pattern complete in area, alert=true in area, alert=false activate Patrol Pattern Set Alert time out time out target detected Complete
PC104 ERBM Controller Simulation VE “Position X Y” Messages ARIES Waypoint Lists “ScriptComplete” Messages “TacticalEnding” Message “ScriptFail” Messages QNXE Telemetry ERBMConnection Process RExec Process Actuators track.out Script Status Flag Hard Drive Shared Memory Data and Message Flow Hardware-in-the-Loop Simulation Data Flow On-Vehicle ERBM Implementation • The NPS ARIES UUV
Modeling UUV, USV and UAV Models 6-DOF Rigid-Body Dynamics Visualization X3D DIS Standalone (AUVW only) Vehicle Hardware in the Loop Virtual Environment (VE) Testing
ARIES UUV ERBM Results • Mission Consisting of a Single Reposition Goal • No Avoid Areas • Required Routing • In-Water Results from Monterey Bay (16 June 2006)
ARIES ERBM Results (2) • Mission Consisting of a Single Monitor Transmissions Goal • 1 Circular Avoid Area • Rectangular Operating Area • VE Results using On-Vehicle Implementation
ARIES ERBM Results (3) • Missions Consisting of Similar Single Area-Search Goals • Single-Target (Left) and Multi-Target Search • Target Detection (Simulated) as Indicated • In Water Results from Monterey Bay (25 July 2006)
ARIES ERBM Results (4) • Multi-Goal Mission • Executes Single-Target Area Search First • On Success (Left) Executes Patrol Goal • On Failure (Right) Executes Monitor Transmissions Goal • VE Results using On-Vehicle Implementation
Research Conclusions and Contributions • Leveraging of dissimilar vehicle commonalities in the development of a vehicle-independent AV data model • Viability of XML as a format of choice for this common data model • Practical application of the common data model to actual vehicles
Research Conclusions and Contributions (2) • Implementation of a set of vehicle-independent task-level behaviors with deterministic time-arc semantics • Demonstration of the use of these behaviors to encode tasking for arbitrary vehicles
Research Conclusions and Contributions (3) • Development of translation mechanisms for conversion between the XML-based common data model and vehicle-specific data formats (text and binary) • XSLT • CFGs • Intermediate XML Form
Research Conclusions and Contributions (4) • Development of a declarative mechanism relying on high-level goals for AV task specification that is more abstract and intuitive than typical AV tasking formats • Implementation and refinement of techniques for converting between declarative goals and task-level behavior scripts
Research Conclusions and Contributions (5) • Design and implementation of a hybrid control architecture that leverages the declarative-to-task-level and task-level-to-vehicle-specific translation capabilities provided by the common data model to extend the autonomous capability of arbitrary vehicles with minimal modification to existing control software
Recommendations for Future Work • Testing with More Actual Vehicles of Different Types • More Rigorous Analysis of UGV, USV, and UAV Requirements • Standard Mission Systems, Payload, and Manipulator Interface and Incorporation into the Task-Level Behavior Set • Planner Generation of Multi-Vehicle and Multi-Pass Searches • Study of Goal-Type / Script Characteristics Relationships and Improved Goal-from-Script Inference • Improved ERBM Tactical Level Functionality • Use of the Common Data Model in Direct Support of Coordinated Operations • Exploration of Various Message-Translation Options During Coordinated Operations • Use of the Common Data Model to Facilitate Interface between AV Systems and More General Command and Control Systems • Possible Evolution from Data Model to Ontology
Task-Level Behaviors • Similar Efforts • Joint Architecture for Unmanned Systems (JAUS) • NATO Standardization Agreement (STANAG) 4586 • Common Command Language (CCL) • Commonalities • Potential Command Types • Closed-Loop—Control Relies on State Feedback • Open-Loop—Explicit Actuator Settings • Non-Control-Related—Mode and Selection Switches • Deterministic Time Arc Semantics
Research Objective 1a • Inter-Vehicle Message Set Development • Identify Messaging Requirements • Implement Messages Meeting these Requirements
Inter-Vehicle Messaging • Related Efforts • Remotely Operated Vehicle (ROV) Systems • Inherently Message Based • JAUS, STANAG 4586 • Vehicle-Independent AV Systems • CCL • Compact Control Language (C2L) • Cooperative Distributed Oceanographic Sampling Network (CoDA) • Foundation for Physical Agents (FIPA) Communicative Act Library Specification (CALS) • Request-Inform Model
XSLT-Based Translation Issues • Limited Numerical Processing • Turing Complete, but not Necessarily Easy • Example: Trigonometry • XSLT Extensions—Typically Implemented in Java Static Java Method Invocation <xsl:value-of select=“ java:LatitudeLongitudeConversion.getXFromLatitude($geoOriginLat, ./LatitudeLongitude/@latitude) ”/> Extension Namespace Method Parameters (XPath)