This project addresses the problem of planning a path for a "hovercraft" style robot. The hovercraft robot presents an interesting challenge in path planning because of the difficulty of controlling the robot with a limited number of thrusters. Some work has been done on the hovercraft controllability problem, and it has been shown that a hovercraft style robot with two fixed thrusters (not acting through the center of mass and producing opposite torques) in a friction-free environment is controllable [1]. However, it has also been demonstrated that the two thruster hovercraft is not small-time locally controllable, or in other words you can drive the hovercraft with two thrusters from A to B, but it is not guaranteed that this can be done without having to go significantly out of your way to do it [2].

A traditional method of path planning for the hovercraft robot might consist of planning a collision free path without respect to the dynamics of the system and then attempting to design a controller that follows the path and satisfies the dynamical constraints. An alternative approach to this method is investigated in this project. The configuration of the hovercraft robot is expanded to the state space of the dynamical model, and traditional path planning methods are applied in this modified "configuration" space.

The structure of the robot in this project is a disc with twin forward facing thrusters, oriented along the centerline of the robot. The thrusters are symmetrical with respect to the centerline, producing equal magnitude force but opposing torque (see Figure 1). The thrusters are only allowed to be on or off – they either product no force or full force. The set of possible thruster outputs at any time are {NONE, LEFT, RIGHT, BOTH}. The thrusters also have a minimum firing time, in this case 1/30^th of a second. The hovercraft travels in the 2-D plane, and is acted on by the forces from the thrusters and friction from the environment. Environmental friction is broken into two distinct components, rotational friction and translational friction. Friction is modeled as a force opposing the direction of motion, strictly proportional to the velocity.

The 2-D hovercraft system configuration can be described by the configuration vector q = [x y q ], representing the x-y location in the plane and the current hovercraft orientation. Because the physical model incorporates friction that depends on the current velocity, the state of the system must also incorporate the first derivatives of these variables, resulting in the state vector x = . The state space equations for this system are listed below.

In the above equations, t is the torque delivered by the thrusters, F is the force exerted by the thrusters, B_r and B_t are the rotational and translational friction coefficients respectively, M is the mass of the robot, and R is the radius of the robot.

The state equations for this system cannot be solved analytically, due to the term in the 4^th and 6^th equations that result from integrating the equations for q . The structure of the configuration space and how it will be searched seems to suggest the application of a one-step O.D.E. solver, especially due to the computational efficiency. The classical Runge-Kutta 4^th order method was chosen for this project [3].

The limited set of inputs for this dynamical system makes it difficult to control. One benefit, however, is that the complete set of reachable points in the near future (up to about 10 time steps) can be computed and their fitness evaluated. In addition the controllability difficulties, path planning in the state space doubles the complexity of the problem immediately. The dynamics of the system place tight constraints on the types of transitions that can be made in the configuration space, so traditional randomized roadmap approaches are not likely to work well. Since future states depend on the present position and velocities, it is also unlikely that a nice curve based planner could be derived, such as the Reeds-Shepp based planners. The best method would appear to be a potential field based approach, where the descent algorithm interrogates the four possible future states, and chooses the best action to take at the present time based on this information. However, due to the complex nature of the configuration space choosing a potential function is complicated.

There are also ambiguities that are introduced based on the types of problems that need to be solved. Planning in the state space would give the user the advantage of being able to specify not only the goal configuration (position and orientation), but also the goal velocities. This may be a necessity in some cases, or optional in others. For instance, bringing the robot to a stop in this system is a complex maneuver, due to the highly constrained dynamics. The problem being solved may not need this complexity; it may be sufficient to have the robot reach some position, irrespective of its velocity or even orientation. These additional constraints/freedoms produce an even greater challenge in selecting the potential function.

The path planner implemented in this project is a derivative of the commonly used randomized potential field method. The overall structure of the planner is as follows.

The interesting points in this algorithm occur if the random walks fail to find their way out of a local minima. It is noted that in order to escape some situations, the robot must apply a long sequence of somewhat coordinated actions, as opposed to random wandering. Since there are only four possible input combinations, the planner simulates doing strictly one action for a while, then picking another action and doing it for a while, etc. The planner can evaluate all the possible resulting states 5 to 10 time steps in the future, and select any which have a lower potential. The reason for incorporating this step in the algorithm is because once random walks have failed we must backtrack to find our way out. Backtracking may throw away a significant amount of work that was involved reaching this point. The exhaustive search hopefully prevents us from accidentally throwing this work away because a few random walks failed. Additionally, the random walks presently have a fixed length. The configuration space may be structured such that these walks will not get us out of a potential well. The exhaustive search sacrifices the total randomness of the walks for expanded temporal coverage; by choosing a good step size for the current potential, the exhaustive search can evaluate positions ten to hundreds of times farther in the future than a simple random walk.

