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.

 

 
Adblock

 

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.