Introduction to Automated Task Planning Jonas Kvarnström Automated Planning and Diagnosis Group Artificial Intelligence and Integrated Computer Systems (AIICS) / IDA jonkv@ida jonkv@ida What is Planning? Shakey 3 4 � Classical example: Shakey � Used the STRIPS planner Planning is thinking ahead � Stanford Research Institute Problem Solver � One of the first planners (1969) Not just reacting to what happens! Thinking about possible actions and their effects, formulating a complete plan that describes what to do and when, in order to achieve a goal …so when do we want computers to do that?
jonkv@ida jonkv@ida Miconic 10 Elevators Sheet Metal Bending 5 6 � Schindler Miconic 10 elevators � Robots bending sheet metal � People enter their destination � Goal: Bend a flat sheet to a specific shape before they board an elevator � Constraints: The piece must not collide with anything when moved! � Many elevators, many floors ( Geometric reasoning required) � The goal : For everyone to be at their destination � Optimized operation saves a lot of time = money! � The plan tells us: Which elevators should go to which floors, in which order? � The gain : Less time to wait for an elevator! jonkv@ida jonkv@ida NASA Earth Observing-1 Mission Unmanned Aerial Vehicles 7 8 � Earth Observing-1 Mission � Unmanned aerial vehicles � Satellite in low earth orbit � Multiple agents to coordinate � Can only communicate 8 x 10 minutes/day � Actions executed concurrently � Operates for long periods without supervision � CASPER software: Continuous Activity Scheduling, Planning, Execution and Replanning � Dramatically increases science returns � Interesting events are analyzed (volcanic eruptions, …) � Targets to view are planned depending on previous observations � Plans downlink activities: Limited bandwidth � http://ase.jpl.nasa.gov/
jonkv@ida jonkv@ida UAV 1: Photogrammetry UAV 2: Traffic Monitoring 9 10 � Photograph buildings, to generate 3D models � Monitor traffic / find possible routes for emergency vehicles jonkv@ida jonkv@ida UAV 3: Finding Forest Fires UAV 4: Emergency Services Logistics 11 12 � Patrol large areas searching for forest fires, day after day after day… � Assist in emergency situations � Deliver packages of food, medicine, water
jonkv@ida Why Planning? 13 � Can’t we just solve these problems ourselves? � Manual planning can be boring and inefficient Domain-Specific vs. � Who wants to spend all day guiding elevators? � Automated planning may create higher quality plans Domain-Independent Planning � Software can systematically optimize, can investigate millions of alternatives � Automated planning can be applied where the agent is � Satellites cannot always communicate with ground operators � Spacecraft or robots on other planets may be hours away by radio jonkv@ida jonkv@ida Introduction Domain-Specific Planning 15 16 � Let’s say we are interested in the photogrammetry domain � Domain-specific planner : Created for a particular domain � Multiple UAVs available � Input: A map containing buildings � Everything else is implicit, � Goal: To take pictures of buildings since the planner already knows what actions are available, etc (hardcoded!) � Implementation: � Calculate suitable UAV positions � Call a Travelling Salesman Problem solver � Generate flight commands PG Plan PG Problem PG-specific Planner � How do you create a photogrammetry plan ? Sounds simple, and can be very efficient! But…
jonkv@ida jonkv@ida Domain-Specific Planning Domain-Independent Planning 17 18 � Specialization means less flexibility ! What if… � We want a generic planning system! � you want to deliver a couple of crates at the same time? � Capable of taking a high-level description of any problem domain and then solving problems within the domain! � Generalize input… PG + Delivery Photogrammetry Satellite Planner problem instance problem instance � you have to consider refueling ? � Different algorithm! PG UAV Satellite General General Plan Plan Planner Domain Domain Planner Planner w/ fuel � you have two UAVs and a UGV (ground vehicle)? � A single planner � Different � Improvements to the planner � all domains benefit Multi- algorithm! � High-level domain and problem definitions TSP � Easier to specify these than to write specialized algorithms planner � Easier to change than a hard-coded optimized implementation � you want to survey an area (send a video feed of the ground)? � Also useful for rapid prototyping � you have dynamic no-fly-zones (”don’t fly there at 15:00-16:00”)? jonkv@ida jonkv@ida What is Common? This is Common! 19 20 � The world contains various types of objects What is common to all of these problems? � Buildings, cards, aircraft, switches, people, … � We are generally interested in properties of these objects � Location of a card , whether we have a picture of a building or not, … � Goals can be described as desired properties � We should have a picture of each building � Actions modify properties (simplified!) � now the UAV is in the air � takeoff(uav) � now we have a picture of the building � photograph(uav, building) � Can only be executed if we can see the building
jonkv@ida jonkv@ida Example 1 Example 2 21 22 � 2. What properties can different types of objects have? � In the Emergency Services Logistics domain: (Defined using state variables ) � 1. What objects exist? � An object is or isn’t at a certain location: at(object, loc) � Helicopters ! A helicopter is or isn’t at a certain location: at(heli, loc) heli = { surv1, surv2, …, A helicopter is or isn’t carrying a certain box: carrying(heli, box) cargo1, cargo2, … } � Boxes ! box = { box1, box2, … } � Locations ! loc = { basestation, person1, person2, …, depot1, depot2, … } � Let’s generalize: Both helicopters and boxes are objects as well. jonkv@ida jonkv@ida Example 4 Example 3 23 24 � 3. What properties do the objects of the current problem have now ? � 4. What can we do about it? Actions! � Every box is at a certain location: � Example: fly(heli, loc1, loc2) at(box1, depot1), � Preconditions: at(box2, depot1), … at(heli, loc1) Situation � Every helicopter is at a certain location: loc2 is free – no other helicopter there right now at(surv1, basestation), L1 L2 fuel(heli) > dist(loc1, loc2) * fuelUsage(heli) at(surv2, person1), … � Effects: � Some helicopters are carrying boxes: at(heli, loc1) is no longer true carrying(cargo1, box4) at(heli, loc2) is true instead fuel(heli) decreases by dist(loc1, loc2) * fuelUsage(heli) � Time requirements: � 4. What properties should they have ? distance(loc1, loc2) / speed(heli) This is our goal! Situation � Take off / land � at(box1, person1), we want to at(box2, person2), … � Hover at the current location achieve � Position the camera at angle θ � Take a visual picture / Take an infrared picture � Lift a package using a winch / Deliver a package using winch
jonkv@ida Domain-Independent Planning 25 Input 1: Planning domain Object Types: There are UAVs, boxes … Properties: Every UAV has a maxSpeed, … Actions: Definition of fly, pickup, … Input 2: Problem instance Objects: Current UAVs are {UAV1,UAV2} Initial State: Box locations, … Goal: Box b1 at location l1, … But what language should we use? jonkv@ida jonkv@ida Desirable Properties Classical Planning 27 28 � Desirable properties of a domain-independent planner: � For efficiency, planners generally exploit domain structure � Should be as general as possible � This implies constraining the expressivity of the planner and its input language! � Handle a wide variety of domains � Should be as efficient as possible � Generate plans quickly � Classical planning uses a common set of constraints… � Should generate plans of the highest quality � Sometimes called "STRIPS planning" � Fewer actions, lower cost, faster to execute, … � Demonstrated using a simple domain: The Blocks World � Should support the user as much as possible � Also introduces PDDL, the Planning Domain Definition Language � Provide useful high-level structures such as actions � General language that a user can easily specify � Subsets are supported by most modern planners Many of these properties are in direct conflict!
Recommend
More recommend
