UEzMOW Autonomous Lawnmower

June, 2007



University of Evansville
Team: Mark Randall
Addisu Taddese
Zachariah Fuchs

UEzMOW June, 2007
2


Table of Contents

Introduction ................................................................................................................................................... 4
1. Speed Control Algorithm ...................................................................................................................... 4
1.1 Classical Analog Speed Control ................................................................................................... 4
1.2 Input and Output ........................................................................................................................... 5
1.3 Implementing a Digital Controller ................................................................................................ 6
1.4 Results ........................................................................................................................................... 6
2. High Level Control ..................................................................................................................................... 7
2.1 Farming Algorithm ............................................................................................................................. 8
2.1.1 Waypoint Computation ............................................................................................................... 8
2.1.2 GPS Coordinate Transformation .................................................................................................. 9
2.1.3 Waypoint Navigation ................................................................................................................. 10
2.2 Obstacle Avoidance Algorithm .......................................................................................................... 10
2.3 Safety Interrupt Routines .................................................................................................................. 10
3. Electronics Design ........................................................................................................................... 11
3.1 GPS Selection/Implementation ................................................................................................... 11
3.2 Obstacle detection ...................................................................................................................... 11
3.3 System Design ............................................................................................................................. 12
3.3.1 Hand Shaking........................................................................................................................... 12
3.3.2 Main Processor ....................................................................................................................... 13
3.3.3 Motors ..................................................................................................................................... 13
3.3.4 Preprocessor ........................................................................................................................... 13
UEzMOW June, 2007
3

3.4 Power System ............................................................................................................................. 14
4. Mechanical Specification ................................................................................................................ 14
Conclusion ................................................................................................................................................... 15
Appendix I ................................................................................................................................................... 16
Appendix II .................................................................................................................................................. 17

UEzMOW June, 2007
4

Introduction

The purpose of this project is to design, build, and test an autonomous lawnmower. The
lawnmower should require minimal setup and operate autonomously using GPS for primary
navigation. The robot should efficiently mow a defined area while scanning for potential
obstacles. If an obstacle is detected, the robot should maneuver around and return to the previous
function. A multitude of safety features will be integrated into both the hardware and software to
avoid accidents. The design team consists of Mark Randall as team leader and lead hardware
designer, Zach Fuchs on control development and hardware support, and Addisu Taddese as low
level control development and software development.
1. Speed Control Algorithm

Speed control is a crucial part of the robot. It guides the robot throughout its operation.
Once the desired speed and direction is set based on GPS readings and object avoidance routines,
it is up to the control algorithm make sure the robot is moving at the right speed and direction.
The basic process of implementing algorithm include measuring the speed of the motors,
determining whether they are going at the right speed or not, and finally outputting a value to the
motors to speed them up or slow them down.

1.1 Classical Analog Speed Control

In a mechanical system where automation is desired, a compensation system that controls
or regulates the system to act in the desired behavior is needed. This compensator analyses the
output fed back to it and generates an input signal to the mechanical system or plant based on a
reference point that is set by the user. The following figure illustrates this concept:

Figure 1: Illustration of a mechanical system with a controller. In this figure r is the input, e is the error
signal received through the feedback system, block C is the controller, u is the input to the plant (Motor
System), and y is the output of the system
UEzMOW June, 2007
5

The Proportional Integral Derivative (PID) controller is the most widely used type of controller
today. A well designed PID controller would compensate for both steady state and transient
errors.

The mathematical formula for a PID controller is given by:


Figure 2: PID controller

As can be seen from the equation and Figure 2, the PID controller consists of the Proportional,
Integral and Derivatives acting on the system in parallel. A digital controller can also be used to
imitate a mechanical control system as it is used in this robot.

1.2 Input and Output

To implement the control system in our lawn mower, we need to know what the current
speed of the motor is. This is done by Hall Effect sensor based encoders. A small magnet is
mounted to the output shaft of each motor which activates a Hall Effect sensor attached to a
circuitry that is connected to our main processor. For every revolution, the output from the Hall
Effect sensor would be a square wave with a period of one revolution time. This is used by our
main processor to determine the speed (frequency) of our motors.
UEzMOW June, 2007
6

Moreover, we need to have a mechanism to tell the motors to go at a certain speed. Pulse
width modulation is used to achieve this. Each motor is connected to an H-driver which utilizes
pulse width modulation. A high pulse would tell the motor to go forward and a low pulse to go
backward. Therefore, a 50% duty cycle pulse width would stop the motors, whereas an 80%
duty cycle makes the motors move forward.

