0

Summary: Is the D Lite algorithm capable of handling a lot of new obstacles at once?*

Hello ^^

I've been working on implementing the D*-Lite pathfinding algorithm, as described in the 2002 article by Koenig and Likhachev, in a C++ program but am having some trouble when trying to implement many new obstacles at once.

In an example map I found online where 's' is the start 'g' is the goal, 0 is an open cell, and 1, is an obstacle, and 2 is an obstacle discovered after the first route is computed:

0 0 0 0 0
0 0 2 0 s
0 1 1 0 0
g 0 1 0 0

My program can easily navigate this. However, I experience issues when trying a test map I made myself, like this:

s 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
0 0 2 2 2 2 2 0 0
0 0 2 0 0 0 0 0 0
0 0 2 0 0 0 0 0 0
0 0 2 0 0 0 0 0 0
0 0 2 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 g

Where the 'robot' moves from the start and suddenly discovers that it's path is quite blocked. And logically it should then move all the way to the right or down to get clear.

Now I was testing with an incremental approach, and it's at this point things don't work. If I remove the bottom-most 2 or right-most 2 it works in this version:

s 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
0 0 2 2 2 2 0 0 0
0 0 2 0 0 0 0 0 0
0 0 2 0 0 0 0 0 0
0 0 2 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 g

Now, I can fully admit that my theory around the D* Lite is not 100% solid, and I'm studying to understand it better, though the lack of examples of D* Lite on larger maps with more obstacles is a pain.

The main question I'm considering is whether the D Lite is capable of handling a lot of new obstacles at once?*

I had an earlier version of my program that only looked at the cells directly neighboring the current cell, and it could handle this map. However, since I'm working towards implementing this in ROS on the turtlebot I figured my program needed to be able to handle obstacles composed of many cells at once.

Thank you

PS: I'm using the non-optimized version of D* Lite, and I've been wondering whether my UpdateVertex is working correctly? In the paper the code looks like this:

procedure UpdateVertex(u)
{07’} if (u ≠ sgoal) rhs(u) = min s'∈Succ(u)(c(u, s') + g(s'));
{08’} if (u ∈ U) U.Remove(u);
{09’} if (g(u) ≠ rhs(u)) U.Insert(u, CalculateKey(u));

But during testing I've experinced cells that run through all 3 if-sentences during 1 call of the function. Is that correct, or are there supposed to be breaks in the code?

OverDemon
  • 103
  • 1
  • 3
  • 8
  • Yes, it can handle multiple new walls at once. What's the actual question here? – BlueRaja - Danny Pflughoeft Nov 27 '22 at 20:33
  • That was the question. I have had success with tests where a single or a few obstacles appear, but as stated above I discovered an issue with a map where I suddenly made a lot of cells obstacles in that arrow shape, all at once. What happens is that when my program has completed ComputeShortestPath it just steps back and forth between the upper left-most cells and the one diagonal below it. Been trying to fix it, but while doing that I just started wondering whether D* Lite could handle a big, sudden change. Haven't found examples showing D* Lite with multiple obstacles, so was uncertain – OverDemon Nov 28 '22 at 01:07

0 Answers0