Shakey s värld med HTNplanering

Shakey s värld med HTNplanering 2010-10-03 Artificiell Intelligens 2, 729G11 Maria Lindqvist Fördjupningsarbete, HT 2010 880913-0506 Linköpings Universitet marli314

2

Innehållsförteckning Inledning... 4 Introduktion till HTN planering... 5 Task Networks... 5 Sönderdelning i HTN-planering... 6 Fördelar med HTN-planering... 8 Översikt över STRIPS... 8 Shakey s värld i HTN hypotetiskt... 9 Slutkommentar... 11 Referenser... 12 3

Inledning Att gå från planering i experimentella miljöer till verkliga komplexa problem skapar en stor utmaning för agenterna. De system som har visat sig mest brukbara i verkliga situationer är hierarkiska system. I det här fördjupningsarbetet ställs två planeringssystem mot varandra STRIPS och Hierarchical Task Network-planning (HTN-planering) med syfte att få bättre förståelse för funktionen hos HTN-planering och de svårigheter som planering i en realistisk domän medför. 4

Introduktion till HTN planering Hierarchical task networks, eller HTN-nätverk är som vanlig planering, förutom att förhållandet mellan handlingar (actions) är i form av nätverk istället för enbart preconditions. För att fritt kunna konstruera task 1 networks istället för enbart att kunna sönderdela (decompose) framåt krävs ett bokföringssystem som representerar alla restriktioner som algoritmen ej än har framdrivit [3]. Det görs genom att de restriktioner som ej har blivit genomdrivna än presenteras i ett bokföringssystem som kallas task network. Ett sådant task network är ett par, w = (U, C) där U är uppdragsnoder, eller task nodes, och C är restriktioner. Varje restriktion måste uppfylla varje plan som är lösningen till planeringsproblemet. Processen slutar när alla icke-primitiva tasks är sönderdelade till primitiva underhandlingar (subtasks) och en actionsekvens är uppnådd. En HTN-planering kräver, förutom task networks, en problemdefinition och en planeringsdomän. Planeringsdomänen består av operatorer och HTN-metoder. Problemdefinitionen består av ett begynnande stadium, begynnande task network, operatorer, och en lista på metoder [1]. Nedan har jag listat ett antal sådana metoder, med ett tillhörande sönderdelningsträd (figur 1) för att illustrera metoderna bättre. Syftet med HTN-planering är inte att nå ett målstadium som det är i STRIPS, utan att hitta en mängd tasks som ska utföras. Slutmålet i HTN-planering kan kallas för en goaltask vilket är ett övergripande task som behöver utföras. Syftet är att hitta en hierarki med sönderdelningar som leder till en mängd primitiva tasks som kan utföras från det begynnande stadiet som definieras i problemdefinitionen. I det här arbetet ger jag enbart exempel på HTN-metoder, och inte problemdefinition eller domän. Task Networks HTN-planering bygger på task networks [2], vilket kan definieras som w = (U, C), där U är uppdragsnoder och C är restriktioner. Det finns exempel på olika restriktioner som är listade nedan: precedence constraints, alltså företrädande restriktioner betyder att för uppdragsnoderna u<v måste de handlingar som följer på u gå före handlingarna som följer på v. before constraints, alltså förekommande restriktioner innebär att något måste vara sant innan en handling kan utföras. after-constraints, eller efterrestriktioner betyder att något måste vara sant precis efter att handlingen är utförd. between-constraints, eller mellanrestriktioner innebär att något måste vara sant både före, under och efter en handling. 1 Task skulle kunna översättas till uppdrag, men jag anser att den översättningen inte är fullständig, så det engelska ordet kommer att användas även i fortsättningen. 5

