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 • Example of using GTrans in planning • Details of GTrans • Lesson learned • References

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)

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

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.

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.

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)

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.

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

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

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

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…

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.

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

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.

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.

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

The Final Plan

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

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

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.

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.

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

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.

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.

Human Users Communication RMI KQML

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.

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

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

Human User & Agent Communication

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

KQML - Standard Verbs

KQML - Standard Parameters

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

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

Control Issues (Multiple Plans)

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

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.

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.

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.

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.

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.

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.

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.

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

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.

GTrans: Mixed-Initiative Planning System