ECE 477 Final Report  Spring 2013
Team 7  COST Robot
From left to right: (back) Eric Osborne, Bryan Dallas, Andrew Loveless,
(front) Caroline Trippel
Team Members:
#1: __Eric Osborne_______________
Signature: ____________________ Date: _________
#2: __Bryan Dallas_______________
Signature: ____________________ Date: _________
#3: __Andrew Loveless___________
Signature: ____________________ Date: _________
#4: __Caroline Trippel____________
Signature: ____________________ Date: _________
CRITERION
Technical content
Design documentation
Technical writing style
Contributions
Editing
Comments:
SCORE
0
0
0
0
0
1
1
1
1
1
2
2
2
2
2
3
3
3
3
3
4
4
4
4
4
5
5
5
5
5
6
6
6
6
6
MPY
7
7
7
7
7
8
8
8
8
8
9
9
9
9
9
10
10
10
10
10
3
3
2
1
1
TOTAL
PTS
ECE 477 Final Report
Spring 2013
Table of Contents
Table of Contents ............................................................................................................................ ii
Abstract ........................................................................................................................................... 1
1.0 Project Overview and Block Diagram ................................................................................. 1
2.0 Team Success Criteria and Fulfillment ................................................................................ 3
3.0 Constraint Analysis and Component Selection.................................................................... 3
3.1 Introduction ...................................................................................................................... 3
3.2 Design Constraint Analysis .............................................................................................. 4
3.2.1 Computation Requirements ...................................................................................... 4
3.2.2 Interface Requirements ............................................................................................. 4
3.2.3 On-Chip Peripheral Requirements ............................................................................ 5
3.2.4 Off-Chip Peripheral Requirements ........................................................................... 5
3.2.5 Power Constraints ..................................................................................................... 5
3.2.6 Packaging Constraints ............................................................................................... 5
3.2.7 Cost Constraints ........................................................................................................ 6
3.3 Component Selection Rationale ....................................................................................... 6
3.4 Summary .......................................................................................................................... 6
4.0 Patent Liability Analysis ...................................................................................................... 7
4.1 Introduction ...................................................................................................................... 7
4.2 Results of Patent and Product Search ............................................................................... 8
4.2.1 Autonomous navigation system and method (7,587,260) ........................................ 8
4.2.2 Method and apparatus for avoiding obstacles by a robot (5,570,285) ...................... 9
4.2.3 Mapped robot system (6,667,592) ............................................................................ 9
4.3 Analysis of Patent Liability ............................................................................................ 10
4.3.1 Autonomous navigation system and method (7,587,260) ...................................... 10
4.3.2 Method and apparatus for avoiding obstacles by a robot (5,570,285) .................... 10
4.3.3 Mapped robot system (6,667,592) .......................................................................... 11
4.4 Action Recommended .................................................................................................... 11
4.5 Summary ........................................................................................................................ 12
5.0 Reliability and Safety Analysis .......................................................................................... 12
5.1 Introduction .................................................................................................................... 12
5.2 Reliability Analysis ........................................................................................................ 12
5.3 Failure Mode, Effects, and Criticality Analysis (FMECA) ........................................... 16
5.4 Summary ........................................................................................................................ 16
6.0 Ethical and Environmental Impact Analysis...................................................................... 17
6.1 Introduction .................................................................................................................... 17
6.2 Environmental Impact Analysis ..................................................................................... 17
6.3 Ethical Challenges .......................................................................................................... 18
6.4 Summary ........................................................................................................................ 20
7.0 Packaging Design Considerations...................................................................................... 20
-ii-
ECE 477 Final Report
Spring 2013
7.1 Introduction .................................................................................................................... 20
7.2 Commercial Product Packaging ..................................................................................... 20
7.2.1 Clocky Robotic Arm ............................................................................................... 21
7.2.2 iRobot Scooba 230 Floor Washing Robot .............................................................. 22
7.3 Project Packaging Specifications ................................................................................... 23
7.4 PCB Footprint Layout .................................................................................................... 23
7.5 Summary ........................................................................................................................ 24
8.0 Schematic Design Considerations...................................................................................... 24
8.1 Introduction .................................................................................................................... 24
8.2 Theory of Operation ....................................................................................................... 25
8.3 Hardware Design Narrative ............................................................................................ 26
8.4 Summary ........................................................................................................................ 27
9.0 PCB Layout Design Considerations .................................................................................. 27
9.1 Introduction .................................................................................................................... 27
9.2 PCB Layout Design Considerations - Overall ............................................................... 27
9.3 PCB Layout Design Considerations - Microcontroller .................................................. 28
9.4 PCB Layout Design Considerations - Power Supply ..................................................... 29
9.5 Summary ........................................................................................................................ 29
10.0 Software Design Considerations ........................................................................................ 30
10.1
Introduction ................................................................................................................ 30
10.2
Software Design Considerations ................................................................................ 30
10.3
Software Design Narrative ......................................................................................... 32
10.4
Summary..................................................................................................................... 34
11.0 Version 2 Changes ............................................................................................................. 34
12.0 Summary and Conclusions ................................................................................................ 35
13.0 References .......................................................................................................................... 36
Appendix A: Individual Contributions ..................................................................................... A-1
A.1 Contributions of Eric Osborne: .................................................................................... A-1
A.2 Contributions of Bryan Dallas: .................................................................................... A-2
A.3 Contributions of Andrew Loveless: ............................................................................. A-4
A.4 Contributions of Caroline Trippel: ............................................................................... A-5
Appendix B: Packaging ............................................................................................................ B-1
Appendix C: Schematic ............................................................................................................ C-1
Appendix D: PCB Layout Top and Bottom Copper ................................................................ D-1
Appendix E: Parts List Spreadsheet ..........................................................................................E-1
Appendix F: FMECA Worksheet .............................................................................................. F-1
-iii-
ECE 477 Final Report
Spring 2013
Abstract
The COST Robot (Cartographic Order Specific Task Robot) is a small, compact robot
capable of fully traversing and mapping a maze. In addition, this design serves as a proof of
concept for a robot whose purpose is to perform various tasks located throughout a maze. The
robot will use the self-generated map of the maze to revisit specific locations marked by colored
LEDs in a predetermined, user-specified order. The robot will be equipped with three types of
sensors: three short-range sensors for hit detection, a long-range sensor for to-scale mapping, and
a color sensor to locate lights.
1.0 Project Overview and Block Diagram
The COST Robot utilizes three types of sensors to intelligently traverse and map a maze.
It has an 8-bit microcontroller running at 8 MHz to effectively complete maze traversal
algorithms. A 7.4 volt Li-Ion battery, mounted to the bottom layer of the chassis, supplies power
to the motors via an h-bridge, and supplies power to the rest of the components after being
regulated by a 5 volt low-dropout linear regulator. Although the motors are powered directly
from 7.4 volt, the microcontroller uses pulse-width modulation to control motor speed.
During maze traversal, the robot will utilize analog to digital conversion to sample three
types of sensors: three short range sensors, one long range sensor, and one colored light sensor.
The COST Robot uses the 4cm to 40cm short range sensors as feedback to straighten its path
through a hallway and detect when it has reached a node. The 20cm to 150cm long range sensor
is utilized to detect lengths of hallways as well as straighten the robot after turning to go down a
hallway. The RGB color sensor samples each channel during maze traversal to detect colored
light nodes.
Upon turning on the robot, the “Enter” and “Cycle” pushbuttons are used to indicate how
many colored lights the robot needs to revisit after traversing the maze and the order to revisit
those lights. The red, green, and blue LEDs are controlled through the microcontroller to indicate
when the robot has revisited the lights specified through the user startup.
After completing maze traversal, the user has the option of connecting the robot to a
computer via USB to download the mapped maze in a graphical user interface.
-1-
ECE 477 Final Report
Spring 2013
Figure 1-1: Block Diagram
Figure 1-2: The COST Robot Final Design
-2-
ECE 477 Final Report
Spring 2013
2.0 Team Success Criteria and Fulfillment
1. An ability to detect proximity to maze walls and prevent wall collisions.
2. An ability to find specific locations in the maze based on the placement of colored
lights.
3. An ability to turn and change direction of movement.
4. An ability to generate an ASCII representation of the explored maze.
5. An ability to transfer stored ASCII map to a GUI program on a computer via USB.
The COST Robot successfully completes the criteria of detecting maze walls to prevent
collisions, finding colored light locations within a maze, turning to change direction of
movement, generating a representation of the explored maze, and transferring the maze to a GUI
on a computer via USB.
3.0 Constraint Analysis and Component Selection
3.1 Introduction
The COST Robot is a robot that will traverse a maze, construct a map of the said maze,
and “remember” the locations of specific locations in the maze marked by colored lights. Once
finished mapping the maze, the robot will then re-visit the locations of these colored lights in a
user-specified order. This robot design serves as a proof of concept for a robot with added
capabilities that could perform order specific tasks at these light locations. The robot will be
controlled by an on/off/select pushbutton and one cycle button. The on/off/select pushbutton will
be used to initiate maze mapping, halt maze mapping, and “lock in” an order for task completion
(order in which to visit colored lights). The other button will be used to cycle through colored
LEDs on the robot body so that the user can chose the order in which the robot will complete
tasks. The order in which the lights are turned on will correspond to desired task order. When the
robot is traversing the maze, it will need a means by which to detect the lights (locations) placed
throughout the maze on the inside surface on maze walls. It need to sense walls on its right and
left as well as directly in front it to avoid collisions (relatively short-range). Furthermore, it
should be able to detect long-range distances for accurate mapping and full maze traversal. All
the while, the robot will also be keeping track of the locations where it has found the colored
lights. With respect to the robot body, we will a base, motor, wheels, etc. A few constraints
which immediately present themselves are power consumption, location awareness, and color
awareness. The constraints are better understood within the context of this design’s Project
Specific Success Criteria:
-3-
ECE 477 Final Report
Spring 2013
1. An ability to detect proximity to maze walls and prevent wall collisions.
2. An ability to find specific locations in the maze based on the placement of colored lights.
3. An ability to turn and change direction of movement.
4. An ability to generate an ASCII representation of the explored maze.
5. An ability to transfer stored ASCII map to a GUI program on a computer via USB.
3.2 Design Constraint Analysis
This design will require a fast sampling rate from multiple ports. In addition, it will need
to interface with many analog and digital off-chip peripherals. As a result, we will have a great
on-chip peripheral need for analog to digital ports, as well as ports for PWM to modulate the
motor speed. Based on all of these constraints in conjunction with the necessary portability of the
device, it is clear that power consumption will be an important factor. Packaging is also an
important consideration, as the size of the robot should be small for ease of maze navigation.
With all of these physical constraints, this project is meant to have a limited budget and the cost
should be kept at a minimum.
3.2.1 Computation Requirements
Our device will be constantly monitoring various measurements acquired from different
devices and performing various computations based on those measurements. Some
measurements that will need to be continuously monitored are those coming from the short range
sensors on the front and sides of the robot. These measurements will be crucial for determining
whether or not the robot is danger of a collision with a maze wall. Running concurrently with the
short range sensors, will be the color light sensor to determine if an LED location has been
reached. Also, the robot will utilize measurements from a long range distance sensor at each
maze node to determine its distance away from the furthest wall straight in front of it. These high
accuracy, long-range measurements will allow the robot to create an accurate map of the maze.
The sensor’s measurements will be converted to digital numbers when keeping track of maze
dimensions. In order to facilitate movement of the robot, two motors, each controlling one of two
wheels, will be used with the aid of two PWM channels. Motor control via PWM channels will
involve constant calculations to ensure that the starting and stopping of robot movement will be
smooth and efficient. The last major calculation requirement of the robot will be to
“intelligently” determine the paths to take to each light/location when performing the orderspecific tasks at the end of its operation.
3.2.2 Interface Requirements
The operating voltage of the microcontroller is 5V. A 7.4V battery will be used to drive
two DC motors and will then be regulated down to 5V to accommodate the microcontroller. In
addition, all components, with the exception of the motors, have operating voltages of 5V and
-4-
ECE 477 Final Report
Spring 2013
will also use this regulated voltage. The general-purpose I/O pins on our device will be utilized
by two pushbuttons, four h-bridge inputs, one RGB light (requiring three pins), and three LEDs.
This amounts to a total of 12 I/O pins in order to implement this design. Since 12 I/O pins is
relatively common for most microcontrollers, we will not be considering any PLDs to expand
I/O capability. Since pushbuttons are considered high or low relative to the microcontroller
VCC, there are no voltage or current constraints for those. However, the RGB lights have a
forward voltage drop of 2V and require 20 mA of current through them. The 4 h-bridge inputs
will be used to control the direction of each motor. Each motor requires two pins to control its
direction.
3.2.3 On-Chip Peripheral Requirements
One of the most significant on-chip peripheral requirements for this design is the amount
of ATD channels needed with decent resolution. Under this requirement, we will need a total of
seven 10-bit ATD channels (three for the short range sensors, one for the long range sensor, and
three for the RBG color). In order to effectively sample each of our sensors, we will also need at
least two output compare timer channels. As we are driving two motors, we will need at least
two channels of PWM. High resolution is not needed so we will use two channels of 8-bit PWM.
Another peripheral requirement includes the four pins needed for SPI which is necessary to
interface with an SD card to allow transfer of map data to a computer at the conclusion of the
run.
3.2.4 Off-Chip Peripheral Requirements
We will not be using any off-chip peripherals for our robot.
3.2.5 Power Constraints
Our device needs to be mobile. In order to compensate for this, the robot needs run on an
easily rechargeable battery. Since there are many sensors on the robot as well as two drive
motors, the battery will be required to have a decent amount of mAh. The motors require about
0.2 mA of current, resulting in about 200 mA. However, as the robot will require precise turns
and accurate movement, it is best to not run the robot until the battery has been drained
completely. Furthermore, the battery cannot be too large or heavy since we want to keep the
robot compact and light. Power regulation will be needed in two parts of the circuit. We plan on
using a 9V source which will then be regulated to 7V for dc motors and 5V for ICs and the
microcontroller. We should be able to keep low voltage swings within our PCB, and regulators
will most likely not need heat sinks. The packaging of our robot will be fairly open and heat
traps are not anticipated.
3.2.6 Packaging Constraints
Our device needs to be relatively compact compared to the size of the maze. In order to
navigate the maze and make precise turns, the robot needs to needs to have a diameter smaller
-5-
ECE 477 Final Report
Spring 2013
than that of the width of a path in the maze. To make a complex maze, it is necessary to have as
narrow of pathways as possible. In addition, the sensor used for wall detection, has a detection
range of 0 cm to 10 cm. This is approximately equivalent to a range of 0 in to 4 in. The robot
must be designed such that all sensors, if at their furthest distance from their designated wall, are
no more than 4 inches away from that wall. Furthermore, the mass of packaging must be kept at
a minimum so as not to exceed the load capacity of the wheel motors.
3.2.7 Cost Constraints
This robot can ultimately be used for mapping out an area and performing specific tasks
within that area in a user-specified order. One such product that currently exists on the marker is
a robotic vacuum cleaner. This product does not generate a map nor does it perform multiple
order-specific tasks; however, it shares the room navigation and hit detection aspects of the
COST robot. With far fewer features and functionality, this robot sells for around $240 [1]. The
estimated cost of our more sophisticated product is about $300, which is reasonable given the
added features of mapping and task performance.
3.3 Component Selection Rationale
For this design, we initially considered two different microcontrollers: the Microchip
PIC18F4550 [2] and the Texas Instruments TMS320F28069 [3]. The PIC microcontroller has 16
10-bit analog to digital converter pins, while the TMS has 12 12-bit analog to digital channels.
Since 10 bits is a sufficient resolution for our design, this feature of the TSM chip is
unnecessary. Next, the PIC has two PWM channels while the TSM microcontroller has 17. Only
two are necessary for this robot so the extra 15 on the TSM micro would be left unused. In
regards to general input/output pins, both the PIC and the TSM have the same amount. Both
microcontrollers have USB capability and four timers. However, while the PIC has three 16-bit
timers and one 8-bit timer, the TSM has four 32-bit timers, which are unnecessary for our
purposes. The TSM drives a pin high with a voltage of 3.3 volts while the PIC has an output
range of two volts to five volts depending on the input supply voltages. Since the peripherals
used in this design requires a five volt logic and supply voltage, the PIC is preferred over the
TSM. Additionally, the motor used for robot movement requires a minimum voltage of seven
volts. The PIC microcontroller runs at eight megahertz while the TSM runs at 20 megahertz. For
our purposes, the extremely high clock speed of the TSM is unnecessary. Based on these metrics
and comparisons we conclude that the PIC18F4550 would best suit our COST Robot design.
3.4 Summary
The overall purpose of this project is to design and construct a robot whose purpose is to
traverse a maze, construct an accurate map of the maze, and perform user-defined, order-specific
tasks. In doing this, we will need to meet several success criteria. Our robot will demonstrate an
-6-
ECE 477 Final Report
Spring 2013
ability to detect proximity to maze walls and prevent wall collisions, an ability to find specific
locations in the maze based on the placement of colored lights, an ability to turn and change
direction of movement, an ability to generate an ASCII representation of the explored maze, and
an ability to transfer stored ASCII map to a GUI program on a desktop computer via USB. This
design will take advantage of fast sampling rates and many analog and digital off-chip
peripherals. It will therefore require many analog to digital ports, as well as ports for PWM to
modulate the motor speed. In regards to calculations, our device will be constantly running
calculations on data gathered from various peripheral devices. The results of these calculations
will aid in hit detection, light detection, maze traversal, and task performance. In addition, the
PWM will be a constant calculation in regards to motor control. Our device needs to be mobile.
In order to compensate for this need, the robot needs to be battery powered with an easily
rechargeable battery. Since there are many sensors on the robot as well as two drive motors, the
battery needs to have a decent amount of mAh. It also cannot be too large or heavy since we
want to keep the robot compact and light. Our device needs to be relatively compact compared to
the size of the maze, and the mass of packaging must be kept at a minimum so as not to exceed
the load capacity of the wheel motors. After analyzing our needs regards to peripherals and other
design constraints we compared and contrasted the features of two microcontrollers: the
Microchip PIC18F4550 and the Texas Instruments TMS320F28069. While some features were
similar or equivalent, we found that the TMS microcontroller contains many unused features or
features unnecessary to our design, coming to the conclusion that the PIC18F4550 would be best
for the design and construction of the COST Robot.
4.0 Patent Liability Analysis
4.1 Introduction
The purpose of this project is to design a small robot to completely traverse a maze before
returning to the maze entrance. The robot will store the configuration of the maze, along with
the location of various colored LEDs along the maze walls. The robot will then revisit these
lights in a predetermined order entered by the user. Upon completion of this task, the robot will
again return to the starting location where it can be retrieved. The user will be able access a
graphical representation of the maze by connecting the robot to a Windows PC with a USB
cable. Because improvement in the area of robotics is mostly considered the domain of research
departments in private labs and universities, there exist relatively few construction and hardware
patents with claims overlapping the physical design elements of the COST Robot. Because of
the overall simplicity of the robot’s behavior, however, many patents on robot operation seem
potentially infringed upon by the COST Robot project. The areas where patent infringement are
most likely to occur are on methods and algorithms used for obstacle detection and avoidance,
along with routines for recording features of the environment from the robot’s perspective.
These were the areas I concentrated my patent search and analysis.
-7-
ECE 477 Final Report
Spring 2013
4.2 Results of Patent and Product Search
The main functions performed by the COST robot will be obstacle/wall avoidance and
environment mapping. Searching for patents regarding methods for these operations yielded
three significant results. A brief description of each patent is included below. It is important to
note that functions such as color light detection and distance measurement are not at risk of
patent infringement since they rely on prebuilt standalone modules – namely the SparkFun
HDJD-S822 light detector and GP2 series distance sensors. The Tremaux algorithm, the maze
solving method used in the project, is also not patented.
4.2.1 Autonomous navigation system and method (7,587,260)
The first patent was filed by David Bruemmer and Douglas Few on July 5, 2006. The
property right to the patent is owned by Battelle Energy Alliance, the world’s largest nonprofit
research and development organization [4]. The patent describes a method allowing a robot
platform to avoid obstacles when in motion. In the patent, a robot platform is defined as
including preceptors, locomotors, and a system controller. The routines in the patent comprise a
simple framework of autonomous robot navigation, easily ported to a wide range of robot
platforms and configurations. The method is most easily used in an event timed loop, where in
each loop iteration the value from each of several distance sensors surrounding the robot is
considered. An event horizon is defined as a distance from the robot in which, if an obstacle is
detected, the robot will react to avoid a collision. The event horizon is a variable distance,
defined by the velocity of the robot. If an event horizon intrusion occurs, the robot turning speed
and velocity are reduced by a proportion of the distance to the detected object [5].
Key Claims (summarized):
1) A method for autonomous robot navigation where, in each iteration of a loop, an event
horizon is defined and the distances to surrounding obstacles are measured and checked
for intrusion. If event horizon intrusion is detected, rotational and translational velocity
are reduced by a proportion of the distance to the nearest detected obstacle. If no
intrusion is found, the translational velocity remains at a constant fraction of a
predetermined maximum speed.
4) If an object obstructs the robot’s forward motion, the robot’s translational velocity is set
to zero (stopping) and both lateral sides are checked for blockage. If either side is
unobstructed, the robot will turn and continue in that direction. If both sides are
unblocked, the robot will turn towards and continue in the direction where obstruction is
furthest away.
-8-
ECE 477 Final Report
Spring 2013
4.2.2 Method and apparatus for avoiding obstacles by a robot
(5,570,285)
The second patent was filed by Shunichi Asaka and Shigeki Ishikawa on September 14,
1994. The patent describes a method for steering and adjusting a robot’s velocity in order to
reach a destination without colliding with an obstacle. The method uses the measured distance
from obstacles on all sides of the robot to avoid both stationary obstructions and evade
unexpectedly moving objects. These distance measurements are used as input parameters to
three separate functions - corresponding to steering angle, velocity, and danger level
respectively. The output from these functions indicates the robot heading and speed necessary
for collision avoidance, along with a value quantifying the urgency the evasive maneuver [6].
Key Claims (summarized):
1) A method for determining a robot’s steering angle and velocity based on the distance to
obstacles surrounding the robot. Each measured distance is used as an input parameter to
three separate functions. The output of one function indicates the new robot steering
angle, and the output from the second indicates the updated robot velocity. The output
from the third function indicates the priority in which the maneuver must be completed in
order to avoid a collision.
2) Changes in measured distances to obstacles over time are used as additional parameters
to the function calculating the danger level.
4.2.3 Mapped robot system (6,667,592)
The final patent was filed by Stephen Jacobs, James Goodnow, David Knuth, Charles
Ward, and Allen Bancroft on August 13, 2001. The property right to the patent is owned by
Intellibot Robotics, a leading manufacturer of automated robotic cleaning systems [7]. The
patent describes a method of commanding a robot to perform a localized task in a designated
area. The robot accesses a stored map of the area layout, referencing it in order to navigate to
the intended target location where a task will be performed. The robot is also capable of
updating the map as the boundary of the area is changed or obstacles are encountered. The
method is meant for integration into a cleaning robot platform, where a localized task would be
defined as cleaning the specified position [8].
Key Claims (summarized):
1) A method comprised of steps for commanding the robot to perform a localized task
within a general area. The robot references a stored map, navigating to the specified task
location while monitoring its position on the map.
14) The robot wirelessly communicates with an operator. The operator sends commands to
the robot specifying the destination location and task to be performed.
-9-
ECE 477 Final Report
Spring 2013
4.3 Analysis of Patent Liability
The obstacle/wall avoidance and environment mapping functions of the COST Robot are
susceptible to possible patent infringement. I outline the details of this infringement for each of
the patents described above in the space below.
4.3.1 Autonomous navigation system and method (7,587,260)
The first claim is a method for navigating a robot, using an array of distance sensors for
obstacle detection. Though the COST Robot project also uses distance sensors for the same
purpose, this is not in itself a breach of the patent. The method outlined in the patent uses a
variable threshold distance, dependent on the robot velocity, to determine when to perform an
obstacle avoidance maneuver. The COST Robot performs the same function, but uses a fixed
threshold distance. Furthermore, the method outlined in the claim specifies that the robot’s
translational and rotational velocity is changed as the proximity to nearby obstacles fluctuates.
The COST Robot, however, moves at a constant speed within the maze.
The fourth claim specifies that if the robot’s forward motion is blocked, the robot stops and
checks whether either of the lateral sides is obstructed. If either path is available, the robot turns
and continues in that direction. If both sides are unblocked, the robot measures the distance to an
obstacle on each side, turning to the direction with the most space available. The COST Robot
stops at all nodes within the maze being traversed, where a node is defined as any intersection of
two paths, or a completely obstructed path (dead end). The robot chooses what direction to turn
according to the Tremaux maze solving algorithm. This is far removed from the simple
decision-making procedure outlined in the patent.
Ultimately, while the COST Robot must avoid obstacles in order to operate properly, its
function, maze traversal, is not substantially the same as that outlined in the patent. Also,
because of the patent method’s substantially simpler decision-making routine, object avoidance
is not performed in substantially the same way. The COST Robot does not sufficiently satisfy
the requirements for doctrine of equivalents infringement.
4.3.2 Method and apparatus for avoiding obstacles by a robot
(5,570,285)
The first claim specifies a method for a robot to avoid both static and dynamic obstacles as
it travels along a path. It uses the measured distance from objects in all directions as input
parameters to three functions. The first two functions output values pertaining to the steering
angle and velocity needed to avoid collision with nearby objects. The third function generates a
danger level value, indicating the urgency of the maneuver. The COST Robot considers distance
sensor outputs sequentially, basing adjustment decisions on only one sensor at a time. It has no
functions for quantifying aggregate obstacle proximity, and the robot moves at a constant speed
within the maze. Also, steering angle is determined by the onboard timer and short range sensor
-10-
ECE 477 Final Report
Spring 2013
readings only. Lastly, the COST Robot has no ability to decipher maneuver urgency, a key
aspect of the claim in the patent.
The second claim specifies that the danger level function mentioned above uses the
changes in proximity over time to obstacles detected as additional inputs. Since the COST Robot
has no function indicating movement urgency, and has no ability to consider the change in sensor
outputs over time, the claim has no overlap with the COST Robot project.
The COST robot must keep from hitting walls inside the maze, but it does so by simply
checking each distance sensor sequentially for obstruction. It has no method for considering all
sensor measurements at once, ultimately avoiding obstacles in a significantly different way than
is outlined in the patent. There is no basis for infringement of any kind.
4.3.3 Mapped robot system (6,667,592)
The first claim outlines a method for commanding a robot to perform a task in a specific
area of a stored map. The robot references the map in order to travel to the chosen destination.
The COST Robot, however, has no information about the maze when traversal begins. A
dynamic map is built based upon node locations found within the maze. The COST Robot
explores the maze according to the Tremaux maze solving algorithm. These key differences
greatly distinguish its operation from the method described in the claim.
The fourteenth claim states that a constant wireless connection exists between the robot and
an operator. The operator can send commands to perform a task at any location within the
robot’s known stored area. The COST Robot has no interaction with an operator after maze
traversal begins. The only user input to the robot is the order in which to revisit lights in the
maze. Once traversal starts, this cannot be changed.
The COST robot performs a significantly different function than that outlined in the patent.
It initially has no information about that maze, and has no wireless communication ability. The
patent ultimately applies very little to the COST Robot project, and there is no basis for
infringement.
4.4 Action Recommended
No cases of patent infringement were found during the patent search and analysis. This
does not mean, however, that zero instances of patent infringement exist. Though there are few
patents on the physical design of small robot systems, many patents on robot behavior and
obstacle avoidance are active. Since the team has no intention of commercializing the COST
Robot, patent infringement is not of paramount concern. However, the aspects of the COST
Robot project most susceptible to accidental infringement are its methods for maze traversal and
collision avoidance. Many patents on similar methods exist and they would be heavily
scrutinized if the COST Robot was to become a commercial product. If patent infringement was
found to exist, the responsible method would be changed so it no longer performs its function in
-11-
ECE 477 Final Report
Spring 2013
“substantially the same way.” If adjusting the method used was not a possibility, and the project
was able to operate properly in its absence, the infringing method would be removed. If the
infringing functionality was necessary to the COST Robot’s operation, the team would attempt to
license the offending method.
4.5 Summary
Because progress in the area of robotics is mostly made in research settings, there exist
relatively few patents with claims applying to the COST Robot project. Though many patents
exist on methods for robot obstacle avoidance, no active patents were found to be infringed
upon. Because the COST Robot is not intended as a commercial product, investigating potential
patent infringement is not of great concern. Still, methods for robot movement are patented
often and the COST Robot could potentially infringe on one in the future. If a case of
infringement is found, the offending method will be replaced with a “novel, useful, and nonobvious” routine. This will eliminate the infringement.
5.0 Reliability and Safety Analysis
5.1 Introduction
The COST Robot will traverse a maze and create a digital map of that maze. When it has
finished creating a map of the maze, previous user input will be used to direct the robot to visit
colored lights throughout the maze in a specified order. At the end of these tasks the robot will
be able to hook up to a computer via a USB port and a maze will be transferred to a PC program
which will interpret and show the maze to the user. All of these things must work reliably for the
robot to be useful to the user. The power supply will be the most critical part, because the robot
is mobile if the power circuitry fails the robot will be rendered useless. Along with this the
microcontroller and oscillator will become major parts as they allow the robot to run given that
power is supplied. Finally, the H-bridge is very important as it allows the robot to move as is
necessary for many of the functions the robot performs. Each part of the robot is essential to
some kind of task, but these parts will hinder the robot the most from completing the task. Along
with this in mind these parts can be the most harmful to the user in a failure, because the robot
may move erratically if the motor control is compromised. Also, the power supply is a dangerous
part of any design. With the wrong setup or a broken part, high current could flow where it
should not and harm the user, by heat or some other method.
5.2 Reliability Analysis
Reliability is an important factor for any product, consumer or otherwise. Reliability can be
measured from the reliability of the parts. The parts analyzed below using the MIL-Hdbk-217f
-12-
ECE 477 Final Report
Spring 2013
[9] are the parts that are most likely to fail. These parts were picked because of the fact they have
high complexity to manufacture or because of their high operating temperature. The PIC18F4550
Microcontroller [10] was picked because of its high complexity, with the 44 pins and the fact it is
an 8 bit microprocessor. The MIC29150 Low Dropout Regulator [11] and the TI L293
Quadruple Half-H Driver [12] were picked because of their higher operating temperatures.
Finally, the CTS CB3 HCMOS/TTL Clock Oscillator [13] was picked not because of complexity
nor operating temperature, but because oscillators are commonly accepted as sources of failure.
However, after further analysis, the calculations showed that this was the most reliable part.
PIC18F4550 Microcontroller [10]
Model Equation: 𝛌𝑷 = (𝑪𝟏 𝝅𝑻 + 𝑪𝟐 𝝅𝑬)𝝅𝑸 𝝅𝑳
Parameter name
Description
Value
Comments
C1
Die complexity failure
rate
.14
πT
Temperature factor
.98
C2
Package failure rate
.016676
πE
Environment factor
4
πQ
Quality factor
10
πL
Learning factor
1
Based on the MIL-Hdbk217f [9] for 8 bit
microcontrollers
Assuming a worst case
junction temperature of 85C
based on worst operating
temp of microcontroller
Based on equation from
MIL-Hnbk-217f page 5-14
[9] for SMT with 44 pins
Handbooks value for
mobile devices
Assumed from the notes
that this is the value to use,
most likely the value is too
large
Number used for devices
older than 2 years in
production
λP
Failure rate per 10^6 2.039032
hours
Mean Time To Failure 490428.7917
MTTF
MIC29150 Low Dropout Regulator [11]
-13-
Approximately 55 years to
a failure for one device
ECE 477 Final Report
Spring 2013
Model Equation: 𝛌𝑷 = (𝑪𝟏 𝝅𝑻 + 𝑪𝟐 𝝅𝑬)𝝅𝑸 𝝅𝑳
Parameter name
Description
Value
Comments
C1
Die complexity failure
rate
.01
πT
Temperature factor
58
C2
Package failure rate
.00092
πE
Environment factor
4
πQ
Quality factor
10
πL
Learning factor
1
Based on the MIL-Hdbk217f [9] for devices with
100 or less bipolar
transistors
Assuming a worst case
junction temperature of
125C based on worst
junction temp of the
regulator
Based on equation from
MIL-Hnbk-217f page 5-14
[9] for SMT with 3 pins
Handbooks value for
mobile devices
Assumed from the notes
that this is the value to use,
most likely the value is too
large
Number used for devices
older than 2 years in
production
λP
Failure rate per 10^6 5.8368
hours
Mean Time To Failure 171326.7544
MTTF
Approximately 19.5 years
to a failure for one device
TI L293 Quadruple Half-H Driver [12]
Model Equation: 𝛌𝑷 = (𝑪𝟏 𝝅𝑻 + 𝑪𝟐 𝝅𝑬)𝝅𝑸 𝝅𝑳
Parameter name
Description
Value
Comments
C1
Die complexity failure
rate
.01
Based on the MIL-Hdbk217f [9] for devices with
100 or less bipolar
transistors
-14-
ECE 477 Final Report
Spring 2013
πT
Temperature factor
58
C2
Package failure rate
.0056
πE
Environment factor
4
πQ
Quality factor
10
πL
Learning factor
1
λP
Failure rate per 10^6 6.024
hours
Mean Time To Failure 166002.656
MTTF
Assuming a worst case
junction temperature of
125C based on worst
estimated junction temp of
the H-bridge
Based on equation from
MIL-Hnbk-217f page 5-14
[9] for SMT with 16 pins
Handbooks value for
mobile devices
Assumed from the notes
that this is the value to use,
most likely the value is too
large
Number used for devices
older than 2 years in
production
Approximately 19 years to
a failure for one device
CTS CB3 HCMOS/TTL Clock Oscillator [13]
Model Equation: 𝛌𝑷 = 𝛌𝒃 ∗ 𝝅𝑸 ∗ 𝝅𝑬
Parameter name
Description
Value
Comments
λb
Base failure rate
.027
πQ
Quality factor
2.1
πE
Environment factor
10
λP
Failure rate per 10^6 .567
hours
Mean Time To Failure 1763668.43
Based on the MIL-Hdbk217f [9] for devices with 20
MHz frequency
Based on devices with a
non MIL-SPEC
Handbooks value for
mobile devices
Based on a quartz oscillator
calculation
Approximately 201 years to
a failure for one device
MTTF
-15-
ECE 477 Final Report
Spring 2013
The overall system of this project is reliable. All of the parts have a reliability within the
same scale of 10^-6 failures per hour. Also, the system will not be a highly bought solution;
therefore a slightly higher failure rate is acceptable. The best way to improve reliability of the
design would be to buy military parts, which would reduce each by a factor of 5. Another way
the reliability could be improved is by adding other subsystems to check the failure modes of
components and disable those functions safely. These options provide an acceptable increase in
price because the niche for the market of this product is so small, so someone buying this would
be willing to pay more.
5.3 Failure Mode, Effects, and Criticality Analysis (FMECA)
This design was analyzed with two criticality levels, low and high. The low criticality level
is anything that will disrupt the complete operation of the robot without possible harm to the
user. The high criticality level is anything that could possibly harm the user. In the low criticality
level category problems such as no LEDs, or no power would be problems. Examples of high
criticality problems are overcharge of the battery, or overheating of the voltage regulator. For the
low criticality problems < 10-6 would be an acceptable occurrence. For high criticality problems
the preference would be to keep the rate below 10-9 because it could be damaging to the user.
The failure modes were analyzed assuming no enclosure around the robot such that a user would
be able to access the components, which could possibly cause harm to them.
5.4 Summary
The design seen in this report could have a better failure rate and this could be decreased by
using higher quality parts. The robot has many ways in which it could potentially fail. Some of
these ways could be potentially harmful to the user. Safety is essential to any design and as such
the design above was analyzed to give the ability to lower the likelihood of problems occurring.
Using the data above, the ways in which the design can fail are able to be seen and in this way
the robot can be redesigned some to lower the likelihood of them happening. The robot would be
designed to reduce the likelihood of the high criticality modes down to 10-9 or less because they
could be harmful to the user. The lower criticality modes would be designed for 10-6 or less
because they would not be harmful to the user. Altogether from this analysis it can be seen the
most possibilities of failure come first from the power supply, then the microcontroller, then the
H-bridge. In redesigning the robot, these sections would have more safety checks in effect.
-16-
ECE 477 Final Report
Spring 2013
6.0 Ethical and Environmental Impact Analysis
6.1 Introduction
The COST Robot is a maze traversing robot which will generate a digital map of the maze
by using its distance sensors to help determine its location. Once the robot has mapped out the
maze it will revisit locations within the maze in an order that was specified by the user at the
beginning of maze traversal. After the robot is done revisiting the number of lights that were
specified, the user will have an option to connect the robot to a computer via USB to transfer the
map data to a GUI in order to view the map.
In regards to environmental impact, the COST Robot will be analyzed in terms of three
periods of its life-cycle. These are manufacturing, normal use, and disposal. When analyzing the
COST Robot, it appears there is only a slight environmental concern. This is determined from
the analysis of components and manufacturing process used to construct the COST Robot, its
small size, power consumption, and product lifetime.
When looking at ethical challenges, there are three categories of different ethical concerns:
safety, misuse, and reliability. After analyzing the COST Robot, it does not appear the ethical
challenges it faces will be difficult to overcome and will be explained in further detail in the
following sections.
6.2 Environmental Impact Analysis
The environmental impact analysis of the COST Robot can be broken into three periods
during its life-cycle: manufacturing, normal use, and disposal. Each category has a unique aspect
in what to consider as having an impact on the environment.
First, the manufacturing part of the COST Robot's life-cycle requires looking at the process
and materials needed to construct the robot. Since there are many components that are required
to construct the COST Robot, only the ones that impact the environment a significant amount
more than the others will be considered in this analysis. These are the manufacturing of the
3.7”x3.7” PCB, 7.4V Li-Ion battery, ICs, and many cardboard boxes used for maze making. The
chassis of the robot is made from recyclable plastic and aluminum, and it is small. Therefore, as
long as the user sends the chassis with the other components to be recycled, the chassis is of
minimal environmental concern. However, PCB manufacturing requires chemicals that could be
hazardous if exposed to the environment such as sulphates, nickel, acids and more. There are
also air emissions released during these processes that are ozone-depleting substances. [14].
Because of this, the PCB of the COST Robot would be minimized to reduce the amount of
emissions per PCB. Li-Ion batteries also contain and involve chemicals that are hazardous to the
environment during manufacturing. There is not much that can be done about replacing the 7.4V
battery on the robot since it requires this voltage for the motors and ICs. There is also a small
-17-
ECE 477 Final Report
Spring 2013
concern with the similar chemicals required to make all the ICs as with the PCB. In order to
reduce this part of the environmental impact as much as possible, the COST Robot can be
optimized in its use of different ICs by combining components such as the digital isolators and hbridge. The manufacturing of the 75 cardboard boxes used to build a maze are not as big of a
concern as other components. They are made from recycled paper materials and other cardboard
boxes. This means the manufacturing process is not hazardous to the environment and actually
saves trees.
Next, the normal use of the COST Robot has a very small environmental impact. When the
robot is powered off the battery is completely disconnected from the circuit and therefore should
theoretically not be using any power. However, based on small leakage in batteries there will be
a very small amount of power consumed. For this analysis, that leakage power will be considered
negligible. When the robot is on, the whole circuit draws about 0.21A of current. At 7.4V, this
comes out to 1.554W or greater. This is a small amount of power for this device. Taking into
consideration the 2.8Ah battery while running at 0.21A, the robot should last about 13 hours
before needing to recharge the battery. However, after further testing of the robot, it seems the
robot’s performance degrades rapidly after 2 hours of operation. This is still a reasonable time
for a mobile robot and would consume only a small amount of coal to recharge the battery. As
far as environmental impact of the COST robot during normal use, this category is of the least
concern out of the three periods.
Finally, the disposal and recycling part of the COST Robot life-cycle will have to be dealt
with properly. The main concerns of this period are proper disposal of the PCB, and recycling of
the Li-Ion battery and motors. Since most of these components are non-biodegradable, it would
be best if they could be recycled. When disposing of the PCB, the user-manual will instruct the
user to take the populated PCB to a PCB recycling company. One company that will be
recommended to the user is B.W. Recycling Inc. [15]. This company takes non-populated and
populated PCBs. The Li-Ion battery disposal is regulated differently depending on where the user
lives. Therefore the user manual will indicate the user needs to look up specific regulations
depending on where they live. It will also be indicated that all rechargeable batteries should be
discharged completely before they are disposed of [16]. The leads should be wrapped in
electrical tape to avoid shorting the battery. The user manual will contain the reference in [16] to
direct the user to find local Li-Ion recycling plants. The motors are another main component that
should be recycled. There is a lot of copper in the windings in the motors that should be recycled
and reused. As a side note, it will also be recommended in the user documentation to recycle the
cardboard boxes used for the maze. Even though the cardboard is biodegradable, it would be
better if they could be reused for manufacturing other paper products.
6.3 Ethical Challenges
When analyzing the COST Robot in the aspect of ethical challenges, there were only a few
that were thought of, but they are as important as any other issue. First, under the topic of safety,
-18-
ECE 477 Final Report
Spring 2013
since this is a prototype of the COST Robot, there are many exposed wires and the PCB is left in
the open. This is an ethical concern since the user could get burned from the components or ruin
the circuitry. To solve this, the wires and PCB would have to be inside an enclosure. A warning
label would also be placed on the outside of the robot to warn the user if the robot was opened up
it could result in electrostatic damage or burning. This same warning would also be added in the
user documentation. The battery would also present a problem since there is a possibility it could
explode. In the COST Robot’s current state, the battery is slightly open to the user and could
cause chemical burns if it exploded. Again, this can be solved by putting an enclosure case
around the battery. The last safety concern is a possibility of the robot starting a fire by one of
the components catching fire. Since the robot catching fire would only be likely to happen
because of a short or over-current, a one amp fuse would be added in series with the power from
the battery. This is also something that can be prevented by various testing in different conditions
to make sure the robot will behave correctly in all situations. Based on the reliability analysis in
the previous homework, the h-bridge is the most likely to fail at 5.8 failures per one million
hours. This is acceptable for the COST Robot since there is no anticipation of having a large
consumer base. Therefore, it does not seem like this will present an ethical dilemma if the COST
Robot is tested even only a quarter of a million times, and one or two failures are seen. Since the
robot will have a fuse it will most likely fail before the user is harmed.
Under the topic of the COST Robot being misused, there are only a couple ethical concerns
that were thought of. The first is the misuse of the battery charger either intentionally or
unintentionally. Li-Ion batteries are sensitive to their state of charge, and if they are overcharged
they could present a danger to the user. Overcharging can cause the battery to either explode or
provide too much voltage to the components which might damage them. To protect against
overcharging the battery, a warning label should be put on the battery itself and the battery
charger to make sure not to charge the battery for longer than its recommended period of time. A
note should also be put in user documentation just to make sure overcharging does not occur.
Another possibility of misuse would be if the user was able to reprogram the robot to do
something unethical. This can simply be resolved by removing any headers that enable
reprogramming.
On the topic of reliability, it can be an ethical concern if the COST Robot does not solve a
maze reliably as it is intended to do. If a user bought this product and it did not behave properly,
they would most likely be upset. Whether the robot is reliable in solving a maze can be solved by
testing the robot in various situations many times to make sure it does not mess up. It will have
to be tested on tiled surfaces and hard carpeted surfaces as well. Soft carpeted surfaces most
likely will not work since the wheels are not designed for this kind of surface. The user
documentation will warn the user about which surfaces the COST Robot works best on.
-19-
ECE 477 Final Report
Spring 2013
6.4 Summary
As long as proper action is taken, the COST Robot should not be a large threat to the
environment. The largest part of the environmental impact will be depending on what processes
the manufacturer of the PCB and microcontroller decide to use. The COST Robot uses a minimal
amount of power and is very efficient during its normal use. When the robot has reached the end
of its life, it is critical that proper measures be taken to send the PCB to a recycling plant and to
recycle the Li-Ion battery in order to reduce the environmental impact further. When considering
ethical challenges, there are a few safety issues that are easily addressed. All wires and
components will have to be covered to prevent burns and damaging components. In case of
battery explosion, the battery will also have to be covered. Also, in order to prevent user misuse,
warning labels must be placed on the battery to prevent overcharge, and headers must be
removed to prevent reprogramming. Last, in order to ensure the product is reliable, it must be
tested many times and include documentation on which types of surfaces to use the robot. If all
issues are addressed properly, the COST Robot will be a safe and reliable device.
7.0 Packaging Design Considerations
7.1 Introduction
In this project, the robot being designed will traverse a maze and map that maze out, while
also determining where colored lights are inside the maze. Once finished mapping the maze it
will revisit the colored lights in an order preordained by a user. It will then exit the maze and the
user will be able to connect a USB cable from the robot to a computer to access a map of the
maze. The maze design will not be open, but will only feature hallways. This will allow the robot
to better map out and traverse the maze. To be able to achieve the different functions necessary
for this project, the design uses 2 pushbuttons, 4 LEDs, 3 ultrasonic range sensors, 1 long range
laser sensor, 2 wheels and motors, a color sensor, a battery pack, and a PCB. All of these things
will need to be packaged into one small robot. The color sensor and range finders will need to
have a clear line of vision, and the wheels will need to be able to be free to move. Also, the
device will have to be able to make near zero point turns to make it through the maze. All of
these factors as well as others have influenced decision making as to how to package this device.
7.2 Commercial Product Packaging
The COST Robot should be physically compact and able to easily navigate a small space.
To better determine the packaging requirements for this design, two similar commercial products
were analyzed: the Clocky Robotic Alarm and the iRobot Scooba 230 Floor Washing Robot.
Both of these robots consist of small bodies on wheels. This general type of packaging is desired
for the COST Robot.
-20-
ECE 477 Final Report
Spring 2013
7.2.1 Clocky Robotic Arm
Figure 7-1: Clocky Robotic Alarm
The idea behind the Clocky Robotic Alarm is simple, it is an alarm clock that rolls away
from the user in the morning when it is time to wake up [17]. It appears from the video that it
does not have the capability of smartly rolling away from the user, but instead uses random turns
to make it harder for the user to catch it. While this product does not have the same functionality
as the current project, it has a similar size and motion capability as the one being designed.
The layout of this design is fairly simple. The two wheels hold up the product and allow it
to move. This also allows the body of the product to rotate around the wheels in the same way
the wheels rotate next to the product to create movement. The two wheels allow for small zero
point turns which is what we would like our product to have as well, but is not as stable because
it is sitting on only two wheels.
The other part of this product is the full plastic shell which holds the logic of the device.
The wheels allow the movement while the shell protects the circuit. This allows users to only see
and interact with the parts they care about. Because of this you can see the screen, the buttons on
the robot, and the wheels sticking out the side of the shell. This is a good idea for that type of
product, but this project's robot will need sensors unblocked by the wheels. This will call for an
open body above the wheels which will create a higher center of gravity. Hence, a stabilization
wheel will be necessary.
-21-
ECE 477 Final Report
Spring 2013
7.2.2 iRobot Scooba 230 Floor Washing Robot
Figure 7-2: iRobot Scooba 230 Floor Washing Robot
The iRobot Scooba 230 Floor Washing Robot is a compact robot whose purpose is to
“mop” small rooms such as bathrooms [18]. The robot is compact in size with a diameter of 61/2 inches and moves on two motorized wheels. It is designed such that it can clean hard-toreach places, making accurate turns so as not to miss areas of the floor.
The Scooba 230 Robot implements a physical design similar to that of what the COST
Robot will need. Both robots are compact – the Scooba at a diameter of about 6-1/2 inches and
the COST Robot at a target diameter between four and five inches – and both utilize two
motorized wheels for navigation. Furthermore, the COST Robot needs to be able to effectively
travel throughout at maze, making accurate turns and having the ability to travel in a straight
line. These are features exhibited by the Scooba. The robots differ in their primary “mission”
during operation. The Scooba robot is designed to mop a floor without intelligent navigation
while the COST Robot is designed to traverse a maze and then intelligently located pre-specified
targets within the maze. In addition, the COST Robot will exhibit rather open packaging while
the Scooba robot is fully enclosed in a plastic case.
In regards to packaging, the compact size of the Scooba robot is very beneficial as it aids in
concise room navigation. The location of the wheels on the outside of the body is also a feature
that the COST Robot will implement. As mentioned, the Scooba robot is enclosed in a plastic
shell. For the COST Robot however, the outer packaging will be more open to avoid heat traps
and eliminate the need for heat sinks in the design. Finally, the Scooba robot runs on a
rechargeable battery which will be an additional requirement of our robot.
-22-
ECE 477 Final Report
Spring 2013
7.3 Project Packaging Specifications
As depicted in Figure B-2 of Appendix B, the basic structural design of the COST Robot
will consist of three octagonal platforms spaced an approximate distance of 1.5” apart from each
other with the third octagonal platform being the PCB. The octagons will have a long diameter of
4”. An octagonal shape was chosen to limit the unnecessary need of plastic that may stick
outside of the turning radius. These platforms will be supported by four posts located at each of
the two front and back corners of the octagon.
The robot will move on two motorized wheels. The motor wheel combination can be seen
in Figure B-3 of Appendix B. The motors will lie on their sides on the bottom platform with the
shaft sticking out away from the body of the robot. This will allow the wheels to be aligned
parallel to each other along the octagonal shape of the robot body.
Figure B-1 of Appendix B illustrates how the sensors and other peripherals are attached to
the robot. Each of these attachments to the robot’s body can be seen in more detail in Figure B-4.
Each of the three short range sensors will be suspended from the bottom of the top platform. The
color sensor will be located on the top of the middle platform facing outwards from one of the
robot sides. The long range sensor will be located on the bottom layer, as will the battery pack.
This design is rather simple mechanically and will not require any special tools or
machinery. The estimated weight of the COST Robot is 235.94 grams (~0.5 pound), with the
bulk of this value coming from the battery, wheels, motor, and hard plastic platforms. The
approximate cost of this product is $165.91.
7.4 PCB Footprint Layout
There are not many major components that will physically be on the project's PCB. Since
all the sensors of the COST Robot need to be at different locations around the robot, these
sensors cannot be mounted to the PCB. Instead, the PCB will have headers set aside for each
sensor and have a few cables that connect to the PCB to branch out to each sensor.
Many of the sensors that do not lay on the PCB will be attached to pre-manufactured
breakout boards. Of the major components that will have to be on the PCB, the footprints do not
take up much room at all. The major components that need to be considered are the 44-pin QFP
PIC18F4550, a QFN 24-MHz oscillator, the 16-pin DIP h-bridge, a USB port, and any headers
needed to support the sensor components. The PIC had the capability of coming in a QFP or DIP
package. The QFP was chosen for obvious reasons of being much smaller. When searching for
oscillators, none could be found with a QFP footprint, so a QFN was chosen since it has a
smaller area than a DIP design. The h-bridge could not be purchased in anything other than a
DIP package. Since the h-bridge already met the design requirements and there was not a
shortage of room on the PCB, the DIP package was chosen despite its large size. Last, since USB
ports and headers have a standard size, there was no choosing between footprints.
-23-
ECE 477 Final Report
Spring 2013
In order to allow easy mounting through screws into each of the four posts on the robot, a
regular octagon with a 4" diameter will be chosen for the size of the PCB. This will give enough
room for analog parts of the circuit to be isolated from CMOS logic as well as ensure there is
enough room for headers.
7.5 Summary
The Clocky Robotic Alarm and the iRobot Scooba 230 have given packaging inspiration on
how to design a near zero-point turn robot. The COST Robot will have a 4" diameter octagonal
shape to make the robot more circular and avoid corner collision while turning. There will be
two motorized wheels to drive the robot and one stabilization wheel since the robot's center of
gravity will be higher than the two examples. Also, since the project robot has many more
sensors on each side of the robot, the enclosure will be more open to avoid packaging
interference and heat traps.
There will be three layers for components to be mounted. The bottom layer will have the
motors, battery, and long range sensor attached to it. The middle layer will have the three short
range sensors hanging from the top layer on the front, left, and right sides. On the left side, the
color sensor will be mounted on the middle layer. The color sensor being on only the left side
will not present a problem since the maze will have lights on both sides of the wall. The top layer
will have the PCB mounted to it.
The PCB Footprint will be the same 4" regular octagonal shape as the layers of the COST
Robot to allow easy mounting. The 4" octagonal area will be more than sufficient to house the
major components - the PIC18F4550, 24-MHz Oscillator, h-bridge, USB port, and headers. The
large PCB will also allow enough room to separate the analog and digital components of the
circuit.
8.0 Schematic Design Considerations
8.1 Introduction
The COST Robot is a design with the intention of building a robot that is able to traverse
and map out a maze. The robot will have the ability to detect colored lights on the walls of the
maze. When the robot has finished the mapping of the maze, the robot will be able to revisit the
colored lights in an order defined by the user. Finally, the user will be able to upload a map via
USB to their computer. A couple of circuit design issues that arise are the power consumption
and the physical size. We must pick parts that are small and as few parts as possible so that that
physical PCB will be small, whether or not the schematic is small. How much power the device
uses is also a concern. While it is not necessary to choose as low power parts as possible parts
cannot be used that consume a large amount of power and that will drain the battery quickly.
-24-
ECE 477 Final Report
Spring 2013
8.2 Theory of Operation
The major subsections of the circuit consist of the power supply, clocking oscillator, motor
drivers, and analog inputs. The power supply (appx. C fig C-2) consists of a 7.4V battery input
that is in series with a fuel gauge sense resistor. A 7.4V battery was chosen so that the motors
would be able to run at a fast enough speed. The fuel gauge monitors all current entering and
leaving the battery by monitoring the sense resistor. This fuel gauge is meant for 2-cell Li-Ion
batteries, and has a simple set-up for what we need. The fuel gauge allows the microcontroller to
know how much of that battery has been used. The fuel gauge sends an interrupt every time a
certain amount of charge has left the battery. The battery will then connect to a Micrel
MIC29150 5V low-dropout regulator [11] to power the majority of our ICs. The low-dropout
regulator was chosen because the distance sensors needed a clean voltage supplied to them and a
switching regulator would have been too noisy.
The next major subsection is the CTS CB3 24 MHz clocking oscillator [13] (appx. C fig C3). The oscillator will be running off 5V like the rest of the components and was chosen to run at
24 MHz because of the necessity to communicate directly to USB through the microcontroller.
The microcontroller has the capability of running at 8 MHz without an external clock and 48
MHz with an external clock. Since 48 MHz is required to communicate through USB, the
external clock was added and the microcontroller uses a phase-lock-loop to create the 48 MHz
signal necessary for USB communication, while the microcontroller core runs at a slower speed.
Next, the Texas Instruments L293Quadruple Half-H Drivers [12] (appx. C fig C-4) are a
single IC that has two H-bridges. The L293 has two power inputs. One is an isolated 5V power
in order to power the switching logic, and the other is the unregulated 7.4V power from the
battery. Since the motors need to have their direction and speed controlled independently of each
other, the L293 operates in a mode with three inputs to control one motor. In order to prevent
feedback from the motors, digital isolators are used between the microcontroller and L293. The
isolators will be supplied with 5V to provide power to the inputs and another 5V line to supply
power to the outputs going to the L293. These 5V lines will both come from the regulated power
supply, but will be connected at a single point to prevent feedback between the two devices.
Finally, there are many analog input lines that transfer voltage levels through headers
(appx. C fig C-5). There will be an 8-pin header to connect the long range sensor (Sharp
GP2Y0A02YK0F [19]), short range sensors (Sharp GP2D120XJ00F [20]), and RGB color
sensor (Avago HDJD-S822-QR999 [21]). The four range sensors take up 1 pin each and the
color sensor takes 3 pins, one each for red, green, and blue. The final pin will be connected to
ground to decrease capacitance and noise on the lines. Each analog input line will have a
possible voltage swing of 0V to 5V, and will be read in on the microcontroller through a10 bit
ADC.
-25-
ECE 477 Final Report
Spring 2013
8.3 Hardware Design Narrative
Based on the major subsections of the circuit (power supply, clocking, motor drivers, and
analog inputs) the microcontroller will use many of its subsystems and pins. The first section, the
power supply, interfaces with the microcontroller (PIC18F4550) [10] on pins 28/29 and 6/7,
these are the power and ground pins. Between the power and ground pins, on each set, is a
bypass capacitor to reduce noise. These are small .01 µF ceramic capacitors. The .01 µF was
chosen because the circuit is operating at a frequency greater than 15 MHz.
The next subsection, clocking, interfaces with the microcontroller on pin 30. This pin is
OSC1 on the PIC18F4550.We use this pin because, as can be seen in the schematic from
Appendix B Figure 3, there is an external oscillator operating in this circuit, as was described in
the previous section. The microcontroller will be configured to use this pin as the new clock for
itself, and for the USB. The microcontroller will use a phase-lock-loop to clock the oscillator to
48 MHz for USB and will divide the clock down to 8 MHz for use of the processor. The 8 MHz
is necessary for the processor so that the PWM can run slower and the motors can be more finely
controlled.
The L293 h-bridge (appx. C fig C-4) is interfaced with the microcontroller on pins 38-41,
and 35/36. Pins 38-41 were chosen because they are close together and are not being used by any
of the other peripherals. These pins are GPIO, Port D 0-3 to be exact, on the PIC18F4550. Pins
35 and 36 are configured for PWM output and control the enable to the h-bridge and thusly
control the speed of the motor, via the duty cycle. As can be seen in appx. C, all of these signals
run through digital isolators to keep feedback from the motors from affecting the
microcontroller.
Finally, the analog inputs (appx. C fig C-5) will be connected to pins 19-22 and 24-26
because these pins are the ADC pins on the microcontroller. To be specific on the PIC18F4550
they are port AN{0-6}. These pins had to be used because the microcontroller only allows using
the AN port pins as analog if they are in sequential order. For example, it is not possible to use
AN3 as an analog input without AN0-AN2 also being analog inputs as well. The microcontroller
will be configured to use these pins as analog inputs so that the analog devices can be sampled.
Any other pins on the micro controller that are being used are in GPIO mode and used as
outputs for LED’s and inputs for pushbuttons. As well as an input to the reset pin to reset the
microcontroller. The only exception to this are pins 42, 43, and 37. These pins are used for USB
output. Pins 42 and 43 are tied to a USB B female connector and allow communication to
another USB enabled device. Pin 37 is Vusb and is the 3.3 V supply of power for USB use. This
pin has a capacitor between it and ground with a value of .47 uF to stabilize the power output.
All pins used and unused are tied to a header for easy access.
-26-
ECE 477 Final Report
Spring 2013
8.4 Summary
The hardware for this design (appx. C fig C-1) has many components. The major
components that this contains are power supply, clock, motor control, I2C bus, and the analog
signals. All of these components are being controlled or used by the microcontroller. The power
supply is regulated down from 7.4 volts, which is needed by the motor, to 5 volts, needed by the
digital components. The clock is 24 MHz and is connected to the microcontroller to give the
option of using the USB on the microcontroller. The motor is controlled through an h-bridge,
which is controlled by the microcontroller via PWM and GPIO, both of which are digitally
isolated. The I2C bus is used by the microcontroller to talk to both the I2C to USB controller and
the digital compass. Finally, the analog signals are all fed into the board through a header which
runs directly to the microcontrollers ADC ports.
9.0 PCB Layout Design Considerations
9.1 Introduction
The purpose of this project is to design a small robot to completely traverse a maze before
returning to the maze entrance. The robot will store the configuration of the maze, along with
the location of various colored LEDs along the maze walls. The robot will then revisit these
lights in a predetermined order entered by the user. Upon completion of this task, the robot will
again return to the starting location where it can be retrieved. The user will be able access a file
containing the format of the maze by connecting the robot to a Windows PC with a USB cable.
The robot uses 3 general LEDs, 1 RGB LED, 3 ultrasonic range finders, 1 long range laser
sensor, 2 motors/wheels, a color sensor, and 2 pushbuttons to realize this functionality. In order
to accurately detect the maze configuration, the distance sensors must have unobstructed paths to
the walls in front of and beside the robot. To accomplish this, the sensors will be mounted along
the side of the robot, on a layer of plastic directly under the PCB. An 8-pin header on the PCB
returns the analog voltages sent from each sensor. These analog lines are as isolated as possible
to prevent noise from impacting the signals. The 7.4V battery also plugs into a header on the
circuit board. The voltage is regulated to 5V and is distributed to the rest of the PCB
components. Due to the extremely small size of our circuit board, approximately 4 inches across
diagonally, the placement of components around the MCU was of great concern. This careful
placement was the most time consuming aspect of the PCB design.
9.2 PCB Layout Design Considerations - Overall
The most pressing PCB design constraint is the small surface area of the PCB. The outline
of the PCB will sit flush with the edge of the robot. The robot must be small enough that a
sufficiently complicated maze can be built for it to traverse without exceeding approximately 6
feet in maze width or length. The initial goal of the PCB was to separate the circuit into several
-27-
ECE 477 Final Report
Spring 2013
partitions pertaining to each subsystem of the PCB. One purpose of this is to isolate sensitive
sensor outputs from high frequency digital lines that might introduce noise to the analog traces,
causing inaccurate distance and color light measurements. If the robot was unable to read
accurate measurements from these sensors, it would be impossible for it to avoid collisions and
accurately record LED locations within the maze. To prevent this issue, the analog input header
was placed as closely as possible to the microcontroller. This keeps these traces from passing
over or under fast switching, high current digital lines. Though it is generally good practice to
route power traces directly to each section of the PCB over the shortest path available, it was not
realistically possible in this design because of the analog trace constraints explained above. A Ushaped path was used to direct power and ground traces to the PCB components, with a branch
extending to each major subsystem.
In addition to these specific considerations, many general PCB layout guidelines were
considered. 16 mil traces were used for all analog and general logic traces on the PCB. 40 mil
traces were used for the main 7.4V and 5V power and ground rails. The 5V grounds of each
PCB section (USB, sensors, pushbuttons, oscillator, MCU) were tied together at a single node.
This node was then tied to the 7.4V ground at the 5V linear regulator. Separate ground planes
were used for each subsystem (analog, motor control etc.). These planes were tied together at a
single location. Finally to save space, surface mount components were used to whenever
possible and decoupling capacitors were placed on the underside of the PCB.
9.3 PCB Layout Design Considerations - Microcontroller
The Microchip PIC18F4550 was the microcontroller chosen for the PCB design. It is
capable of running at a maximum speed of 8MHz using the internal oscillator. Though this
speed may be adequate for the normal operations of the robot, an external oscillator of at least
20MHz is required to use the onboard USB functionality. The CTS CB3 oscillator requires a
simple configuration circuit, consisting of a .01µF capacitor and 10KΩ resistor [13]. It requires
only one microcontroller port pin to operate properly, and it was connected to pin 30 (Oscillator
1) for this design.
According to the PIC18F4550 datasheet, 0.1µF bypass capacitors must be placed between
the power and ground pins of the microcontroller [10]. In order to position the capacitors as
close as possible to the 18F4550 power and ground pins, they were placed on the underside of
the board, under the microcontroller. This keeps the capacitors from disrupting the traces of the
rest of the microcontroller pins. The PIC18F4550 has only two 5V/GND pin pairs, so only two
bypass capacitors were needed.
The placement of programming and debugging headers were also important considerations
in the PCB design. In order to program the microcontroller, a standard female 5-pin PICkit 2
header is required. Since the PICkit connector is sensitive to transmission length, a maximum
cable length of 6 inches is recommended [10]. To be conservative, the programming header was
-28-
ECE 477 Final Report
Spring 2013
placed as close to the microcontroller as possible, sharing the reset (MCLR) trace with the reset
button. For debugging, the microcontroller’s USART will be used to print messages to a
terminal and thus it was connected to a 4-pin header. Through testing, the MCU was determined
capable of printing messages to the workstation PC reliably over cable lengths as long as 8 feet
at a baud rate of 9800 Bd. Because of the protocols robust nature, its placement on the PCB was
not of large concern.
In order to reach necessary subsystems on the PCB, the microcontroller was placed near the
center of the board. This allows the MCU to access all necessary components using relatively
short traces. To facilitate easier debugging, four 11-pin female headers were placed around the
perimeter of the microcontroller. This allows jumper wires to access any of the PIC18F4550’s
44 pins, and will allow for easy fly-wiring if necessary. Traces radiate outward from the
microcontroller headers and pin assignments were changed to prevent overlapping traces where
possible. A 16 mil trace width was used for almost all logic traces.
9.4 PCB Layout Design Considerations - Power Supply
The robot’s components all run off of one of two supply voltages – 7.4V and 5V. A 2-cell
7.4V Lithium-ion battery will be used to power the robot, and must directly run the L293D Hbridge driver chip and motors [12]. A 3-pin “idiot-proof” connector will be used to plug the
battery output into a 3-pin header on the board. The connector, with power in the middle and
ground on each side, will function properly no matter which direction it is plugged in. The loss
of battery capacity is calculated using a Linear Technology LTC4150 fuel gauge chip. The 7.4V
line passes through a 10mΩ “sense” resistor and is decoupled by a 4.7µF capacitor as specified
in the fuel gauge data sheet [22]. Immediately afterwards, a fast 0.1µF capacitor and 10µF
“bulk” capacitor are encountered. The purpose of this “bulk” capacitor is to recharge the many
decoupling capacitors on the PCB. The voltage is then regulated to 5V using a MIC29150 lowdropout regulator. The MIC29150 regulator requires a 0.5 µF capacitor at the input, and a large
10µF capacitor at the output [11]. Voltage from the 5V node is then dispersed, as directly as
possible, to all of the other PCB components. The 5V subsystems and 7.4V motor components
are placed separately from each other on the circuit board, and their grounds are tied together
only at the regulator. Great care was taken to avoid analog signal traces when routing power
lines, so very few crossings of the two occur.
In the final PCB design, ground planes were used for each logical subsection of the circuit
(analog, motor etc.). These ground planes were tied together at the regulator, providing a direct
low impedance path to common ground.
9.5 Summary
The COST robot has many PCB requirements that must be carefully considered when
completing the circuit board layout. The small 11 square inch surface area of the PCB makes
-29-
ECE 477 Final Report
Spring 2013
separating analog and digital signals difficult. Noise on the analog lines could greatly impact the
robots ability to traverse the maze, so avoiding this was a very high priority objective.
The Microchip PIC18F4550 was chosen as the microcontroller for the project. To ensure
proper functionality of the MCU, two 0.1µF bypass capacitors are placed between the 5V and
GND pins, in accordance to the datasheet guidelines. A 5-pin PICkit header was placed near the
microcontroller for in-circuit programming. A 4-pin header was connected to the USART,
allowing the MCU to print messages to a computer terminal while debugging. Headers were
placed around the MCU, allowing for easy debugging and fly-wiring in the future.
A 7.4V 2-cell Lithium-ion battery will be used to power the robot. It directly powers the
DC motors, and is regulated to 5V in order to power the majority of the components on the
board. All main 5V rails terminate at one main node, and 7.4V and 5V ground traces meet only
at the regulator. Ground planes were tied together only at the regulator, maintaining proper
isolation of the various subsystems. Decoupling capacitors were used as necessary between all
power and ground rails. Two 10µF “bulk’ capacitors were placed near the entrance of power
into the PCB, and are used to recharge the rest of the bypass capacitors.
10.0 Software Design Considerations
10.1 Introduction
The COST Robot (Cartographic Order Specific Task Robot) is a small, compact robot
capable of fully traversing and mapping a maze. In addition, this design serves as a proof of
concept for a robot whose purpose is to perform various tasks located throughout a maze. The
robot will use the self-generated map of the maze to revisit specific locations marked by colored
LEDs in a predetermined, user-specified order. The robot will be equipped with three types of
sensors: three short-range sensors for hit detection, a long-range sensor for to-scale mapping, and
a color sensor to locate lights. Sensor-reading as well as robot movement and maze traversal will
be controlled via the PIC18F4550 microcontroller. The micro will be programmed using
embedded C, and the code will be organized primarily in a “flag”-driven fashion.
10.2 Software Design Considerations
The code will be structured around flags set or cleared by button presses, compass
readings, and sensor readings. Button presses will set flags to accept user input and start maze
traversal or data transfer. Compass flags will instruct the robot to correct its direction of
movement to maintain a straight path. Sensor readings will set flags to stop robot movement as
nodes are reached within the maze – a node being a point at which the robot has the ability to
proceed in more than one direction, a dead end, or the location of a colored LED. This design
-30-
ECE 477 Final Report
Spring 2013
requires many digital I/O pins in addition to PWM channel control, ATD channels, and USB and
I2C interfacing.
Three single-colored LEDs, one RGB LED, two pushbuttons, and four motor directioncontrol output signals will be located on pins configured as digital I/O. This microcontroller
features five registers for general purpose I/O – PORTA, PORTB, PORTC, PORTD, and
PORTE. Associated with these registers are the TRISA, TRISB, TRISC, TRISD, and TRISE
registers. Setting or clearing a bit in one of these registers corresponds to configuring the
associated pin as an input or output, respectively.
The single-colored LEDs in conjunction with the pushbuttons on the robot’s body will
allow the user to control robot functionality. At the start of operation, the user will select the
desired number of lights (ranging from zero to three) for the robot to revisit after mapping the
maze, the color of these lights, and the order in which the robot should visit them. Once traversal
begins, the robot uses the short-range sensors and an RGB color sensor to determine the
locations of nodes within the maze. In order to accurately map the maze, the robot takes
advantage of the long range IR sensor’s distance measurements. Finally, to aid in successful
navigation, the robot will use digital compass measurements. These measurements will help
ensure that the robot is moving in a direction perpendicular to the wall in front of it.
Each of the sensors – three short-range, one long-range, and one color – will utilize analog
to digital conversion. The PIC18f4550 features 13 pins for A/D conversion – AN0 though AN12,
of which the first seven will be used. Analog to digital conversion on these channels is controlled
with the use of three 8-bit registers: ADCON0, ADCON1, and ADCON2. The ADCON0 register
contains three sets of bits(s) to control channel selection and general conversion. The CHS bits
(bits 5-2) are used to select the ANx channel on which the conversion is to take place. The
GO_DONE bit determines the conversion status of the converter module. When set to 1, this bit
indicates that a conversion is in progress; when set to 0, this bit indicates that that the converter
module is in an idle state. Lastly, the ADON bit (bit 0) enables or disables the converter module
by setting or clearing the bit, respectively. The ADCON1 register contains two sets of bit(s):
VCFG and PCFG. The VCFG bits (bits 5-4) are used to determine the reference voltages for the
conversion, in this case 0V and 5V. The PFCG bits (bits 3-0) are used to determine the whether
the inputs on each of the ANx channels will be analog or digital. Finally, the ADCON2 register
contains three sets of bits: ADFM, ACQT, and ADCS. The ADFM bit (bit 7) determines whether
the result of the A/D conversion will be right or left justified by setting or clearing the bit,
respectively. The ACQT bits (bits 5-3) determine the A/D acquisition time and the ADCS bits
(bits 2-0) determine the A/D conversion clock frequency as a function of the internal oscillator
frequency.
Robot movement will be controlled via two motor-wheel combinations. Each motor will
require one PWM module and two Digital I/O pins configured as outputs by clearing the
corresponding TRISx bits. PWM functionality is enabled by setting bits two and three of the
-31-
ECE 477 Final Report
Spring 2013
CCPxCON register both to one. Each PWM module (CCP1 and CCP2) has a 16-bit register
associated with it that is used to determine the duty cycle and period of the PWM channel’s
output. Functions will exist to alter the duty cycles of the two PWM modules, directly setting
either the right or left motor speeds. The direction of the robot’s movement will be aided by a
digital compass. The compass will return a hexadecimal value that will be interpreted to identify
the direction of the robot’s movement. Communication between the compass and the
microcontroller will take place via I2C, using the SDA and SCL pins.
Finally the robot will communicate with a computer via USB. After the robot as finished
mapping the maze and revisiting the user-specified LEDs, it will be connected to the computer
with a USB cable to transfer the mapped maze. This microcontroller supports USB
communication through the connection of the D+ and D- pins to the USB connector and a
24MHz oscillator output connected to the OSC1 pin. Due to the nature of USB communication,
the internal oscillator must be run at full speed, and the PLLDIV register must be set to 6
(specific to the 24MHz frequency of the external oscillator).
The maze will be constructed of equal sized cubes placed side-by-side. For explanatory
purposes, it will be assumed that the length of a cube side is N inches. As a result, the path that
the robot will travel throughout the maze will be divided into segments equal in size to one of the
cube faces. This means that the lengths of all pathways (in inches) throughout the maze will be
divisible by N, and the width of each pathway (in inches) will be equivalent to N. Furthermore
this is true of the lengths and widths of maze walls. As a result, the entire maze, walls and
pathways included, can be divided in to a grid of N X N blocks.
In order to ensure full traversal of the maze, a modified version of the Tremaux algorithm
[24] will be used. As pathways are traversed, the robot will be use an infrared long-range sensor
to obtain accurate measurements of hallway lengths. As the robot makes its way down a hallway,
it will store the locations of maze nodes using a coordinate system. In addition, it will keep track
of the nodes that are accessible in each direction (top, bottom, right, or left) from the current
node being examined. This will make revisiting lights in an intelligent matter much simpler.
Finally, they type of node will be stored as normal (decision point or dead end), red (red LED
location), green (green LED location), or blue (blue LED location).
10.3 Software Design Narrative
The first function to be called by the main function of the program is the OpenPeripherals
function. This function is responsible for initialization of the internal registers of the
PIC18F4550. First, the OSCCON register is used to set the internal oscillator frequency of the
microcontroller to 8 MHz by setting the IRCF bits (bits 6-4) all to 1. A while loop then waits to
ensure that the frequency of the internal oscillator has stabilized before proceeding to the rest of
the code by checking the IOFS bit (bit 2). Next, all general purpose I/O pins are specified as
-32-
ECE 477 Final Report
Spring 2013
either inputs or outputs. The ADCON0, ADCON1, and ADCON2 registers are then initialized to
support analog to digital conversion. The converter module is enabled and the conversion status
is initialized to an idle state. After A/D setup, the USART is opened for communication to aid in
debugging and the two PWM channels necessary for speed control of the two motors are opened
with their duty cycles initialized to 0. First priority level interrupts are enabled by setting the
IPEN bit of the RCON register and high-priority interrupts are enabled by setting the GIE_GIEH
bit of the INTCON register. The timer0 module is configured by initializing groups of bit(s) in
the T0CON and INTCON registers. The timer is initially disabled while timer settings are
configured. Timer0 interrupts are enabled, and the timer0 overflow interrupt is set to high
priority by setting the TMR0IE and TMR0IP bits in the INTCON register, respectively. Other
T0CON bits are used to determine how often the timer will increment and about how long the
timer will run before it overflows. Finally, the OpenPeripherals function initializes I2C
communication for data transfer between the digital compass and microcontroller.
Progress: The OpenPeripherals function has been written and tested.
The second function to be called is UserSetup. This function begins by running a startup
sequence in which each of the LED’s is consecutively turned on and then off to signal that power
has been given to the robot. Immediately following the startup sequence, one of the three singlecolored LEDs is illuminated. Each time the user pushes the Cycle pushbutton, a new light is
illuminated. If all three single-colored LEDs are illuminated when the user presses the Cycle
button, all of them will turn off and the sequence will begin again. Once the Run/Ent button is
pressed, the number of LEDs that are lit at that time will be stored as the number of LEDs for the
robot to visit at the end of the traversal. A similar method is used to allow the user to specify
which colored lights will be visited and in what order. An 8-bit variable “orderLED” will be used
to keep track of this information though the setting and clearing of bits. After obtaining the
necessary user input, the LEDs on the body of the robot will start flashing to indicated that the
robot is ready for traversal. Traversal begins when the Run/Ent button is pressed.
Progress: The UserSetup function has been written and tested.
Next, the MapMaze function is called, and the robot begins its traversal of the maze. This
traversal function uses four other functions: TurnRight, TurnLeft, GetCompassData, and
FindNode. The TurnRight function first stops both motors and sets the duty cycles of each of
their PWM inputs to be the same nonzero value. Then the motor inputs are set such that the robot
turns to the right by 90 degrees at which point the motors are stopped again. The TurnLeft
function works similarly. The GetCompassData function makes use of the built-in I2C
capabilities of the PIC18F4550 to obtain compass data and return an integer value indicating the
current direction of movement. Finally, the FindNode function moves the robot forward until a
new node is reached. It checks the various sensors and compass data to determine whether a
node has been reached or direction correction is needed.
Progress: The MapMaze function and sub-functions have been written and tested.
-33-
ECE 477 Final Report
Spring 2013
After calling the MapMaze function, the main function calls the VisitLights function. This
function uses the same functions as the MapMaze function, but this time to revisit the lights
specified at the beginning of the run.
Progress: The VisitLight function has been written and tested.
The last function to be called is the transmitUSB function. This function will be responsible
for transferring the map data structure to a computer via USB. USB functions were adapted from
source [23]. This source includes both firmware and host software for a bidirectional USB
communication example. This example uses byte by byte transfer of data across the USB cable
and was adapted for the COST Robot which will transfer the map structure in a byte by byte
fashion. After transferring the data structure to the computer, host software written in C# will
generate a graphical representation of the maze
Progress: USB transfer code has been written and tested.
Lastly, host software will be written in C# to decode the map data structure on the
computer and translate the map into a graphical representation of the maze.
Progress: The host software graphical user interface has been written and tested.
10.4 Summary
The COST Robot is a compact robot whose first purpose is to traverse and map a maze. Its
second function is to relocate specific spots within the maze marked by colored LEDs in a
predetermined, user-specified order. To provide a user interface, the robot body will feature three
single-colored LEDs, one RGB LED, and two pushbuttons. These will be connected to pins
configured as digital I/O. The robot will move with the use of two motor-wheel combinations.
Each motor will require a PWM channel input and two general purpose I/O inputs to control
speed and direction. To aid in maze navigation, short-range distance sensors, a long-range IR
sensor, an RBG color sensor, and a digital compass will be used. The five sensors will interface
with the microcontroller via A/D pins. The compass, alternately, will make use of built-in I2C
communication capabilities. Lastly, USB will be used to transfer the data structure representation
of the map to a computer where it will be decoded by host software written in C#.
11.0 Version 2 Changes
After building, debugging, and testing the COST Robot, the team learned very much from
completing this project. One of the most important concepts learned is to always have a backup
plan. There were a few methods the team counted on working and found out they were not
reliable later down the road. If it had been planned for overlap in the uses of some of the
peripherals, the team could have had a backup in case one was not reliable. This was mainly the
use of the compass. Since the compass was unreliable, the team spent a lot of time just trying to
-34-
ECE 477 Final Report
Spring 2013
figure out ways to straighten the robot before moving down a hallway. If the team had come up
with a backup plan before testing it on the robot, the team would not have wasted as much time
trying to fix the problem.
Another change that would be made during a second iteration would be to have feedback
on each motor speed. There was a lot of changing motor values in order to get each motor to
balance with each other. However, if there was feedback to tell exactly how fast each motor was
spinning, it would have been easy to balance and tell how quickly to move.
Given another chance, the team would have tried to scan hallways faster. More than half of
the time spent in a maze is only scanning down hallways to measure box length and straighten. If
this could be sped up, the traversal time would be greatly reduced. Now it is known that the data
received from the long range sensor is fairly accurate when sampling at or below the
recommended response time. This means the robot may have been able to scan quickly, but
sample slower and still obtain accurate results to straighten off of.
Last, although this is a small lesson, one thing that would be done in a second iteration
would be to order two batteries instead of just one. There was a lot of down time due to having to
recharge the battery after a few hours. With two batteries the team could have charged one while
using the other.
Other than the lessons mentioned, the team feels like the COST Robot was well thought
out, and the project went very well for a first iteration.
12.0 Summary and Conclusions
The team’s major software accomplishments include USB communication between a
microcontroller and a C# executable, utilizing flash memory to store a representation of the
maze, converting a maze traversal algorithm into programmable code, and utilizing the stored
maze to intelligently find paths to certain locations. These functions work together to allow the
robot to intelligently determine when it is done mapping a maze and how it will go back to
revisit a specified location. These accomplishments also allow the user to easily see what the
robot is “thinking” by using USB to download the map it has generated.
Through these software accomplishments, the team learned to coordinate separately writing
different parts of the code hierarchy. As each portion was being written in parallel,
communication was necessary if the code was to be integrated together. Through some tutorials
and debugging, USB protocol and C# syntax were learned as well.
The major hardware accomplishments include generating and utilizing a PCB to integrate
all components, using feedback sensors to implement a conceptual maze traversal algorithm on a
robot, and controlling robot motion through software controlled PWM. Along with this, a well
thought out chassis needed to be made to house all sensors and components. These
-35-
ECE 477 Final Report
Spring 2013
accomplishments allowed the project to change from a theoretical algorithm to an actual product
to carry out the commands of the concept.
Through working on this project, the team has learned about printed circuit board design
and techniques for soldering surface mount components as well as the aforementioned USB
protocol and C# syntax along with cooperation skills. There have been lessons gained in the
inability of sensors living up to their manufacturer’s expectations as well as the constant need for
a common ground amongst communication partners. Last, the team learned the deceptiveness a
cold joint can have on a circuit if overlooked and the ability to adapt components and software to
fit a project’s needs.
13.0 References
[1] Lowe’s LLC., “Neato Robotics Neato XV-11 Robotic All-Floor Vacuum System” [Online]
Available: http://www.lowes.com/pd_18871-24435-9000001_0__?productId=3322800&cm_mmc=SCE_PLA-_-Appliances-_-VacuumsFloorCare_-3322800&CAWELAID=1023764253&%22cagpspn=pla%22
[2] Microchip Technology Inc., “PIC18F4550” [Online] Available:
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010300
[3] Texas Instruments Inc., “TMS320F28069” [Online] Available:
http://www.ti.com/product/tms320f28069
[4] Battelle LLC. “About Us”, [Online], Available: http://www.battelle.org/about-us.
[Accessed March 27, 2013]
[5] David Bruemmer, Douglas Few, et al. “Autonomous navigation system and method,” U.S.
Patent 7,587,260, Jul. 5, 2006
[6] Shunichi Asaka, Shigeki Ishikawa, et al. “Method and apparatus for avoiding obstacles by a
robot,” U.S. Patent 5,570,285, Sep. 14, 1994
[7] Intellibot LLC. “How It Works”, [Online], Available: http://intellibotrobotics.com/how/us.
[Accessed March 27, 2013]
[8] Stephen Jacobs, James Goodnow, David Knuth, Charles Ward, Allen Bancroft, et al.
“Mapped robot system,” U.S. Patent 6,667,592, Aug. 13, 2001
-36-
ECE 477 Final Report
Spring 2013
[9] Military Handbook Reliability Prediction of Electronic Equipment, 217F ed., Dept. of
Defense, Washington D.C., 1991.
[10] Microchip, “28/40/44-Pin, High-Performance, Enhanced Flash, USB Microcontrollers with
nanoWatt Technology,” PIC18F2455/2550/4455/4550 datasheet, Oct. 2005.
[11] Micrel, “High-Current Low-Dropout Regulators,” MIC29150/29300/29500/29750
datasheet, Dec. 2012.
[12] Texas Instruments, “Quadruple Half-H Drivers,” L293(D) datasheet, Sep. 1986 [Revised
Nov. 2004].
[13] CTS, “HCMOS/TTL Clock Oscillator,” CB3(LV) datasheet.
[14] H. J. Lewis and A. Ryan, (2010, Nov. 02). Printing as an Alternative Manufacturing
Process for Printed Circuit Boards [Online]. Available:
http://cdn.intechopen.com/pdfs/12292/InTechPrinting_as_an_alternative_manufacturing_process_for_printed_circuit_boards.pdf
[15] “B.W. Recycling” [Online]. Available: http://www.webuyics.com/scrap-pcb.htm
[16] “Lithium Battery Disposal Guidelines” [Online]. Available:
http://www.bipowerusa.com/documents/disposal.asp
[17] Author Unknown. (2013). Clocky Robotic Alarm [Online]. Available:
http://www.thinkgeek.com/product/91f2/?rkgid=275668648&cpg=ogpla&source=google_p
la&gclid=CNScjfOvk7UCFbAWMgodpGMAJw
[18] Author Unknown. (2013). iRobot Scooba 230 Compact Floor-Washing Robot with
Cleanser Packets [Online]. Available: http://www.hsn.com/products/irobot-scooba-230compact-floor-washing-robot-with-clea/6495861
[19] Sharp, “GP2Y0A02YK0F”, [Online], Available:
http://www.sharpsma.com/webfm_send/1487 . [Accessed February 21, 2012]
[20] Sharp, “GP2D120XJ00F”, [Online], Available:
http://www.phidgets.com/documentation/Phidgets/3520_0_Datasheet.pdf . [Accessed
February 21, 2012]
[21] Avago Technologies, “HDJD-S822-QR999 RGB Color Sensor”, [Online], Available:
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/LightImaging/HDJD-S822QR999.pdf . [Accessed February 21, 2012]
-37-
ECE 477 Final Report
Spring 2013
[22] Linear Technology. “LTC4150 Battery Gas Gauge Data Sheet”, [Online], Available:
http://cds.linear.com/docs/en/datasheet/4150fc.pdf . [Accessed February 21, 2012]
[23] “18F4550 USB Demo Board” [Online] Available:
http://18f4550.com/USB_demo_board/USB_demo_board.html
[24] Rochester Institute of Technology, “Playing With Mazes” [Online] Available:
http://people.rit.edu/dbsgsh/MAZES3.pdf
-38-
ECE 477 Final Report
Appendix A:
Spring 2013
Individual Contributions
A.1 Contributions of Eric Osborne:
As having the role of analog hardware designer, Eric's major technical contributions to the
project were the final choice of system components, half of the schematic and circuit design,
PCB layout, populating the PCB, most of the system design and building, and a small amount of
coding. Although the team was fairly self sufficient, Eric also was assigned the role of team
leader and occasionally distributed tasks to other team members.
The first part of the semester was spent mainly on planning. Although all team members
helped research which components to use for the robot, each team member gave Eric the part
that was chosen and he was responsible for checking over each part to make sure they would be
compatible with each other. After checking them over, Eric ordered samples for many of the
components. During this time, Eric also spent a lot of time choosing a fuel gauge that would be
easy enough to implement so it would work with the 2-cell battery. Eric and Bryan eventually
decided on a fuel gauge with only a few passive components. Eric and Andy were also able to
decide a low-dropout regulator would work best with the team's design for a few reasons. The
first is that a regular dropout regulator would give just under 5V, which is not sufficient for the
design. The second is that a low-dropout regulator would provide a cleaner reference voltage for
the ADC. Since Eric had this role in the component selection, Eric helped write the component
selection rationale homework as well.
During the next few weeks, Eric and Bryan worked on creating the schematic which
contained the microcontroller, motor drive subsystem, power supply, oscillator circuit, USB
interface, fuel gauge, light array, input headers, and user interface. While doing this, pin
assignments were made for each necessary device. This involved carefully reading datasheets for
pinouts and recommended passive components. Many of the components used required
footprints to be made, so Eric helped Bryan make a few of these. When this was done, Eric
assisted Bryan with his schematic design homework. Shortly after, since he was already familiar
with the schematic and had a good understanding of Eagle, Eric helped Andy with the layout of
the PCB he was responsible for.
Once the PCBs arrived, Eric was the team member responsible for soldering components to
the board. He started by soldering the power supply, tested it, and let it burn in overnight. The
next session Bryan assisted him by referencing the schematic and having parts ready for him to
solder as Eric soldered the component Bryan handed him previously. Eric focused on soldering
all passive components first, and then soldered the microcontroller, programming header, and
LEDs. At this time Eric and Bryan tested the power supply, microcontroller, and LEDs
altogether by programming a heartbeat program and turning the circuit on. Next, Eric was able to
solder all the other components to the board except the USB connector. The team decided it
would be best to leave the USB off until it was fully working with our breadboard. At this time
A-1
ECE 477 Final Report
Spring 2013
the team decided not to use the compass, but were able to test the motors and sensors using our
newly populated PCB. Correction to the PCB was not necessary at this time because all the
soldered components worked.
Eric's next major task involved building the actual robot. He measured and cut the base and
second level octagons as well as drilled holes for support posts and sensor mounting. With some
help, Eric then started mounting everything together and screwed the PCB into the top posts. At
some point, he soldered a small power breakout for the sensors to receive 5V and made the wire
harness for the motors and analog sensors. At this time, the environmental analysis homework
was due so Eric wrote that.
Nearing the last few weeks of the semester, the robot had been built and only a few parts of
code needed to be written, tested, and compiled together. Although the code was mainly handled
by other team members, Eric added a few small things while the other members were focused on
larger portions of the code. For instance, Eric added the timer interrupt and logic for sampling
colored lights only while traversing through a hallway, some distance sensor enable logic that
allowed the robot to start correcting off walls as soon as it passed the previous node, and Bryan
helped him add the interrupt routine and storing of the fuel level for the fuel gauge. During these
last few weeks, while the team was running the robot through mazes, Eric quickly put together
the team poster. He also spent time collecting all previously corrected homework and completed
the final report. Last, Eric created our PSSC demonstration video and posted it online.
A.2 Contributions of Bryan Dallas:
Throughout the semester Bryan worked on many different aspects of the project. He helped
in many different areas being that Bryan is both a digital and hardware person. During the
semester he helped to pick out parts for the robot, helped to design the schematic, helped with
the skeleton code and setup for our micro controller, wrote starts to movement functions to be
tested, modified USB code for use with the robot, and wrote the maze mapping and revisiting
lights algorithms, along with miscellaneous other things.
The first part Bryan helped with, the picking out of parts, was helped in different ways.
First, Bryan contributed ideas as to how to build and program the robot. The reason this was
necessary was to make sure that the team knew how to solve the problem before they ordered
parts. Bryan suggested getting the long range sensor so that the robot would be able to measure
down hallways and be able to tell the distance it traveled. Also, while picking out parts Bryan
helped to find and decide on the parts the team was using. The team worked together to find the
parts. Bryan picked out an I2C to USB part that the team did not end up using, but helped to
research and check that the parts that were used would work. For example, Bryan helped with the
researching of the fuel gauge that was used.
A-2
ECE 477 Final Report
Spring 2013
Next, Bryan helped to design the schematic. Caroline and Eric had worked some on
figuring out which pins would need to be used on the micro controller, and Bryan and Eric
finished that task and worked together on creating the schematic, as well as making the footprints
for the parts that were used.
Continuing on Bryan worked on setting up the skeleton code for the micro controller. He
finished defining the rest of the pins which Caroline had started, he then moved on to setting up
the peripherals in the code. Things such as I2C, USART, ADC, PWM, and the inputs and
outputs of generic pins. Bryan also figured out how to configure some of the parts of the micro
for the team's use, such as the clock. He then started to create functions for the simple tasks of
the robot. Things such as setting the motor speed, delaying, turning left, and turning right. All of
these parts were written without the robot and therefore needed to be tested when it was built and
modified.
The USB code was also something that Bryan worked on. Caroline had tested the example
code we had gotten and wired it up on a breadboard. Bryan then took that code and modified it
so that it would work for transferring the map to the computer. He set up a protocol to transfer
the data between the micro and the C# program. Caroline wrote the code for the C# program,
which he then took and added into the C# program for the USB transferring. Bryan also made a
quick change to make sure that the negative numbers in the struct were handled correctly. Eric
helped him to quickly iron out the bugs he was having when testing it.
Next, Bryan wrote code for maze mapping and revisiting lights. He first worked on the
revisiting lights based on the struct that he had come up with to hold the maze. Bryan used the
data in the struct to find the shortest path to the light that we needed to go to. He then tested this
using sample data Caroline had made. Bryan then modified Caroline's excel file to automatically
make the struct data based on information that was provided. He then added lights to the maze
and made the maze go negative to test each corner case. The map maze code, Bryan wrote
starting with a some pseudo code that Caroline had written. He modified it to handle more corner
cases and removed the idea of using a compass from it, and also added in the functions that were
used for movement. Bryan modified the revisit lights functionality to work in the mapping out
the maze as well because they are similar ideas. The team then tested this part with the robot and
Bryan ironed out the last few bugs that there were.
Finally, Bryan worked on many other miscellaneous tasks. He worked on making the robot
write to flash and hold data correctly. He worked on adding the USB example code to our robot
code. Bryan helped Eric with making the fuel gauge work in our circuit. He also worked with
Eric to populate the PCB. Bryan helped by handing Eric the parts in order and making sure he
had everything so that he only had to solder the parts on. Bryan soldered together some of the
headers that we needed and soldered headers onto some of the parts.
A-3
ECE 477 Final Report
Spring 2013
A.3 Contributions of Andrew Loveless:
Andrew suggested the original project concept – to build a robot to traverse a maze while
visiting specific “beacons” in a certain order. He researched microcontroller choices and found
multiple websites documenting the use of the PIC18F4550 microcontroller. He compared its
capabilities to other similar MCUs and ultimately chose the 18F4550 for the project –
specifically for the tremendous amount of supporting documentation. He ordered a PICkit 2
programmer, DIP versions of the microcontroller, and soldered programming connectors during
the first week of class. This gave the team an opportunity to start writing test code rapidly.
Andrew and Caroline wrote the initial skeleton for the project, including all configurations
settings and declarations necessary to write simple sample routines. Andrew assisted Caroline in
investigating different maze traversal routines, deciding on the Tremaux Algorithm. Andrew
tested the algorithm on multiple sample maze configurations to verify its applicability to our
project.
After Eric and Bryan completed the preliminary schematic with the team’s chosen parts,
Andrew individually, built the final schematic for the project. This new schematic addressed
issues with the original design and made it possible to determine proper component placement
when designing the PCB. He divided the necessary components into subsystems and because of
the simpler layout, he and Caroline were able to find and correct pin assignment issues not
previously apparent in the design. This prompted the team to reconsider the functional
capabilities of each pin in order to more carefully choose port assignments.
Andrew, along with Eric, made the initial PCB layout for the project. The first PCB layout
was cramped and made the intelligent placement of components very difficult. One major issue
was that a large section of the board was being used for an I2C to USB converter chip. Andrew
decided that it would be preferable to utilize the on-chip capabilities of the 18F4550 as this
would free up a large amount of space on the board. In order to implement this change, Andrew
built another version of the schematic. The new iteration eliminated the need for any
intermediate conversion chips in the design and freed up space for a roomier PCB layout. With
this new board space, Andrew also introduced other improvements to the design – including the
use of female headers for access to any microcontroller pin. The schematic was designed to
allow part placement on all four sides of the MCU figure. This allowed him to divide
components into subsystems and place them into labeled groupings reflective of their eventual
placement on the PCB. This made PCB design and layout a much more manageable task, as
components were placed relative to their position on the schematic. Andrew and Eric worked on
designing the new PCB for over a week leading up to the midterm review presentation.
For the rest of the semester, after Eric finished construction of the robot base and chassis,
Andrew focused entirely on writing functions to correctly control the robot’s movement within
A-4
ECE 477 Final Report
Spring 2013
the maze. While Bryan’s goal was to implement the overarching maze traversal algorithm,
Andrew worked to build the necessary movement functions – including obstacle avoidance,
course correction, controlled turning, and measuring. Caroline acted as a bridge between these
two extremes and collaborated with Andrew closely – especially in designing accurate
measurement and turning techniques. Andrew built the code to control the robot while moving
down a hallway – interpreting the change in distance from the side of the robot to the walls over
time to determine the severity of course correction needed. This allowed the robot to correct
harshly when a crash was imminent, but adjust only slightly when a small amount of drift was
detected. Andrew and Caroline then spent a week trying to properly implement the compass into
the movement routines. The compass, however, was ultimately unable to accurately determine
direction and it was dropped from the design. Andrew worked with Caroline for a month to
properly implement all the necessary robot movement functionality into robust and dependable
functions. They expanded Andrew’s hall traversal code to include the ability to detect openings,
branches, dead ends, and colored lights.
Andrew and Caroline then built functions to turn the robot accurately and measure the
distance to the end of a hallway. Since the team lost the use of the digital compass, this
functionality was vital to the success of the project. Once these movement functions were
integrated into the maze traversal code, Andrew was responsible for making adjustments to the
robot movement parameters as needed based on the maze configuration and battery level. This
helped the robot have the best possible chance of traversing each new maze.
A.4 Contributions of Caroline Trippel:
Initially, all team members worked together to select general components and Caroline was
responsible for submitting the parts order form. Andrew had already ordered some PIC18F4550
microcontrollers and the PICkit 2 programmer, so prior to parts delivery, Caroline first worked
with Andrew on constructing the initial skeleton file for the project, adding all microcontroller
initializations necessary to test module functionality. Caroline then worked on testing the timer
module, and adding pin initializations/declarations to the main file that corresponded to the
peripherals used in the project. Schematic and PCB design/layout were largely handled by
Bryan, Eric, and Andy; however, Caroline worked with Andy to find and correct some pin
assignment issues that were initially missed.
With Andy’s assistance, Caroline then worked on choosing an appropriate maze traversal
algorithm, keeping in mind that the robot would need to traverse the entire maze before exiting.
They selected the Tremaux algorithm, an algorithm in which the robot was guaranteed to visit
the entire maze and exit out the entrance, provided that was the only opening. Andy and Caroline
independently tested the algorithm on various mazes to ensure proper functionality. Caroline and
Bryan agreed upon a data structure to use to store the map and exactly how it would be
A-5
ECE 477 Final Report
Spring 2013
represented in flash. Caroline wrote out the algorithm in a combination of psuedocode and
embedded C. This version of the algorithm used the compass to determine orientation/direction
and to control turning. In addition, it assumed all measurement to be highly accurate and easily
divisible by box lengths. Later on however, the compass was abandoned and a new measuring
method adopted. At this point, Bryan took over algorithm development and eliminated compass
dependencies.
After this, she moved focus to implementing USB communication. Using a tutorial specific
to the PIC18F4550, she was able to establish communication between the computer and
microcontroller. Caroline developed a sample application in which C# host software could
communicate with the microcontroller bidirectionally via USB. The C# host software consisted
of a GUI with two labels and three pairs of radio buttons. Each label corresponded to a
pushbutton connected to a micro input pin while each pair of radio buttons corresponded to an
LED connected to a micro output pin. Upon a successful USB connection, the GUI labels would
be updated to “pressed” or “not pressed” depending on the state of the pushbuttons (micro
communicating with computer), and the GUI radio buttons could be used to turn LEDs on or off
(computer communicating with micro). This would later be used to transfer an ASCII
representation of the mapped maze of to the computer to be interpreted by a C# program. Bryan
then took this file and linked it to Caroline’s previously tested USB protocol adding any
necessary modifications handshaking protocol.
Next, Caroline and Andrew began working together on robot movement. Andrew
developed a very effective method for traveling down hallways in a relatively straight line.
Caroline then worked with Andrew to develop a means by which to gracefully avoid imminent
collisions with walls. They tested this many times, adjusting motor values until the robot moved
perfectly down a straight hallway.
After finalizing straight movement, Caroline and Andrew began developing techniques for
accurate turns and measurements. First, they aimed to control turning and straightening with the
use of the digital compass. However, due to the magnetic field produced by the motors, it proved
impossible to use for the intended application. After much debugging and testing, Caroline and
Andrew decided that the compass would not be used. Instead they developed methods for
straightening and measuring based on samples taken from the long-range sensor. Andrew
linearized the output of the long range sensor. Then he and Caroline adjusted the regression
constant to exaggerate the measurement differences between box increments. This allowed for
measurements to be immediately converted to box lengths. Through this process, they made an
effective straightening algorithm and determined that the long range sensor could not accurately
detect distances of less than three boxes in front of it. The straightening algorithm was so
effective that it made it possible to make turns based on delays – straightening the robot before
and after.
A-6
ECE 477 Final Report
Spring 2013
Caroline and Andrew then took all of the movement functionality and organized it into
functions to be used by the Tremaux and Visit Lights algorithms. They expanded hallway
traversal to include sensor sampling in order to stop the robot at openings, dead ends, and
colored lights. The functions that they developed with then incorporated into the new version of
the Tremaux algorithm and Visit Lights code that Bryan had written. At this point all team
members were involved with the debugging process, testing various mazes and making
adjustments as necessary, with major logical adjustments being made by Bryan.
A-7
ECE 477 Final Report
Appendix B:
Spring 2013
Packaging
Figure B-1: Front View of the Robot
B-1
ECE 477 Final Report
Spring 2013
Figure B-2: COST Robot Base Structure
B-2
ECE 477 Final Report
Spring 2013
Figure B-3: COST Robot Motor and Wheel Design
B-3
ECE 477 Final Report
Spring 2013
Figure B-4: COST Robot Interfacing Components
B-4
ECE 477 Final Report
Appendix C:
Spring 2013
Schematic
Figure C-1: Full Schematic Diagram
C-1
ECE 477 Final Report
Spring 2013
Figure C-2: Power System
C-2
ECE 477 Final Report
Spring 2013
Figure C-3: Oscillator
C-3
ECE 477 Final Report
Spring 2013
Figure C-4: Motor Control
Figure C-5: Analog Sensor Input Port and Pushbuttons
C-4
ECE 477 Final Report
Spring 2013
Figure C-6: Microcontroller and Headers
C-5
ECE 477 Final Report
Appendix D:
Spring 2013
PCB Layout Top and Bottom Copper
Figure D-1: PCB Top Copper with Silkscreen
D-1
ECE 477 Final Report
Spring 2013
Figure D-2: PCB Bottom Copper with Silkscreen
D-2
ECE 477 Final Report
Spring 2013
Figure D-3: PCB Top and Bottom Layers Together
D-3
ECE 477 Final Report
Appendix E:
Vendor
Spring 2013
Parts List Spreadsheet
Manufacturer
Part No.
Solarbotics
Solarbotics
Sparkfun
SuperBrightLEDS
Sparkfun
Phidgets
Sparkfun
Texas Instruments
SuperBrightLEDs
Avago
Phidgets
Sharp
GM3 (224:1 90 Degree
Shaft), Blue
SN754410
5050-RGB
SEN-10904
1103_1
GP2Y0A02YK0F
Mouser
Microchip
PIC18F4550-I/PT
SuperBrightLEDS
All-Battery
SuperBrightLEDs
Samsung
RL5-RGB-C
31444
Trossen Robotics
Trossen Robotics
PO-950
Description
Wheel and shaft package
H-Bridge Motor Driver 1A
RGB 5050 SMD LED
HDJD-S822 Color Sensor Breakout
1103_1 - IR Reflective Sensor 10cm
Infrared Proximity Sensor Long Range Sharp GP2Y0A02YK0F
8-bit Microcontrollers - MCU 32kBF
2048RM FSUSB2
RL5-RGB-C Clear TriColor LED
AT: Samsung Li-Ion 18650 Cylindrical
7.4V 2800mAh Flat Top Rechargeable
Battery w/ PCM Protection
Pololu Ball Caster with 3/8 Inch Plastic Ball
Unit
Cost
Qty
Total Cost
$7.98
3
$23.94
$2.35
$0.74
$24.95
4
10
1
$9.40
$7.40
$24.95
$10.60
$14.95
3
1
$31.80
$14.95
$5.48
3
$16.44
$1.59
$24.99
5
1
$7.95
$24.99
$2.99
1
$2.99
TOTAL
E-1
$164.81
ECE 477 Final Report
Appendix F:
Spring 2013
FMECA Worksheet
Sub-blocks
A- Microcontroller
B- Fuel Gauge
C- User I/O
D- Power
E- Motor controller
Failure
No.
A1
Failure Mode
Possible Causes
Pin output stuck
at ‘1’
Over voltage to the
microchip
A2
Pin output stuck
at ‘0’
Under voltage to
microchip, microchip
“burned” out
A3
Failure of A/D
channel(s)
Chip defect, software
malfunction, bad
reference lines, noisy
power lines
B1
Battery reading
discharging to
quickly
Rsense shorted, Cf
shorted
Failure Effects
Method of
Detection
Observation –
Inspect pins,
overheated Hbridge
Short circuit in Hbridge, LEDs
always off,
invalid USB
communication
LEDs stuck on,
Observation –
fuel gauge does
All LEDs stuck
not turn on,
on, probing pins
unable to control
motors
Erratic movement Observation –
of the robot
Robot does not
move through
the maze
correctly
Misinformation to Observation –
the user about the battery indicator
battery state
drops quickly
F-1
Criticality
Remarks
High
This assumes that
multiple pins are stuck
at ‘1’
Low
This could be 1 or more
pins stuck at ‘0’
High
Low
ECE 477 Final Report
Spring 2013
Observation –
robot is not
running
Low
Observation –
Battery
discharges at an
slower rate than
reality
Observation –
Microcontroller
stops working,
probing the
resistors
Observations –
button presses
are erratic
Low
No information to
user
Observation –
LEDs don’t
work
Low
Short to battery,
no power to
circuit
Kills the battery
quickly by
drawing to
much current
High
B2
Battery reading
not discharging
Rsense open circuited Thinks the battery
is not
discharging, no
power to board
B3
Battery
discharging at too
slow a rate
Cf open circuited,
R16/R17 open
circuited
Misinformation to
user about the
battery state
C1
Microcontoller
stops working
R(7-12) or R14/15
short circuits
Robots stops
running
C2
User input fails
R13/14/15 open
circuits
User buttons are
floating
C3
LEDs don’t turn
on
R(7-12) open circuits
D1
No power to
circuit
Cout_reg, Cpow5d,
Cin_reg, Cinbulk,
Cdpowin short
circuited, linear
regulator dead
F-2
Low
Low
This assumes the micro
will stop working from
too much current to the
micro from the I/O
ECE 477 Final Report
Spring 2013
D2
5V Power rail >
5V
Linear regulator
failed
Damage to
components on
PCB
Observation –
regulator too
hot, smoke
High
D3
5V Power rail <
5V
Linear regulator
failed
Robot doesn’t
work
Observation –
smell or
probing circuit
High
D4
7.4 V Power rail
> 7.4 V
Overcharging/Failure
of battery
Damage to all
components
Observation –
bloated
battery/battery
leakage, etc.
High
D5
7.4 V Power rail
< 7.4 V
Battery level too low,
battery “died”
Robot will not
turn on, or is
unstable
Observation –
Robot does not
work
Low
E1
Erractic behavior
of output pins of
digital isolator
Decoupling
capacitors shorted
Unable to control
robot
Observation –
Robot will
move erratically
High
E2
No output to
motors
Digital isolators
failed, H-bridge
failed,
Cd(1/2)_iso(1/2)
open circuited
Motors will not
run
Observation –
robot does not
move
Low
F-3