1.3 Implementing a Digital Controller

Figure 3: Basic software block diagram for digital speed control system
Digital controllers are gaining popularity these days because of the ability to modify them
as need be by the user. We have implemented a digital PID controller in our lawn mower using
the C language. The basic routine is shown below.

1.4 Results

A plot of the step response of the two motors is shown in Figure 4. This plot was generated
by capturing the speed of the motors through the UART in a delimited data form. MS Excel was
UEzMOW June, 2007
7

then used to plot the graph. From the step response, we can understand that our system has
reached a steady state speed of 4000Hz which is the desired speed. Also it can be seen that the
controller compensated for speed differences between the two motors that occurred due to
different friction forces being applied.

Figure 4: Step response of compensated system


2. High Level Control

As the robot maneuvers through the course, the high level
control algorithm considers a multitude of factors with
varying priorities when determining the next robotic action.
These factors consist of the robots position with respect to
boundaries of the course, the robots desired path, and
potential obstacle blocking this path. As mentioned before,
some factors have priority over others. For example, it is
Figure 5: Algorithm Hierarchy
UEzMOW June, 2007
8

much more important to avoid running someone or something over than maintaining a straight
path. Considering these priorities, the main processing loop contains a hierarchy of control
algorithms, which can be seen in Figure 5.

2.1 Farming Algorithm

The farming algorithm is the default high level controller when no higher priority
algorithms are in effect. This algorithm guides the robot along the quickest path through the
course while providing complete course coverage. In order to accomplish this, a series of
waypoints are calculated prior to the start of the run. The control algorithm then utilizes the GPS
information to determine the current location and the desired path to the next waypoint. After it
arrives at this waypoint, it continues on to the next point until it has completed to course.

2.1.1 Waypoint Computation

As mentioned before, a series of waypoints are loaded into the robot at the beginning of the
competition. These waypoints are calculated using six points that define the boundaries of the
arena. A MATLAB program then calculates a path considering the size of the robot, linear
velocity, and turning velocity. The program breaks the path into a series of waypoints, which are
loaded into the robot. A graph of an example path can be seen in Figure 6. In this picture the blue
lines represent the borders of the course and the red lines represent the desired path of the robot.
In implementation, the GPS coordinates of the corners of the course will be measured at the
actual field and will provide the inputs to the function and the waypoint outputs will be in
relative GPS coordinates.

Figure 6: Example output path
UEzMOW June, 2007
9

2.1.2 GPS Coordinate Transformation

The GPS receiver provides the GPS information in the form of global latitude and
longitude, but this data requires preprocessing before it can be used by the control algorithm. The
position data does not vary much within the range of the arena when compared to range of
possible values. For example, at 45 degree latitude, the length of a degree of latitude is
approximately 69 miles. The small competition arena is dwarfed when compared to this scale.
As a result, much of the information provided by the GPS is unneeded and be thrown out to
decrease the size of the data point. Only the last few bits are necessary for navigating such a
small area.
Also, the control algorithm is based on a relative coordinate system to simplify
calculations. In the path shown above in Figure 6, all movements are constrained to x and y
directions. Unfortunately, the x and y directions of the course will probably not line up with
latitudinal or longitudinal directions of the GPS. Therefore, a rotation function is applied to the
incoming stream of data to transform the global coordinates into a relative coordinate system of
the competition course. The coordinate systems origin is placed at the lower left corner with
respect to the robots starting position. A simulation of this algorithm can be seen in Figure 7.
On the left, a course is outlined in blue with an arbitrary path shown in red. This image utilizes
the global coordinate system. On the right, the same course and path are represented after being
transformed to the robots relative coordinate system.

Figure 7: Example coordinate transformation

UEzMOW June, 2007
10

2.1.3 Waypoint Navigation

Once the global GPS coordinates are truncated and transformed into the relative coordinate
system, they are fed into the waypoint navigation control algorithm. This algorithm adjusts
motor velocities in order to maintain the desired heading towards the next waypoint. Because the
robots movements have been constrained to purely x or y directions, the desired path can be
defined as a line in the x or y direction. The robot must then follow this line to the next way
point. As a result, only one portion of the coordinate, either the relative x or y, need to be
analyzed, which simplifies the control algorithm a great deal. The difference between the desired
coordinate and the actual coordinate provides the input to the control algorithm. The desired
motor velocities are calculated using a PID function for each of the wheels. Once the robot
reaches the desired waypoint, it proceeds to the next waypoint.
2.2 Obstacle Avoidance Algorithm

