A Region-Based Strategy for Collaborative Roadmap Construction

Abstract

Motion planning has seen much attention over the past two decades. A great deal of progress has been made in sampling-based planning , whereby a planner builds an approximate representation of the planning space. While these planners have demonstrated success in many scenarios, there are still difficult problems where they lack robustness or efficiency, e.g., certain types of narrow spaces. Conversely, human intuition can often determine an approximate solution to these problems quite effectively, but humans lack the speed and precision necessary to perform the corresponding low-level tasks (such as collision checking) in a timely manner. In this work, we introduce a novel strategy called Region Steering in which the user and a PRM planner work cooperatively to map the space while maintaining the probabilistic completeness property of the PRM planner. Region Steering utilizes two-way communication to integrate the strengths of both the user and the planner, thereby overcoming the weaknesses inherent to relying on either one alone. In one communication direction, a user can input regions, or bounding volumes in the workspace, to bias sampling towards or away from these areas. In the other direction, the planner displays its progress to the user and colors the regions based on their perceived usefulness. We demonstrate that Region Steering provides roadmap customizability, reduced mapping time, and smaller roadmap sizes compared with fully automated PRMs, e.g., Gaussian PRM.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Planning valid (e.g., collision-free) motions for movable objects (robots) is a difficult problem with broad applications to robotics, bioinformatics [1], gaming/virtual reality [2], automated assembly [3], and other areas. Despite the importance of motion planning , it is computationally intractable to design complete planners for high (often $>$5) dimensional systems [4].

Much attention has turned to sampling-based planners [5, 6] which address this complexity by building an approximate model of the planning space through, often randomized, sampling of robotic configurations. Despite advances in the development of fully automated planners, certain scenarios such as narrow passages remain problematic or even unsolvable with these approaches [7]. Human-assisted planners could help to remedy this, as approximate solutions to some problems are easily discovered by human intuition [8]. In situations where a fully automatic planner might not efficiently and/or reliably find a solution, a user can guide the planner by providing a nearly valid trajectory or other such hints [3]. In these systems, the human often performs a global scene analysis of the workspace, while the machine handles high-precision tasks such as collision detection and low level path-finding [9–11].

However, most human-assisted planners either limit the user’s interaction with the planner (e.g., through one-time subgoal specifications) or limit the planner’s automation (e.g., through only localized collision avoidance) with one-way interaction. More recent work, I-RRT (Interactive-Rapidly-exploring Random Tree) [12], attempts to bridge this gap. In I-RRT, the user controls a virtual avatar (representing the robot) which biases the growth direction of the planner. However, I-RRT is designed for single-query scenarios, requires continuous user action, and constrains the interface to one which can fully control the avatar.

We introduce a collaborative roadmap construction strategy, called Region Steering, that allows the user to steer a Probabilistic RoadMap (PRM) [5] planner towards/away from designated regions of the workspace. Region Steering allows the user to direct the planner by defining regions of the workspace on which to focus or ignore. These regions are then used to bias the configuration space sampling of the PRM. Region Steering maintains the probabilistic completeness of the underlying planner. Additionally, Region Steering provides live feedback to the user: it displays not only the roadmap, but also the perceived usefulness of each region. The user can modify, add, or delete regions dynamically to effectively steer the roadmap toward environment coverage faster than was possible by the automated planner alone. Region Steering also identifies regions where connecting the roadmap is difficult so that the user can provide better assistance by specifying attraction regions in these areas. The specific contributions of our work are as follows:

• A collaborative strategy, Region Steering, in which a user specifies and manipulates workspace regions to steer a PRM towards/away from vital areas.

• Experimental analysis of our method in a variety of environments showing both improved mapping efficiency and roadmap customizability compared with fully automatic planners.

Region Steering offers a novel interactive system for multi-query planning that requires only intermittent user action on a standard computer interface, e.g., a mouse. Finally, we note that the goal of this work is to verify the feasibility of our scheme and to understand how these hints and cooperation affect the planner. We have therefore left the analysis and optimization of the user interface to future work.

2 Preliminaries and Related Work

In this section, we outline preliminaries and present a selection of related work that is most relevant to our proposed collaborative planner.

