Computer Controlled Robotic Car

jadesoreΤεχνίτη Νοημοσύνη και Ρομποτική

13 Νοε 2013 (πριν από 4 χρόνια και 8 μήνες)

102 εμφανίσεις


Computer Controlled Robotic Car

Blue Car Team

Senior Design Final Report

Spring 2003

Faculty Advisor: Dr. Lee Belfore III

Computer Controlled Robotic Car

ECE 486

Ray Boland, Talal Buhamed, Janice Fishburn, Tuan Hoang, Nadeemulla Mahadik

Bryan Robinson, Jason Sheehan and Daniel Vasconcelos

Old Dominion University

College of Engineering & Technology



The senior design project challenges undergraduate engineering students to work
on a large group project that focuses on the devel
opment of a complete system. Our team
designed and constructed an autonomous, computer
controlled, robotic car to enter in the
IEEE Hardware competition. As the result of design concept review and prototype trials,
our final design included: a layered, rou
nd aluminum frame; dual stepper motors; power
source of primary batteries; embedded microcontroller; structured object
program; candle detection circuit; line sensors; ultrasonic sensors; remote indicators (line
sensor indicators); and cup deploym
ent arm. Our design achieved twice the required
speed to run the course, and sound, reliable mechanisms and sensors facilitated the
necessary car functions to successfully extinguish the light emitting diode (LED) candle
in any given room of the model hous
e’s floor plan. Our dynamic team of mechanical,
electrical and computer engineers optimized the allotted time to achieve a balance of cost
versus complexity for a highly competitive car design.


The IEEE Hardware Competition is based on the
creative aspect of electrical and
computer engineering. This competition emphasizes problem solving and engineering
economics. The setting of this competition is designed in the interest of challenging
undergraduate engineers to devise a creative, strategi
c, economic solution to the problem
presented. The students not only perform the necessary tasks but also contend with other
competitors in the same arena. This year, the students were tasked with building a
controlled robot that can navigate the
complete floor plan of a model house.
While maneuvering the model house, the robot must also be able to locate a red Light
Emitting Diode (LED) “candle” that represents a small house fire. Once the candle is
located, the robot must extinguish it by coverin
g the LED candle with a cup. This must be
done in the shortest time possible. This team has set forth to design and build such a
robot, and the approach was to functionally subdivide the overall problem.




Our final
design utilized the Object
Oriented Programmable integrated circuit
(OOPic) version of the programmable integrated circuit (Pic) controller from Savage
Innovations. Our selection of this microcontroller was based on the ease of use and
flexibility. Since w
e did not have a dedicated workstation for software development, a
controller had to be chosen that would allow for portability and platform independence.
The OOPic offered an integrated development environment (IDE) that worked on all the
machines that th
e team tested. The OOPic IDE was very flexible and allowed for
development in BASIC, C and Java syntaxes. The OOPic IDE also used new objects to
represent variables and outputs in the system, rather than traditional integers, Boolean or
other core data typ
es. This microcontroller uses an object to represent digital I/O pins in
the basic logic states. Any pin was manipulated by assigning a ‘1 ‘or a ‘0’ to change the
logic level of that pin. Digital I/O pins can be grouped in an array to act as a data bus.
ere are advanced objects to support proven robotics parts, such as the Devantech sonar
sensor, which our team chose to implement. Overall, the OOPic provided a flexible
development environment, and a programming system with a very simple learning curve.

he Design of the Robot’s Body

The body was designed with the smallest possible footprint to satisfy a need for
maneuverability. Not only were there contest restrictions on the overall dimensions, but
also movement around the track required a nimble design.

With two drive motors, one on
each side, a circular footprint was the best option as depicted in figure 1. The dual motors
allowed the robot to turn directly on its center point. Any shape other than a circular
design would cause a changing radius. This d
esign maximized our usable area and
minimized our chances of touching a wall. To stabilize the design special brackets were
made to hold a ball bearing against the bottom of the chassis. The low friction of the
bearing proved ideal in keeping the robot sta
ble and minimized resistance to motion. The
ball bearing supports had to be custom made due to the unavailability small casters.


To assist with the organization the robot was designed in layers. The power
source, motors, one forward
facing ultrasoni
c sensor and line tracking sensors were
positioned on the bottom layer. The heavy power source was mounted low to maintain a
low center of gravity. If the power source were positioned on a higher layer, a moment
would have resulted when the robot moved, wh
ich would have been detrimental. The
line tracking sensors were fastened to the underside of the bottom layer. The LED sensors
hung down from the next layer to match the height of the candle and optimize sensitivity.
A top view of the bottom layer can be
seen in figure 2.

, Exploded View of Lower Layers

Figure 2, Top View of Bottom Layer


