Planering – Bild 1 Planering Sökning jämfört med planering STRIPS operatorer Icke-linjär planering

Planering – Bild 2 Sökning jämfört med planering Antag att vi har uppgiften att köpa mjölk, bananer och en borrmaskin Standard sök algoritmer kommer att misslyckas: Eftersom heuristik / måltest inadekvat

Planering – Bild 3 Sökning Representation av operatorer: Genererar efterföljare m h a någon funktion t.ex. succersor(NewState, State). Representation av tillstånd: En komplett beskrivning av ett tillstånd är given. För det flesta problem är tillstånd en enkel datastruktur t.ex. i 8-spelet eller var vi befinner oss i Rumänien. Representation av mål: Det enda sökalgoritmen vet om sitt mål ges av måltestfunktionen samt den heuristiskafunktionen. Problem: Heuristiken kan endast välja mellan olika tillstånd och ge oss ett närmare målet; inte eliminera handlingar från att bli undersökta. Den är en ”Black box”. Representation av en lösning: En obruten sekvens av operationer från ett starttillstånd till ett måltillstånd. Problem: Det gör att vi måste bestämma oss för var vi skall gå, innan vi bestämt oss för hur vi skall lösa problemet - köpa, låna, stjäla..- kan vi inte bestämma oss för var vi skall gå.

Planering – Bild 4 Sökning jämfört med planering forts. Planeringssystem gör följande för att lösa dessa problem: 1) Genom att öppna upp representationen av tillstånd, mål och handlingar så kommer planeraren att kunna göra direkta kopplingar mellan tillstånd och handlingar. Tex om vi vet att Have(Milk) är inkluderat i vårt mål och att Buy(x) ger Have(x), så vet planeraren att det är bra att ha med Buy(Milk) i sin plan. 2) Tillåta planeraren att addera handlingar till planen när helst det behövs, snarare än att lägga till handlingar inkrementellt från ett start tillstånd. Det finns ingen koppling mellan ordningen som vi lägger till handlingar i planen och när de skall utföras. 3) De flesta problem har delproblem som är oberoende av varandra. Lös därför de oberoende problemen var och ett för sig.