If we must backtrack, the Plan algorithm forces a random walk after backtracking. Due to the nature of Descend, a simple descent here would place us exactly in a local minima we had to escape from before. The random walk at this point is intended to get the robot to a different state where it is possible to find other minima, and eventually the goal configuration.

Descend takes advantage of the limited combinations of inputs. Since there are only 4 possible future states from a given configuration, Descend checks each and picks the configuration with the smallest potential.

The random walk algorithm simply picks random thruster inputs and runs the path simulation forwards. The algorithm is not presented but is straightforward.

The ExhaustiveForwardSearch algorithm does a depth first search of paths that are all in length. In order to reduce memory allocation, the algorithm prunes child nodes that were not productive (did not produce a smaller potential than we have already found).

The potential function selection was the most difficult part of the project. Several generations of potentials that attempted to allow the planner to precisely place the robot at specific points in the state space were tried. One difficulty in designing the potential function is the combination of expressions must not only incorporate terms that act as some sort of controller for the robot (to "drive" it close to the desired configuration), but also terms that precisely "drive" the configuration "distance" to zero. In these equations, a balance needs to be struck between getting the robot to the goal quickly but with several configuration parameters nowhere near their goal positions and getting the robot precisely to the goal before the Sun’s nuclear fuel runs out. In order to intelligently drive the robot, some terms of the potential were designed to have shapes like that in Figure 2. In this figure, time axis represents a measure of the time remaining until the goal is reached and the deltav axis represents how far the robot is from its goal velocity. As it can be seen, potentials must be defined that prevent the robot from overshooting its goal velocities.

Other terms that were incorporated into the potential functions were weights for terms that had little bearing when the robot was near/far from the goal. One weight that was tested was the expression (commonly recognized as the Gaussian probability distribution function). This function is plotted in Figure 3. These terms were used to apply emphasis and de-emphasis to potential terms that were significant/insignificant at different distances. For instance, when far from the goal the actual orientation of the robot will most likely need to be pointed towards the goal in the 2-D plane, irrespective of the goal orientation.

While tweaking the potentials used initially could solve some simple planning problems without obstacles, they were extremely poor at solving most problems. In order to simplify the project for the sake of time, exact planning in the state space was discarded for a planner that could drive the robot to various positions in the X-Y plane and not worry about final velocities and orientations. This type of planner is not necessarily without value. This type of potential may be sufficient for a robot which is tasked with destroying a military target or intercepting some sort of evader. The current implementation of the planner uses a potential which directs the robot’s velocity towards the goal position in the X-Y plane, and incorporates a linear distance factor to favor reaching the goal position quickly.

Insufficient time remained at the end of the project to incorporate obstacles into the robot’s world. At this point it is believed that the planner requires tuning of the potential function. Obstacles would likely be incorporated into the potential function by adding a decaying exponential or term based on the robot’s distance to the obstacle in the X-Y plane. It would likely be beneficial to include the velocity of the robot in this calculation, to attempt to head off collisions (and subsequent backtracking to avoid them) before they were to occur.

Because of the difficulty of this problem, one potential area of interest may be in combining the potential field and randomized roadmap approaches. The roadmap approach might bring out paths through the configuration space that the strict potential field planner might miss. In order to overcome the difficulty in connection points in the roadmap, a localized potential field descend might be applied between points in the roadmap. Instead of connecting the "nearest" (in terms of linear distance) points in the configuration space, the potential function approach would want to redefine what the neighborhood of a point in configuration space its. Points that are very close in simple linear distance may be extraordinarily difficult to connect due to the dynamics of the system.

The program written for this project displays the results of the path planner on a Windows 95/Windows NT PC with a 3-D animation of the resulting path. Viewing the output requires a PC with Direct3D installed correctly. At Iowa State University, the PC workstations in Atanasoff hall are capable of running the simulations.

Implementation is based on a simple MFC application, generated by Visual C++. Nigel Thompson’s 3D Plus library [4] is used as a wrapper for the 3-D objects. The application begins initially waiting for the user to enter the initial and goal positions. This is done via the Simulation|"Enter initial/goal" menu item and associated dialog. The user can enter the initial and goal states, however the goal orientation and velocity points will not be used in the path planning.

Once the initial and goal states have been entered, the program will span a child thread to calculate the path. Once the thread has finished planning the path, the program will begin displaying the path. The blue sphere represents the initial position, the green sphere represents the goal position. If the robot moves off the screen the display can be adjusted with the numeric pad cursor keys (scroll right/left, up/down), or can be zoomed in/out with the numeric keypad +/- keys. To redisplay the most recent path plan, select Simulation|Redisplay.

Some example screen shots are given below.