Motion Strategies for a Car-Like Robot
A Final Project for CS 476, Spring 1998
by Benjamin Burnett and Tina Troutner

Explanation of Project     World 1    World 2     World 3    Home

Project Description

As stated elsewhere, the goal of the project was to develop a path-planning mechanism for a car-like robot to navigate through 2D world. The idea is that given an interpretation of the world, an initial point and a goal region, the robot in our program would be able to determine a path through the world that would not collide with any obstacles. In our project, we assumed that the problem was non-holonomic (which was proved in class), and therefore it is that our car could move both forward and backward. However, the car has a large constraint, the maximum turning angle PHI. In simple terms, this means that (like a normal car) our robot can only turn so far in a given period of time, or more specifically, the robot cannot move sideways. This poses a problem in navigation, for a path determine by the path-planner may not necessarily conform to the constraint of the turning radius. So when programming this assignment, the maximum turning angle needed to be kept in mind.

The most challenging part of the implementation described below was to have the program select points and paths that are not in, or collide with obstacles. Once the preliminary path was chosen, the next problem was in "smoothing out" the path so that the robot would not move in strange and random ways. Finally, once the "smooth path" was developed, the robot had to navigate along this path, always obeying the maximum turning radius, and checking to make sure that no part of the robot "nudged" or "skimmed" an obstacle wall.

Implementation of the Collision-Checker:

Our collision-checker, Collide, uses the robot's longest "radius" to develop a "buffer zone" around all the obstacles. If the point given to the collision checker is inside the obstacle, or inside this buffer zone, the Collide routine returns false to the caller, stating that the point is "bad". We also implemented a procedure called SegCollide that tested any given segment to see if it collided with an obstacle. We used SegCollide to eliminate paths that went through obstacles, and to make sure that when the robot was moving it didn't collide or runover any obstacle regions.

Compute a Collision-free non-holonomic path:

To compute a Collision-free path, we used the Randomized Roadmap technique to develop a "map" for the robot through the entire workspace. Then we used Depth-First Search to find a path from the initial region to the goal region. Once that path was found, SmoothPath was called to remove any loops or unnecessary points in the path. In essence, what our program does is randomly chose x points in the world, rejecting those tagged by  Collide. Of the points remaining, those within a distance of d of each other are connected to form a map - much like a roadmap of highways and interstates we use in our cars. Once the program has this map (which includes the initial and goal points), the route the robot takes is chosen by a Depth-First Search, which starts at the initial region and works it's way to the goal. Smooth path removes any cycles from the chosen path. Finally the robot navigates along this route, turning mindful of it's maximum turning radius. When the robot encounters a turn that is too sharp, the robot adjusts until the turn can be achieved. Also, while moving along the path the robot "backs up" when it comes to a place in the path that skims to close to an obstacle (which makes the path non-holonomic). This process is repeated until the robot "finishes" the chosen route (encounters the goal region)..

One noticeable problem in our technique is that the path has a tendency to jog a little until we call our SmoothPath routine. We attempted to remove these jogs in our path smoothing technique, but undoubtedly in some cases the jog will remain. In some case, our robot may decide to turn in the wrong direction, causing it to "spin" (which is really a short back and forth motion which allows the robot to reorient itself) until it can "see" its next point on the path. Also, when chosing the number of points and distance, different worlds have different numbers of minimum points and distances.

Overall, the program seems to work fairly effectively. It will, however, fail to navigate through an environment where the passageways are less than twice the radius of the robot. This is because we implemented our collision checker using a "buffer zone" around the obstacles instead of allowing the robot to slide along the edge of a obstacle. Computationally, if the robot must navigate through the same environment multiple times, our program would be very effective. However, if the robot is always changing environments, a lot of wasted processing is done.

Please direct any comments to Tina Troutner or Ben Burnett