CS 476 Final Report - An Obstacle Based PRM

Johan Jacobsson and Wen-Cheih Chang

Project Description

In this project we implement an Obstacle Based Probabilistic Road Map (OBPRM). It is a randomized planning algorithm based on a Probabilistic Roadmap Method (PRM). The difference between an ordinary PRM and the OBPRM are that it tries to plan close to obstacles. This is where planning is hard so it makes sense to concentrate the planning here.

Implementation Approach

This project is implemented using C++, LEDA and the Motion Strategy Library. We started to implement the most basic parts of the OBPRM. After this we tried to add as many refinements as possible. There are a few things that we left out from the paper. We did not for example implement any A* methods. The natural thing to do was the derive our own class OBPRM from the already existing class PRM. A lot of things where changed or added. The biggest change is how the graph is constructed. A good picture of the obstacles are needed since that is where we want to plan. This OBPRM solves 2D problems because the data structures of environment for 2D and 3D in MSL are quite different.

Examples

Below are some examples with images. It is easily to find that most nodes in the roadmap placed closed to obstacles.

	OBPRM graph for data\cross. In this case, there are 50 nodes surround each obstacle. This is a parameter we may tune to reduce the size of the graph, and make it simpler.
	OBPRM path solution for data\cross.
	OBPRM graph for test data.
	OBPRM path solution for test data. The path from OBPRM has a property that it goes against the obstacles.
	PRM graph. for test data. 1st picture: 486 Nodes, 14848 Edges. (unsolved yet) 2nd picture: 5000 Nodes, 170k Edges! (solved finally) The PRM has big problems making it through narrow passages.
	PRM path solution for test data. PRM may produce nicer (shorter) than OPBRM, but it usually takes much more time.

Comparison

Here are some comparisons between OBPRM and other planners. Basically, we compare node and edge numbers in the graph.

Planner	RRTConCon	OBPRM	PRM
data\cross	Nodes: 445 Edges: 6916	Nodes: 1829 Edges: 14106	Nodes: 753 Edges: 4898
data\fpd3 (*modified to rotate)	Nodes: 21 Edges: 18	Nodes: 370 Edges: 6752	Nodes: 805 Edges: 17646
test problem	Nodes: 158 Edges: 50	Nodes: 371 Edges: 4836	Nodes: 5000 Edges: 170k

Comment:

The PRM has big problems making it through narrow passages. While the OBPRM has a tendancy to bounce against the walls.
For some cases, esepecially obstacles are rather smaller, OBPRM takes lot of time to connect the graph while the solution is somehow simple. But for complex obstacles, or narrow corridors, OBPRM can show its power to make path around them easily.
Generally, OBPRM is faster than PRM a lot. In our implementation, it focused on connecting different components in the graph. Although it may take a while to generate the graph, once it is done, the solution is there also. In other words, OBPRM do not need to iterate for many times to get the solution.

Results and Conclusions

The OBPRM performs well in cluttered environments. In large open spaces it often takes a long detour, this is built-in in the design of the algorithm and is expected. We had some problems since the OBPRM needs to know about all the obstacles explicitly. This made it very hard to convert the OBPRM to solve 3D problems.
Since OBPRM is a variation of PRM, the connective of the roadmap becomes a crucial factor to find suitable path between initial state and goal state. Base on this factor, we used different approach to connect all available nodes and the edges/nodes ratio is higher than other planners (except PRM).

Implementation Files

OBPRM planner based on PRM, Model2DRigid, and GeomPQP2DRigid classes in MSL.

Makefile - makefile of the program.
Obprm.h - header file.
Obprm.C - main Obprm class definition. A subclass of PRM, and the default planner after the program compiled.
data.tar.gz - Test data file, including a robot and obstacles.

Somthing modified in MSL:

defs.h - rename macros min(), max() to Min(), Max(). To avoid confliction with the member function of Sorted Sequences (sortseq) in LEDA.
guiplanner.C - modify Display a little to show Cin nodes in different colors.