I ett task network förekommer inte endast en metod, utan det är ett antal uppdragsnoder som tillsammans bildar ett nätverk som är sammankopplat av restriktioner mellan uppdragsnoderna. Givet ett task network som innehåller en uppdragsnod med en tillhörande task och en metod kan detta metoden sönderdela uppdragsnoden till en ny subtask vilket producerar ett nytt task network med en nya restriktioner och omdefinierade uppdragsnoder. För att sedan kunna utföra en sönderdelning till ett mer primitivt stadie krävs en början med ett task network av formen w = ({u}, C) där u är en uppdragsnod med en tillhörande task, som till exempel push-box(r, b, l 1, l 2 ). Sedan appliceras en metoden, till exempel Push(r, b, l 1, l 2 ) vilket gör att det task network som fanns från början omvaldas till w2 = ({u 1, u 2 }, C) eftersom att u 1 och u 2 är subtasks till den överliggande metoden och blir tillsammans uppdragsnoder i ett nybildat task network. Sedan appliceras en till metod, som hör ihop med u1, vilket skulle kunna vara Move(r, l 1, l 2 ). Då har två sönderdelningar skett och det nya nätverket blir w 3 = ({u 2, u 3, u 4 }, C 3 ) enligt: t u3 = setup(b) t u4 = move (r) t u5 = finish(b) C 3 = {u 3 < u 4, u 4 < u 5 } Sönderdelning i HTN-planering I HTN-planering är ursprungsplanen eller problemet en beskrivning av vad som behöver göras, till exempel att laga en cykel. Den blir mindre genom en action decomposition, alltså de stora handlingarna delas upp i ett antal tydligare handlingar ända tills enbart primitiva handlingar kvarstår. Det realiseras i ett sönderdelningsträd med så få grenar som möjligt för ett bra resultat, med sammansatta tasks i de övre noderna för att få en överblick. De sönderdelas till primitiva handlingar, som är handlingar som kan utföras automatiskt. Det betyder[1]att HTN-planering är en form av konkretisering snarare än att skapa en beskrivning av nödvändiga aktiviteter för att nå ett mål. Värt att notera är att planer som kommer ur ren HTN planering, det vill säga enbart ur sönderdelning är ett ganska onaturligt sätt att lösa problem och i de flesta verkliga domäner används en kombination av HTN-planering och partialorderplanering. Ett exempel på en goaltask i en HTN-planering är Light High Lightswitch i en Shakeydomän - alltså att tända en lampa som sitter så högt att Shakey måste klättra upp på en låda för att nå den. För att kunna göra den planeringen krävs att ett antal metoder listas. En metod används på ett sammansatt task som har okända resultat och gör att det kan sönderdelas till ett eller flera enklare subtasks. Subtasks är ett antal mindre abstrakta tasks än det sammansatta task som de tillhör, men kan ändå vara både sammansatta och primitiva tasks beroende på komplexiteten hos det begynnande tasket. Nedan har jag listat exempel på metoder som kan höra till Shakey-domänen: - För att utföra ett task att en robot ska tända en lampa i ett rum krävs att roboten befinner sig i rummet och att han har tillgång till en låda som han kan placera under lampknappen 6

- För att utföra ett task att en robot ska tända en lampa krävs först att han bedömer om lampan redan är tänd eller ej, och därefter tänder lampan om den är släckt. Dessa metoder kan realiseras i en mer detaljerad metodbeskrivning nedan som tillhör sönderdelningsträdet i figur 1: Light HLS(b, l1, l2, ls, r) Prepare(b, l1, l2 r) PushButton() PushBox() Climbup() Figur 1, Decomposition tree i ett task network. Light HighLightSwitch är ett sammansatt task som sönderdelas till Prepare och PushButton. De med grå bakgrund är primitiva tasks. En HTN-metod är en tupel med fyra komponenter: m = (name(m), task(m), subtask(m), constr(m)) där subtask(m), constr(m) är ett task network. Nedan presenteras ett antal HTNmetoder som bygger på att tända en lampa som befinner sig så högt upp att roboten måste klättra upp på en låda för att tända den. Light HLS (l1, l2, b, r, ls) ;; metod för Shakey att tända en lampa med en hög lampknapp Task: Light high lightswitch (l1, l2, b, r, ls) ;; En ickeprimitiv handling Subtask: u 1 = Prepare(r, b, l1, l2) u 2 = PushButton (r, ls, l1) Constr: u 1 < u 2 ;; subtask u1 ska utföras före subtask u2 Prepare (r, b, l1, l2, ls) ;; metod att förbereda för tändningen Task: Prepare (l1, l2) ;; En ickeprimitiv handling Subtask: u 1 = PushBox (r,, b, l1, l2) u 2 = ClimbUp (r, b, l1) Constr: u 1 < u 2, before({u 1 }, at(r, l1)), before({u 1 }, at(b, l1)) before({u 1 }, not( at(r, ls))) PushBox (b, l1, l2,r) ;; metod att flytta en låda om den inte är på l2 Task: u0 = push-box(l1, l2) ;; En primitiv handling Subtask: ;; inga subtasks, är en primitiv funktion Constr: before({u}, at(r, l1)), before({u}, at(b, l1)) ClimbUp (b, l1,r) ;; metod klättra upp på en låda om den befinner sig på samma plats Task: u0 = Climb-up-on-box (r, l1, l2) ;; En primitiv handling Subtask: ;; inga subtasks, är en primitiv funktion 7

