In che modo differiscono gli algoritmi all'avanguardia di path path per cambiare i grafici (D *, D * -Lite, LPA *, ecc.)?

Negli ultimi anni sono stati sviluppati molti algoritmi di pathfinding in grado di calcolare il percorso migliore in risposta ai cambiamenti del grafico molto più velocemente di A *: quali sono e in che modo differiscono? Sono per situazioni diverse o ne fanno alcune obsolete?

Questi sono quelli che sono stato in grado di trovare finora:

• D * (1994)
• Focused D * (1995)
• DynamicSWSF-FP (1996)
• LPA (1997)
• LPA * / Incrementale A * (2001)
• D * Lite (2002)
• SetA * (2002)
• HPA * (2004)
• Anytime D * (2005)
• PRA * (2005)
• Field D * (2007)
• Theta * (2007)
• HAA * (2008)
• GAA * (2008)
• LEARCH (2009)
• BDDD * (2009 - Non riesco ad accedere a questo documento: |)
• Incremental Phi * (2009)
• GFRA * (2010)
• MTD * -Lite (2010)
• Tree-AA * (2011)

Non sono sicuro di quale di questi si applichi al mio problema specifico: li leggerò tutti se necessario, ma mi farebbe risparmiare un sacco di tempo se qualcuno potesse scrivere un riassunto.

Il mio problema specifico: ho una griglia con un inizio, una fine e alcuni muri. Attualmente sto usando A * per trovare il percorso migliore dall'inizio alla fine.

L'utente sposta quindi un muro e devo ricalcolare di nuovo l'intero percorso. Il passaggio "move-wall / recalculate-path" avviene più volte di seguito, quindi sto cercando un algoritmo che sarà in grado di ricalcolare rapidamente il percorso migliore senza dover eseguire un'intera iterazione di A *.

Tuttavia, non sto necessariamente cercando un'alterazione di A *: potrebbe essere un algoritmo completamente separato.

Quindi ho sfogliato i fogli e questo è ciò che mi ha brillato. Se c'è qualcuno più esperto nell'argomento, per favore correggimi se sbaglio (o aggiungi la tua risposta, e invece la accetterò!) .

I collegamenti a ciascun documento sono disponibili nel post delle domande sopra.