Planering – Bild 5 Planering i situations logik Plan_Result(p, s) är situationen som uppstår när vi utför en sekvens av handlingar p ifrån initial situationen s Plan_Result([], s) = s Plan_Result([a|p], s) = Plan_Result(p, Result(a, s)) Initial tillstånd  s At(Home, S 0 )  ¬Have(Milk, S 0 )  ¬Have(Bananas, S 0 )  ¬Have(Drill, S 0 ) Handling som Efterföljare Tillstånds axiom  a, s Have(Milk, Result(a, s))  [(a = Buy(Milk)  At(Supermarket, s)  (Have(Milk, s)  a != Drop(Milk))] Fråga At(Home, Plan_Result(p, S 0 ) )  Have(Milk, Plan_Result(p, S 0 ) )  Have(Bananas, Plan_Result(p, S 0 ) )  Have(Drill, Plan_Result(p, S 0 ) ) Lösning p = [Go(SM), Buy(Milk), Buy(Bananas), Go(HWS), Buy(Drill), Go(Home)]

Planering – Bild 6 Ytterligare Problem... Om vi skulle använda oss av situations logik och teorembevisare så skulle det leda till nya problem. Ineffektivt tex pga av att om planen p når målet så gör även [Inget|p] och [A,A -1 |p] där Inget inte förändrar situationen (iaf inte så att vårt mål blir berört) och A -1 inversen av A, dvs s = Result(A -1, Result(A, s)), detta skulle kunna ge upphov till onödiga steg i vår plan. Genom att lägga restriktioner på språket så får vi mindre valmöjligheter och vi får en mindre domän att undersöka Vi använder oss av en icke-linjär planeringsalgoritm istället för en teorembevisare.

Planering – Bild 7 STRIPS operatorer Enkla att förstå för människor dock begränsad uttryckskraft Handling: Buy(x) Villkor: At(p), Sells(p, x) Effekt: Have(x) P.g.a. begränsade språket så ger det en effektiv algoritm Villkor: konjunktion av positiva termer Effekter: konjunktion av termer

Planering – Bild 8 STRIPS språket Tillstånd representeras som en konjuktion av funktionsfria grundade termer som kan vara negerade. Initialtillståndet vid banan, mjölk, borr problemet: At(Home)  ¬Have(Milk)  ¬Have(Bananas)  ¬Have(Drill) En tillståndbeskrivning behöver inte vara komplett. Frånvaron av en term i ett tillstånd gör att vi betraktar det termen som falsk. Mål får även innehålla variabler: At(x)  Sells(x, Milk)

Planering – Bild 9 Typer av planerare Progressions planerare : Går från ett starttillstånd till ett måltillstånd. En vanlig sök algoritm fungerar bra. T.ex. breddenförst Problem: Hög branching faktor, får bara en lösning av många Icke-linjär regressions planerare: Går baklänges från ett mål tillstånd till ett start tillstånd. Går bra eftersom vi inte behöver ha kompletta tillstånd. Det finns tillräckligt med information i STRIPS-operatorerna för att gå baklänges. Låg branching faktor (Regression) samt vi får en generell lösning, lösningen motsvaras av en eller flera olika totalt initierade lösningar (Icke linjär)

Planering – Bild 10 Tillstånds rymd jmf. Plan rymd Standard sökning: nod = konkret tillstånd i världen Planerings sökning: nod = partiell plan Definition: Öppet villkor är ett villkor som ännu ej blivit uppfyllt Operatorer på icke linjära partiella planer: addera en länk från en existerande handling till ett öppet villkor addera ett steg för att uppfylla ett öppet villkor synkronisera ett steg med ett annat (inga konflikter) Gå från icke kompletta / vaga planer (dvs partiella planer) till kompletta, korrekta planer.

Planering – Bild 11 Sockor och sko problemet Op(Handling: RightShoe, Villkor: RightSock, Effekt: RightShoeOn) Op(Handling: RightSock, Effekt: RightSockOn) Op(Handling: LeftShoe, Villkor: LeftSock, Effekt: LeftShoeOn) Op(Handling: LeftSock, Effekt: LeftSockOn)

Planering – Bild 12 Initial Plan Plan(Steps: { S1: Op(Handling: Start), S2: Op(Handling: Finish, Villkor: RightShoeOn, LeftShoeOn)} Orderings: {S1 < S2} Links:{}

Planering – Bild 13 Sockor och sko problemet forts…. Plan(Steps: { S1: Op(Handling: Start), S2: Op(H: RightShoe, V: RightSockOn, E: RightShoeOn), S3: Op(Handling: Finish, Villkor: RightShoeOn, LeftShoeOn)} Orderings: {S1 < S2 < S3} Links:{S2--RightShoeOn-->S3}

Planering – Bild 14 Sockor och skor forts... Plan(Steps: { S1: Op(Handling: Start), S2: Op(Handling: RightSock, E:RightSockOn), S3: Op(H: RightShoe, V: RightSockOn, E: RightShoeOn), S4: Op(Handling: Finish, Villkor: RightShoeOn, LeftShoeOn)} Orderings: {S1 < S2 < S3 < S4} Links:{S2--RightSockOn-->S3, S3--RightShoeOn-->S4}

Planering – Bild 15 Sockor och sko problemet forts... Plan(Steps: { S1: Op(Handling: Start), S2: Op(H: RightSock, Effekt: RightSockOn), S3: Op(H: LeftSock, Effekt: LeftSockOn), S4: Op(H: RightShoeOn, P: RightSockOn, E: RightShoeOn), S5: Op(H: LeftShoeOn, P: LeftSockOn, E: LeftShoeOn), S6: Op(Handling: Finish, Villkor: RightShoeOn, LeftShoeOn)} Orderings: {S1 < S2, S3 < S4, S5 < S6} Links:{S3--LeftSockOn-->S5, S5--LeftShoeOn-->S6, S2--RightSockOn-->S4, S4--RightShoeOn-->S6}

Planering – Bild 16 Icke linjära planer start Finish En plan är komplett oom varje villkor är uppfyllt Ett villkor är uppfyllt oom det uppfylls av en effekt i något tidigare steg och inget mellanliggande steg reverserar effekten LeftShoeOn, RightShoeOn

Planering – Bild 17 Icke-linjär planerare function POP(initial, goal, operators) returns plan plan <- Make-Minimal-Plan(initial, goal) loop do if Solution?(plan) then return plan S need, c <- Select-Subgoal(plan) Choose-Operator(plan, operators, S need, c) Resolve-Threats(plan) function Select-Subgoal(plan) returns S need, c pick a plan step S need from Steps(plan) with a precondition c that has not been achived return S need, c

Planering – Bild 18 Icke-linär planerare forts. Procedure Choose-Operator(plan, operator S need, c) choose a step S add from operators or Steps(plan) that has c as an effect if there is no such step then fail add the causal link S add --c--> S need to Links(plan) add the ordering constraint S add < S need to Orderings(plan) if S add is a newly added step from operators then add S add to Steps(plan) add Start < S add < Finish to orderings(plan) procedure Resolve-Threats(plan) for each S threat that threatens a link S i --c--> S j in Links(plan) do choose either Demotion: Add S threat < S i to Orderings(plan) Promotion: Add S j < S threat to Orderings(plan) if not consistent(plan) then fail

Planering – Bild 19 Bananer, mjölk och borr Op(Handling: Go(there), Villkor: At(here), Effekt: At(there), ¬At(here)) Op(Handling: Buy(x), Villkor: At(store), Sells(store, x), Effekt: Have(x) Plan(Steps: { S1: Op(H: Start, E: At(Home), Sells(HWS, Drill), Sells(SM, Milk), Sells(SM, Bananas)), S2: Op(Handling: Finish, Villkor: Have(Drill), Have(Milk), Have(Bananas), At(Home)} Orderings: {S1 < S2} Links:{}

Planering – Bild 20 Initial tillståndet: Bananer, mjölk och borr...

Planering – Bild 21 Bananer, mjölk och borr... Plan(Steps: { S1: Op(H: Start, E: At(Home), Sells(HWS, Drill), Sells(SM, Milk), Sells(SM, Bananas)), S2: Op(H: Buy(Drill), V: At(store), Sells(store, Drill), E: Have(Drill)), S3: Op(H: Buy(Milk), V: At(store), Sells(store, Milk), E: Have(Milk)), S4: Op(H: Buy(Bananas), V: At(store), Sells(store, Bananas), E: Have(Bananas)), S5: Op(Handling: Finish, Villkor: Have(Drill), Have(Milk), Have(Bananas), At(Home)} Orderings: {S1 < S2, S3, S4 < S5} Links:{S2--Have(Drill)-->S5, S3--Have(Milk)-->S5, S4--Have(Bananas)-->S5 }

Planering – Bild 22 Bananer, mjölk och borr... Tunna pilar= ordning Tjocka pilar= kausala länkar

Planering – Bild 23 Bananer, mjölk och borr... Plan(Steps: { S1: Op(H: Start, E: At(Home), Sells(HWS, Drill), Sells(SM, Milk), Sells(SM, Bananas)), S2: Op(H: Buy(Drill), V: At(HWS), Sells(HWS, Drill), E: Have(Drill)), S3: Op(H: Buy(Milk), V: At(SM), Sells(SM, Milk), E: Have(Milk)), S4: Op(H: Buy(Bananas), V: At(SM), Sells(SM, Bananas), E: Have(Bananas)), S5: Op(Handling: Finish, Villkor: Have(Drill), Have(Milk), Have(Bananas), At(Home)} Orderings: {S1 < S2, S3, S4 < S5} Links:{S1--Sells(HWS, Drill)-->S2, S1--Sells(SM, Milk)-->S3, S1--Sells(SM, Bananas)-- >S4, S2--Have(Drill)-->S5, S3--Have(Milk)-->S5, S4--Have(Bananas)-->S5 }

Planering – Bild 24 Bananer, mjölk och borr... Plan(Steps: { S1: Op(H: Start, E: At(Home), Sells(HWS, Drill), Sells(SM, Milk), Sells(SM, Bananas)), S2: Op(H: Go(HWS), V: At(x), E: At(HWS), ¬At(x)), S3: Op(H: Go(SM), V: At(x), E: At(SM), ¬At(x)), S4: Op(H: Buy(Drill), V: At(HWS), Sells(HWS, Drill), E: Have(Drill)), S5: Op(H: Buy(Milk), V: At(SM), Sells(SM, Milk), E: Have(Milk)), S6: Op(H: Buy(Bananas), V: At(SM), Sells(SM, Bananas), E: Have(Bananas)), S7: Op(Handling: Finish, Villkor: Have(Drill), Have(Milk), Have(Bananas), At(Home)} Orderings: {S1 < S2, S3 < S4, S5, S6 < S7} Links:{S2--Go(HWS)-->S4, S3--Go(SM)-->S5, S3--Go(SM)-->S6), S1--Sells(HWS, Drill)-->S4, S1-- Sells(SM, Milk)-->S5, S1--Sells(SM, Bananas)-->S6, S2--Have(Drill)-->S5, S3--Have(Milk)-->S5, S4--Have(Bananas)-->S5 }

Planering – Bild 25 Bananer, mjölk och borr... Här har vi nått en återvändsgränd.

Planering – Bild 26 Bananer, mjölk och borr... Plan(Steps: { S1: Op(H: Start, E: At(Home), Sells(HWS, Drill), Sells(SM, Milk), Sells(SM, Bananas)), S2: Op(H: Go(HWS), V: At(Home), E: At(HWS), ¬At(Home)), S3: Op(H: Go(SM), V: At(Home), E: At(SM), ¬At(Home)), S4: Op(H: Buy(Drill), V: At(HWS), Sells(HWS, Drill), E: Have(Drill)), S5: Op(H: Buy(Milk), V: At(SM), Sells(SM, Milk), E: Have(Milk)), S6: Op(H: Buy(Bananas), V: At(SM), Sells(SM, Bananas), E: Have(Bananas)), S7: Op(Handling: Finish, Villkor: Have(Drill), Have(Milk), Have(Bananas), At(Home)} Orderings: {S1 < S2, S3 < S4, S5, S6 < S7} Links:{S1--At(Home)-->S2, S1-->At(Home)-->S3, S2--Go(HWS)-->S4, S3--Go(SM)-->S5, S3-- Go(SM)-->S6 S1--Sells(HWS, Drill)-->S4, S1--Sells(SM, Milk)-->S5, S1--Sells(SM, Bananas)-->S6, S2--Have(Drill)-->S5, S3--Have(Milk)-->S5, S4--Have(Bananas)-->S5 }

Planering – Bild 27 Synkronisering av ordningen Ett mellanliggande steg som förstör (Clobbering) ett villkor i en kausal länk t.ex. Go(Home) förstör för At(HWS): Demotion: lägg före Go(HWS) Promotion: lägg efter Buy(Drill) I vårt fall blir: Orderings: från {S1 < S2, S3 < S4, S5, S6 < S7} till {S1< S2 < S4 < S3 < S5, S6 < S7}

Planering – Bild 28 Bananer, mjölk och borr... Det villkoret som hittills inte är uppfyllt är i at(home) Finish steget. Genom att lägga till ett Go(Home) steg så uppnår vi det, men introducerar ett till villkor At(x): 1. Om vi försöker att uppnå At(x) genom att länka x= Home från intitial tillståndet så finns det inget sätt vi kan göra det som inte förstör för Go(HWS) och Go(SM). 2. Om vi försöker att uppnå At(x) genom att länka x = HWS så finns det inget sätt att undvika att förstöra för Go(SM). 3. Om vi försöker att uppnå At(x) genom att länka x = SM så kan vi förstöra för Villkoret för Buy(Milk) och Buy(Bananas), men detta kan lösas genom att vi lägger en ordning så Go(Home) kommer efter dessa steg.

Planering – Bild 29 Bananer, mjölk och borr...

Planering – Bild 30 Plan(Steps: { S1: Op(H: Start, E: At(Home), Sells(HWS, Drill), Sells(SM, Milk), Sells(SM, Bananas)), S2: Op(H: Go(HWS), V: At(Home), E: At(HWS), ¬At(Home)), S3: Op(H: Buy(Drill), V: At(HWS), Sells(HWS, Drill), E: Have(Drill)), S4: Op(H: Go(SM), V: At(HWS), E: At(SM), ¬At(HWS)), S5: Op(H: Buy(Milk), V: At(SM), Sells(SM, Milk), E: Have(Milk)), S6: Op(H: Buy(Bananas), V: At(SM), Sells(SM, Bananas), E: Have(Bananas)), S7: Op(H: Go(Home), V: At(SM), E: At(Home), ¬At(SM)), S8: Op(Handling: Finish, Villkor: Have(Drill), Have(Milk), Have(Bananas), At(Home)} Orderings: {S1 < S2 < S3 < S4 < S5, S6 < S7 < S8} Links:{S1--At(Home)-->S2, S2--Go(HWS)-->S3, S2--At(HWS)-->S4, S4--Go(SM)-->S5, S4--Go(SM)-->S6, S4-- Go(SM)-->S7, S1--Sells(HWS, Drill)-->S3, S1--Sells(SM, Milk)-->S5, S1--Sells(SM, Bananas)-->S6, S3-- Have(Drill)-->S8, S5--Have(Milk)-->S8, S6--Have(Bananas)-->S8, S7--Go(home)-->S8 } Genom att vi går till HWS före SM (Demotion av HWS) så undviker vi konflikter. Bananer, mjölk och borr...

Planering – Bild 31 Bananer, mjölk och borr... Slutgiltiga lösningen

Planering – Bild 32 Icke-linjär planerare Är komplett : Finns det en lösning så hittar vi den. Kan utökas för att hantera komplexa problem. Möjliga utökningar: Hantering av hierarkiska planer Att kunna hantera resurser, t.ex. tid, pengar. (Icke-linjära) planerare används inom en rad olika områden; allt från planeringen av sammansättningen av Jaguar bilar och hela fabriker produktions planering hos Hitachi till att planera tillverkningen av rymdskepp samt planeringen av rymdfärder. T.ex. Så har Hubble teleskopet två planerare en långtids planerare och en korttidsplanerare. Sedan kan astronomer skicka in förfrågningar där de anger prioritet samt en massa parametrar om vart teleskopet skall riktas, under vilka tider planeterna står som astronomerna vill osv planerarna räknar sedan ut en plan med avseende på indata och tar fram de kommandon som behövs för att utföra de förfrågningar som den fått.