Implementation of the Visibility PRM via ISU's MSL ...and creating more acronyms in the process ComS 476 Final Project - Spring 2001 Jacob Laack and Mark O'Brien

Instead of choosing to connect every new node to the existing graph, like with the traditional PRM, the PRMVis checks every new node's "field of vision." A node that cannot see any other node from its current position, assumes the role of a "guard." Any node that can see two guards is connected to those guards and becomes a "connector." Nodes that can't serve either of these roles are discarded. Our planner constructs a roadmap by finding a new node (free of collision), promoting or discarding it, and repeating this process until discarding a number of consecutive nodes equal to the number in the NumNodes field from the PlanCtrl window of the MSL. (whew)

Our approach/implentation closely follows that of the original PRM. The real diffences between it and the PRMVis appear during the construction of the roadmap. After about a week of coming up with different ideas for classifying our nodes, we found an algorithm in a paper (provided by the prof.) that modeled our ideas in a much more formal way. The algorithm builds a roadmap by storing new guard nodes in components and new connectors in a list. When two guard components are connected, they are merged and the involved edges are added to the roadmap.

In the ideal case, at the end of the construction phase, a single guard component should remain containing guard nodes able to observe the entire "free space" of the world and are connected via connector nodes. Large open areas within the free space are easily covered by a single guard but narrow passages or the need for complex translations/rotations can break the PRMVis as well as our implentation. In this respect, our implentation can solve most of the example problems we have thrown at it unless they require some precise motion for it to succeed. A maze-style world is nice as long as the shape fits easily down the hallway while problems requiring a ring wiggled off a bent pole are still out of reach.

There are a couple ways of "tweaking" our implentation. Changing the NumNodes property in the PlanCtrl window will enhance the stubborness of the planner. The more failures allowed, the better chance at placing a guard in a much needed spot. Also, if the first press of the "Construct" button fails to construct a working roadmap, repeated clicks of the same button will result in further attempts to add-on to the previous roadmap.

Screenshots

• Triangle [Path|Roadmap]
• Maze [Path|Roadmap]
• Maze (without rotation) [Path|Roadmap]
• Wrench (in a cage) [Path|Roadmap]
• Wrench (thru a wall) [Path|Roadmap]
• 2Dmaze4C (modified) [Path|Roadmap]

fdp3
	PRM	PRMVis
Path
Roadmap
Results	PRM Nodes: 887 Edges: 28986 ColDet: 95673 Components: 1 Construct Time: 0.839999s	PRM Nodes: 5 Edges: 8 ColDet: 53968 Ending # of guard sets: 1 Max Number of Gaurd sets: 2 Max number of consecutive failures: 1000

cross
	PRM	PRMVis
Path
Roadmap
Results	PRM Nodes: 801 Edges: 5232 ColDet: 257874 Components: 20 Construct Time: 87.47s	PRM Nodes: 124 Edges: 190 ColDet: 267823 Ending # of guard sets: 29 Max Number of Gaurd sets: 39 Max number of consecutive failures: 10

cage
	PRM	PRMVis
Path
Roadmap
Results	12000 nodes in the PRM. PRM Nodes: 12161 Edges: 13202 ColDet: 424842 Components: 6390 Construct Time: 93.4s Plan Planning Time: 0.0699768s Failure to find a path in the graph.	PRM Nodes: 237 Edges: 460 ColDet: 2020390 Ending # of guard sets: 7 Max Number of Gaurd sets: 14 Max number of consecutive failures: 100

From the above examples, it's easy to tell that the PRMVis creates much "cleaner" roadmaps than the traditional PRM.

Planner Files

• prmvis.h
• prmvis.C
• visibility.C

• Triangle - a simple map with one large obstacle; only translation allowed
• Maze - the "Pac-Man" maze created for Homework 3
• Wrench - a wrench trapped in a birdcage