Preliminaries. A robot is a movable object whose position and orientation can be described by $n$ parameters, or degrees of freedom (dofs), each corresponding to an object component (e.g., object positions, object orientations, link angles, and/or link displacements). Hence, a robot’s placement, or configuration, can be uniquely described by a point $\langle x_1, x_2, \ldots , x_n \rangle$ (where $x_i$ is the $i$th dof) in an $n$-dimensional space called the configuration space ($\mathcal {C}_{\textit{space}}$) [13]. The subset of all feasible configurations is the free space ($\mathcal {C}_{\textit{free}}$), while the union of all infeasible configurations is the obstacle space ($\mathcal {C}_{\textit{obst}}$). Thus, the motion planning problem is that of finding a continuous trajectory in $\mathcal {C}_{\textit{free}}$ from a given start configuration to a goal configuration. In general, it is infeasible to compute explicit $\mathcal {C}_{\textit{obst}}$ boundaries [4], but we can often determine the validity of a configuration quite efficiently, e.g., by performing a collision detection (CD) test in the workspace, the robot’s natural space.

Sampling-based Motion Planning. One methodology of addressing the complexity of motion planning is sampling-based methods [5, 6] which solve motion planning problems by creating an approximate mapping of $\mathcal {C}_{\textit{free}}$. They can typically be categorized into graph-based approaches such as Probabilistic RoadMaps (PRMs) [5] or tree-based approaches such as Rapidly-exploring Random Trees (RRTs) [6]. While they improve over deterministic techniques, sampling-based approaches struggle with discovering narrow passages [7].

Probabilistic RoadMaps (PRMs). PRMs construct a map of $\mathcal {C}_{\textit{free}}$ by first randomly sampling valid configurations. Nearby samples are then connected by validating simple paths between them, which form the edges of the map. Finally, start and goal configurations are connected to the roadmap and a graph search, e.g., A$^*$, is used to extract a solution path.

To improve the mapping of narrow passages, some PRM variants attempt to map $\mathcal {C}_{\textit{obst}}$ surfaces [14–17], by intelligently biasing or filtering sampling toward the $\mathcal {C}_{\textit{obst}}$ boundary. Though this and the previous PRM variants have shown success, there are many problems where they perform inefficiently or simply fail to generate a solution.

Region-informed Sampling-based Motion Planners. Some improvements to PRMs use information gain or learning techniques to guide sampling to specific regions of the environment. Feature Sensitive Motion Planning  [18, 19] subdivides the space into regions, individually plans in each region, and merges them together. It was designed to help map heterogeneous environments. However, these methods do not easily accommodate roadmap customization as the user has no way to control the regions.

Human-assisted Planning. Although human-assisted motion planning has been studied for the last two decades, there is still relatively little work in this area, and no cooperative planner has achieved widespread use. In many approaches, the human performs global scene analysis of the workspace, while the machine handles high-precision tasks such as collision detection. In [3, 8] the user can specify configurations which are critical to finding a collision-free path, while the planner performs collision checking and path-finding between sub-goals. In [20], the user is responsible for controlling an arm’s linkage while the machine takes care of the wrist. The user sets a number of sub-goals and finds a path between any two adjacent sub-goals using a best-first search, while the machine examines the neighbors and chooses the first collision free path found. In [10], when the operator uses a haptic probe to designate the desired speed and the rate of turn for the robot, the machine performs close range obstacle avoidance and provides force feedback to the operator. Another approach investigates the idea of converting workspace into $\mathcal {C}_{\textit{space}}$ [9, 21]. In this way, the robot can be represented as a point, which is easier for humans to visualize and control. Since $\mathcal {C}_{\textit{space}}$ is typically of higher dimension, the strategy explores interfaces that show the user various slices of $\mathcal {C}_{\textit{space}}$. Human-assisted motion planning has also been explored for dynamic environments. For example, in [11], the human can intervene and handle events such as unexpected obstacles; afterward, the machine can resume control without any re-planning.

A truly two-way planning approach, Interactive-RRT (I-RRT) [12] allows the user to control an avatar representing the robot in a virtual representation of the workspace. The algorithm biases tree growth by the avatar’s position and provides online feedback to the user through a haptic device and/or node coloring. This approach, however, is limited to single-query scenarios, requires the user to continuously provide input throughout the planning process, and is constrained to interfaces which can fully control the robot avatar. Another interactive approach using RRTs [22] introduces relaxation of collision constraints to overcome difficulties in virtual assembly/disassembly problems. Rough paths are retracted by a randomized method and then connected via a bidirectional RRT.

