Managing Multiple Moving Vehicles with Patch Models Venkatesh

Managing Multiple Moving Vehicles with Patch Models Venkatesh G. Rao Postdoctoral Associate Cornell University Raffaello D’Andrea Associate Professor Cornell University Four Year MURI Research Review UCLA, January 28, 2005 With inputs from Tichakorn Wongpiromsarn and Thientu Ho

What Next?

Outline Focus: missing elements: symbolic-subsymbolic interface, functional integration, abstraction and hierarchies, open systems, expressive coordination mechanisms… • Motivation: combat operations and wide-area disaster relief • Region Connection Calculus (RCC) • Patch models for abstraction • Implementation overview • Ongoing work

Air Combat Operations • Vast amounts of spatio-temporal information • 200 -plus aircraft, dozen types, service, mission hierarchies • 24 -hour cycle of planned missions/sorties, plus reactive and opportunistic missions • Main bottleneck: mission coordination and resource allocation • Opposed architectural tensions: centralized, human-in-loop information sharing versus autonomy for agents (Rob Murphey, circa last week) (Based on discussions with Lt. Col. Fred Zeitz, USAF (retd). )

Future of Air Combat (OSD) Manned Aircraft AEW Air Combat CAS Nonlethal SEAD Stand-Out AEA Mission Complexity Armed Recce Strike Current UAVs Comm Relay Stand-In AEA Information Operations Non-Pene ISR Reactive SEAD Deep Strike TAC Recce Cruise Missiles Likelihood of Encounter Lethal SEAD Potential UCAV Missions High Value Strike Penetrating ISR Directed Energy BDA Slide Taken from OSD UCAV Missions Briefing, 10/7/03 Presented at UCAVs, Armed UAVs and LAMs Conference by Mr. James Durham, Lead, Deputy Secretary of Defense UCAV Options Study, Office of the Secretary of Defense, Programs, Analysis and Evaluation, TACAIR Division

Tsunami Relief • Dozen countries • Dozen navies and air forces • Political constraints on resource movement • ‘Last Mile’ distribution network overloaded • Poor coordination: too much material in some districts, too little in others • HUNDREDS of organizations working bottom-up, THOUSANDS of individuals participating randomly • Relief material traffic jams in frontline cities

The System Design Problem • Problem 1: A ground unit in a combat theater requests a strike mission for a target of opportunity that will be vulnerable for 30 minutes. • ANALYSIS: Can C 2 system achieve 30 -minute WC reactivity? • SYNTHESIS: Given a dozen such process performance parameters, design a C 2 • Problem 2: A businessman in Colombo, Sri Lanka, wants to volunteer his fleet of 6 trucks for tsunami relief work logistics. • ANALYSIS: Can the combination of local, national, intergovernmental and non-government agencies deliver 90% utilization of these trucks over the next week? • SYNTHESIS: Design a distributed disaster-relief coordination website that permits this level of efficiency of utilization

Problem Characteristics • • • Kill-chain is interesting because it crosses functional boundaries What is the right ontology? What information is pertinent and how do you represent it? How do you reason about this information? What problem solving processes need to be engineered? How do you design a system that realizes the representations and problem solving processes using agents as building blocks? • GOAL: Sufficiently simple system models to support distributed planning, scheduling, control, learning and human interaction. Models must also facilitate posing of global-scope questions such as kill-chain reaction time.

Tool: Region Connection Calculus* • Randell, Cui and Cohn, 1992, based on Allen, 1983 • Main application to do: Weather and GIS

Representing Combat Theaters

Representing Disaster Relief Operations

Reasoning and Computation • RCC is NOT set theory (= regular sets of T 3 spaces) • RCC is undecidable; decidable subsets exist • For A+B, A’, “many sorted logic” called LLAMA is needed • Need extra machinery for time, orientation, shape, variety • Reasoning with any of these individually is NP hard • All can be formulated as standard CSPs • Poverty Conjecture: “There is no problem-independent, purely qualitative representation of space or shape” (Forbus et. al. , 1987) • OUR GOAL is representational; computational processes will be function dependent and include quantitative data

Abstraction for motion domains • • Can support (semi/) automated reasoning with abstract models Cut down information overload for humans in loop Insulate efficient computation Protect symbolic technology from numbers and calculus

Patch Models Let G be the set of regions in the plane satisfying RCC axioms. A patch p(t) is a region of the plane, defined for the instant t. Given a domain (D, E), and a function E (t, e), (D is in G, and E is a set of entities), satisfying: a scene history S (t 0, tf) is a triple (D, E, E(t)) defined on [t 0, tf]. A view history V(t 0, tf) is a pair (P (t), R (t)) where P (t) is a set of patches and R is a partial representation function

Patch Models (contd. ) A view history is said to correctly represent a scene history if Restricting S (t 0, tf) and V(t 0, tf) to an instant yields views and scenes. Continuity for scene and view histories is defined by: where the term |…| represents the measure of the set difference between the regions denoted.

Illustration

Patch Models (contd. ) A view history is strongly continuous if the cardinality, n, of P(t) remains constant in [t 0, tf]. For a strongly continuous view history, define the region connection state X(V(t)) of the view history : A patch model is a scene history and a set of one or more view histories that represent it.

Continuity illustrated • • • Formation and breakup: two patches created and destroyed? One patch dormant? Did the patch at t+ become the patch at t- by moving or is it a new patch? Cause of subtleties: patches do not have physical identities

Example: Entry-and-Exit Basic mission template for hostage rescue, covert operations, rush plays in football

