1 / 66

GTrans: Mixed-Initiative Planning System

IT 803 Spring 2004 – Mixed-Initiative Intelligent Systems – Prof. G. Tecuci. GTrans: Mixed-Initiative Planning System. by Michael Cox Reviewed by Vu Le. Presentation Outline. Introduction to GTrans Planning as goal transformation . GTrans: a system using goal transformation

studs
Download Presentation

GTrans: Mixed-Initiative Planning System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IT 803 Spring 2004 – Mixed-Initiative Intelligent Systems – Prof. G. Tecuci GTrans: Mixed-Initiative Planning System by Michael Cox Reviewed by Vu Le

  2. Presentation Outline • Introduction to GTrans • Planning as goal transformation. • GTrans: a system using goal transformation • Example of using GTrans in planning • Details of GTrans • Lesson learned • References

  3. Typical Planning Models: Search • In AI community, one of the most dominant models of planning is search, as in Protégé. • Planning consists of searching from initial state to goal state via sequence of operators. • Pre-cond – Operator(params) – Effect • Example: blockworld B C A C C B B B A B A C A C A Initial state Final state (Goal)

  4. Typical Planning Models: Hierarchical Task Decomposition • The other common model is hierarchical task decomposition, as in Disciple. • The planning task is successively decomposed into subtasks until they are elementary tasks. • Find the solutions for simplest tasks. • Successively compose the solutions until solution to the initial task is obtained. T1 S1 … T11 S11 T1n S1n … S111 T111 T11m S11m

  5. The Alternative Approach:Planning as Goal Transformation • The “alternative” is to model planning as goal transformation. • Planning involves moving goals through a problem space to reach equilibrium between available resources & constraints of dynamic environment. • This approach is still using search in the background and hiding all details of search from user. • The user can steer the goal around the problem space with the help from system to find the best possible solutions.

  6. Planning as Goal Transformation • Equilibrium between resource and constraints: enough resource & constraints are preserved. • Constraints violation • Goal is to deliver package to a recipient at certain address. • Recipient is no longer at that address (constraint violated). • Goal change: return the package to sender. • Not enough resource • Goal is to destroy the bridge. • Not enough dynamites to fulfill the task (not enough resource). • Goal change: to reduce the transportation through the bridge such as damage part of the bridge.

  7. Planning as Goal Transformation • The motivation of modeling planning as goal transformation is • Cognitive model of planning as search is not intuitive for human because • Human planner typically jumps around based on existing knowledge rather than systematically searches the state space. B C A C C B B B A B A C A C A Initial state Final state (Goal)

  8. Planning as Goal Transformation • The other motivation: • Being able to understand planning details requires amount of knowledge in planning technology such as pre-conditions, post-conditions and operators with variables bound. • Naïve users feel overwhelmed by details of planning as search.

  9. Presentation Outline • Introduction to GTrans • Planning as goal transformation. • GTrans: a system using goal transformation • Example of using GTrans in planning • Details of GTrans • Lesson learned • References

  10. GTrans • Mixed-initiative Planning System. • Using goal transformation approach. • Using Prodigy planning system in backend.

  11. Presentation Outline • Introduction to GTrans • Example of using GTrans in planning • Create scenario • Step-by-step demonstration • Details of GTrans • Lesson learned • References

  12. Create Scenario • Create scenario is the first step in planning. • Create scenario loads a domain and sets up the objects that belong to domain. • Load domain: Military • File/LoadDomain/Military: A map comes up with no object. • Map has 2 rivers R1, R2 and bridges over them. There is a town & 2 airports. • Goal of this exercise is to prevent movement across rivers. • When user loads a domain, the system offers the relevant objects in that domain for user to select. • Military domain: Objects: fighter jets, warships, missiles…

  13. Create Scenario • The map has details but they are just images. • Objects that represent them are needed to interact with GTrans. • Objects have properties: F15 can destroy only 1 bridge and can damage any bridge. • Create objects: mobile v.s stationary objects. • Mobile objects are drag-and-drop enabled: airplanes, ships, people. • Stationary objects are not: bridges, rivers, towns, airports. • This scenario needs F15s to destroy bridges. • Create 5 bridges over 2 rivers, 4 F15s, 1 police, 1 infantry.

  14. Set Initial States • Select State/Initial States. • Once the user selects initial state, the system suggests lists of initial states associated with objects. • User can set the state of objects by right-click on them. • Examples: • F15_1 is ready • Airport_1 is close to river_2 • Bridge_1 enables movement over River_1

  15. Set Goals • Select State/Final States. • System helps set up the goals by providing lists of goals associated with objects. • There are 2 ways to set goal: • Right-click on target, a popup menu with goals associated with objects. Select the desired goal. Bridge: building bridge, destroy bridge. • Assign resource such as mobile object to target object by dragging: • Right-click on target, a list of goals associated with targets and resources comes up. Select the desired goal. • Drag F15 to bridge -> goal: destroy bridge by F15 • The goal of this scenario is to make River_1 impassable • The letter “G” will be asserted at the target.

  16. Run Planner • Click on Planning/Run to start the planner. • There will be some types of message returned from planner such as: Done or No Plan with explanations. • No plan to blow up all 5 bridges with 4 F15s. • Need goal transformation. • System helps user transform the goal by offering a hierarchical trees of predicates in particular domain. • is-destroyed  is-damaged • Impassable  restricted-movement.

  17. Transform Goal • Click on Planning/Change Goals to start the transform. • Select current goal and change it. • Change from “outcome-impassable” to “outcome-restrict-movement”.

  18. The Final Plan

  19. Presentation Outline • Introduction to GTrans • Example of using GTrans in planning • Details of GTrans • Architecture • Communication • Control • Shared awareness • Tasks • Evaluation • Lesson learned • References

  20. Architecture RMI KQML • Three-layer architecture: • GTrans RMI server • Planning user interface (PUI) • Prodigy/Agent

  21. Architecture • GTrans RMI server and Planning UI use RMI mechanism to communicate. • Planning UI and Prodigy/Agent use KQML to exchange information. • GTrans server allows multiple users to co-plan. • Planning UI coordinated with Prodigy/Agent allows users to create objects, set or modify goals, solve problems… • Prodigy/Agent allows underlying Prodigy to communicate with Planning UIs.

  22. GTrans Server • Users log in/out to/from GTrans server during planning. • A user shares planning information to other users via GTrans server in joint/share planning mode. • The user uses PUI to communicate with system. • The interactions of Gtrans server and Planning UIs follows publisher-subscribers pattern. • A PUI subscribes to the publisher (GTrans server) when user logs in to the system. • An event generates from PUI will be distributed to subscribed PUIs via publisher.

  23. Planning User Interface (PUI) • This is the user’s workplace where menu-based mixed-initiative transactions happen. • Users can setup goals, assign resources, change goals with agent assistance. • There are two types of transactions from Planning UI • To GTrans Server: RMI • To Prodigy/Agent: KQML

  24. Prodigy/Agent • Consists of Prodigy Planner and wrapper • Prodigy Planner is a domain independent, state-space planner. • Prodigy uses backward & forward search from initial states to goal. • Prodigy domains are represented with a conceptual hierarchy and a set of operators. • Wrapper serves as interface between Prodigy planner and Planning UI.

  25. Presentation Outline • Introduction to GTrans • Example of using GTrans in planning • Details of GTrans • Architecture • Communication • Control • Shared awareness • Tasks • Evaluation • Lesson learned • References

  26. Communication • There are 2 types of communication: • Among users • Between user and agent • Communication between users is realized by GTrans RMI server. • Communication between user and agent is realized by Prodigy wrapper.

  27. Human Users Communication RMI KQML

  28. Registration Service • GTrans RMI Server offers registration service • Each Planning UI connects to GTrans server has to register. • Each Planning UI disconnects to GTrans server has to unregister. • Registration service monitors all connected clients and allows interaction between clients. • Planning UI connects to server via Java RMI.

  29. Registration Service subscribe acknowledge create event acknowledge GTrans RMI Server Planning UI distribute event acknowledge unsubscribe • Move objects • Delete objects • Remove goals • Remove states • Release shared objects • Typical events: • Add objects • Set goals • Set states • Request shared objects

  30. RMI (Remote Method Invocation) • RMI facilitates the interprocess communication between Java Virtual Machines. • RMI enables remote method invocation. • RMI server creates the remote objects. • RMI client invokes a method on a remote object. • Example • Naming.bind(“rmi:///CalendarImpl”, new CalendarImpl()); //create an instance of object and bind it to name CalendarImpl • Naming.lookup(“rmi:///cs.gmu.edu/CalendarImpl”); //lookup the remote object at the specified URI: remote objects //bound to the name CalendarImpl at cs.gmu.edu

  31. Human User & Agent Communication

  32. Human User & Agent Communication • The communication is enabled via Prodigy wrapper. • KQML (Knowledge Query & Manipulation Language) is used in communication. • Lisp-like syntax • (tell :content (word “hello”) :sender M :receiver S) • (request :content (kill P)) • (achieve :content (killed P))

  33. KQML - Standard Verbs

  34. KQML - Standard Parameters

  35. Presentation Outline • Introduction to GTrans • Example of using GTrans in planning • Details of GTrans • Architecture • Communication • Control • Shared awareness • Tasks • Evaluation • Lesson learned • References

  36. Control Issues (Single Plan) • User sends planning request to agent via achieve(goals) • If the agent does not fully understand the context of the goals, then it asks user via query(obj,state) such as What is initial state of the missile? • The clarification is realized by reply(obj,state) • If everything is clear then agent generates plan and send back the plan to user via tell(plan) • If there are more than one available plans in system then the agent receives a standby signal. In this case we have multiple plans

  37. Control Issues (Multiple Plans) • When agent receives standby signal then it asks user if s/he wants more by ask-one. • The user can cancel or next • next signals agent to provide a stream of plans. • The first next provides all needed parameters such as depth-bound, time-bound… • agent sends back first plan via tell. • The next next specifies how the next plan differs from the first (shorter, different…) • Continue until no more plan

  38. Control Issues (Multiple Plans)

  39. Presentation Outline • Introduction to GTrans • Example of using GTrans in planning • Details of GTrans • Architecture • Communication • Control • Shared awareness • Tasks • Evaluation • Lesson learned • References

  40. Shared Awareness • There are two types of communication: • Among users • Between user and agent. • Consequently, there are two types of shared awareness: • Shared awareness among users • Shared awareness between user and agent

  41. Shared Awareness Among Users • There are 3 modes of planning • Separate planning: Plans cannot be seen by other planners, all resultant plans are independent. • Information sharing planning: Plans can be seen by other planners, all resultant plans are independent • Joint planning: Plans can be seen by other planners, all resultant plans combine into a complex plan. • Share/Joint planning allows shared awareness to be realized.

  42. Separate Planning • The users do not co-operate in separate planning. • No one can see other’s plan. • The domains from different users can be different. • In short, the two plans are total independent.

  43. Information Sharing Planning • The users do not co-operate in separate planning. • But one can see other’s plan. • The domains from different users can be different. • In short, the two plans are total independent. • One of purposes of this mode is to compare plans.

  44. Joint Planning • The users do co-operate in planning. • One can see other’s plan. • The domains from different users can be different. • In short, the two planning are independent. • Joint planning is really useful in multi-domains planning.

  45. Joint Planning • Example of joint planning: • Suppose to send a package from a post office to an oversea country. • One planner has expertise in truck-logistics domain. • The other planner has expertise in air-logistics domain. • Neither domain is suffice to carry on the task. • Neither planner can achieve the goal by itself. • Need to joint plan: from post office carry package by truck to nearest airport. From there fly the package over to that country.

  46. Shared Objects • Ownership of objects: in joint planning the server serves as repository of objects. • If user wants to borrow objects not owned by her/him then s/he sends request to server. • If the object is available (either not owned by any one or owned but not in use) then that object is sharable. • Example: • In military domain, an F15 is defined as being able to blow up only 1 bridge but can damage a numbers of bridges. • If the task is blowing up 2 bridges with only 1 F15 then there are 2 solutions: • Either ask for help by getting 1 more F15 if it’s available. • Or reduce the goal to blow up 1 bridge and damage 1 bridge.

  47. Shared Awareness between user and agent • The agent and user share information during the discourse. • The agent sends to user the info based on request: All objects in domain. All available goals in domain. All initial states in domain. All hierarchy of concepts, predicates in domain. • The information helps user create objects, set initial states, setup goals, transform goals.

  48. Shared Awareness between user and agent • All objects in domain: help user select available objects in domains. • Fighter jets, warships, missiles… in military domain. • Available goals in domain: help user decide what goal to achieve. • Associated with bridge is goal of destroying, building… • Initial states in domain: help user setup initial states of problem. • Associated with missiles is state of being stored, loaded… • Hierarchy of concepts, predicates: help user transform the goal. • Hierarchy of predicates: is-destroyed  is-damaged

  49. Presentation Outline • Introduction to GTrans • Example of using GTrans in planning • Details of GTrans • Architecture • Communication • Control • Shared awareness • Tasks • Evaluation • Lesson learned • References

  50. Task: User Task • The planning details are hidden from user in black-box. • The user has 3 handles to the black-box. • The user controls the planning process by: • Defining the goals. • Assigning the resources. This is nice feature of Goal Transformation. • Users has more control over the process. • Set the priorities of goals (not implemented). • Adjusting the goals and resources based on the world changes as well as the response (succeeded, failed with explanations) from black-box.

More Related