Teleoperation. A related but distinct field is teleoperation. The primary goal of teleoperation is to create a stable, closed-loop interaction between an operator and a robot that provides the user with a sense of presence-at-a-distance [23]. Teleoperation focuses on capturing a user’s mechanical skills directly, which differs from the high-level, detached nature of human-assisted planning. Nonetheless, both seek to provide a form of two-way communication, referred to as bilateral control in teleoperation literature. A recent work in teleoperation [24] notes that this form of interaction can be burdensome on the user, e.g., in situations with cyclic or repetitive motions, and takes steps to provide the robot with greater autonomy so that the user need only provide global guidance rather than direct control.

3 Collaborative Roadmap Construction: Region Steering

In this work, we propose a simple collaborative strategy for PRM construction in which a user specifies and manipulates workspace regions to steer a planner towards/away from important areas. During the mapping process, the user can observe the current state of the roadmap and see where the planner is having trouble connecting nodes. To guide the map construction, the user can then create attract regions in difficult areas. Attract regions bias node sampling in the workspace area they define, which focuses node creation where it is most needed. The user can also specify avoid regions, which conversely prevent node creation within the specified area. These can be employed to customize the resulting roadmap by steering nodes around undesirable or dangerous areas. We reiterate that our goal in this work is to understand what information is useful to the planner in our strategy, and not to evaluate the user experience.

Example. Figure 1 shows a simple example to illustrate the general progression of our algorithm in a 2D environment with large obstacles and a few narrow passages. In this example, we create a map-construction query to represent our desired coverage of the space with start and goal configurations. The user begins by specifying particular regions to influence the sampler, as shown in Fig. 1a. The user specifies two attract regions (green) in areas that will be difficult for the planner (e.g., a long, narrow passage), as well as one avoid region (striped). The avoid region exemplifies the customizability aspect of our strategy. Though the planner would be likely to sample successfully in that wider passage, the user indicates a desire to avoid that area, perhaps due to environmental considerations not available to the planner.

Fig. 1

Example scenario. a User pre-specifies one avoid and two attract regions. b An attract region is shaded red to indicate declining usefulness. c User responds by moving the region to a more productive location. d The resulting roadmap

Over time, the planner identifies one of the attract regions as unproductive and changes its color to red, as shown in Fig. 1b. In contrast, the other attract region, within the narrow passage, has proven to be useful and remains green. The avoid region behaves as a virtual obstacle and remains devoid of samples. The user modifies the unproductive region (Fig. 1c) by moving it into the narrow passage containing the goal and then resizing it accordingly.

By exchanging cooperative feedback, the planner and user have discovered the difficult regions of the environment in which to focus node creation. The roadmap can thus be completed and connected efficiently (Fig. 1d).

Definitions. We define a region as a bounding volume in the workspace. In our system, we currently implement bounding spheres (BS) and axis-aligned bounding boxes (AABB) as shown in Fig. 2; however, our planner is not restricted to these forms of boundaries.

Regions are allowed to overlap and are classified as attract, avoid, or proposed. Attract regions are used to bias the planner toward a region, whereas avoid regions act as virtual obstacles that the planner must avoid. If avoid and attract regions overlap, the avoid regions take precedence meaning that no samples will lie there. Proposed regions are those that have been recommended by the planner but have not yet been handled by the user. Attract regions are initially colored green but gradually change to red as the planner deems them ineffective, avoid regions are colored dark gray, and proposed regions are colored blue.

Fig. 2

Parameterization of AABB and BS regions. AABB regions (a) are specified by two points, while BS regions (b) are specified by a point and a radius

3.1 Collaboration Strategy

In this section, we describe a strategy for enabling a user to collaborate with an automated planner, as shown in Algorithm 1. Given an environment and a sampling technique, e.g., OBPRM [14], our strategy begins by allowing the user to input regions prior to planning. After this, the planner begins mapping the space. Until the sampler is done, e.g., samples $n$ nodes or has $c\,\%$ of coverage, we randomly determine an attract region in which to focus sampling, generate a sample $q$ within that region, and connect $q$ to the roadmap. After this, we provide feedback to the user: first, if that node likely lies in a narrow or difficult space, we recommend a new region based upon $q$ to the user. Second, we update the region’s usefulness and alter the color of the region to show the estimated density of samples in the region’s free space. Lastly, we update the display of the roadmap so that the user can view the roadmap and connected components in real-time. If $q$ lies within an avoidance region, we do not add $q$ to the roadmap. We provide further algorithmic details below.