Entry-Exit (contd. )

Entry-Exit (contd. ) Region connection history Sample portion of realization

Sensing and Command • Any correct view history that can be uniquely constructed from a scene history is a legal observer view history Vo(t). • Any (possibly incorrect) view history is a legal command view history Vc(t) for the domain (D, E) it represents for the period [t 0, tf] that it is defined. • A view history error Vc(t)-Vo(t) is defined if R(t, e) and E(t, e) induce the same partition on E. • Vc-Vo can be computed from X(Vc(t)) and X(Vo(t)) • Control problem: achieve Vc(t)-Vo(t) =0

Remarks 1. The definitions define legal dynamic abstractions 2. Partiality of R(t, e) permits relevance-based abstraction 3. R(t, e) being into allows for arbitrary nonrepresentational patches in P(t) 4. Continuity enforces RCC transition continuity 5. Strong continuity captures persistence of a team entities 6. Discontinuities model context shifts and formation and breakup phenomena (moving to a different induced partition of E)

Expressivity • Problem: trivial representations • Define expressivity e(V(t)) of a view as the ratio of the size of the reachable set of X(t) to the size of the state space, 8 n(n-1)/2 under arbitrary rigid translations of all patches in P(t). • Expressivity is hard to compute, but bounds can be computed.

Examples • The scene itself has e= (2/8) n(n-1)/2 • The trivial view: n patches all equal to the whole domain has e= (1/8) n(n-1)/2 • Hull expansion observer view e =(3/8) n(n-1)/2 • ‘Hula Hoop’ observer view has e > (3/8) n(n-1)/2 • Expressivity is usefully high when the abstraction is neither too coarse, nor too fine.

Spatio-Temporal Realizability • A view history is realizable if there exists at least one possible scene history, with initial scene S(t 0), such that Vc(t 0, tf) is a representation of S(t 0, tf). • Relation to expressivity: highly expressive views lead to more realizable futures • Must consider temporal realizability as well, to achieve desired RC vector

Examples 1. Finite hula-hoop views of finite number of infinitismal entities (completely realizable) 2. Two cars at an intersection, patches defined relative to road edges and car front and rear (but not lateral position) 3. ATC, patches defined relative to nominal trajectories (Tomlin’s ATC method)

Patch Model Capabilities • Planning: RCC-TIC CSP (can handle dynamic worlds!) • Observation becomes view history generation • Execution monitoring becomes view drift detection • Feedback control becomes view matching • Coordination becomes view merging • Inter-mission conflict resolution is frame patch constraint satisfaction • Adversary intention recognition is RCC string recognition • Resource allocation: RCC plus occupancy distributions • Uncertain information translates to low-expressivity views (view dilution occurs as pdf covariances increase) • Generals have balanced resolution views, privates have unbalanced resolution views • Multiple hierarchies (mission/service): multiple views at each node • Humans enter the loop naturally as part of the plan refinement problem

Caveats • Poverty conjecture: will always need to augment RCC -based information • Planning is between PSPACE to EXPSPACE hard, but… • Plan adaptation and refinement is the need, rather than first-principles planning • BIG ONE: One-pass view history realization not enough, need convergent iterative (multipass) refinement architectures

Patchworks Implementation Architecture Human Input Patch Model Layer (Abstraction) Interface to other processes (planning, coordination, communication, learning) Detailed domain representation layer iteration Distinction from target assignment simulator: 1. Need light-weight representations for symbolic logic methods 2. Support interleaved deliberative/reactive behaviors 3. Make space/time fundamental Motion Planning Kernel Execution Layer

Patch-Based C 2 Architecture Automate 80% of information flow via views; rule bases capture coordination protocols, command loci Slower, coarser view histories upstream in hierarchy, created trickle-up, trickle-down (view filtering and fusion) Command Node 1. 1 View 2 Command Node 1. 1. 1 Command Node 1. 1. 2 View 1 View 2 Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Dynamically defined command nodes; autonomy locus composed from mission and service hierarchy views, composition rules Vehicle 6 Wrapper-based domain interaction layer, real-time reconfigurable

Glimpses of Refinement Algorithm portfolio approach for repairing broken paths (Thientu Ho) Failure vs. speed tradeoff for highly aggressive discounted horizon dynamic refinement using circular arcs (Tichakorn Wongpiromsarn)

Summary • Developed theoretical basis for abstraction-based motion management in complex, adversarial environments • Developed prototype abstraction-based motion management system (patchworks) • Proof-of-concept demonstrations of support for centralized/decentralized planning, plan recognition and coordination • Completed (unintegrated) components for iterative path refinement

Ongoing Work • • • Refine theory Support more processes and functions Support automated abstraction Release open source version 2. 0 STRETCH goal 1: import RCC-based primitives into a planning DDL, glue patch models to BDI (Joint Intention) theory • STRETCH goal 2: Demonstrate multi-node system in a simulation game • Publication pipeline: CCO ’ 05, GNC ‘ 05

Optimization techniques for multi-vehicle cooperative control M. Earl and R. D’Andrea (Cornell University) Modeling and strategy generation • MILP methods Improve MILP efficiency using intelligent time discretization techniques • Centralized planning (using fast tree search techniques) with decentralized plan execution (using optimal trajectory primitives) Algorithm analysis Demonstrate cooperative control methods on adversarial missions derived from Robo. Flag • Tradeoff between computational complexity and optimality • Phase transitions as a function of vehicle capabilities (helpful discussions with C. Gomes).