4

我已经实现了 D*-Lite 算法（这里有一个描述，它是一种在边缘成本随时间变化时进行寻路的算法），但是我在进行边缘成本更新时遇到了问题。它主要工作，但有时它会卡在一个循环中，在两个顶点之间来回移动。我正在尝试创建一个展示这种行为的测试用例，目前在大型应用程序中使用时会发生这种情况，这使得调试变得困难。

我会尽快建立一个测试用例，但也许有人可以立即发现我从伪到 C++ 所做的错误。（下面包含一个测试用例）这篇文章展示了一个优化版本，图 4，这是我已经实现的版本。伪代码粘贴在下面。

我的实现源代码可在此处获得。

如果有帮助，我将在我的代码中使用这些类型：

struct VertexProperties { double x, y; };
typedef boost::adjacency_list<boost::vecS, 
                              boost::vecS, 
                              boost::undirectedS,
                              VertexProperties,
                              boost::property<boost::edge_weight_t, double> > Graph;
typedef boost::graph_traits<Graph>::vertex_descriptor Vertex;
typedef DStarEuclidianHeuristic<Graph, Vertex> Heuristic; 
typedef DStarPathfinder<Graph, Heuristic> DStarPathfinder;

如果需要有关使用的更多信息，请询问，粘贴太多了。

D*-Lite 的伪代码：

procedure CalculateKey(s)
{01”} return [min(g(s), rhs(s)) + h(s_start, s) + km;min(g(s), rhs(s))];

procedure Initialize()
{02”} U = ∅;
{03”} km = 0;
{04”} for all s ∈ S rhs(s) = g(s) = ∞;
{05”} rhs(s_goal) = 0;
{06”} U.Insert(s_goal, [h(s_start, s_goal); 0]);

procedure UpdateVertex(u)
{07”} if (g(u) != rhs(u) AND u ∈ U) U.Update(u,CalculateKey(u));
{08”} else if (g(u) != rhs(u) AND u /∈ U) U.Insert(u,CalculateKey(u));
{09”} else if (g(u) = rhs(u) AND u ∈ U) U.Remove(u);

