Wandering in the Robot PlayGround

Introduction

The inspiration for Robot PlayGround was a desire on the part of the developer to combine two disciplines, virtual reality(VR) and motion strategies, into a single project. Because Robot PlayGround was designed to be the final project in two classes, it has two separate goals. For VR, it had to be highly interactive and graphically interesting. For motion strategies, it had to efficiently calculate paths for a robot with movement in four dimensions (translating freely in space, and turning about its vertical axis).

An Overview of Robot PlayGround

Inside of the environment are numerous objects: a robot, a cargo block, a target, and several obstacles. Using a glove supported by the CAVE library, the user can pick up objects by touching them with a closed hand. The object moves with the user's hand as long as the hand is closed. Objects may be placed anywhere in the environment, and may be rotated about their vertical axes by turning the hand.

There is no physics modeling for objects when the user moves them. An object released in midair will not fall, and objects can be positioned so that they intersect each other. It was decided that obstacles were easier to position if they could intersect, but a future release may disallow intersections with targets, cargos, and robots, as this can confuse the motion planning algorithms.

• Obstacles

  

  The obstacle blocks are pink rectangular objects. Initially, ten blocks are placed in the same position at the center of the floor. In addition to being positioned by the user, they can also be scaled to create different sized objects. To scale an obstacle, the user touches it with the first finger of the gloved hand extended. The user can then push and pull on the sides of the obstacle, changing its size. Changing the hand gesture ends the scaling operation.

• Cargo and Targets

  

  The cargo object is a small blue block, initially floating in space near one corner of the environment. The target is more visually interesting: a series of concentric circles that pulse red and green. The cargo and target both support the standard grab and move operation, but have no other interactive features.

• Robots

  

  The robots themselves are the most complex objects in the environment, both visually and interactively. Because of the unusual movement characteristics of the path planning algorithms, it was decided to use helicopters and other hovering machines as models. One model is a traditional-looking helicopter. Another version of Robot PlayGround uses a model that more resembles a flying saucer, which seems to be the most natural looking (the helicopter has an unfortunate tendency to fly backwards).

  The robots support several interactions in addition to the usual grab and move. Touching them with the first finger extended toggles them on and off. Touching them with two fingers extended toggles the display of additional information related to the path planning algorithm. This includes displaying the roadmap and a slice of the robot's configuration space (see the Implementation section for a detailed explanation of this mode).

  The robots also include status lights to relay basic information to the user. These lights are the top of the flying saucer robot and the canopy windows of the helicopter robot. The lights are red when the robot is off, green when it is on and following a path, and blue when it is working to find a path.

The usual loop of actions for a user in the Robot PlayGround environment is to position the obstacles, target, and cargo as desired and then start up the robot to see if it can find its way around. However, it is also possible to change the environment while the robot is moving - repositioning blocks, or even moving the robot if it gets stuck. The robot ignores objects that are being carried by the user, but when they are set down again the robot will adjust its course to compensate.

Implementation

Geometry Representation and Configuration Space

Most modern path-planning algorithms for solid-bodied robots take advantage of the notion of Configuration Space. A configuration of a robot includes the position of a reference point inside the robot and the amount of rotation along its axes. For example, a robot that can translate freely in three-dimensional space and rotate along only one axis has a four dimensional configuration space. The goals and obstacles in physical space can be mapped into this configuration space, so that solving the path planning problem for the physical robot can be done by finding a path for a notional "point robot" in the configuration space.

In order to maximize performance and keep the user interface as simple as possible, Robot PlayGround places certain restrictions on object geometry. The key restriction is that the surfaces of objects must be either horizontal (parallel to the XZ plane) or vertical (perpendicular to XZ). Surfaces that rise at an angle, are not allowed, although they can be approximated by using multiple objects. So, a flat-sided Egyptian pyramid would be illegal, but a South American step pyramid shape is allowed.

In terms of user interaction, this means that objects can only be rotated along their Y axis. Because objects (and the robots themselves) can move in 3D space and rotate along one axis, Robot PlayGround uses a 4D configuration space.

Generating the Configuration Space

The user can change the environment in Robot PlayGround at any time by picking up and moving an obstacle. Any such change requires modifications to the configuration space and reevaluation of any paths. Therefore, it is important that the configuration space and path finding algorithms be as fast as possible. This proved to be the most difficult part of the project.