As the robot performs the farming algorithm, it will eventually encounter at least one
obstacle blocking its path. In preparation for this, the processor will continually monitor five
ultrasonic range sensors looking for upcoming obstacles. When an obstacle is detected, the
controller will switch to an obstacle avoidance routine that maintains a minimum distance from
the obstacle while attempting to follow the previous path. If the robot drives too close to the
obstacle, it will abort its initial path and drive away from the obstacle.


2.3 Safety Interrupt Routines

There are two primary safety interrupts in software. The first function continually verifies
that the robot is still within the borders of the course. If it enters the surrounding safety zone, the
blades are turned off and robots route is altered so that it returns to the main course where the
blades will be turned back on. If the robot ventures too far, software will disable both the blade
motors and drive motors and wait for restart. This function prevents the robot from running out
of control. The second function involves the remote turn off. Although the remote turn off is
hardware controlled, software will also monitor the incoming signal and disable all motors if the
signal changes.


UEzMOW June, 2007
11

3. Electronics Design

The electronics where designed with three main tasks in mind: getting and using GPS data,
implementation of before mentioned speed control algorithms, and obstacle detection/avoidance.
For this we have designed a system based around two ATMEL 8051 processors.
3.1 GPS Selection/Implementation

Before the actual hardware design process could
continue we needed to select an appropriate GPS unit
for the project. This will tell us what types of hardware
we would need to implement to support the GPS. The
selection of the GPS unit was governed by two main
considerations, accuracy and price. After contacting
and talking with many GPS manufactures we decided
on the Trimble BD950. The BD950 boasts a 2cm
accuracy and although it has a retail price of over
$10,000 Trimble sold us them for $2,000 each. The
BD950 can be used in standalone, differential, or Real-Time Kinematic (RTK) modes. To get the
accuracy needed for this application we have chosen to use the GPS unit in RTK mode. This
mode requires that the user not only have a GPS unit on the machine but must also setup a Base
Station from which distance and phase calculations can be done to increase the accuracy of the
GPS. In order for this to work the two GPS units must have five common satellites, and be able
to talk to each other. The specification for the BD950 in RTC low latency mode call for a radio
modem that can transmit standard RS232 data at a baud rate of at least 9600 bps. We have
fulfilled this requirement by using two BlueSMIRF 100 meter Bluetooth wireless serial ports
in a slave/master configuration. Finally we found that the only hardware required to interface
with the BD950 was a standard RS232 serial port, and enough processing power to deal with the
data as it was downloaded.
3.2 Obstacle detection

There are a number of different ways to address this issue, and we
used the following factors to help with our selection: cost, output type,
and environment. These factors lead us to using ultra sonic range
detectors. After testing several different types of ultra sonic devices we
found that the Maxbotix LV-EZ1 had plenty of resolution, was very
easy to use, and was relatively inexpensive. Its small size also made it very easy to install. The
Figure 8: Picture of BD950 GPS Receiver
Figure 9: Picture of
Maxbotix LV-EZ1
UEzMOW June, 2007
12

LV-EZ1 can be interfaced to a microprocessor using, pulse width, analog voltage, or serial
digital output. We have decided that we will use the pulse width output for our purposes on this
project. The LV-EZ1 simply needs a Logic one sent to its RX pin and it will start. After the
distance has been calculated by the device it creates a pulse on its PW pin that is representative
of distance. The distance can be calculated using the scale factor of 147uS per inch. In our final
implementation we have used five of these sensors. The sensors are mounted on a turret on the
top of the robot placed 45 degrees apart. This arrangement gives us 180 degrees of vision
around the robot for detecting objects or obstacles.
3.3 System Design

The system is built around two Atmel 89X51 processors. The main processor being used is
an Atmel AT89c51EDS, the processor was selected because of the teams vast knowledge into
the 8051 architecture, as well as, some of its very unique features. The main processor will be
implementing the control algorithms. This means that it will be using data collected by from the
two motor encoders, bump sensors, preprocessed GPS data, and preprocessed obstacle data to
control the path of the robot. The second process is an Atmel AT89C51ED2, this processor will
be used to preprocess any data received from the GPS, and distance sensors. This processor will
manipulate the data from the devices to make it easier for the main controller to use, thus off
loading some processing time.

Figure 10: Simple system Diagram of multiprocessor configuration.
3.3.1 Hand Shaking

UEzMOW June, 2007
13