Constr: before({u0}, at(r, l1)), before({u}, at(b, l1)) PushButton (b, l1,r, ls) ;; metod att tända lampan Task: u0 = push-button (r, l1, l2) ;; En primitiv handling Subtask: ;; inga subtasks, är en primitiv funktion Constr: before({uo}, at(r, l1)), before({u0}, at(b, l1)), before({u0}, at(ls, l1)) before({u0}, unlit(ls) Det som är ett task network är subtasksen och constraints, vilka båda behövs för att rätt bedömning om vilket subtask som ska utföras härnäst ska kunna göras. De constraints som förekommer i mitt exempel är before -constraints, alltså att något måste vara sant före ett task kan utföras. Det finns även precedence -constraints, där ett subtask måste prioriteras före ett annat subtask, vilket tydliggörs med en < -symbol. Det blir ganska självklart i det här fallet eftersom att det inte går att tända lampan innan det är förberett med en låda på rätt ställe. De sammansatta tasksen har subtasks men inte de primitiva eftersom att de går att utföras på en gång. Fördelar med HTN-planering Det är allmänt erkänt att planering i realistiska domäner kräver planering på olika nivåer [2]. Det gör att en enklare, mer beräkningsbar version av verkligheten kan tillverkas av planeraren. Det är därför som HTN-planerare är de planerarna som har använts mest när det gäller praktisk planering i verkligheten. Fördelen med en hierarkisk struktur är enligt Russel och Norvig (2003) att på varje nivå i hierarkin reduceras funktionen till ett litet antal aktiviteter, decompositions, på den nästkommande nivån vilket gör att beräkningskostnaden för att arrangera aktiviteterna blir liten (jämfört med andra planerare som reducerar en uppgift till ett stort antal aktiviteter). Översikt över STRIPS STRIPS är ett problemlösningssystem som söker genom världen efter en viss modell som gör att de uppsatta målen efterföljs [4]. STRIPS var skapad just för planering av en robot som ska navigera och flytta objekt. I STRIPS definieras ett startstadium och ett målstadium. Regler med preconditions och effekter definieras till varje handlingsoperator. Dessa regler tar världens predikat som argument vilket resulterar i ett nytt stadie i värden efter att regeln har blivit utnyttjad, om nu preconditions är uppfyllda. Algoritmen försöker finna en mängd operatorer som skapar ett stadie i världen som är detsamma som målstadiet. En operator i STRIPS består av tre huvuddelar: 1. Operatorns namn och alla parametrar 2. Preconditions 3. Effekter Nedan följer ett exempel på en operator i STRIPS för att flytta en robot r från plats A till plats B: 8

Action (Move(r, A, B), PRECOND: At(r, from, to) Robot(r) Location (A) Location(B) EFFECT: At(r, A) At(r, B) För att förenkla för den som tolkar koden delas ibland effekten in i add list för positiva parametrar och en DELETE LIST för negativa parametrar. Shakey s värld i HTN hypotetiskt Som beskrivet tidigare fungerar HTN och STRIPS mycket olika, men jag ska ändå försöka uttrycka Shakey s värld i ett hierarkiskt nätverk. Eftersom att HTN fungerar på ett annorlunda sätt än STRIPS, bör ett huvudmål sättas upp med ett antal underliggande sammansatta tasks som därefter kan leda till primitiva tasks istället för enbart en domän och ett problem. Det kan ske på olika sätt. Det ena är att ha ett statiskt mål, som till exempel AllLightswitchesOn som därefter måste sönderdelas till andra sammansatta tasks för att slutligen bli primitiva. Där ser vi fördelen med att kunna använda HTN-planering i Shakey s miljö, och det är att mer komplexa frågor om världen kan ställas. De frågorna var tidigare möjligen genomförbara med ADL-planering ocskså skulle vara fullt genomförbara med HTN-planering. Problemet är just Shakeydomänen så primitiv från början att det väldigt fort går ner i direkt genomförbara actions annars och trädet blir mer en samling rötter än ett verkligt träd, för att förklara det bildligt. Det skulle dock gå att genomföra, och acceptera att Shakeydomänen är så simpel och därför göra precis som det illustrerades när sönderdelningen förklarades, och nöja sig med att det träd som går ut blir det lite mer likt hur det fungerar i STRIPS, fast göra det med hierarkiska nätverk istället. För att kunna göra Shakey s värld i HTN-planering krävs att ett HTN-problem definieras. Ett HTN-planeringsproblem består av fyra delar [2]: Ett inledande tillstånd Ett inledande task network En mängd operatorer En mängd metoder Att lösa ett sådant problem går att göras på flera olika sätt, och det finns en mängd planerare som har använt sig av HTN-planering men som har använt helt skilda algoritmer. Den här studien fokuserar mer på sönderdelningen och på de övergripande funktionerna än på hur det appliceras i verkligheten för att lösa ett problem, därför förklaras detta bara ytligt. För just Shakey s värld skulle det inledande tillståndet vara placeringen av alla objekt och positioner i världen samt var Shakey befinner sig. Task network i det här fallet skulle börja med det task som först behöver utföras, samt de restriktioner som finns gällande vad som får utföras före något annat eller tvärt om. För en STRIPS action description för a, som har p som precondition och e som effekt blir den action som ska sönderdelas Achieve (e) eftersom att det är effekten som är huvudmålet. Sönderdelningen får då två steg: Achieve (p) och a. 9

Det betyder att den STRIPS-action som presenterades tidigare ser ut som följer i HTNplanering: Action (Achieve( At(r, A) At(r, B) PRECOND: at(robot, A), EFFECT: at(robot, B) ( At(r, A) 10

Slutkommentar HTN går att implementera på Shakey s värld, men det framgår tydligt att det inte är det som HTN-planering främst är till för. Hade resurs- eller tidsrestriktioner varit avgörande faktorer hade HTN-planering kommet mer till sin rätt. Det blir också mer komplicerat eftersom att Shakey-domänen gör att primitiva handlingar går att implementeras redan från början. Därför krävs en svårare uppgift, som till exempel att tända alla lampor eller dylikt för att det ska gå. Det var mycket svårt att hitta ett sätt att skriva ut hur det ska göras eftersom att HTNplanering, som jag förstod det, i sig inte är ett färdigutarberat planeringssystem. Istället är det mer är en teori med en algoritm som kan utnyttjas i olika former av planerare, ofta tillsammans med partialorderplanering. 11

Referenser [1] Artificial Intelligence A Modern Approach, Second Edition, Russell, Stuart, Norvig, Peter,Prentice Hall 2003 [2] Automated planning: theory and practice. Ghallab, Elsevier/Morgan Kaufmann 2004 [3] Zhou, H. H, Hu, D. H, Hogg, C, Yang, Q & Munoz-Avila, H. Learning HTN Method Preconditions and Action Models from Partial Observations. Proceedings of the 21 st international joint conference on Artificial intelligence, 2009. S. 1804-1809 [4] STRIPS: A new approach to the application of theorem proving to problem solving, Nilsson, N. E & Fikes, R.E. Stanford Research institute 1970 12