The next layer was dedicated entirely to the motor control boards and power
source feeds. The top layer hosted the arm. This allowed the arm and cup to operate
within a pair of horizontal tracks. As the arm slid forward, the cup was dropp
ed on the
candle. Two ultrasonic sensors were also attached to the bottom of this layer and faced to
the left and right of the robot. The microcontrollers were mounted on vertical plates for
ease of access. A front view of the robot can be seen in figure 3

Figure 3, Forward View of Robot Upper Layers

Initially, the material used for the robot was acrylic. It appeared to be easy to
work with, aesthetically pleasing, and readily available. The first two prototypes were
constructed out of acrylic. However,

acrylic was difficult to accurately machine in the
necessary tolerances. In addition, it had a tendency to break when working too close to
the edge of a piece. The manufacturing team decided that aluminum would be the better
choice, so ODU’s machine shop
was tasked to manufacture the body and wheels of the

The arm has been the most revised system of all. The final design used a trolley
that gripped the cup, which moved along a horizontal track. Prior to deployment, the cup
and trolley were contai
ned within the body of the robot. A motor turned a shaft with a
small gear that turned a larger gear, which is linked to the trolley. The pinned lever
moves the trolley to the deployment position so the cup clears the robot. A side

switch triggered

the trolley to release the cup. After release of the cup, the arm is
retracted within the body of the robot. Figures 4 and 5 illustrate the side and top views of
the arm system.

Figure 4, Side View of the Arm System

Figure 5, Top View of the Arm Syst

The Drive System

The drive system must accurately maneuver the robot and fit within the allotted
space within the robot’s chassis. Likewise, the physical size of the track limited the size
of the overall robot. These size constraints narrowed our choic
es of drive components.

Our research revealed that servomotors and stepper motors are the two dominant methods
for robotic drive systems.

Control systems for servomotors are “real time” and can be complex.
Servomotors rely on a shaft encoder to feedback i
nformation about the position to a
control system. Typically, the control system regulates the drive signal in real time to
maintain the desired speed. Control systems can be simplified by using a dedicated
microcontroller to regulate the motor drive signa
ls in response to the feedback signal.

Stepper motors require a sequence of rectangular pulses applied to the motor’s
coils to control the motion. Stepper motors normally do not use feedback. The motor’s
shaft either responds or not to the pulses applied
to the coils. Therefore, the control
system does not need to be real time. A series of pulses to the coils will result in the
expected motion, provided the stepper motor produces enough torque. We used a
unipolar stepper motor because it only requires a si
ngle ended voltage supply with no
increase in the required switching circuitry. Since the control system for stepper motors is
usually less complex, it consumes less space. Control simplification is why we choose
stepper motors for our design.

A number of

shelf control systems were available for the stepper motors,
but they were relatively expensive. To reduce cost we designed a system that used a four
bit, bi
directional shift register (74LS194) to produce the required sequence of pulses.
These pu
lses drove an array of four power transistors to handle the current that drives the
motor’s coils. The rotational speed of the motor was controlled by the clock frequency
driving the shift register. A 555 timer operating in the astable mode was used to pro
a variable frequency clock that could be controlled by a three bit digital signal from the
microcontroller (initial design). This clock frequency fed into an eight
stage frequency
divider (74LS393) that provided a turn down ratio of 256 to 1. To selec
t a particular
frequency to drive the shift register, an eight
bit multiplexer (74LS151) was used with the
three selection bits. Later, trial runs proved that eight different speeds were not necessary.
Subsequently, we modified the speed control to only us
e two control bits from the
microcontroller (final design), which provided four of the eight possible speeds to control
the stepper motors.


The Power Supply

To satisfy the power needs of our robot three problems had to be overcome. First,
the rules of th
e contest specifically prohibited cables to be attached to the robot. This
implied that the robot’s power supply must be “self contained.” Second, the rules of the
contest required autonomous operation of the robot. This meant that once the robot
started a

trial, human intervention was prohibited during the trial. Therefore, the power
supply must be sufficient to sustain robot operation for the maximum period of a trial (3
minutes). Third, the contest rules specified a maximum physical size for the robot. S
the prototype indicated that space would be at a premium on the robot’s chassis,
emphasis was placed on minimizing the space occupied by all systems.

We decided to use chemical cells (herein referred to as batteries). Batteries fall
into two classif
ications: primary (non
rechargeable) and secondary (rechargeable). We
choose primary batteries due to the advantages of higher energy density, greater
reliability of performance, and international availability. The higher energy density was a
strong factor

