Cargo-carrying Robot in a VR Environment

Com S 476/576 FINAL PROJECT - Spring 1998

Christopher Just

Project Description

This project began as an attempt to combine two projects and two disciplines - motion planning and virtual reality. The goal was to create a virtual environment in which a user could manipulate obstacles in 3D, and then test the ability of different robots to perform a simple task. The task chosen is to pick up a block of cargo and deliver it to a target. This task has several major complications:

The shape of the robot changes half-way through the operation - suddenly it has a piece of cargo dangling beneath it. The obstacle space also changes, because the cargo is no longer an obstacle.
Performance is a major issue. The environment is very interactive - users are allowed to pick up and reposition obstacles at any time, changing the configuration space and possibly invalidating the robot's path. Anything that interferes with a VR environment's framerate is a severe problem - possibly even causing cybersickness. While spinning the path-planning algorithm into a separate thread may prevent the worst of these problems, a long delay is still a problem in the interactive environment.

The Approach

It was decided that the first (and so far, only) batch of robots would use a randomized roadmap approach to pathfinding. Randomized roadmaps are particularly useful for finding multiple paths when the obstacle space remains constant, which explicitly is not the case here. However, the algorithm is relatively straightforward and lends itself to being displayed visually (that is, the ability to display both the roadmap and Cobst made the program more interactive and visually interesting).

Path planning is done in a 4D configuration space. The robots are able to translate freely in x, y, and z coordinates, but can only rotate on their vertical axis (y, in the cave environment). While this limitation was included mainly for reasons of performance, it is reasonable based on the models of the robots, which include helicopters and flying-saucerish hovercraft. Such vehicles are typically only capable of a small amount of rotation on their other axes, with effects on their movement that would be troublesome to emulate.

There are some minor problems with the paths generated by the algorithm:

Since paths are made up of multiple straight links, the resulting robot motions can look jerky.
There are no constraints on direction of motion. For example, the helicopter robot is as likely to fly backwards as forwards.
Since the algorithm is based on placing points randomly, it is not guaranteed to find a solution even if one exists. The robots "bail out" of the algorithm after a fixed number of failures, though they can be restarted to try again.

The Environment

The environment is a 12' x 12' x 9' cube, the same size as the ICEMT C2 device. A number of rectangular blocks are placed in the center of the floor, which the user can position to create obstacles. These blocks can also be scaled to create walls, ceilings, etc.

The cargo - a small blue block - and the target marker can also be placed anywhere in space.

The Robots

The picture above shows two of the robot models. Of course, the representations used in path planning are much simpler than the graphic models, but are worth considering. The representation of the helicopter robot is made up of two polyhedrons. The body is a rectangular solid, while the rotors are represented by a thin octagonal body. In addition, the cargo, if present, is an additional square shape descending from the body. The reference point for configuration space, and center of rotation, is located just below the center of the blades.

Configuration Space

Generating a 4D configuration space in which to plot paths can be time consuming. Luckily, a restriction imposed by the object interaction routines allows the configuration space to be computed very quickly.

The lucky coincidence works like this: all obstacle blocks in the environment have sides that rise vertically, and flat tops and bottoms. This restriction grew out of the difficulty of dealing with yaw and roll when using the CAVE library's simulator mode. Coincidentally, similar restrictions apply to the robots themselves. The 2D configuration-space algorithm can be modified to generate 3D configuration space with these restrictions simply by figuring out the amount of vertical clearance necessary above and below each obstacle for each component of the robot. The algorithm is discretized along the theta dimension, using steps of 2 degrees, to create the full 4D configuration space.

In the picture below, a cross-section of the configuration space is displayed (the user can change the height of the cross-section by raising and lowering his hand). Cobst is drawn in red and blue; the rotation is that of the robot in its current orientation. If you look closely, you can see several polygons drawn around each physical obstacle. Each of the two parts of the robot creates a different polygon, with different vertical sizes and positions.

Path Planning

The robot has several goals, which it deals with one at a time. The first is to find its way to a point just above the cargo object. The second is to take the cargo to a point just above the target marker. In each case it does this by creating a randomized roadmap.

The roadmap is created by scattering points randomly through the 4D configuration space and connecting them where possible. Points can be connected if:

They are closer than some maximum distance (here set at 3 feet), and

A straight line drawn between the points does not intersect Cobst.

Points representing the robot's current position and its current goal position are added to the roadmap, and then it is searched as an undirected graph. The current implementation uses a simple breadth-first search, which is guaranteed to produce a solution with a minimal number of links (not neccessarily the shortest physical distance).

If the graph search fails, the roadmap is expanded and the search repeated. The robot will go through a certain number of iterations of expansion and search before surrendering.

In the picture above, the roadmap that the robot used to travel from its point of origin (just above the red-and-green target marker) to the cargo is displayed in green and yellow. The color variation indicates the amount of rotation for each point.

Results

The current state of the project is functional, but imperfect. In particular, a great deal of time could be spent tuning the workings of the randomized roadmap algorithm. In particular, the current batch of robots tend to give up too easily, and to need too many iterations to find a result. The first step to solving this is to increase the initial number of points generated, but some experimentation is required to find a "good" general number.

Performance-wise, the results were quite pleasing. Thanks in part to the trick found in generating Cobst, the overall time for generating the C-space, the roadmap, and a path to the goal is typically 1 to 3 seconds on an SGI Octane. While this still suggests that the path-planning should be spun into a separate process before being used in a fully immersive environment, it's certainly good enough to create a sense of interactivity between user and robots.

There are other issues in the program needing to be addressed that are not strictly issues of path planning. These include:

The ability to save/restore obstacle setups. This would make testing much simpler, saving the time required to setup obstacles every time the program is run.
The ability to run in the full C2 setup. This is mostly a shared-memory issue which the CAVE library chooses to foist on the application developer, and which this programmer hasn't been able to deal with yet. Which leads to...
Porting to a different VR development environment. The CAVE library is not quite an ideal development system. I would like to port this program to a more advanced, friendlier environment, such as VR Juggler - forthcoming from ICEMT ;) - at the first opportunity.

Additional Information

A report on this program for CprE 575 is available here. This report goes into more detail on the VR and interaction aspects of the program.
Information on the CAVE library's programming environment is available here.

Implementation Files

Note: This program requires the CAVE library (which I don't have permission to distribute). It also requires the OpenGL Utility Toolkit (GLUT), available for free here.