We adopt a simple strategy for selecting regions. First, we consider the entire workspace as an attract region so that we can retain the probabilistic completeness of the underlying PRM approach we use. Then, we uniformly at random select a region from the attract regions e.regions. We limit sampling of positional degrees of freedom to this workspace region, and require the robot located at the sampled configuration to lie entirely inside the workspace region selected. If the sampler is unable to generate a configuration, we continue on with the next iteration of the main loop of the planner. If samples repeatedly cannot be found within the region, we gradually change the region’s color from green to red to indicate its ineffectiveness.

Assuming a sample gets added to the roadmap, $\textsc {IsDifficultNode}$ will return true if the number of successful connections is less than some threshold, i.e., one successful connection. In this case, we insert a proposed region as a boundary around the difficult node into the scene. If the user does not handle this region within a certain amount of time, we remove it from the scene as the user likely thinks this region is unimportant. Note the user can add these regions back at any time they desire.

To guide the user’s manipulation of the regions, we color the regions based upon their perceived usefulness $u$ to the planner by setting the region’s RGB value to be $\langle 1-u, u, 0 \rangle$. In this manner, the region is green when it is most useful and red when it is least productive. We base the usefulness on the approximated density $d$ of the successful samples within the region in $\mathcal {C}_{\textit{free}}$:

$$ d = \frac{n}{\mu {\left( \mathcal {C}_{\textit{free}}\cap r\right) }} \approx \frac{n}{\mu (r)\frac{n}{n+f}} = \frac{n+f}{\mu (r)}, $$

where $n$ is the number of successful samples, $f$ is the number of failed sampling attempts, and $\mu (r)$ is the volume of the region $r$. Essentially, we are loosely approximating the ratio of successful samples to the volume of $\mathcal {C}_{\textit{free}}$ covered by $r$. We define usefulness by: $u = \exp ^{-d^2},$ which allows us to have a smooth transition from useful to unproductive region coloring. Our choice in metric is a monotonically decreasing function over time motivated by the fact that too many samples in $\mathcal {C}_{\textit{obst}}$ do not add anything to the roadmap and too many samples in $\mathcal {C}_{\textit{free}}$ create oversampling and again do not greatly help the planning process. In $\textsc {UpdateMap}$, we simply update the display of the roadmap to the user. Nodes in the same connected component are displayed with the same color so that the user can easily determine whether two nodes are connected.

Region Steering also allows the user to customize the roadmap by specifying avoid regions. Avoid regions act like virtual obstacles and block the sampler from generating nodes within them. By blocking out unwanted workspace areas, the user can easily and intuitively steer the planner toward producing a desirable roadmap. For example, suppose our system is used to plan motions for a robot surveying an area. The user can alter the roadmap by specifying dangerous areas as avoid regions that the robot must evade. This flexibility offers an efficient means for handling transient or previously unknown hazards as the roadmap can be modified without needing to conduct further sampling.

3.2 User Input

In our collaborative system, we allow various forms of input to manipulate the regions in an online and interactive fashion. First, the user can pre-provide regions to the planner before planning begins. Second, the user can add, delete, move, and resize regions during the planning process. Finally, the user can optionally handle the regions which are recommended by the system. All of these options are constructed to avoid the need for continuous interaction: the user can provide as much or as little input as desired.

We use simple mouse input to accommodate the various forms of interaction. Based upon where the user clicks, we can project the 2D window coordinate $\varvec{w} = \langle w_x, w_y \rangle$ to a 3D plane defined by a point ${\varvec{p}} = \langle p_x, p_y, p_z \rangle$ and a normal ${\varvec{n}} = \langle n_x, n_y, n_z \rangle$. We use this operation to allow intuitive region definition and manipulation. We outline all of the operations on regions below:

