Managing Multiple Moving Vehicles with Patch Models

1. Managing Multiple Moving Vehicles with Patch Models Venkatesh G. RaoPostdoctoral 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

2. What Next?

3. 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

4. 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).)

5. Manned Aircraft Potential UCAV Missions Current UAVs Cruise Missiles Future of Air Combat (OSD) Air Combat CAS AEW Nonlethal SEAD Armed Recce Reactive SEAD Stand-Out AEA Mission Complexity Strike Stand-In AEA Information Operations High Value Strike Non-Pene ISR Deep Strike Penetrating ISR TAC Recce Lethal SEAD Directed Energy Comm Relay 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 Likelihood of Encounter

6. 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

7. 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 C2 system achieve 30-minute WC reactivity? SYNTHESIS: Given a dozen such process performance parameters, design a C2 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, inter-governmental 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 The System Design Problem

8. 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.

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

10. Representing Combat Theaters

11. Representing Disaster Relief Operations

12. Reasoning and Computation • RCC is NOT set theory (= regular sets of T3 spaces) • RCC is undecidable; decidable subsets exist • For A+B, AB, 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

13. 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

14. Patch Models Let G be the set of regions in the plane satisfying RCC axioms. A patchp(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, andE is a set of entities), satisfying: a scene historyS (t0, tf) is a triple (D, E,E(t)) defined on [t0, tf]. A view historyV(t0, tf) is a pair (P (t), R (t))whereP (t) is a set of patches and R is a partial representation function

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

16. Illustration

17. Patch Models (contd.) A view history is strongly continuous if the cardinality, n, of P(t) remains constant in [t0, tf]. For a strongly continuous view history, define the region connection stateX(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.

18. 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

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

20. Entry-Exit (contd.)

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

22. Sensing and Command • Any correct view history that can be uniquely constructed from a scene history is a legal observer view historyVo(t). • Any (possibly incorrect) view history is a legal command view historyVc(t) for the domain (D,E) it represents for the period [t0, 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-Vocan be computed from X(Vc(t)) and X(Vo(t)) • Control problem: achieve Vc(t)-Vo(t)=0

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

24. 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 inP(t). • Expressivity is hard to compute, but bounds can be computed.

25. 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 viewe =(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.

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

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

29. Patch Model Capabilities • Planning: RCC-TIC CSP (can handle dynamic worlds!) • Observation becomes view history generation • Execution monitoring becomes view drift detection • Feedback controlbecomesview 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

30. 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

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

32. Command Node 1.1 View 1 View 2 Command Node 1.1.1 Command Node 1.1.2 View 1 View 2 View 1 View 2 Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Patch-Based C2 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) Dynamically defined command nodes; autonomy locus composed from mission and service hierarchy views, composition rules Wrapper-based domain interaction layer, real-time reconfigurable

33. 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)

34. 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

35. 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

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