320 likes | 515 Views
Planering. Sökning jämfört med planering STRIPS operatorer Icke-linjär planering. 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. Sökning.
E N D
Planering • Sökning jämfört med planering • STRIPS operatorer • Icke-linjär planering
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
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å.
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 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, S0) ¬Have(Milk, S0) ¬Have(Bananas, S0) ¬Have(Drill, S0) • 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, S0) ) Have(Milk, Plan_Result(p, S0) ) Have(Bananas, Plan_Result(p, S0) ) Have(Drill, Plan_Result(p, S0) ) • Lösning • p = [Go(SM), Buy(Milk), Buy(Bananas), Go(HWS), Buy(Drill), Go(Home)]
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.
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
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)
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)
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.
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)
Initial Plan • Plan(Steps: { S1: Op(Handling: Start), • S2: Op(Handling: Finish, • Villkor: RightShoeOn, LeftShoeOn)} • Orderings: {S1 < S2} • Links:{}
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}
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}
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}
Icke linjära planer • 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 start LeftShoeOn, RightShoeOn Finish
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 • Sneed, c <- Select-Subgoal(plan) • Choose-Operator(plan, operators, Sneed, c) • Resolve-Threats(plan) • function Select-Subgoal(plan) returns Sneed, c • pick a plan step Sneed from Steps(plan) • with a precondition c that has not been achived • return Sneed, c
Icke-linär planerare forts. • Procedure Choose-Operator(plan, operator Sneed, c) • choose a step Sadd from operators or Steps(plan) that has c as an effect • if there is no such step then fail • add the causal link Sadd --c--> Sneed to Links(plan) • add the ordering constraint Sadd < Sneed to Orderings(plan) • if Sadd is a newly added step from operators then • add Sadd to Steps(plan) • add Start < Sadd < Finish to orderings(plan) • procedure Resolve-Threats(plan) • for each Sthreat that threatens a link Si --c--> Sj in Links(plan) do • choose either • Demotion: Add Sthreat < Si to Orderings(plan) • Promotion: Add Sj < Sthreat to Orderings(plan) • if not consistent(plan) then fail
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:{}
Bananer, mjölk och borr... • Initial tillståndet:
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 }
Bananer, mjölk och borr... • Tunna pilar= • ordning • Tjocka pilar= • kausala länkar
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 }
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 }
Bananer, mjölk och borr... • Här har vi nått en återvändsgränd.
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 }
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}
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.
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: 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... • Slutgiltiga lösningen
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.