Addition. When adding a region, the user can click in the scene to define a vertex of the bounding volume and drag the mouse to size appropriately. In planar environments, the mouse position is projected directly onto the environment plane. For volumetric environments, the mouse position is projected onto the plane defined by a point ${\varvec{p}} = \overrightarrow{cam_{pos}} + d*\overrightarrow{cam_{dir}}$ and a direction ${\varvec{n}} = -\overrightarrow{cam_{dir}}$, where $\overrightarrow{cam_{pos}}$ is the position of the camera, $\overrightarrow{cam_{dir}}$ is the direction the camera is facing in the scene, and $d$ is a displacement distance (typically $^1/_3$ of the environment’s bounding radius). For example, to add an AABB region, the user clicks the scene, which defines a single vertex, and then drags the mouse to size the box and define a second, opposite vertex to complete the AABB (shown in Fig. 2).

Deletion. The user can select any region at any given point in time. If the user selects a region, it can be ordered for deletion. Selection is based upon projecting the mouse position into the scene to identify the object it hits first.

Manipulation. Manipulation is a bit more difficult. All regions can be translated and resized in the scene. When translating, we allow for two motions. If the user left-clicks the selected region, we translate on the plane defined by $p = c$ and ${\varvec{n}} = -\overrightarrow{cam_{dir}}$, where $c$ is the center of the region. If the user right-clicks the selected region, then we translate in and out along $\overrightarrow{cam_{dir}}$. To resize a given region, the user highlights the edge of the region and resizes via click-and-drag. For example, with AABB regions, selecting an edge allows manipulation for two of three dimensions at any given time, or for BS regions, the radius can be manipulated by selecting the boundary of the projected sphere. When a region is manipulated, the numbers of successful and failed sampling attempts are reset so that the region’s effectiveness and coloring can be recomputed.

Recommendation processing. When the user sees a recommended region, which is initially proposed, the user can ignore the region completely, delete it, or manipulate it and commit it as either an attract or an avoid region. Thus, these regions do not affect the planner until they are handled by the user.

3.3 Probabilistic Completeness

Region Steering is probabilistically complete because we retain the entire workspace as an attract region, assuming that the underlying sampler is probabilistically complete. As this region has a probability of being selected, if the underlying sampler guarantees asymptotically complete coverage of the space, then our planner maintains the same property. We note that if the user creates avoid regions that prevent solving the query, we cannot detect that through sampling-based planning alone. This does not change the probabilistic completeness of the planner as the underlying planning problem becomes unsolvable.

4 Experimental Analysis

In this section, we compare Region Steering with other common PRM techniques and I-RRT [12]. We show how our strategy leverages the information provided by the user to improve roadmap construction time and provide customized output in a variety of scenarios. We do not claim that the user interface is optimal or intuitive: it is merely sufficient for the user to communicate with the planner and allows us to study the usefulness of two-way collaboration with PRMs. We leave analysis and development of an improved interface to future work.

4.1 Setup

In our experiments, we study the impact of Region Steering on PRM sampling techniques by comparing its performance with Basic PRM (referred to as Uniform) [5], OBPRM [14], and Gaussian PRM [15] (referred to as Gaussian), and I-RRT [12]. These methods were all implemented in a C$++$ motion planning library developed in the Parasol Lab at Texas A&M University. It uses a distributed graph data structure from the Standard Template Adaptive Parallel Library (STAPL) [25], a C$++$ library designed for parallel computing. Our strategy is not restricted to any underlying sampling technique: we use Uniform in these experiments, but any sampler can be used. As such, we believe it is fair to compare against other samplers which bias sampling for narrow and cluttered environments, such as OBPRM and Gaussian PRM. For Gaussian PRM, we configure the $d$ value of the Gaussian distribution to twice the robot radius for the environment, which provided consistent results. Though there may be better $d$ values, we believe that this maintains a fair basis of comparison. I-RRT’s parameters were selected based on recommendations in [12]. We test Region Steering with both AABB regions, referred to RS-AABB, and BS regions, referred to as RS-BS. Additionally, we test Region Steering using both one-way and two-way interaction to demonstrate the benefit of two-way collaboration. In the one-way tests, all regions are input prior to the PRM execution: the user is not allowed to alter any regions during mapping. In the two-way tests, the user is allowed to add, alter, and delete regions during roadmap construction as they see fit. All methods use Euclidean distance, straight-line local planning, and a $k=10$-closest neighbor connection strategy.

Fig. 3

Various environments for experimental analysis. All queries require traversal through narrow passages between the start (red) and goal (blue) configurations. a Heterogeneous. b FloorPlan. c Hook. d LTunnel. e Walls