• Ricalcoli semplici
  • D * (aka Dynamic A * ) (1994): nella corsa iniziale, D * funziona in modo molto simile ad A *, trovando il percorso migliore dall'inizio alla fine molto rapidamente. Tuttavia, quando l'unità si sposta dall'inizio alla fine, se il grafico cambia, D * è in grado di ricalcolare molto rapidamente il percorso migliore dalla posizione di quell'unità al traguardo, molto più velocemente della semplice esecuzione di A * dalla posizione di quell'unità. D *, tuttavia, ha la reputazione di essere estremamente complesso, ed è stato completamente obsoleto dal D * -Lite molto più semplice.
  • Focused D * (1995): un miglioramento di D * per renderlo più veloce / "più in tempo reale". Non riesco a trovare alcun confronto con D * -Lite, ma dato che questo è più vecchio e D * -Lite ne parla molto di più, presumo che D * -Lite sia in qualche modo migliore.
  • DynamicSWSF-FP (1996): memorizza la distanza da ogni nodo al nodo finale. Ha una grande configurazione iniziale per calcolare tutte le distanze. Dopo le modifiche al grafico, è in grado di aggiornare solo i nodi le cui distanze sono cambiate. Non correlato a A * e D *. Utile quando si desidera trovare la distanza da più nodi al traguardo dopo ogni modifica; in caso contrario, LPA * o D * -Lite sono in genere più utili.
  • LPA * / incrementale A * (2001): LPA * (Lifelong pianificazione A *) , noto anche come incrementale A * (e, a volte, confusamente, come "LPA", anche se non ha alcuna relazione con l'altro algoritmo chiamato LPA) è un combinazione di DynamicSWSF-FP e A *. Al primo avvio, è esattamente lo stesso di A *. Dopo lievi modifiche al grafico, tuttavia, le ricerche successive dalla stessa coppia iniziale / finale sono in grado di utilizzare le informazioni delle esecuzioni precedenti per ridurre drasticamente il numero di nodi che devono essere esaminati, rispetto ad A *. Questo è esattamente il mio problema, quindi sembra che LPA * sarà la mia soluzione migliore. LPA * differisce da D * in quanto trova sempre il percorso migliore dallo stesso inizio alla stessa fine; non viene utilizzato quando il punto iniziale si sta spostando(come le unità che si muovono lungo il percorso migliore iniziale) . Però...
  • D * -Lite (2002): questo algoritmo utilizza LPA * per imitare D *; cioè utilizza LPA * per trovare il nuovo percorso migliore per un'unità mentre si sposta lungo il percorso migliore iniziale e il grafico cambia. D * -Lite è considerato molto più semplice di D * e poiché funziona sempre almeno quanto D *, ha D * completamente obsoleto. Pertanto, non vi è mai alcun motivo per utilizzare D *; usa invece D * -Lite.
• Movimento a qualsiasi angolo
  • Field D * (2007): una variante di D * -Lite che non limita il movimento a una griglia; cioè, il percorso migliore può far muovere l'unità lungo qualsiasi angolo, non solo 45- (o 90-) gradi tra i punti della griglia. È stato utilizzato dalla NASA per individuare i rover su Marte.
  • Theta * (2007): una variante di A * che fornisce percorsi migliori (più brevi) rispetto al campo D *. Tuttavia, poiché si basa su A * anziché su D * -Lite, non dispone delle funzionalità di rapida ricodifica di Field D *. Vedi anche .
  • Incremental Phi * (2009): il migliore dei due mondi. Una versione di Theta * che è incrementale (ovvero consente una rapida ripianificazione)
• Spostamento di punti target
  • GAA * (2008): GAA * (Generalized Adaptive A *) è una variante di A * che gestisce i punti bersaglio in movimento. È una generalizzazione di un algoritmo ancora precedente chiamato "Moving Target Adaptive A *"
  • GRFA * (2010): GFRA * (Generalized Fringe-Retrieving A *) sembra (?) Essere una generalizzazione di GAA * a grafici arbitrari (cioè non limitati a 2D) usando tecniche di un altro algoritmo chiamato FRA *.
  • MTD * -Lite (2010): MTD * -Lite (Moving Target D * -Lite) è "un'estensione di D * Lite che utilizza il principio alla base del General Fringe-Retrieving A *" per effettuare ricerche a target mobile in rapida sostituzione.
  • Tree-AA * (2011): (???) Sembra essere un algoritmo per la ricerca di terreni sconosciuti, ma si basa su Adaptive A *, come tutti gli altri algoritmi in questa sezione, quindi l'ho inserito qui. Non sono sicuro di come si confronta con gli altri in questa sezione.
• Fast / sub-ottimale
  • Anytime D * (2005): questa è una variante "Anytime" di D * -Lite, realizzata combinando D * -Lite con un algoritmo chiamato Anytime Repairing A * . Un algoritmo "Anytime" è un algoritmo che può essere eseguito con qualsiasi vincolo temporale: troverà un percorso molto subottimale molto rapidamente per iniziare, quindi migliorerà su quel percorso più tempo gli verrà concesso.
  • HPA * (2004): HPA * (Hierarchical Path-Finding A *) serve per trovare un gran numero di unità su un grafico di grandi dimensioni, come nei videogiochi RTS (strategia in tempo reale) . Avranno tutti posizioni di partenza diverse e posizioni di fine potenzialmente diverse. HPA * suddivide il grafico in una gerarchia per trovare rapidamente percorsi "quasi ottimali" per tutte queste unità molto più rapidamente rispetto all'esecuzione di A * su ciascuna di esse singolarmente. Guarda anche
  • PRA * (2005): da quanto ho capito, PRA * (Partial Refinement A *) risolve lo stesso problema di HPA *, ma in modo diverso. Entrambi hanno "caratteristiche prestazionali simili".
  • HAA * (2008): HAA * (Hierarchical Annotated A *) è una generalizzazione di HPA * che consente un attraversamento limitato di alcune unità su alcuni terreni (es. Un piccolo percorso attraverso il quale alcune unità possono attraversare, ma non quelle più grandi; o un buco che solo le unità volanti possono attraversare; ecc.)
• Altro / Sconosciuto
  • LPA (1997): LPA (algoritmo di ricerca del percorso senza loop) sembra essere un algoritmo di routing solo marginalmente correlato ai problemi che gli altri algoritmi qui risolvono. Lo dico solo perché questo documento è confuso (e erroneamente) referenziato in diversi luoghi su Internet come il documento che introduce LPA *, che non lo è.
  • LEARCH (2009): LEARCH è una combinazione di algoritmi di apprendimento automatico, utilizzati per insegnare ai robot come trovare autonomamente percorsi quasi ottimali. Gli autori suggeriscono di combinare LEARCH con Field D * per risultati migliori.
  • BDDD * (2009): ??? Non riesco ad accedere al documento.
  • SetA * (2002): ??? Questa è, apparentemente, una variante di A * che cerca nel modello "diagramma binario di decisione" (BDD) del grafico? Sostengono che in alcuni casi esegue "diversi ordini di grandezza più velocemente di A *" . Tuttavia, se sto capendo correttamente, quei casi sono quando ogni nodo sul grafico ha molti spigoli?

Alla luce di tutto ciò, sembra che LPA * sia la soluzione migliore per il mio problema.

C'è un grande avvertimento quando si usa D *, D * -Lite o uno qualsiasi degli algoritmi incrementali in questa categoria (e vale la pena notare che questo avvertimento è raramente menzionato in letteratura). Questi tipi di algoritmi utilizzano una ricerca inversa. Cioè, calcolano i costi verso l'esterno dal nodo obiettivo, come un'ondulazione che si diffonde verso l'esterno. Quando i costi dei bordi cambiano (ad es. Aggiungi o rimuovi un muro nel tuo esempio), tutti hanno varie strategie efficienti per aggiornare solo il sottoinsieme dei nodi esplorati (aka "visitati") che sono interessati dalle modifiche.

Il grande avvertimento è che la posizione di questi cambiamenti rispetto alla posizione dell'obiettivo fa un'enorme differenza per l'efficienza degli algoritmi. Ho mostrato in vari articoli e la mia tesi che è del tutto possibile che la peggiore delle prestazioni di uno di questi algoritmi incrementali sia peggiore del buttare via tutte le informazioni e ricominciare da capo con qualcosa di non incrementale come il semplice vecchio A *.

Quando le informazioni sui costi modificate si avvicinano al perimetro del fronte di ricerca in espansione (la regione "visitata"), pochi percorsi devono cambiare e gli aggiornamenti incrementali sono rapidi. Un esempio pertinente è un robot mobile con sensori collegati al suo corpo. I sensori vedono solo il mondo vicino al robot, e quindi i cambiamenti sono in questa regione. Questa regione è il punto di partenza della ricerca, non l'obiettivo, quindi tutto funziona bene e gli algoritmi sono molto efficienti nell'aggiornamento del percorso ottimale per correggere le modifiche.

Quando le informazioni sui costi modificate sono vicine all'obiettivo della ricerca (o il tuo scenario vede le posizioni di cambio obiettivo, non solo l'inizio), questi algoritmi subiscono un rallentamento catastrofico. In questo scenario, è necessario aggiornare quasi tutte le informazioni salvate, poiché l'area modificata è così vicina all'obiettivo che quasi tutti i percorsi precalcolati passano attraverso le modifiche e devono essere rivalutati. A causa del sovraccarico di memorizzare ulteriori informazioni e calcoli per eseguire aggiornamenti incrementali, una nuova valutazione su questa scala è più lenta di un nuovo inizio.

