Goal-Driven Adaptable Software Architecture for UAVs

Transcription

1 SEAS DTC Annual Technical Conference 2008 Goal-Driven Adaptable Software Architecture for UAVs William Heaven, Daniel Sykes, Jeff Magee, Jeff Kramer SER001 Imperial College London

2 The Challenge Autonomous systems are deployed in environments in which contact with operators is infrequent or undesirable To be reliable, autonomous systems should be able to adapt to new circumstances on their own

3 The Challenge The system should determine (without intervention) How to achieve / maintain its goal and with what capabilities The software components required to control these capabilities C1 C2 C3 C4

4 The Challenge Automatically configure and execute these software components in a way that satisfies the goal Finally: Maintain goal satisfaction in a changing environment by updating software configurations generating alternative plans using alternative capabilities when necessary

5 Summary of work so far Goal Management Plan failure Change Management Constraints + LTL formulae Plan generation Configuration failure Component Control Configuration generation

6 Goal Management: Advances Shortcomings of old planner NuSMV-based plan generator unsuited to concurrent and distributed planning Hard to generate domain model from high-level specs Hard to manipulate and analyse output No simple means to separate system behaviour from environment behaviour

7 Goal Management: New LTSA Planner Extension of Labelled Transition System Analyser NuSMV-based algorithms adapted: LTS instead of FSM Both domain input and plan output modelled as LTS Advantages: Concurrent and distributed domains and planning Compositional planning for multi-agent systems Existing work on automatic generation of domain models from high-level user scenarios Compositional model and minimisation feature allow clear separation of system and environment behaviours in plans

8 Goal Management: New LTSA Planner

9 Goal Management: Domain Model Top layer manages a world model or domain Domain specified by temporal logic constraints over an alphabet of actions using fluent predicates defined in terms of these actions Alphabet set Actions = {start_goto, start_unloading, unloaded,.. } Fluents fluent LOADED = <loaded, unloaded> fluent AT_UNLOADER = <arrive_unloader, depart_unloader> LTL Constraints constraint C = [](!X start_unloading W LOADED && AT_UNLOADER)

12 Goal Management: Dynamic Plan Generation Domain LTS Pruned Domain LTS = Plan Plan generation

13 Goal Management: Dynamic Plan Generation fluent LOADED = <loaded, unloaded> fluent AT_UNLOADER = <arrive_unloader, depart_unloader>... constraint C = [](!X start_unloading W LOADED && AT_UNLOADER)... assert Goal =![]!LOADED!LOADED -> DONE LOADED && AT_UNLOADER -> start_unloading LOADED &&!AT_UNLOADER -> start_goto_unloader...

14 Goal Management: Dynamic Plan Generation fluent LOADED = <loaded, unloaded> fluent AT_UNLOADER = <arrive_unloader, depart_unloader>... constraint C = [](!X start_unloading W LOADED && AT_UNLOADER)... assert Goal =![]!LOADED!LOADED -> DONE LOADED && AT_UNLOADER -> start_unloading LOADED &&!AT_UNLOADER -> start_goto_unloader...

15 Goal Management: Dynamic Plan Generation fluent LOADED = <loaded, unloaded> fluent AT_UNLOADER = <arrive_unloader, depart_unloader>... constraint C = [](!X start_unloading W LOADED && AT_UNLOADER)... assert Goal =![]!LOADED If plan fails, replanning requested!loaded -> DONE LOADED && AT_UNLOADER -> start_unloading LOADED &&!AT_UNLOADER -> start_goto_unloader...

16 Change Management Middle layer selects and instantiates the software components and configurations required to implement a generated reactive plan Components implement plan actions Explicit provided ( ) / required ( ) interfaces used to derive complete configuration MotionController VectorGoTo MoveTo Implements start_goto_x actions

17 Change Management: Component Selection Interfaces give a dependency graph between components Configuration constructed by following dependency chains C1 C1 C5 C2 C7 C5 C2 C7 C6 C6 C3 C4 C3 C4 Selected configuration checked against structural constraints

18 Change Management: Selecting Alternatives B C B A Alternatives for each requirement fewer components A faster C more reliable

19 Change Management: Selecting Alternatives B C B A Alternatives for each requirement fewer components A faster C more reliable ADAPTATION

20 Component Control JamVM Backbone RMI Components JamVM Backbone Planner Interpreter Components

21 Demonstration High-level goal: Clear all yellow balls from given area Can be encoded as Continue loading and unloading balls indefinitely []((LOADED -> <>!LOADED) && (!LOADED -> <>LOADED)) []((LOADED -> <>!LOADED))... Assuming LOADED, next objective becomes!loaded Recall: fluent LOADED = <loaded, unloaded> constraint C = [](!X start_unloading W LOADED && AT_UNLOADER)

24 Demonstration

25 Summary As the bedrock of a reliable autonomous system, our architecture supports Automated generation of reactive plans, providing robustness in non-deterministic domains Automated selection of alternative software configurations at runtime to cope with system failures, changes in the world, and changes to operator goals Automated replanning when the current reactive plan and available software configurations are insufficient for achieving a goal

26 Future Work Key areas still to work on include Automated updating of the domain following an unexpected change in the world Taking architectural and non-functional requirements into account when selecting software configurations Guaranteeing smooth and safe transitions between configurations, preserving state and avoiding inconsistency Co-operation vs. decomposition for multi-agent, concurrent, distributed systems Simulations in more diverse environments Optimising adaptation using learning