There are several ways to generate the configuration space for a robot and an environment. An initial attempt made use of a 2D configuration space calculation algorithm based on the edges of polygons, discretized over the y(height) and theta(rotation) parameters. This worked, but proved prohibitively expensive. In order to maintain the desired level of precision (chosen to be 1/2" of height and 2 degrees of rotation), the algorithm had to be called a great many times in order to generate the full 4D configuration space. The result was memory intensive and very time consuming - taking upwards of 30 seconds on an SGI Onyx. Clearly, another technique was needed.

The limitations placed on object geometry provided a cheap way out, one that probably should have been considered in the first place. Since all objects and robots are represented as solids with flat tops and bottoms and sides that rise straight up, the configuration space representation of obstacles (with a fixed theta) will be likewise. Basically, the configuration space representation of an obstacle is a shell enclosing that obstacle, designed to give the robot enough clearance to avoid touching it.

Since we know that the cross-section of any obstacle remains the same at any height, the configuration space algorithm just figures out those cross-sections, and the top and bottom values so that the robot will have sufficent vertical clearance. We discretize along the theta parameter, computing the configuration space for 180 separate theta values (instead of the original 180 theta values multiplied by 180 y values). The resulting algorithm takes a fraction of the memory, and executes in under a second. Also, it is bounded by the number of obstacles in the space, and does not depend on the size of the space.

Path Planning in Configuration Space

The robots use a Randomized Roadmap algorithm to plot courses in the configuration space.
1. A number of points (x,y,z,theta) are placed randomly through the configuration space. Robot PlayGround's implementation initially places 100 points. Points are also added to indicate the positions of the robot and its current goal (either the cargo or the target).
2. If two points are sufficiently close together, an attempt is made to connect them. The connection algorithm draws a line through the 4D configuration space, checking for collisions with obstacle representations.
3. The connected points are treated as a graph and searched to find a path between the points representing the robot and its goal.
4. If no path was found, we add more points to the graph and try again, until a path is found. This implementation also bails out after adding 500 points.
The randomized roadmap algorithm is generally very effective. However, it does have several drawbacks. The most important of these is that it is not guaranteed to find a path, even if one exists, though the probability of this decreases as more points are added. Also, the paths that it generates consist of multiple short line segments. The resulting robot motion tends to be jerky - another reason why the flying saucer robot model looks more convincing than the helicopter.

The Robot Information Display



When the user touches a robot with two fingers pointing, it toggles an information display which consists of two parts.

1. A slice of the configuration space at the height of the user's hand is displayed, showing obstacle representations in translucent red and blue. The slice displayed changes as the user moves his/her hand up and down. The theta value used is the current rotation of the body.

   Using this part of the display, the user can see the actual constraints on robot motion. For example, if two blocks are separated by a narrow gap, the user can determine if the robot could actually fit between them. If the obstacle representations overlap, there is not room for the robot. If there is any gap, then the robot can squeeze through the space.

2. The current roadmap is also displayed. Points are shown in red. The paths between them are displayed in yellow and green. Remember that each point in the roadmap actually exists in four dimensions: x, y, z, and theta. The theta coordinate controls the color of the paths: pure green represents 0 degrees rotation, fading to yellow as the rotation increases.

Limitations and Future Work

Initial use of Robot PlayGround has shown that a load/save feature to store object positions would be a very helpful feature. Setting up obstacles can be time consuming, especially in the CAVE Library's simulator mode.

Pains were taken to ensure that the pathfinding algorithm executed with the best possible speed, but it still creates a significant glitch in the displays when it happens. Fortunately, this only happens when the environment changes. But, if other strategies are implemented, they may be more time consuming. Ideally, the motion planning should be decoupled from the display process.

Finally, the current implementation has shared memory issues that may keep it from working properly on multiple screens, or a full C2 setup. This has not been tested.

The developer would also like to port the Robot PlayGround to a more advanced VR development environment, such as that provided by VR Juggler, when it becomes available.

Conclusion

Bibliography

• LaValle, Steve. Com S 576X Motion Strategy: Algorithms and Applications, lectures and notes. http://www.cs.iastate.edu/~cs476/
• The 3/24/98 status report on Robot PlayGround is available here.
• The original Robot PlayGround proposal is available here.