by Mikael Beckius

http://www.eng.iastate.edu/~beckius/motion/

Introduction
The goal of the project was to create a virtual 3D environment where the user will hunt down a hovering 3D-robot carrying an obstacle from one place in the virtual environment to another. This was not fully achieved due to lack of time but the missing part (carrying objects) could probably be added without to much effort.

In the current implementation you can either choose between a random generated world or reading one from a file.

Right now the user can navigate throughout the enviroment, that is filled of mountains serving as obstacles, place the goal and the robot where ever he/she wants to. Then the user can start the robot and the robot tries to find a path. The robot has 4 degrees of freedom, x,y,z translation and rotation around y.

The planning was based on the framework for RRTs made by Steve LaValle.

Implementation
Implementation of the application was done on the SGI-machines using vrjuggler, C++, PQP collision detection package, LEDA and the RRT framework. Vrjuggler is a simulator for building VR applications and makes it easy to transfer and run them on the cave system at Iowa State. PQP takes triangles as input geometry an is based on incremental distance computation. LEDA is a very handy package with a lot of implemented structures etc. which make programming easier. The RRT framework is based on the following structure: An RRT that takes problem as an input. The problem itself takes a world and a model of the robot as an input.

World and robot model
In order to make the planner to work with the designed enviroment an new world was implemented. The new world was defined by the PQP-objects of the obstacles and overrides the super class. Right now all the obstacles are made up by different PQP-objects since there should have been the possibility of moving them. It might be faster to define them all as the same PQP-object (no testing done). The robot is also an PQP-object and Cfree is defined as the space where there is no collision between the robot and the mountains.

The robot, an airplane look a like, was designed so that in can rotate around its own axis, fly up an down and all the directions in the xz-plane.

Below is a picture of the robot while selected by the user.

This might not be a too air plane look a like motion but it makes it possible to have find a path almost in real time to any position in the world. The combination of metric and input seems some what sensitive though. Small changes can make it much harder for the robot to find a path at all. Did some experimentation with forward a only robot but it didn't perform too well after reaching a goal near the boundaries or in front of an obstacle. The metric currently used is the euclidean distance plus weighted rotation.

The robot seemed to perform much better when the rotation was removed. It almost always found a path and generally seemed to be much shorter than the one with rotation. The difference was not as obvious while doing some testing in 2D. The 2D paths actually seemed to be the shortest possible path for most cases.

Planner
The planner used was the RRTExtExt with the two trees growing towards each other from init and goal. Tried some of the other planners as well without doing any comparisons. Noticed though that the RRTConCon seemed extremely power full for finding a path. But it definitely not give the shortest and smoothest paths.

Source Code
All files for my application!

Files of particular interest:
world.cc
motion.cc
model.cc

Some pictures showing different cases
Goal and init at same height but it has to go over the mountain to reach rather than to go around it.

Goal is at a higher position than the init.

Robot started from the position in the previous position and went to a lower position behind a small mountain.