D *, D * -Lite veya bu kategorideki artımlı algoritmalardan herhangi birini kullanırken büyük bir uyarı var (ve bu uyarının nadiren literatürde belirtilmiş olduğuna dikkat etmek gerekir). Bu tür algoritmalar ters arama kullanır. Yani, hedef düğümden maliyetleri, dışa doğru yayılan bir dalgalanma gibi hesaplarlar. Kenarların maliyetleri değiştiğinde (örneğin, örneğinize bir duvar ekler veya kaldırırsınız), yalnızca değişikliklerden etkilenen keşfedilen (aka 'ziyaret edilen') düğümlerin alt kümesini güncellemek için çeşitli etkili stratejiler vardır.
En büyük uyarı, hedeflere göre bu değişikliklerin yerinin, algoritmaların etkinliği için muazzam bir fark yaratmasıdır. Çeşitli makalelerde ve tezimde, bu artan algoritmaların herhangi birinin en kötü durum performansının tüm bilgileri bir kenara atmaktan ve düz eski A * gibi artımlı olmayan bir şeyle baştan başlamaktan daha kötü olmasının tamamen mümkün olduğunu gösterdim .
Değişen maliyet bilgisi, genişleyen arama cephesinin çevresine ('ziyaret edilen bölge) yakın olduğunda, birkaç yolun değişmesi gerekir ve artan güncellemeler hızlı olur. Uygun bir örnek, vücuduna takılı sensörleri olan mobil bir robottur. Sensörler dünyayı sadece robotun yanında görüyor ve bu yüzden de değişiklikler bu bölgede. Bu bölge hedefin değil aramanın başlangıç noktasıdır ve bu nedenle her şey yolunda gider ve algoritmalar değişikliklerin düzeltilmesi için en uygun yolu güncellemede çok etkilidir.
Değişen maliyet bilgileri aramanın amacına yakın olduğunda (veya senaryonuz yalnızca başlangıç değil hedef değiştirme konumlarını görürse), bu algoritmalar feci bir yavaşlamaya maruz kalır. Bu senaryoda, kaydedilen bilgilerin neredeyse tamamı güncellenmelidir, çünkü değişen bölge hedefe o kadar yakındır ki, önceden hesaplanmış tüm yolların değişikliklerden geçmesi ve yeniden değerlendirilmesi gerekir. Ek bilgi saklama ek yükü ve artımlı güncellemeler yapmak için yapılan hesaplamalar nedeniyle, bu ölçekte yapılan yeniden değerlendirme yeni bir başlangıçtan daha yavaştır.
Örnek senaryonuz, kullanıcının istediği duvarı taşımasına izin verdiği için, D *, D * -Lite, LPA * vb. Kullanıyorsanız bu sorunla karşılaşacaksınız. Algoritmanızın zaman performansı kullanıcıya bağlı olarak değişecektir. giriş. Genel olarak, "bu kötü bir şey" ...
Örnek olarak, Alonzo Kelly'nin CMU'daki grubu, algı bilgilerini gerçek zamanlı olarak paylaşan, yer robotlarını havadan robotlarla birleştirmeye çalışan PerceptOR adlı harika bir programa sahipti. Bir kara taşıtının planlama sistemine gerçek zamanlı maliyet güncellemeleri sağlamak için bir helikopter kullanmaya çalıştıklarında, bu soruna çarptılar, çünkü helikopter kara taşıtının önünde uçabiliyordu, maliyetin hedefe daha yakın olduğunu görebiliyordu ve böylece yavaşlıyordu algoritmalarıyla. Bu ilginç gözlemi tartıştılar mı? Hayır. Sonunda, yönettikleri en iyisi, helikopterin yer aracının doğrudan tepesine uçmasını sağlamaktı - onu dünyanın en pahalı sensör çubuğu yaptı. Tabii, küçük davranıyorum. Ama kimsenin konuşmak istemediği büyük bir problem - ve yapmalılar,
Bunu tartışan sadece bir avuç kağıt var, çoğunlukla benim tarafımdan. Bu soruda listelenen orijinal makalelerin yazarları veya öğrencileri tarafından yazılan makalelerden, bu problemden bahseden sadece bir tanesini düşünebilirim. Likhachev ve Ferguson, gerekli güncellemelerin ölçeğini tahmin etmeye çalışmayı ve eğer artımlı güncellemenin yeni bir başlangıçtan daha uzun süreceği tahmin edildiğinde saklanan bilgilerin temizlenmesini önermektedir. Bu oldukça mantıklı bir çözüm, ancak başkaları da var. Doktora, çok çeşitli hesaplama problemleri arasında benzer bir yaklaşımı genelleştirir ve bu sorunun kapsamı dışındadır, ancak bu algoritmaların çoğuna ve daha fazlasına kapsamlı bir genel bakışı olduğu için referansları faydalı bulabilirsiniz. Bkz http://db.acfr.usyd.edu.au/download.php/Allen2011_Thesis.pdf?id=2364 detaylar için.