All experiments were run on Dell Optiplex 780 computers running Fedora 17 with Intel Core 2 Quad CPU 2.83 GHz processors with the GNU gcc compiler version 4.7. Each planner is run until either an example query is solved or a roadmap size of 10,000 nodes is reached. The user-guided executions were performed by graduate students studying motion planning. In order to minimize the impact of user variance, the users were allowed to practice with the system until they developed consistent performance. Consequently, one- and two-way strategies did not vary significantly across trials and in many cases differed primarily in greater care taken in region creation for one-way tests and ability to delete unproductive regions in two-way tests. However, it should be noted that in practicing with the system the users were able to receive feedback from the planner on their one-way strategies; no such feedback would be available in a true one-way system. The one-way tests thus represent the idealized performance of a user who knows an effective strategy a priori.

The example construction query is designed to verify complete coverage of the environment such that if the query can be solved using the roadmap, then the roadmap sufficiently covers $\mathcal {C}_{\textit{free}}$. Failing to solve the query indicates that there are areas that are disconnected or not covered in the roadmap. Thus, the roadmaps constructed by Region Steering are reusable for multi-query use: after the initial query, subsequent queries can be solved with minimal or no further sampling. We report the number of successful completions, the number of nodes in the final roadmap produced, the time required for initial user input (for our collaborative region strategy), and the time needed to build the map. All experiments are run with 10 trials, and the metrics reported are averages of the successful runs.

Environments are shown in Fig. 3. Construction queries are shown in start configuration (red) and goal configuration (blue) pairs.

• In Heterogeneous (Fig. 3a), a simple 2dof robot must traverse a series of cluttered regions and narrow passages from the bottom to the top of the environment.

• In FloorPlan (Fig. 3b), a 3dof mobile robot must traverse through a cluttered apartment from a living room to a bedroom. This environment is representative of a possible robotic assisted-living platform for retirement communities, upon which the floor plan is based.

• In Hook (Fig. 3c), an 8dof free-flying robot with three articulated links must maneuver through a wall with a small hole.

• In LTunnel [26] (Fig. 3d), an L-shaped, free-flying robot must traverse two difficult narrow passages to get from the left side of the environment to the right.

• In Walls [26] (Fig. 3e), a simple stick-like robot must traverse a series of narrow passages (walls with holes) from one end of the environment to the other.

We only compare against I-RRT in the Heterogeneous environment because this is the only robot fully controllable by our interface, a mouse with 2dof.

4.2 Roadmap Construction Comparison

In our first experiment, we compare the mapping efficiency of Region Steering with other PRMs: Table 1 shows the success rates of the various methods in the environments, Fig. 4a displays the number of nodes in the final roadmap produced in each environment, and Fig. 4b presents the time required by each method. In FloorPlan, Uniform and Gaussian had normalized times of 6.786 and 1.755, respectively, and were cut-off to better show the data.

Table 1 Success rates for the various PRMs in the test environments

Fig. 4

a Number of nodes and b time required by each method to solve the construction query, normalized to OBPRM. For the Region Steering methods in (b), the upper portion of the bar represents the user’s pre-specification time, while the lower portion represents the time taken by the automated planner after pre-specification

Performance. Our experiments demonstrate that Region Steering offers more reliable and efficient roadmap creation compared to the tested automatic methods. The user’s input improves the number of successful construction attempts to 100 % across all environments (in the intended two-way case). By examining the planner feedback, the user can identify workspace areas where the planner is unable to sample or connect nodes to the map, and then intervene by creating an attract region to bias sampling in those areas. This allows the collaborative strategy to focus system resources on difficult regions and provides greater robustness to sampling-based randomness compared to the automatic methods. Additionally, Region Steering typically improves construction efficiency in terms of both the number of nodes and the total time required to build the map (even with the overhead of collecting initial user input): Region Steering’s running time improved on the fastest automatic planners by a minimum of 46 % in Walls and a maximum of 91 % in Hook. I-RRT’s performance is comparable to Region Steering, which performed slightly better in Heterogeneous. We also note that if the number of queries to solve were greater, the difference between the methods would be more pronounced as Region Steering can reuse the computed roadmap. By taking advantage of the user’s intuitive global analysis of the scene, Region Steering can focus sampling in difficult areas between the connected components of a roadmap and, thus, achieve higher connectivity and reduced planning time. In turn, the reciprocal feedback given to the user—including showing the roadmap and connected components, visualizing a region’s usefulness, and recommending specific regions—can guide the user toward achieving these ends.