Poiché il tuo scenario di esempio sembra consentire all'utente di spostare qualsiasi muro desideri, questo problema si presenterà se usi D *, D * -Lite, LPA *, ecc. Le prestazioni temporali del tuo algoritmo saranno variabili, a seconda dell'utente ingresso. In generale, "questa è una brutta cosa" ...

Ad esempio, il gruppo di Alonzo Kelly alla CMU aveva un fantastico programma chiamato PerceptOR che cercava di combinare robot di terra con robot aerei, tutti condividendo informazioni sulla percezione in tempo reale. Quando hanno tentato di utilizzare un elicottero per fornire aggiornamenti dei costi in tempo reale al sistema di pianificazione di un veicolo terrestre, hanno riscontrato questo problema perché l'elicottero poteva volare davanti al veicolo terrestre, vedendo cambiamenti di costo più vicini all'obiettivo e quindi rallentando giù i loro algoritmi. Hanno discusso di questa interessante osservazione? No. Alla fine, il migliore che riuscirono a fare fu far volare l'elicottero direttamente sopra il veicolo terrestre, rendendolo l'albero dei sensori più costoso al mondo. Certo, sono meschino. Ma è un grosso problema di cui nessuno vuole parlare - e dovrebbero,

Ci sono solo una manciata di articoli che ne discutono, principalmente da parte mia. Di articoli scritti dagli autori o dagli studenti degli autori degli articoli originali elencati in questa domanda, posso pensare solo a uno che menziona effettivamente questo problema. Likhachev e Ferguson suggeriscono di provare a stimare la scala degli aggiornamenti richiesti e di svuotare le informazioni memorizzate se si ritiene che l'aggiornamento incrementale richieda più tempo di un nuovo inizio. Questa è una soluzione abbastanza sensata, ma ce ne sono anche altre. Il mio dottorato di ricerca generalizza un approccio simile in una vasta gamma di problemi computazionali e sta andando oltre lo scopo di questa domanda, tuttavia potresti trovare utili i riferimenti poiché ha una panoramica completa della maggior parte di questi algoritmi e altro. Vedi http://db.acfr.usyd.edu.au/download.php/Allen2011_Thesis.pdf?id=2364 per dettagli.