The two processors are communicating using the eight bit data buss. In order to have two
way communications several things needed to be setup between the processors. There are two
tri-state transparent latches (74HCT373) sitting on both of the processors busses this allow data
to be sent/received without crashing the buss. The two external interrupts are also being used in
this process to signal data ready/received.
3.3.2 Main Processor

The main processor is responsible for monitoring the safety bump switches, wireless kill
switch, and encoders. The
safety bump switches, and
wireless kill switch are all
logic devices that are simply
connect to a set of I/O pins.
The Encoders are using two
modules of the programmable
counter array (PCA) which
can be used in capture mode
to calculate pulse width.
Lastly the main processor is
responsible for controlling the
motors. The motors are
hooked to the last three
modules of the PCA these modules are setup in pulse width modulation (PWM) mode.
3.3.3 Motors

The drive motors are being driven using two Freescale 33886 five amp h-bridges. These
drivers were selected because of their high current capability and input frequency range (up to 10
kHz). As stated above they are being driven by the microprocessor by a PWM signal. The h-
bridge has been configured so that a 50% duty cycle reflects a dynamic breaking state. This
allows anything over 50% to cause a forward motion, and anything below to cause reverse. This
setup is preferred because when implementing an algorithm it allows the user to use all unsigned
arithmetic.
The cutting motors are being driven directly from the 24V DC power supply via a 24V relay.
The microcontroller is driving an IRF510 mosfet which will charge the coil of the relay. This
will cause the contact on the relay to close turning on the cutting motors.
3.3.4 Preprocessor
Figure 11: Picture of AT89C51ED2 main robot controller PCB. Schematic
found in appendix I.
UEzMOW June, 2007
14


The Second Processor will be used to preprocess data received from the GPS and ultra sonic
sensors. The GPS is connect to the processor via a
standard RS232 port and standard ASCII characters are
transmitted to the processor in a comma separated
fashion. The processor will download the data pars out
what is needed create an 8 bit number representative of
the robots location and download it to the main
processor. This processor will do all calculation
necessary to translate the data from the global
coordinate system to the relative coordinate system.
This processor will also take care of preprocessing any
data from the ultra sonic sensors. The five ultra sonic
sensors will be connected to the processor using the
five channels of the PCA. In addition additional I/O was needed to fire each of the sensors
separately. To correct this problem an output port was added to the I/O buss which can now be
used to start each sensor. The processor will translate the pulse width measurement to inches,
and download this data to the main processor.
3.4 Power System

The robot will have one power source which is made up of two 12 volt (17AH) lead acid
batteries in series this creates one 24 volt power source. The battery charge time on a slow
charge is 20 hours, and four hours on a fast charge. The 24 volt source is used to power all
motors. This 24 volt source is then regulated down to two five volt power supplies that will be
used for the logic power on the computer boards. Besides being regulated one of the five volt
supplies is completely isolated from the 24 volt side of the circuit. This is done using a TDK-
Lambda CC6-2405 isolation chip. The other five volt supply is not isolated from the 24 volt
supply and uses a standard five volt switching regulator. The isolated five volts is important
because it removes and motor noise from the logic power/ground busses. This kind of noise can
corrupt analog data and cause processors to reset. On the PC boards we have used magnetic
isolation chips (ADuM1400) to complete the isolation between our logic outputs and the h-
drivers. The other non-isolated five volt supply is used to power the magnetic isolators and the
logic level side of the h-drivers.
4. Mechanical Specification

The Robot has five 24 volt DC motors three for mowing blades and two for driving the
wheels. The two drive motors are geared down 60 to 1 to allow enough torque to handle small
Figure 12: Picture of AT89C51RD2
Preprocessor PCB . Schematic found in
appendix II
UEzMOW June, 2007
15

hills. The drive motors drive two 10.5 inch knobby tires. The outside dimensions of the mower
are 35 l X26 w X 26 h. The mower has three cutting blades for a total cutting width of 21.
The cutting blades turn at 5800 RPM. The noise level of the robot is between 85 -90 db. The
total cutting time is between 2-3 hours and can cut approximately 5400 square ft per charge.

Conclusion

After months of work a lots of thinking and testing we think that we may have something
that will work. All of our sub systems have been tested and most of our algorithms have been
simulated, but we are yet to put it all together and test it out. We are very excited as we hope to
see it cut grass for the first time next week. We are also very excited to see what the other teams
have come up with. We hope that the next 15 days will be very productive and that we will have
a robot that our team and the University of Evansville will be proud to enter.






UEzMOW June, 2007
16


Appendix I

UEzMOW June, 2007
17


Appendix II