One- versus Two-Way Communication. In three of the environments (FloorPlan, Hook, and Walls), the user strategies for one-way communication were very similar to their two-way counterparts. While the ability to correct input errors and delete unproductive regions contributed to performance, it was not the dominating factor in these cases. Conversely, the user strategies differed significantly in the other two environments (Heterogeneous and LTunnel). In these environments, the two-way strategies relied on the ability to modify the regions in order to map the space efficiently. For example, in Heterogeneous the user would typically begin with a large region in the center and modify it as the system provided feedback to make it smaller and more focused on areas that were not yet connected. This approach is not possible in one-way planning, and performance in that environment suffered from the inability to re-target the PRM’s focus. In LTunnel, the two-way strategy for boxes achieved better performance than its one-way counterpart by simply deleting attract regions once a single CC had broken through. The one-way spheres case for this environment was far more dramatic because it was too difficult for the user to precisely specify spherical regions that conservatively estimated the box-like tunnel. In the two-way case, the user could roughly estimate the regions required and then modify those that failed to contribute to the roadmap. The inability to make such adjustments prevented the user from building this map consistently with spherical regions. This implies that two-way interaction provides significant benefits when the workspace area of interest is shaped differently than the planning region.

Region Shape. Our data shows that the user specification time for BS regions is generally less than that of AABB regions, but the planning time for BS regions is generally greater than for AABB regions. This suggests a trade-off between the ease of a region’s manipulability and its effectiveness. However, the total mapping time does not seem to differ significantly. Furthermore, from our experience, different users prefer different region types depending on the environment and situation. While the one-way/two-way comparison hints that some of this disparity is related to how well a planning region fits the workspace area of interest, we leave the full investigation of these choices to a future user study.

Fig. 5

a Building and b Helicopter environments used to illustrate roadmap customizability. Avoidance regions are shown in dark gray and queries are shown as red/blue pairs

4.3 Roadmap Customization

In this experiment, we illustrate roadmap customization through Region Steering. The user is tasked with requiring creation of a roadmap which avoids a specific area. We test this in the two environments shown in Fig. 5. Building is an office building in which several homotopically equivalent paths exist for a 2D omni-directional robot. The avoidance region shown in dark gray represents some area of danger (such as a fire or collapsed portion of the building) that the robot should avoid. Helicopter is a 3D cityscape that is traversed by a flying robot with 3 dofs. In this environment, we require the robot to avoid flying through an open architecture of a building (again shown as a dark gray region). The construction query is designed so that there are at least two homotopically distinct paths from start to goal and at least one of them passes through the avoid region. We show the percentage of roadmaps who’s shortest path successfully avoids the region for our Region Steering compared to Uniform. Ten trials were completed, and the successful percentages of ‘safe’ maps are shown in Table 2.

Table 2 Percentage of maps with shortest paths correctly steering away from the avoidance regions

As we can see, our strategy is successfully able to avoid the regions that might be traversed by an automatically planned path. Additionally, the roadmaps created by Region Steering contain no nodes in the avoid region, while the successful roadmaps created by Uniform simply did not use their nodes in the avoid region for their shortest path. We would like to emphasize that although it is possible to design these constraints into the problem specification, our strategy allows online customization during roadmap construction. This as-needed specification makes Region Steering well suited to handling newly discovered or temporary constraints without needing to alter the environment description. These simple tools enable a user to customize solutions for a variety of scenarios with minimal operational burden.

5 Conclusion

In this paper, we introduce Region Steering, a collaborative planning approach for PRM techniques. In one direction of interaction, the planner displays mapping progress, colors regions based on their perceived usefulness, and recommends regions based on difficult nodes. In the other direction, a user can manipulate, add, and delete regions to guide sampling. Our experiments show that Region Steering provides increased robustness and customizability compared to fully automated methods.

In the future, we plan to perform a user study to evaluate the effectiveness of the interface. We are specifically interested in discerning what type of interactions lead to effective cooperation between the user and the underlying planner. In addition, we plan to extend our technique to fixed-base manipulators, which will likely provide an opportunity to develop additional collaboration strategies for a variety of applications.