in consideration due to the limited space available within the footprint of the
robot. The energy density for primary batteries run at 100 (W
hr/kg) while secondary
batteries has a capacity of 26 to 35 (W
hr/kg). Rechargeable batteries typically have
nished capacity with each recharging. After a number of recharging cycles, the
storage capacity unpredictably diminishes. Fresh primary batteries however are very
predictable in terms of capacity and terminal voltage. Lastly, primary batteries are widely
vailable at common retail outlets as opposed to rechargeable batteries.

Since our robot has both analog and digital components, it was designed with two
independent power supplies. The final energy budget was estimated at 2.0 A @ 15V for
the analog syste
m and 1.0 A @ 9V for the digital systems, which summed to a total
power of 30W. The original length of a trial was a maximum of 5 minutes. To be
conservative, we used a figure of 12 minutes, making our energy budget 6.0 (W
Using the figure of 100 (W
r/kg) as the energy density, this gave us a figure of 60 gm
required. Therefore, we used AA (alkaline, 22 gm each) as our primary battery of choice.
This meant that 14 AA batteries in series will be used for the analog power supply and a
single 9V will be
used for the digital power supply.


The Sensory Components of the Robot

The sensor system consisted of line detectors, three ultrasonic sensors and the
LED detectors. Both the line and the ultrasonic detectors were off
shelf devices,
which were design
ed specifically for robotic design. The line tracking sensor, alias the
Tracker, was manufactured by Lynxmotion. Each Tracker module consisted of three
infrared LED/photodetector pairs and an Schmitt trigger hex inverter. The robot was
designed with two Tr
acker modules in offset positions that allowed for more resolution
and range of line detection. A schematic of the Tracker can be seen in figure 6.

Figure 6, Schematic of Tracker Module

For proximity detection, the robot was designed to use three ult
rasonic sensors.
We used the Range Finder, alias Ranger, which is manufactured by Devantech. These
sensors were mounted on the front, left and right of the robot. The Ranger was chosen
because of its compact size, sensitivity and affordability. A rear vie
w of the Ranger can
be seen in figure 7.

Figure 7, Rear View of Ranger Module


Detection of LED candle was accomplished with three silicon NPN
phototransistors. The LED detectors are used to guide the robot toward the candle. Since
infrared light posed tre
mendous interference for the phototransistors, we mounted the
phototransistors inside opaque square plastic tubing, and mounted a square infrared filter
(removed from an old camcorder) on the front end of each tube. The two front
phototransistors ar
e positioned such that their range of angular detection overlaps by 5
degrees. When the LED candle is seen by both phototransistors, the robot is within 2.5
degrees of a direct heading toward the candle. Therefore, the goal was to keep the candle
in the si
ght of both front
facing detectors. The third phototransistor was mounted
approximately 90 degrees to the left of the front
facing phototransistors. This third sensor
enabled the robot to optimize its search time. Figure 8 is a schematic of the overall LED

detector circuit.

Figure 8, LED Detector Circuit



The objective of a strategy development was to enhance the planning and design
prior to the construction of the robot. According to the rules, the three possible rooms

the candle would be placed were to be announced prior to the competition. Based

on this information our team developed twenty
eight different probabilities for the
navigation of the track. We calculated that the distance traveled to navigate the track was

approximately 7 meters. The velocity of the robot is 5 meters per minute, which is double
the speed needed to cover the track in 3 minutes.

68HC11 Microcontroller

Initially, our team had selected the 68HC11 microcontroller from Motorola. This
oller was chosen for its size, development platform independence, and proven
robustness in the industry. The development platform was a Microsoft Windows
environment with an Imagecraft C compiler. The compiler worked well, but the serial
port connectivity
and EEPROM programming tools, provided by our 68HC11 vendor,
proved to be incompatible from system to system. Therefore, the control was switched to
the OOPic.

The LED Detectors

When testing the LED detectors it became apparent that incandescent and
orescent lighting contained an AC component of 120 hertz. The AC component
interfered with the reliable detection of the candle. We were able to eliminate the
interference by modifying the feedback path of the phototransistor’s amplifying circuitry
a capac
itor in parallel with the resistor, see figure 8.


It was bought to our attention that on past robotic teams the major problems were
mechanical in nature. Ironically, electrical and computer engineers were the primary
focus of this hardware

competition. As a team, we invited mechanical engineering
students to participate in our project. Their contribution has been invaluable toward the
elimination of the many mechanical complexities.

Like most engineering projects, we were presented with
a well
defined problem,
and given limited time and money to solve it. Our method of subdividing the design
problem dedicated one or two people to each major part of the robot. Although this
approach resulted in the completion of the individual tasks, it di
d present

interface/assembly problems. The majority of the time spent on this project was dedicated
to overcoming interfacing problems.


We would like to thank our sponsors
Infinity Design Group, Inc
. and