Ultrasonic Path Planning and
Filtering
16-735 Robotic Motion
Planning
Final Project Report
Sean Hyde
12/19/07
Introduction
For our final
project for motion planning we were required to implement a path planning
algorithm that included a filtering component on an actual robot. As I didn’t have a robot to implement my
project on, I thought it would be fun to build a robot that included dead
reckoning ability (a first for me) and use the ultrasonic sensors I was so
familiar with to do either mapping or path planning.
Physical Design
I designed the robot
in Solidworks based around my tight budget and the
components I already had. A render is
shown below. The robot used servo motors
for drive, 5 ultrasonic sensors (2 SRF04 and 3 PING))) sensors), two quadrature encoders and a PIC 18F4525 microcontroller. The ultrasonic sensors worked very well and I
was generally able to sense obstacles to with +- 1 inch up to a rather
impressive distance.

I machined the parts
and constructed the robot myself.
The main issue with
the design was with the quadrature encoders. The encoder discs were mounted on the wheels
and the sensors were mounted on the robot frame. This meant that there was no rigid connection
between the two. In fact, the wheels,
connected to the output of the servos, would flex as much as half a centimeter
as the robot drove. They were also not
true to the frame and would wobble another half centimeter. This combined variance in the distance
between the encoder and the sensor led to the sensors being essentially useless
as I would lose at least a quarter of a rotation.
Path Planning
Because of the
problems with the encoders, I was unable to do either true dead reckoning or
mapping as I had no good fix on my position.
Instead I opted to do filtered path planning using estimated position
and a correction system based on basic knowledge of the map.
To navigate, the
robot uses a form of the potential planner.
Each of the five sensors can generate a repulsive force at the angle to
which they are mounted on the robot.
These readings are, however, filtered to check against false
positives. The goal also exerts an
attractive force on the robot. The catch
is that this requires the relative positions between the robot and goal be
known. Because the encoders are
non-functional I had to figure my position in a different way. First, the robot estimates its position by
converting the move command to the sensor (known) and a delta time (known) to
an estimated delta position. This
estimation holds up rather well as long as the robot is moving. The large deadband
of the servos breaks down this estimation at low speeds. To help account for this, the robot has a
general knowledge of its environment.
The robot notes the obstacles as it passes them with its two nearly
perpendicular sensors. If these updates
differ from the guessed position by a small amount, the position is
updated. If the difference is too large,
the robot will prefer its estimate to the map-based update.
Software Design
As the
microcontroller was a PIC 18F, I wrote the code in C. I had worked with both ultrasonic sensors and
servos before using a PIC and so this was fairly straightforward. A variable duty PWM signal was used to
generate the servo pulses. Other than
this, the robot followed a relatively straightforward loop. Calculate potential vectors and sum
them. Translate these into desired wheel
velocities. Update the position
estimate. Update the PWM rates.
Overall I was very
impressed with how the PIC performed, especially given the number of floating
point calculations I was asking it to do.
The software-based estimation also performed quite well in getting the
robot to its destination (and knowing when it had accomplished this).
Results
The robot performed
quite well considering its handicaps. It
would successfully complete the maze (success meaning that it arrived at the
destination and stopped) at least two out of three runs. The most important variable to success was
the starting heading. Below is a video
of the robot completing the maze.
Future Work
Although this poor
little incarnation of a robot may be scrapped, I have certainly learned a lot
from the experience that will put toward my next robot. Currently, two different ideas are floating
around my head. The first is a
modification on a balancing robot.
Although I wasn’t able to experiment with Kalman
Filters on this design like I had planned, I am fairly confident that the PIC
processor has the processing power to handle it. My other plan is to resurrect my human
interface robot into something far more advanced, both from a human interface
standpoint as well as from a path planning standpoint. I would like to be able to get the robot to
navigate between waypoints and I think this is a strong step in that direction. I will, however, ensure that the encoders are
shaft encoders placed directly on the
shafts of the motors.