L'idea principale è quella di utilizzare un algoritmo incrementale, in grado di sfruttare i calcoli precedenti quando viene bloccato il percorso calcolato iniziale. Questo è spesso studiato nel contesto di robot, navigazione e pianificazione.

Koenig e Likkachev, ripianificazione rapida per la navigazione in terreni sconosciuti, Transazioni IEEE sulla robotica, vol. 21, n. 3, giugno 2005 introduce D * Lite. Sembra sicuro dire che D * è obsoleto, nel senso che D * Lite è sempre veloce come D *. Inoltre, D * è complesso, difficile da capire, analizzare ed estendere. La Figura 9 fornisce lo pseudocodice per D * Lite e la Tabella 1 mostra risultati sperimentali con D * Lite rispetto a BFS, Indietro A *, Avanti A *, DynamicSWSF-P e D *.

Non conosco gli algoritmi più recenti che elenchi (sempre D *, campo D *, LEARCH). Di recente ho visto un robot che utilizzava D * Lite per la pianificazione in un ambiente con camminatori casuali. In questo senso, non credo che D * Lite sia obsoleto. Per il tuo problema pratico, suppongo che non ci sia nulla di male nel provare il solito modo ingegneristico: adottare un approccio e, se non si adatta alle tue esigenze, provare qualcos'altro (più complesso).

Vorrei aggiungere qualcosa sull'esplorazione rapida di alberi randomizzati o RRT. L'idea di base ha buone discussioni su Internet, ma probabilmente è sicuro iniziare con i collegamenti dalla pagina di Wikipedia e con gli articoli originali di Kuffner e LaValle sull'argomento.

La caratteristica più importante degli RRT è che possono gestire spazi di valore estremamente elevato di dimensioni estremamente elevate senza soffocare. Sono in grado di gestire le dinamiche, non sono ottimali ma sono probabilisticamente completi (garantiti per avere successo se il tempo di calcolo va all'infinito) e sono in grado di gestire obiettivi in ​​movimento. Ci sono alcune estensioni che consentono loro di lavorare in spazi non statici, il migliore dei quali sembra essere il lavoro RRT multipartito che ho collegato di seguito.

• http://en.wikipedia.org/wiki/Rapidly_exploring_random_tree
• http://swing.adm.ri.cmu.edu/pub_files/pub4/zucker_matthew_2007_1/zucker_matthew_2007_1.pdf

Le strutture dati chiamate oracoli della distanza gestiscono tali problemi. Tuttavia, la maggior parte dei risultati della ricerca sono solo per grafici statici .

Se i grafici sono griglie (e quindi planari), esistono alcune strutture di dati dinamici (non è chiaro se le costanti siano abbastanza piccole per l'applicazione in questione):

Percorsi esatti più brevi:

Jittat Fakcharoenphol, Satish Rao: grafici planari, bordi di peso negativo, percorsi più brevi e tempo quasi lineare. J. Comput. Syst. Sci. 72 (5): 868-889 (2006)

Percorsi più brevi approssimativi:

Philip N. Klein, Sairam Subramanian: uno schema di approssimazione completamente dinamico per i percorsi più brevi nei grafici planari. Algorithmica 22 (3): 235-249 (1998)

Ittai Abraham, Shiri Chechik, Cyril Gavoille: oracoli di distanza approssimativi completamente dinamici per grafici planari tramite etichette di distanza proibite. STOC 2012: 1199-1218

A scuola mi dilettavo con l' ottimizzazione delle colonie di formiche . In alcuni testi è stato pubblicizzato come una soluzione per la modifica continua di grafici, reti di routing, ecc. Non è una soluzione ingegnerizzata, ma un adattamento da come le formiche navigano intorno agli ostacoli diffondendo feromoni per segnare percorsi buoni e cattivi. Non ho idea se funzioni per il tuo problema, ma penso che sia un punto di vista interessante.