Path Database Guidance for Motion Planning

TL;DR

This paper addresses how to leverage prior experience in motion planning by storing solutions as a path database and using it to guide online search. It introduces Path Database Guidance (PDG), a method that continuously filters the database during search and uses path length as a heuristic to guide tree growth, dynamically interleaving database guidance with a baseline planner. PDG formalizes cost-to-go estimates with $V_p(x)$ and $V_D^\delta(x)$, updates guidance when edges become invalid, and relies on caching and batched computations to stay efficient, often using a GPU-based collision checker. The approach is validated across several simulated environment distributions, showing that PDG reduces collision checks by 2–20x and achieves faster solutions than baselines, with notable gains when paired with a parallel exploration strategy; results also highlight the importance of offline training to tune the path database and their guidance. Overall, PDG demonstrates that treating the path database as a tunable, updating guiding space can substantially improve robustness and efficiency of guided motion planning in diverse environments.

Abstract

One approach to using prior experience in robot motion planning is to store solutions to previously seen problems in a database of paths. Methods that use such databases are characterized by how they query for a path and how they use queries given a new problem. In this work we present a new method, Path Database Guidance (PDG), which innovates on existing work in two ways. First, we use the database to compute a heuristic for determining which nodes of a search tree to expand, in contrast to prior work which generally pastes the (possibly transformed) queried path or uses it to bias a sampling distribution. We demonstrate that this makes our method more easily composable with other search methods by dynamically interleaving exploration according to a baseline algorithm with exploitation of the database guidance. Second, in contrast to other methods that treat the database as a single fixed prior, our database (and thus our queried heuristic) updates as we search the implicitly defined robot configuration space. We experimentally demonstrate the effectiveness of PDG in a variety of explicitly defined environment distributions in simulation.

Figures (6)

• Figure 1: A simple example where Lightning performs poorly despite containing useful paths in its database. In this scenario where no single path solves the $(s,t)$ planning problem on its own, Lightning chooses the path (bolded) with fewest collisions, throwing out all computation relating to the discarded paths (left). Since the entire difficulty of such a problem is encapsulated in navigating this narrow passage, repairing the broken segment with Bidirectional-RRT is approximately as difficult as solving the original problem (center). Finally the original path is combined with the repaired portion to solve the MP problem such that ultimately the database and PFS were used sequentially (right).
• Figure 2: Example run of PDG on the same environment and paths as Figure \ref{['fig:lightning_bad']}. Validated edges are marked green. First we filter the paths to those that pass near the goal $t$, and validate the connection to $t$. Next we attach from the search tree (the start state $s$) onto a nearby path and follow it until we collide with an obstacle (left). The part of the path before the invalid portion is deleted and we attach onto the next available path (center left). If there is no nearby path to attach to we select which node from the tree to expand using RRT until we can again latch onto a path (center right). This process continues until we reach the goal (right).
• Figure 3: For computing the value of state $x$ we find the closest state $c$ on every path, if $c$ is within $\delta$ of $x$ then we validate the edge to the next state after $c$ in the path, $n$. If that connection is valid (left) we say the estimated cost-to-go value of $x$ is the distance from $x$ to $n$ plus the distance from $n$ to the end of the path. If the edge is invalid (middle) our estimate for $x$ (from this path) is infinite. If $x$ is itself on the path (right) but the edge to $n$ is invalid then we delete the part of the path up until the invalidated portion.
• Figure 4: Example samples of environments and tasks from our three distributions, RandomPassage (top left), Cubicles (top/center right), and Shelves (bottom). In RandomPassage each vertical obstacle is blocked at the top or bottom. In Cubicles each group of cubicles faces the same direction but the number and group orientation are sampled at random. In Shelves the number, distance, size, and depth of the shelves varies, with the task always sampled as a configuration whose end effector is in the center of a shelf.
• Figure 5: A comparison between Lightning and PDG runtime as a function of the number of paths in the database on the RandomPassage environment \ref{['fig:env_examples']}. The Exploit-Explore (EE) ratio is the number of times PDG uses the database to determine which tree node to expand divided by the total number of tree expansions. Both algorithm implementations use (bidirectional) RRT to repair and explore respectively. Notice how Lightning achieves a peak performance around $100$ paths and stays relatively flat as the database grows nearly two orders of magnitude. In contrast, PDG smoothly improves as the database gets larger until around $1000$ paths, and then gets worse as guidance from the database saturates (the EE ratio increases). This matches intuition, that the method pays for more paths than necessary, and that Lightning has a very weak dependence on the database size since most it is unused during each query.