procedure ComputeShortestPath()
{10”} while (U.TopKey() < CalculateKey(s_start) OR rhs(s_start) > g(s_start))
{11”} u = U.Top();
{12”} k_old = U.TopKey();
{13”} k_new = CalculateKey(u));
{14”} if(k_old < k_new)
{15”}   U.Update(u, k_new);
{16”} else if (g(u) > rhs(u))
{17”}   g(u) = rhs(u);
{18”}   U.Remove(u);
{19”}   for all s ∈ Pred(u)
{20”}   if (s != s_goal) rhs(s) = min(rhs(s), c(s, u) + g(u));
{21”}   UpdateVertex(s);
{22”} else
{23”}   g_old = g(u);
{24”}   g(u) = ∞;
{25”}   for all s ∈ Pred(u) ∪ {u}
{26”}   if (rhs(s) = c(s, u) + g_old)
{27”}     if (s != s_goal) rhs(s) = min s'∈Succ(s)(c(s, s') + g(s'));
{28”}   UpdateVertex(s);

procedure Main()
{29”} s_last = s_start;
{30”} Initialize();
{31”} ComputeShortestPath();
{32”} while (s_start != s_goal)
{33”} /* if (g(s_start) = ∞) then there is no known path */
{34”}   s_start = argmin s'∈Succ(s_start)(c(s_start, s') + g(s'));
{35”}   Move to s_start;
{36”}   Scan graph for changed edge costs;
{37”}   if any edge costs changed
{38”}     km = km + h(s_last, s_start);
{39”}     s_last = s_start;
{40”}     for all directed edges (u, v) with changed edge costs
{41”}       c_old = c(u, v);
{42”}       Update the edge cost c(u, v);
{43”}       if (c_old > c(u, v))
{44”}         if (u != s_goal) rhs(u) = min(rhs(u), c(u, v) + g(v));
{45”}       else if (rhs(u) = c_old + g(v))
{46”}         if (u != s_goal) rhs(u) = min s'∈Succ(u)(c(u, s') + g(s'));
{47”}       UpdateVertex(u);
{48”}     ComputeShortestPath()

编辑：

我成功地创建了一个显示错误行为的测试用例。将它与 pastebin 中的代码一起运行，它会在最后一次get_path调用中挂断，在节点 1 和 2 之间来回切换。在我看来，这是因为节点 3 从未被触及，所以那样走会有一个无限的代价。

#include <cmath>
#include <boost/graph/adjacency_list.hpp>
#include "dstar_search.h"

template <typename Graph, typename Vertex>
struct DStarEuclidianHeuristic {
    DStarEuclidianHeuristic(const Graph& G_) : G(G_) {}

    double operator()(const Vertex& u, const Vertex& v) {
        double dx = G[u].x - G[v].x;
        double dy = G[u].y - G[v].y;
        double len = sqrt(dx*dx+dy*dy);
        return len;
    }

    const Graph& G;
};

struct VertexProp {
    double x, y;
};

int main() {
    typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS,
        VertexProp, boost::property<boost::edge_weight_t, double> > Graph;
    typedef boost::graph_traits<Graph>::vertex_descriptor Vertex;
    typedef boost::graph_traits<Graph>::edge_descriptor Edge;
    typedef DStarEuclidianHeuristic<Graph, Vertex> Heur;

    typedef boost::property_map<Graph, boost::edge_weight_t>::type WMap;

    Graph g(7);
    WMap weights = boost::get(boost::edge_weight, g);
    Edge e;
    // Create a graph
    e = boost::add_edge(0, 1, g).first;
    weights[e] = sqrt(2.);
    e = boost::add_edge(1, 2, g).first;
    weights[e] = 1;
    e = boost::add_edge(2, 3, g).first;
    weights[e] = 1;
    e = boost::add_edge(1, 4, g).first;
    weights[e] = 1;
    e = boost::add_edge(3, 4, g).first;
    weights[e] = 1;
    e = boost::add_edge(3, 5, g).first;
    weights[e] = sqrt(2.);
    e = boost::add_edge(2, 6, g).first;
    weights[e] = sqrt(2.);
    e = boost::add_edge(5, 6, g).first;
    weights[e] = 1;
    e = boost::add_edge(6, 7, g).first;
    weights[e] = 1;
    g[0].x = 1; g[0].y = 0;
    g[1].x = 0; g[1].y = 1;
    g[2].x = 0; g[2].y = 2;
    g[3].x = 1; g[3].y = 2;
    g[4].x = 1; g[4].y = 1;
    g[5].x = 2; g[5].y = 3;
    g[6].x = 1; g[6].y = 3;
    g[7].x = 1; g[7].y = 4;

    DStarPathfinder<Graph, Heur> dstar(g, Heur(g), 0, 7);
    std::list<std::pair<Edge, double>> changes;

    auto a =  dstar.get_path(); // Find the initial path, works well
    std::copy(a.begin(), a.end(), std::ostream_iterator<Vertex>(std::cout, ","));
    // Now change the cost of going from 2->6, and try to find a new path
    changes.push_back(std::make_pair(boost::edge(2, 6, g).first, 4.));
    dstar.update(changes);
    a = dstar.get_path(); // Stuck in loop
    std::copy(a.begin(), a.end(), std::ostream_iterator<Vertex>(std::cout, ","));

    return 0;
}

编辑2：更多进展。如果我用just （不为空）替换while循环中的中断条件，则找到路径！虽然它很慢，因为它总是检查图中的每个节点，这不应该是必需的。此外，由于我使用无向图，我添加了一些代码来更新和.ComputeShortestPathU != ØU{40"}uv

4

5 回答 5

7

您的代码至少有两个问题（不包括typenames 我std::vector<TemplateParameter>::iterator为了编译它而必须在构造之前添加）。

  1. 您正在使用不允许的启发式算法，因为对角线的成本为 1 但长度为 √2。这可以防止第二次调用 toComputeShortestPath做任何事情。

  2. 您正在使用的堆的更新方法（按照约定是 Boost 私有的，因此显然没有记录）仅支持密钥减少。D* Lite 也需要增加密钥。

于 2011-09-05T18:59:55.107 回答
3

不幸的是，在这里发布伪代码并不是很有用，因为伪代码可能是正确的，但实际的实现可能有问题。

通常，在路径查找算法中，如果您在节点之间循环，那么该算法很有可能不会从一组潜在的路径节点中删除访问过的节点。这通常是通过在遍历节点时在节点上设置一个标志来完成的，并在您返回搜索树时重置该标志。

于 2011-08-30T15:09:26.560 回答
0

问题出在 UpdateVertex 函数中。

伪代码是假设比较是在整数上编写的（它们在论文中）。在您的实现中，您正在对浮点值进行比较。如果您要处理非整数成本，则需要添加容差。

您可以通过使用 -Wfloat-equal（甚至更好的 -Werror=float-equal）编译在 GCC 上进行测试

于 2011-09-10T10:54:25.630 回答
0

我也有你同样的问题。我想我找到了原因，也许在这个时候你找到了解决问题的方法，可以给我一些提示。

我认为问题来自U列表。

因为可能每个顶点的某些键的值高于s_start. 所以ComputeKey(s)<ComputeKeu(s_start)不满足（ComputePath 中的第一个条件），第二个条件rhs(s_start)>g(s_start)不满足，因为当您沿着路径移动时，您会通过正在保持一致的单元格。

然后当这两个条件不满足 while 停止时，程序停止扩展新的单元格。

当您计算路径时，沿路径连续使用最小化g(s)+c(u,s)您的路径，最终在一个单元格上仍然具有无限g成本（因为它在 while 循环中没有扩展）。

这甚至是如果你改变条件，U!=0在算法工作时使用，这会迫使程序扩展U列表中的所有顶点。（但你肯定失去了动态算法的优势）。

现在我希望我已经帮助了你，如果你不再需要这个帮助，也许你可以帮助我。

于 2012-04-26T00:45:53.777 回答
0

在实现D* Lite（普通版）和优化版时，我自己也遇到了这个问题。我有点不确定为什么它首先会发生，但我似乎被一些障碍物（十字形或高垂直障碍物）的排列触发，其中算法突然无法探索更多选项并最终在两者之间来回跳跃无限循环中的两个选项。我已经在这里早些时候创建了一篇关于这个的帖子，以及我是如何绕过无限循环问题的，但是代价是算法可能变得有点慢。

于 2020-04-29T12:55:30.810 回答