Há uma grande ressalva ao usar D *, D * -Lite ou qualquer um dos algoritmos incrementais nesta categoria (e vale a pena notar que essa ressalva é raramente mencionada na literatura). Esses tipos de algoritmos usam uma pesquisa invertida. Ou seja, eles calculam os custos para fora do nó da meta, como uma ondulação se espalhando para fora. Quando os custos das arestas mudam (por exemplo, você adiciona ou remove uma parede no seu exemplo), todos eles têm várias estratégias eficientes para atualizar apenas o subconjunto dos nós explorados (também conhecidos como 'visitados') que são afetados pelas alterações.
A grande ressalva é que a localização dessas mudanças em relação à localização da meta faz uma enorme diferença para a eficiência dos algoritmos. Eu mostrei em vários artigos e minha tese que é perfeitamente possível que o pior desempenho de qualquer um desses algoritmos incrementais seja pior do que jogar fora todas as informações e começar de novo com algo não incremental, como o simples A * antigo.
Quando as informações de custo alteradas estão próximas do perímetro da frente de pesquisa em expansão (a região 'visitada'), poucos caminhos precisam ser alterados e as atualizações incrementais são rápidas. Um exemplo pertinente é um robô móvel com sensores conectados ao seu corpo. Os sensores apenas veem o mundo perto do robô e, portanto, as mudanças ocorrem nesta região. Essa região é o ponto de partida da pesquisa, não o objetivo, portanto tudo funciona bem e os algoritmos são muito eficientes na atualização do caminho ideal para corrigir as alterações.
Quando as informações de custo alteradas estão próximas do objetivo da pesquisa (ou o seu cenário vê os locais de alteração do objetivo, não apenas o início), esses algoritmos sofrem uma desaceleração catastrófica. Nesse cenário, quase todas as informações salvas precisam ser atualizadas, porque a região alterada está tão próxima da meta que quase todos os caminhos pré-calculados passam pelas alterações e devem ser reavaliados. Devido à sobrecarga de armazenar informações e cálculos extras para fazer atualizações incrementais, uma reavaliação nessa escala é mais lenta que um novo começo.
Como o cenário de exemplo parece permitir ao usuário mover qualquer barreira que desejar, você sofrerá esse problema se usar D *, D * -Lite, LPA * etc. O desempenho do tempo do seu algoritmo será variável, dependendo do usuário entrada. Em geral, "isso é uma coisa ruim" ...
Como exemplo, o grupo de Alonzo Kelly na CMU tinha um programa fantástico chamado PerceptOR, que tentava combinar robôs terrestres com robôs aéreos, todos compartilhando informações de percepção em tempo real. Quando tentaram usar um helicóptero para fornecer atualizações de custos em tempo real ao sistema de planejamento de um veículo terrestre, eles enfrentaram esse problema porque o helicóptero podia voar à frente do veículo terrestre, vendo mudanças de custo mais próximas da meta e, assim, diminuindo a velocidade abaixo seus algoritmos. Eles discutiram essa observação interessante? Não. No final, o melhor que conseguiram foi fazer o helicóptero voar diretamente acima do veículo terrestre - tornando-o o mastro de sensor mais caro do mundo. Claro, estou sendo mesquinho. Mas é um grande problema que ninguém quer falar - e deveria,
Existem apenas alguns documentos que discutem isso, principalmente por mim. Dos artigos escritos pelos autores ou estudantes dos autores dos artigos originais listados nesta pergunta, posso pensar em apenas um que realmente mencione esse problema. Likhachev e Ferguson sugerem tentar estimar a escala de atualizações necessárias e liberar as informações armazenadas se estima-se que a atualização incremental leve mais tempo do que um novo começo. Esta é uma solução bastante sensata, mas também existem outras. Meu doutorado generaliza uma abordagem semelhante em uma ampla gama de problemas computacionais e está indo além do escopo desta pergunta. No entanto, você pode achar úteis as referências, pois ele tem uma visão geral completa da maioria desses algoritmos e muito mais. Veja http://db.acfr.usyd.edu.au/download.php/Allen2011_Thesis.pdf?id=2364 para detalhes.
