Display On VGA Without SDRAM

ECE 477 Final Report  Spring 2010
Team 11  RoboSiM
Miles Ryan
Whittaker Taylor
Michael
Bryan Mize
McDonnel
Team Members:
#1: Bryan McDonnel Signature: _Bryan McDonnel_______ Date:

_5/03/2010
#2: Michael Mize Signature: _Michael Mize_ ______ Date:

_5/03/2010
#3: Ryan Taylor Signature: __Ryan Taylor ________ Date:

_5/03/2010
#4: Miles Whittaker Signature: __Miles Whittaker______ Date:

_5/03/2010
CRITERION SCORE MPY PTS

Technical content 0 1 2 3 4 5 6 7 8 9 10 3
Design documentation 0 1 2 3 4 5 6 7 8 9 10 3
Technical writing style 0 1 2 3 4 5 6 7 8 9 10 2
Contributions 0 1 2 3 4 5 6 7 8 9 10 1
Editing 0 1 2 3 4 5 6 7 8 9 10 1
ECE 477 Final Report Spring 2010
Comments: TOTAL
TABLE OF CONTENTS
Abstract 1
1.0 Project Overview and Block Diagram ?
2.0 Team Success Criteria and Fulfillment ?
3.0 Constraint Analysis and Component Selection ?
4.0 Patent Liability Analysis ?
5.0 Reliability and Safety Analysis ?
6.0 Ethical and Environmental Impact Analysis ?
7.0 Packaging Design Considerations ?
8.0 Schematic Design Considerations ?
9.0 PCB Layout Design Considerations ?
10.0 Software Design Considerations ?
11.0 Version 2 Changes ?
12.0 Summary and Conclusions ?
13.0 References ?
Appendix A: Individual Contributions ?
Appendix B: Packaging ?
Appendix C: Schematic ?
-ii-
Appendix D: PCB Layout Top and Bottom Copper ?

Appendix E: Parts List Spreadsheet ?
Appendix F: FMECA Worksheet ?
-iii-
Abstract
RoboSiM (Robotic Surveillance in Motion) is a fully autonomous, GPS-guided platform

that is capable of navigating to a target location, recording audio surveillance, and returning back
to the home location. It uses a suite of onboard sensors to detect and avoid obstacles in its path.
The rover’s small size makes it ideal for remote surveillance operations with minimal user
interaction.
The team was able to design and construct a working prototype that performed GPS
navigation calculations, basic obstacle detection, and audio recording. Although the audio quality
was poor, and the robot occasionally stalled because of obstacles with corners, all of the major
design goals of the project were met, and the team considers RoboSiM to be a success.
1.0 Project Overview and Block Diagram
RoboSiM is utilizes a GPS, digital compass, three ultrasonic sensors, and a PIC24H
microcontroller to make autonomous navigational decisions. The three ultrasonic sensors are
connected to the ADC module of the PIC24H in order to determine distance to obstacles. The
digital compass is communicated to through I2C and is used to determine current heading. The
GPS is communicated to through UART and is used to determine the current location of
RoboSiM. The PIC24H uses all of the peripheral data to determine the heading that is wanted,
how to avoid obstacles, and when the target is reached. Once the target is used, a microphone
connected to the ADC module of the PIC24H is used to record audio. Then RoboSiM uses the
sensors to navigate back to the starting location.
A-1
A-2
2.0 Team Success Criteria and Fulfillment
1. An ability to display the current status of the robot on an external display

RoboSiM’s LCD display is fully functional. During navigation, the display shows the
destination coordinates; when recording, it indicates how much time is left before recording is
finished. Between these modes, the display prints initialization information, such as GPS cold-
start time and satellite fix status.
2. An ability to read and write data from a portable media device

SD card support on RoboSiM is fully functional. On start-up, destination GPS
coordinates are read from the file “TARGET.TXT” on the card. After surveillance audio has been
recorded, it is stored to the file “AUDIO.ALW”.
A-3
3. An ability to make navigational decisions based on sensor, GPS, and digital compass data
RoboSiM will use GPS coordinates and heading information from the digital compass
to determine the proper direction of travel to reach the target coordinates. Ultrasonic sensors
detect obstructions and signal the navigation system to adjust the route to prevent a collision.
Some corner cases will confuse the obstacle detection, but RoboSiM will generally avoid
collisions and successfully reach the destination.
4. An ability to move robot using steering and motor drive

Kinetic control is fully functional. Two brushed dc motors control independent tracks,
which are operated in a differential drive configuration. As a result, RoboSiM is able to move in
both medial directions and turn with a near-zero turning radius.
5. An ability to record and encode audio

Audio recording is performed with a simple electret microphone and op-amp
configuration. During RoboSiM’s recording phase, audio samples from the amplifier output are
taken by the microcontroller’s ADC block, then encoded in A-Law PCM format. The resultant
audio files are generally very noisy, and the speaker must be within 12 inches of the microphone
to be distinguishable. However, it is possible to discern both the identity of the speaker and the
content of the speech.
3.0 Constraint Analysis and Component Selection
1.0 Introduction
This project’s goal is the development of a GPS-guided, autonomous, robotic
platform, capable of performing surveillance tasks. The system should be capable of traveling
unguided to a preprogrammed destination, avoiding any obstacles along the way. Once there, the
system should be able to capture and store audio samples. When the surveillance has been
completed, the vehicle should be able to return to its starting position for data retrieval. But, in
order for this project to be considered a success, the platform must specifically demonstrate an
ability to:
A-4
1. Display the current status of the robot on an external display.

2. Read from and write to a portable media device.
3. Make navigational decisions based on sensor, GPS, and digital compass data.
4. Control the robot using steering and motor drive.
5. Capture and encode audio.
For the project to succeed, it will be necessary to integrate several peripherals,
including a GPS unit, a digital compass, ultrasonic sensors, motors, an LCD screen, an SD card
reader, and a microphone. All peripherals will be managed by a microcontroller, which will
perform all digital-to-analog conversion, pulse-width modulation, and navigational control. In
addition to the microcontroller, a digital signal processor will be needed for encoding the
captured audio in a standard format.
2.0 Design Constraint Analysis
The Guided Robotic Autonomous Surveillance Platform (GRASP) project has several
important constraints to consider. The platform is intended as a surveillance tool for military
applications. To this end, the vehicle needs to be reliable, small, and quiet. Unfortunately, these
three characteristics are not mutually exclusive.
As a tool, it is important for the vehicle to be dependable. It must not only travel to the
correct target position, but arrive there quickly and efficiently. This means that the vehicle needs
ample computational power as well as reliable supporting electrical systems. The size of the
chassis determines what electrical components can be used, and contributes to the overall noise
dissipation.
Size, in a way, determines the reliability of the platform. Depending on the design of
the chassis, the vehicle may be able to traverse certain types of terrain it may not otherwise be
able to. Similarly, sound requirements can be met by using damping materials, but not without
affecting possible chassis designs or heat dissipation characteristics.
The following sections will detail these considerations, among others that will shape
the course of this project.
2.1 Computation Requirements
The navigational effectiveness of the vehicle depends largely on the computational
capabilities of the chosen microcontroller. In order to reliably control the vehicle’s trajectory, and
accurately detect and avoid obstacles, it will be necessary to update the robot’s heading several
times a second. GPS modules can be configured to produce position updates at various regular
intervals (e.g., 10Hz) [2], giving a discrete window in which a single update computation must
A-5
be completed. Given a single-cycle microcontroller with a 32MHz clock speed, like the
ATxmega256A3 [5], and a 10Hz GPS refresh rate, a navigational update has a window of
roughly 3.2 million instructions in which to be completed. This should be more than enough time
to perform the necessary analog-to-digital conversions, decide on a new heading, issue new
pulse-width-modulated signals to the control motors, and update the LCD screen.
The digital signal processor’s computational power isn’t much of an issue for this
design, since most commercially available DSP chips will be capable of converting audio input
into the proper format with sufficient speed (e.g., 200MHz clock speeds). But, the
microcontroller will have to be able to handle a steady stream of data from the DSP and send it
out to the SD card in a timely manner. However, the update window won’t be a constraining
factor while recording audio, since the vehicle will be stationary while recording audio.
2.2 Interface Requirements
Gathering all of the necessary data for a single navigational update will require the
microcontroller to utilize several different interfaces. The ultrasonic sensors and battery sensor
would each need an analog-to-digital conversion channel (4 pins) [8], and the digital compass
module uses an I2C interface (2 pins) [9]. Each DC motor would need a PWM channel and two
control lines (6 pins), the DSP and SD card use an SPI interface (8 pins) [6, 7, 3], and the GPS
unit needs a UART interface (2 pins) [2]. Most LCD screens need several-bit wide buses, but this
is easily circumvented by an external shift register (1 pin) if the microcontroller is input/output
constrained.
At most, 33 input/output pins would be needed, a number not unreasonable for a lot of
commodity microcontrollers. A TQFP ATxmega256A3, for example, has 50 available
input/output pins, easily meeting this project’s requirements [5].
2.3 On-Chip Peripheral Requirements
The GRASP project requires at least 4 separate analog-to-digital conversion channels,
2 pulse-width modulation channels, an I2C module, multiple SPI modules, and a UART module.
These are all standard on most commercially available microcontrollers, and this project doesn’t
require a large number of any one type of interface. As a result, GRASP isn’t limited by unusual
requirements of particular types of communication protocols, widening the range of acceptable
microcontrollers.
2.4 Off-Chip Peripheral Requirements
A-6
As stated above, any LCD screen used for displaying the state of the vehicle would
require a several-bit wide communication bus. To conserve input/output pins on the
microcontroller, it may be necessary to use a shift register to convert a serial output from the
microcontroller to a data bus of the needed width. But, if a microcontroller with an ample
amount of input/output pins is used, this won’t be needed.
2.5 Power Constraints
A mobile robot must contain an onboard power supply in order to be truly self-
contained; many commercially available platforms (RC helicopters, for example) use
rechargeable battery packs in concert with voltage regulators to supply all of the onboard
hardware. A similar approach will be used for this project.
Because this design utilizes differential drive technology, the propulsion will be
controlled by two independent DC motors. While there are many DC motors available on the
market, this application will require motors with relatively low torque, as the robot is planned to
be small and lightweight. Additionally, the vehicle will employ only a small set of sensors and
two microcontrollers. As a result, a single rechargeable battery pack will be able to support both
the propulsion hardware and the control electronics.
An adequate battery for this application would be a 7.2V NiMH unit with a 2300mAh
capacity. A rough estimate of the current drawn by the entire GRASP system is around 750mA
continuous, which would yield a 3.1 hour battery life.
A NiMH battery pack with a small form factor is desirable, so that space requirements
will not be a major factor for integration. To regulate temperature, the battery will be placed in a
location with exposure to external airflow (such as the undercarriage of the robot).
At least two voltage regulators will be employed (one for the motors and one for the
microcontroller/sensor array), so heat generation is expected on the PCB. Components with
built-in heatsinks would minimize construction costs.
2.6 Packaging Constraints
Because the robot is intended as a surveillance machine, it is important to keep the
entire system as small and discrete as possible. Selecting a small RC car as a platform base will
keep the entire system compact.
In order to use GPS technology, the robot will most likely need to be in an outdoor
environment. As a result, the electronics will need to be protected from moisture and debris
A-7
sources commonly found outside. A simple plastic shield over the top of the robot will be useful
for protection and could be painted with a camouflage pattern to maintain stealth. If additional
protection is needed, the entire circuit could be coated with a potting material such as hot glue.
Another major concern for a mobile platform is vibration from moving along an
uneven surface. An RC base platform with shock absorption should provide enough protection,
assuming it has been carefully constructed.
2.7 Cost Constraints
The project cost is estimated at $386, as detailed by the parts list at the end of this
document. The most significant single costs are the GPS unit, the RC car base, and the ultrasonic
sensors. It will be important to find suppliers who are willing to offer free samples. The
ultrasonic sensors should be the easiest to obtain for free, whereas the RC car base will be the
most difficult to obtain for free.
The supporting hardware for the project (voltage regulators, bypass capacitors,
resistors, etc) have an estimated cost of $25 dollars, which could be decreased significantly by
obtaining parts from the senior design lab stock and willing suppliers.
3.0 Component Selection Rationale

There are two options to consider when deciding on a chassis base for the vehicle: a
pre-built chassis salvaged from an RC car, or an ad hoc construction. A pre-built RC car will
obviously be more expertly constructed, and possibly more reliable. But, an ad hoc constructed
chassis would be more customizable, allowing for greater flexibility in the layout of the
electrical systems. A purchased chassis, however, would likely be cheaper and quicker to obtain,
freeing up construction time to be focused on electrical design.
When considering microcontrollers, it is important to know what peripherals with
which it needs to interact. For the GRASP project, there are two distinct front-runners: the
Atmel ATXmega256A3, and the Freescale 9S12C32. Several peripheral modules are required by
this project, as detailed in the above sections. And, after identifying supplementary parts, it soon
became apparent that the 9S12 didn’t support I2C [4]. The ATXmega256A3, on the other hand,
supports all of the necessary peripherals [5], and is readily available from Digi-Key online. The
AVR microcontroller has 256KB of flash memory, multiple SPI, UART, and I2C interfaces[5].
A-8
With help from the course staff, two possible candidates for the audio signal processor
have been identified: the Analog Devices ADSP-21262 (from the SHARC series) and the
Microchip dsPIC-33. The DSP will be responsible for analog to digital conversion of the audio
signal from the microphone, encoding into MP3 format, and transmission to the microcontroller.
Microchip’s dsPIC-33 architecture contains a 10-bit analog-to-digital converter that
operates at up to 2Msps [7]. To capture human speech, the system will need to store at least
48ksps (otherwise aliasing will occur in the speech waveform); the dsPIC satisfies this
requirement. The dsPIC can communicate over SPI to the microcontroller (the block diagram
shows this connection), which will be sufficiently fast to transfer the encoded audio to the
microcontroller (and subsequently to the storage medium) [7].
Perhaps the most important phase for the DSP chip is the audio encoding. The team
has tentatively selected the MP3 codec, although there are indications from other hobbyists that
the dsPIC may not be suited for this format. The dsPIC-33 does support a number of ITU
standard formats for speech encoding, such as G.711 and G.726A [7], which makes it a powerful
option.
PIC microcontrollers have been historically user-friendly, and there is a large code
base from which to draw examples and implementation ideas. This ease of use will be important
for the code development phase of the project. Compared to the ADSP-2162, the dsPIC-33 has
also been, for past teams, easier to integrate.
The Analog Devices SHARC ADSP-21262 is a 32-bit processor tailored specifically
for audio processing [6]. Unlike the dsPIC-33, there are no analog-to-digital converters on the
board, so external hardware must be used [7]. Adding an external analog-to-digital converter will
complicate the design, and it may be possible to use one of the spare analog-to-digital conversion
channels on the microcontroller to convert the audio signal and send that data to the DSP board
through SPI or UART.
The power of the ADSP-21262 lies in its ability to encode MP3 (and other audio
standards). Its clock rate (200MHz) is significantly greater than the microcontroller (an Atmel
AVR has a clock rate of up to 32MHz) [6, 5], so the encoded waveform should be available
quickly relative to the availability of un-encoded audio data. With this high clock rate, the power
consumption of the device is higher than that of the dsPIC-33 (1.65W vs 1.00W). As detailed
A-9
previously, power consumption should be minimized on a mobile platform to extend battery life
and reduce heat creation.
The ADSP-21262 has a very useful evaluation board with factory-supplied example
code, which should make software development easier. According to the course staff, however,
this part has been historically harder to integrate outside of the development board environment.
Because there are many functional parts of the robot, it will be important to minimize integration
difficulty.
4.0 Summary
The success of this project depends heavily on the adequate consideration of the
constraints laid out in the above sections. An ATxmega256A3 microcontroller provides more
than enough peripheral modules and input/output pins for controlling all of the different devices
on the vehicle. The Venus-based GPS module is very accurate and has a serial interface. The
Xiamen Ocular LCD screen and has a well documented communication protocol. Previous teams
have had success with ultrasonic sensors and dsPIC-33 digital signal processors. With all of these
decisions completed, the project can begin in earnest.
4.0 Patent Liability Analysis
1.0 Introduction
When manufacturing a product, maximizing profit is the biggest goal. Therefore, it is
important to minimize any chances of patent infringement to save on costs. The key areas we
may be infringing on any patents, are our navigation algorithm, our method of detecting
obstacles, and the format we chose to write to the SD card with which is FAT32. Below are the
results of patents searches related to those three areas and an analysis of each liability as well as
what actions would be taken to avoid any lawsuits.
2.0 Results of Patent and Product Search

The four primary functions performed by RoboSiM will be navigation, object
detection, recording audio, and storing data to an SD card using FAT32 format. Searching for
patents in these four categories yielded three results. US patent number 5,758,352, titled
Common name space for long and short filenames [11], claims a directory system for accessing
A-10
files using FAT32 format and was filed on September 5, 1996. US patent number 7,587,260,
titled Autonomous navigation system and method [12], claims an algorithm for autonomously
navigating a mobile robot and was filed on July 5, 2006. US patent number 7,688,676, titled
Sonar scanner [13], claims a method of detecting obstacles by using reflected sound waves and
was filed on May 5, 2008.
2.1 Common Name Space For Long and Short Filenames

This patent provides a common namespace where each file has one or more long
filenames and one short filename associated with it. The long filenames are set up to minimize
any compatibility issues. The key claims of this patent include a method of accessing files using
five steps. First, create a directory. This would hold the short name and location of any files
inside of it. Next, a second directory is created, holding the short name, and the first portion of
the long name associated with the file. The third step involves storing the first two directories to
the same storage device among any other existing directories used by the directory service. Then,
access the file using the second directory. Finally, create and store a sequence of additional
directories containing the next portions of the long filename. This claim is repeated to apply to
many computer systems using multiple forms of storage.
2.2 Autonomous Navigation System and Method

This patent defines a robotic platform which would perform instructions
autonomously to navigate to a desired location and the algorithm used to achieve this goal. A
robotic platform is defined as having sensors, motors, and a controller. The algorithm is defined
by setting a time frame, referred to as an event horizon, which is based on the current velocity of
the robotic platform. Then, movement is based on whether an obstacle is detected within this
event horizon. If an obstacle is detected, rotation and velocity are adjusted to compensate. First
the robotic platform will determine if it is blocked in the forward direction. If not, it will
continue forwards, otherwise, it will stop and check one of the lateral sides. If one of the lateral
sides is unblocked the robot will turn and continue on in that direction. However, if the robot is
blocked on all sides it will chose the direction with the obstacle furthest away and continue on in
that direction.
A-11
Another key claim is that the robot will include a storage medium with instructions to
be performed by the controller to successfully navigate autonomously. These instructions include
the maximum translational and rotational velocities, methods for calculating the event horizon,
methods for determining if an obstacle is detected, and the ability to change the velocities if need
be. There are also instructions used to determine whether or not obstacle detection is already in
progress.
2.3 Sonar Scanner

The final patent is a method for detecting obstacles by using sound waves. This is
done by sending out sound waves and receiving an echo back. Then determining whether or not
the echo is from the original sound wave. If not, it is ignored, otherwise calculations are done on
the threshold value of the echo and any plural echoes within a set time frame from the first echo
to determine the distance to the surface reflecting the echoes back. This method of detecting
obstacles can be used to control a mobile robot.
3.0 Analysis of Patent Liability

Using FAT32 format to store the target and home coordinates and any defined values,
such as how long to record audio, would be a literal infringement on US patent number
5,758,352. While not clear at first how RoboSiM could infringe on the patent, it becomes more
apparent once you realize that the FAT32 format uses the directory structure defined by the
patent.
Our navigation algorithm would be an infringement of US patent number 7,587,260
under the doctrine of equivalence. While not exactly the same since we do not define an event
horizon based on the robots velocity, we do accomplish substantially the same thing in
substantially the same way. Our algorithm detects objects in the same manner by first checking
forward and then the sides and then making any necessary changes to the velocity of the robot.
Another key difference is that our robot will ultimately be reaching a specified target destination,
though this extra functionality would not alleviate any liability issues.
The ultrasonic sensor that we implement for obstacle detection would be a literal
infringement on US patent number 7,688,676. RoboSiM would use sound waves to determine if
A-12
an obstacle exists and how far away it is. Then it would make a navigational decision to
maneuver around the obstacle.
4.0 Action Recommended

Since there could clearly be a case made of infringement on the three patents
mentioned, some actions must be taken to alleviate any potential lawsuits. In the case of US
patent number 5,758,352, we would simply need to license the use of this patent from Microsoft.
On December 3, 2003 Microsoft released the announcement that they would license their patents
for the FAT32 format at $0.25 per unit sold or a maximum of $250,000 per license [14]. To make
matters worse there are three other patents that must be licensed from Microsoft in order to use
FAT32. Another way around this would be to use a more open standard.
In order to avoid a lawsuit due to infringement on US patent number 7,587,260, we
could do one of three things. First, we could again purchase a license of the patent. However, if
RoboSiM were to be a high demand product, it may be more profitable to purchase the patent
outright. Finally we could just develop another algorithm for determining how to detect and
avoid obstacles. Along these lines, we would need to license US patent number 7,688,676 or if
we do decide to develop an alternative algorithm we could just use a different type of sensor
other than sonar. Although, there would likely be other patents that would be infringed upon for
any other sensor we might use.
5.0 Summary
In conclusion RoboSiM very likely infringes on patents Common name space for long
and short filenames, Autonomous navigation system and method, and Sonar scanner. These three
patents cover three of the four primary functions that RoboSiM will perform. In order to get
around that we would license the FAT32 format, purchase the patent granting us the ability to
autonomously navigate, and license the patent that would allow us to detect obstacles using
either an ultrasonic sensor or a cheaper alternative.
List of References
A-13
4.0 Reliability and Safety Analysis
2.0 Introduction
RoboSiM is an autonomous, GPS-guided robotics platform intended to navigate through
a series of user-programmable waypoints to a target destination, discretely record audio
surveillance, and then return to its starting location. Its mobile nature and outdoor operation
introduce risk factors that affect safety and reliability. As well, component failures can affect
system performance.
The most risk-prone functional blocks of this platform are the power supply and motor
control system. Operating temperatures in these devices are expected to be higher than the
ambient environment, and currents spikes may drive the devices near maximum ratings. In
addition to a reliability risk, faults in these systems have the potential to cause personal injury.
Because the microcontroller is a complex digital component, it is also a reliability hazard.
Faults on single pins may cause unexpected LCD outputs and motor behavior. Whole functional
block failures may lead to faulty navigational decisions. Understanding the failure rates of risky
components and failure modes in each functional block is important in system design and risk
mitigation. A detailed analysis of each follows.
5.0 Reliability Analysis

Of the variety of components used to realize RoboSiM’s design, there are five
components that pose the greatest risk to platform reliability: AOD413 (power MOSFET, 6V
supply), TA8429A (H-Bridge controller), LM22672MR-ADJ (switching controller, 3.3V supply),
TPSB476K010R0250 (output capacitor, 6V supply), and PIC24HJ128GP306 (microcontroller).
5.1 Components at Risk

The AOD413 MOSFET is used as a 6V buck converter switch, exposing it to potential
currents of up to 5A and heat accumulation. Because of its elevated operating temperature and
constant switching, it is at a greater risk of failure than most of the components in the design.
RoboSiM’s kinetic system is driven by a pair of brushless DC motors, each managed by a
TA8429A H-bridge controller. As with the AOD413, these components are expected to handle
A-14
large currents (up to 2.45A each at motor stall) and high junction-to-ambient temperatures (up to
140 °C). Together, these factors elevate the risk of a premature failure.
Although the 3.3V power supply will handle less current that the 6V supply (only up to
500mA), the LM22672MR switching controller uses an integrated MOSFET to control the buck
regulator. As a result, this package is likely to accumulate heat and handle large current
transients. The control logic inside the package also contributes to the chance of component
failure.
Ideally, capacitors are derated by 50% of the maximum operating voltage or more to
prevent excess wear. The output capacitor in RoboSiM’s 6V power supply, a 33µF AVX tantalum
device, has a rated voltage of 10V, resulting in a derating of only 40%. As a result, there is a
slightly elevated risk of capacitor failure. A fault of this sort could potentially damage the motors
or the 6V power supply, making the risk important to consider in this analysis.
The PIC24H microcontroller is not expected to handle a large amount of current (relative
to the power components), but it is the most complex device on the platform. As well, it is an
integral part of the navigational system. Choosing the correct set of operating conditions to
reduce the risk of part failure is important to guarantee RoboSiM’s functionality.
5.2 Failure Rate Analysis
Component: AOD413 6V NPN MOSFET

Model Used: Transistors, Low Frequency, Si FET
λp = λb*πT*πA*πQ*πE
Parameter Description Qualifier Value Comments
Name
λb Base Failure Rate MOSFET 0.0120 -
πT Temperature Factor 140 °C 6.0 Ttyp = 25 °C + (6V)
(480mA)(40°C/W) =
140.08 °C
πA Application Factor Power FET 2.0 6V supply switch

πQ Quality Factor Plastic 8.0 Not MIL-SPEC
πE Environmental GM (Ground 9.0 -
Factor Mobile)
Entire Design: λp = 10.368 failures per 106 hours MTTF = 11.003 years per failure
A-15
Component: TA8429A H-Bridge Controller

Model Used: Hybrid Microcircuit
λp = (ΣNc*λc)*(1 + 0.2πE)*πF*πQ*πL
Parameter Name Description Qualifier Value Comments
Nc1 Number of Discrete - 1 1 Power MOSFET

Components
Nc2 Number of Logic - 1 1 Control Logic Array
Microcircuits
λc1 Failure Rate, Discrete See Figure 9 0.0390 Transistors, Low-
Components Frequency, Si FET
λc2 Failure Rate, Logic See Figure 10 0.1440 Microcircuits,
Microcircuits Gate/Logic Arrays
πF Function Factor Power 21.0 High Currents &
Temperatures
πQ Quality Factor Commercial 10.0 Not MIL-SPEC
πL Learning Factor >2.0 Years 1.00 Introduced October
2008
πE Environmental Factor Ground Mobile 4.00 -
Component: LM22672MR-ADJ 3.3V Regulator Switching Controller

Model Used: Hybrid Microcircuit
λp = (ΣNc*λc)*(1 + 0.2πE)*πF*πQ*πL
Parameter Name Description Qualifier Value Comments
Nc1 Number of Discretes - 1 1 Power MOSFET

Nc2 Number of Logic - 1 1 Control Logic Array
Microcircuits
λc1 Failure Rate, Discretes See Figure 11 0.0150 Transistors, Low-
Frequency, Si FET
λc2 Failure Rate, Logic See Figure 12 0.0888 Microcircuits,
Gate/Logic Arrays
πF Function Factor Power 21.0 High Currents &
Temperatures
πL Learning Factor >2.0 Years 1.00 Introduced 2001
πE Environmental Factor Ground Mobile 4.00 -
A-16
Component: TPSB476K010R0250 6V Output Capacitor

Model Used: Capacitors, Fixed, Electrolytic, Tantalum, Solid
λp = λb*πCV*πSR*πQ*πE

Name
λb Base Failure Rate S = 0.6, R = 25°C 0.0199 Stress = 6V/10V
πCV Capacitance Factor C = 33µF 1.5213 -
πSR Series Resistance 10kΩ/6V 0.0660 -
Factor
πQ Quality Factor Lower 10.0 Commercial Quality
πE Environmental Ground Mobile 8.0 -
Factor
Component: PIC24HJ128GP306
Model Used: Microcircuits, Microcontroller
λp = (C1*πT + C2*πE)*πQ*πL

Name
C1 Die Complexity 16-bit MOS 0.280 -
πT Temperature Factor 30 °C 0.130 Minimal heating @
35mW
C2 Package Fail Rate SMT 0.0250 64-pin TQFP
πE Environmental Ground Mobile 4.0 -
Factor
πL Learning Factor >2 years 1.00 Long lineage of PIC
devices
As expected, the power electronics are most likely to fail. In the worst case scenario,
the H-Bridge controllers will fail after 1.649 years (14,542 hours) of run time. RoboSiM is not
designed for constant operation, but with a large-scale deployment, the number of failures per
hours could be substantial.
Of the parts considered, the 6V output capacitor is the most reliable at one failure every
714.2 years. For a single system’s operation, this is acceptable. However, as with the power
A-17
electronics, a significant number of robots operating simultaneously will increase the number of
failures per hour.
These results indicate that steps should be taken to improve the reliability of the whole
system. One possible step is improving the derating on the 6V power supply output capacitor.
Currently, the device is operating at a stress of 0.6; nominally, this value should be 0.5 or less. A
simple part substitution can be easily made to the present design.
Each of the H-Bridge motor controllers are designed to handle up to 3A of current; both
of the brushless dc motors used in RoboSiM’s kinetic system draw up to 2.45A at stall. Although
the controllers will operate correctly at these levels, the part lifetimes will ultimately shorten as
the motors are operated at or near stall. Selecting replacement parts that are designed to handle
greater currents, like Infineon’s TLE5206 (rated at 5A), will more conservatively derate the
kinetics system and extend the mean time to failure (MTTF).
The same logic applies to the power supply components. Both the 3.3V switching
controller and the 6V switching MOSFET can be replaced with components designed for greater
currents and power dissipations. Many of these components have larger heat sinks and lower
thermal coefficients, which improve the operating temperature and decrease the risk of failure.
According to the US Department of Defense’s Reliability Prediction of Electronic
Equipment handbook [15], there are two factors that are weighted heavily in predicting failure
rates: the quality factor and the environmental factor. The former accounts for the manufacturing
processes used to realize the device. For components that are created using MIL-SPEC
procedures, these quality factors are generally low (on the order of 1.0 – 2.0); however, most
commercial devices are higher (on the order of 8.0 – 10.0). RoboSiM uses exclusively
commercial components, so each device’s predicted failure rate can be as much as an order of
magnitude higher than a MIL-SPEC equivalent. Substituting these parts for the commercial-
grade components used will necessarily improve system reliability.
The environmental factor plays a significant role in predicting failure rates. Because this
platform is designed as a mobile ground vehicle, the failure rates are elevated relative to a
ground fixed system. Improving the quality of RoboSiM’s enclosure – stronger materials,
weather-resistant potting material, and shock resistance – will not change the predicted fail rate
as calculated by MIL-HDBK-217F, but the act would in practice enhance reliability in the field.
A-18
6.0 Failure Mode, Effects, and Criticality Analysis (FMECA)

RoboSiM can be effectively decomposed into three functional blocks: the decision
engine, comprised of the PIC24H microcontroller and an array of sensors; the motor control
system, which includes the H-Bridge controllers and the dc motors; and the power supply system,
which encompasses both the 3.3V and 6V regulators.
Each functional block is susceptible to a unique set of failure modes, as summarized in
Appendix B. The consequences of each mode are varied, and range in criticality. To objectively
capture the severity of each failure, the following scale will be used to define failure mode
criticality:
Low: nuisance failure; no risk of component damage or personal injury

Acceptable failure rate: 1 failure per 106 hours
Elevated: additional component damage likely; no personal injury
High: risk of personal injury and additional component damage
Several of the failure modes involve some level of personal injury due to abnormally high
operating temperatures. Also, the NiMH battery technology can be prone to overheating and fire
in some situations. It is assumed that a user will have direct contact with the system during these
failures, although this will probably not be the case during navigation.
Faults in either of the power supplies may result in short circuits between power rails
or excessively high currents through power devices. This failure analysis assumes that there is no
current-limiting function available on the platform. In reality, chemical batteries will physically
limit fault current during short conditions.
7.0 Summary
RoboSiM is a reliable platform; even the most failure-prone components will, on average,
fail only once in 14,542.5 hours of operation. However, there is much room for improvement in
both safety and reliability. More conservative derating of passive devices, power supply
transistors, and H-Bridge controllers will extend the mean time to failure for the devices at risk.
A-19
Using military-grade components can also reduce part failures per million hours by up to an
order of magnitude. Finally, designing a stronger, more weather-resistant package will reduce the
deleterious effects of the operating environment.
Safety risks are minimal with this system. The most serious consequences of any of the
failure modes are small burn injuries, but these pose virtually no risk to human life. RoboSiM,
with or without the improvements suggested in this document, is a safe, reliable navigation and
surveillance system.
5.0 Ethical and Environmental Impact Analysis
1.0 Introduction
RoboSiM is a robotic platform designed for surveillance purposes. This involves

quietly traveling to a programmed location and recording an audio conversation. Using the
device in its intended application presents a number of different ethical and environmental
considerations that need to be taken into account. This includes ethical considerations such as
concerns for privacy, and environmental concerns such as component choice and utilizing power
in the most efficient way possible. By taking these considerations into account during the
design phase, we are able to produce a product that is both ethically sound and environmentally
friendly.
2.0 Ethical Impact Analysis
The RoboSiM platform will need to be tested under a variety of different operating
conditions before it can be released to market. Since the device is to be used for surveillance
purpose, ethical considerations will need to be taken into account when testing and using the
device. It is unlikely we can prevent the operator from the using the device in ways which are
unethical; however, we need to make sure our testing is done ethically. Ideal testing conditions of
the platform would involve an environment where participants being monitored are unaware that
the device is monitoring them inside of their vicinity. To accomplish this, individuals or a group
will need to be notified that they will be monitored sometime throughout the day in order to test
the stealth abilities of the platform. Participants for this type of testing should be chosen on a
volunteer only basis; this will ensure that the privacy of the individuals in the experiment is not
A-20
being violated, and allow people to avoid being placed in an undesirable situation. To further
increase privacy and protect the individuals, conversations recorded during testing should be
kept private and not used for anything that is beyond the scope of the platform’s audio recording
capabilities.
The content stored on the SD card is another ethical consideration that will need to be taken
into account. Data on the device will be stored using an unencrypted file system where
information can easily be read (and possibly modified) by an unexpected third party. This type
of data modification by an outside source could result in the robot commencing surveillance on
an unknown party, thus violating the party’s right of privacy. A solution to this dilemma would
be to use an encryption standard such as RC4 to protect the data on the SD card. This would
result in the data being inaccessible to anyone happening to come across the robot on its journey.
The downfall to this solution would be that the data would need to be decrypted every time the
user wanted to extract data from the card, and encrypted when an audio conversation was
recorded or destination coordinates where input. The slowdown caused by this would be
noticeable to the user; however, the ethical implications would likely outweigh any decrease in
speed.
Another ethical consideration to be taken into account is storing items in the interior of
the robot with the intended use of causing harm to others. This would include objects such as
explosive device that could be programmed to detonate at a chosen location. The possibility of
this occurring could be minimized by designing the enclosure with the least amount of free space
available to the user; this could also possibly reduce the magnitude of such an occurrence if it did
occur, since higher amounts of ingredients are typically used to produce more devastating results
in explosive devices. Our enclosure was designed in the manner of utilizing all space available
in the most efficient means possible, thus limiting the possibility of the robot being used as a
type of weapon.
3.0 Environmental Impact Analysis
An essential piece of the project that has the greatest impact on the environment is
choice of battery. When choosing a battery, it is important to choose a unit that can be recycled
and is constructed using environmentally safe materials. A rechargeable battery should be
chosen over disposable units, due to rechargeable batteries having “up to 32 times less impact
A-21
on the environment than their disposable counterparts[21].” Choosing a rechargeable battery

over a disposable option also results in having less of a negative impact on non-renewable
resources, global warming, air pollution, air acidification, and water pollution [21]. A battery
choice that has the greatest negative impact on these areas is NiCad (nickel-cadmium) type
batteries; batteries utilizing this technology contain cadmium that is toxic [22]. This would
present a problem if the user decided to discard the product in a way that was not
environmentally friendly. Based on environmental concerns surrounding NiCad, it is better to
choose a battery type that has less of an environmental impact such as lithium-ion and NiMH
(nickel-metal hydride); these types of batteries are safer to the environment, and easier to
recycle than their NiCad counterparts [22]. They are also cheaper to produce than previous
generation NiCad [22]. To try and prevent the user from discarding the battery in ways which
are hazardous to the environment, instructions will be placed inside the user manual telling the
user how to properly discard them. An additional information label will also be asserted to the
battery, to address situations where the user does not have the user manual.
The PCB is another area that needs to be addressed when considering the
environmental impact of the device. Traces on some PCBs have lead in them during the
manufacturing stage [23]. Disposal of electrical components such as the PCB has become a
problem around the world. There have been findings in China, India, and Pakistan that “reveal
extremely hazardous and dangerous e-waste recycling operations that pollute the air, water, and
soil of Asian countries and endanger residents [23].” When bringing the platform to market, it is
important we use a manufacturer who creates PCBs containing no lead or other harmful
materials. Some alternative materials that can be used for PCB construction include copper,
nickel, and tin; these materials are readily available from a variety of different manufactures.
This could possibly increase the price of production; however, it is likely the long term benefits
from implementing it will outweigh the price increase, even if it is passed on to the consumer.
Object detection is another area that presents an environmental concern. The three
ultrasonic sensors being employed operate by emitting a signal at the frequency of 42 kHz; a
number of different animals also use this frequency, thus presenting a concern to animals. An
example is the microbat which emits calls between the range of 14 - 100 kHz; it uses these calls
for communication purposes [24]. Another animal that utilizes sound around 42 kHz is the rat.
Baby rats send out distress calls between 30 – 50 kHz which “elicit maternal care, such as
A-22
retrieving infants to the nest [24].” Since the robot is likely to be used in an open environment,
it is unlikely to come in contact with these animals; however, the concerns should still be noted
in the user manual to prevent any confusion or harm to these animals and their habitat.
Another environmental consideration that should be taken into account is utilizing
power in the most efficient way possible. This can be accomplished by disabling components
when they are not in use. Component usage in our project can be separated into two areas:
components utilized when the robot is traveling to its location, and components used when the
robot is recording an audio conversation. The components used when the robot is traveling to
its location include the ultrasonic sensors, GPS module, digital compass, SD card, LCD, and
motor control circuit. Components utilized when the robot has reached its destination include
the microphone and preamp circuit, SD card, and LCD. During the two possible stages, it is
possible to disable or put to sleep components that are not in use; for example, the motor control
circuit can likely be disabled when the robot has reached its destination. Applying this logic to
all the devices will be environmentally friendly and also conserve battery life.
4.0 Summary
By taking ethical and environmental considerations into account during the design
phase of the project, we are able to produce a product that is both ethically sound and
environmentally friendly. Since our project is used for surveillance purposes, the major ethical
concern surrounding the project is privacy and using the platform in ways that comply with
current laws and regulations. Since we are unable to determine under what context the user will
be using the device, it is important for us to make ethical decisions in the testing phase of the
project. Testing the device ethically involves using participants who are willing to participate
voluntarily, and keeping information obtained during testing private to prevent any sort of legal
prosecution. Environmental considerations also need to be taken into consideration when
choosing components that will be used for manufacturing. In this area it is important to choose
components that will have the least amount of impact on the environment; this includes using a
PCBs containing no harmful materials and choosing batteries that are environmentally friendly.
By making these considerations today, we are able to ensure a safe and healthy planet for the
future.
A-23
6.0 Packaging Design Considerations
A-24
1.0 Introduction
RoboSiM is intended to be a small and stealthy surveillance platform. For this reason,
it is important for all the components to fit neatly into a compact package that makes very little
noise. The project cannot be too small, or it may not be able to handle terrain that gets too
rugged. Also, the project cannot be too big, or it would be easily noticeable, inhibiting its ability
to be stealthy. To keep our design as inaudible as possible, we may insulate the final prototype
with sound dampening material.
[1] Commercial Product Packaging

We have identified two products that are similar to ours. The first is the SRV-1
Blackfin Mobile Surveillance Robot [25], and the second is the WowWee Rovio Mobile Webcam
[26]. The Blackfin is closest to the design that we would like to achieve, but both of these
products are used for capturing video footage so we will need to adapt our product to be able to
record audio in lieu of video capture.
1.1 Product #1
The SRV-1 Blackfin Mobile Surveillance Robot is an R/C toy that allows the user to
explore the terrain of a home or office. One really nice aspect of its design is that the entire
package fits in your palm. Instead of the typical 4-wheel R/C car, the Blackfin uses tank-like
treads to navigate the desired location. The Blackfin is Java-based and can interface with a PC
using Wi-Fi. This connectivity allows the robot to be remotely controlled using a web server.
A-25
Among the design's positive features are its tank treads. They allow the robot to
navigate rugged environments with very little resistance. Additionally, the palm-sized packaging
improves its stealth characteristics.
The Blackfin’s electronics are not enclosed, meaning that any noise created is not
dampened, rendering stealth much more difficult. While this may not be a problem for something
as small as the Blackfin, our RoboSiM will be larger and will have motors that may create a
substantial amount of noise. RoboSiM will emulate the Blackfin's tank treads and compactness,
but we will differ from it because we will need to record audio as opposed to video.
1.2 Product #2
The WowWee Rovio Mobile Webcam is a robotic sentry that can be programmed to
follow up to 10 paths in an indoor environment. Any device capable of browsing the internet is
capable of controlling the Rovio and monitoring its progress along the programmed paths. We
have considered creating a 3-wheeled package to save power and create a quieter product, but in
the end we decided that tank-like treads would be better suited for rugged terrain (which is the
intended application).
While having a microphone raise up once our project has reached its location would
protect the microphone from any unwanted damage during transit, it would also introduce
unneeded mechanical complexity. Though our final project may be close to the size of the Rovio
we would like to aim for something smaller. Also, using three wheels in the same manner as the
sentry would be complicated due to the embedded wheels that allow for perpendicular motion
with respect to the wheel. In the end, our project may resemble the Rovio's size and will be
A-26
enclosed to protect the components from the environment. However, it will differ in almost every
other way.
[2] Project Packaging Specifications

We intend to start with the RP5 Tracked Chassis manufactured by Pololu [27]. From
there we will build upwards, mimicking the SRV-1 Blackfin Mobile Surveillance Robot. The
final product is intended to be as compact as possible to minimize visibility. The included motors
may need replaced to save power consumption and to decrease audible noise generation. In
addition, we will add an omni-directional microphone [29] to the front, along with three
ultrasonic sensors [28] (one to the left, one to the right, and one to the front of the chassis). We
considered using Velcro to attach the sensors and microphone in case they later needed replaced,
but there may be issues with static electricity associated with that approach. For now we are
exploring the possibility of expansion platforms (manufactured by Pololu) that the RP5 supports.
The expansion platforms will be useful since it may be impractical to fit everything on a single
layer while providing mechanical protection to the PCB. A concept CAD drawing is attached to
this document. We estimate our final product will weigh about 1 lb.
[3] PCB Footprint Layout

The major PCB-mounted components of this design and their packaging are
summarized in the following table:
Device Standard Package Length (mm) Width (mm) Height (mm)
PIC24HJ128 64-pin TQFP 10 10 1
VS1053B 48-pin LQFP 7 7 1.4
MMC Bay N/A 27.5 29.1 2.2
3.3V Regulator 4-pin HSOP 10.67 14.73 10
7.2V Regulator 4-pin HSOP 3.1 3.1 10
12-pin Header Breakaway Header 10 2 4
4-pin Header Breakaway Header 6 2 4
H-Bridge 20-pin HSOP 16 14.45 3.4
For both the microcontroller and the audio codec chip, we have selected small surface-
mount packages (TQFP and LQFP) because the through-hole variants are excessively large due
to the pin count. These will be a technical challenge to manually solder, which is why we are
planning to install sockets on the PCB instead of mounting the chips directly to the board.
A-27
The packaging choices were less flexible for the regulators and H-bridge chips, as the chips
we have selected are offered in 4-pin HSOP only. Conveniently, these packages are surface-
mount ready and relatively compact.
The size of our PCB will be smaller than the internal area of the RP-5 chassis, so we can
choose an arbitrarily large (or small) board as long as the components fit. Because we will have
both high-power (voltage regulators and motor controller) and low-power (microcontroller,
encoder) components on the board, it is desired to separate each type. As can be seen on the
preliminary PCB layout (Appendix C), the rear half of the board will contain the high-power
components and the front half of the board will contain the low-power components.
We are considering installing expansion boards in the robot’s bay that will allow us to build
the robot vertically. The top-most expansion will be the base upon which the sensors and LCD
will be mounted; this allows us to conserve PCB space by interfacing via headers (rather than
mounting the devices directly on the PCB. We estimate that a 4in x 4in board will be sufficiently
large to contain all of the components and provide the necessary separation. This size board will
also allow us to place the PCB inside the bay of the rover, protecting it from the elements.
[4] Summary
To meet the design objectives it is important for all the components to fit nicely in a
compact package that makes very little noise. To achieve this, we are going to emulate the shape
of the Blackfin and enclose it like the Rovio. The robot's dimensions will be 7” x 5.5” x 4.5”
(with room for vertical expansion) and weigh about 1 lb. The construction of the robot will be
modular and maintainable. The PCB will be arranged in a manner that separates low- and high-
power devices (to minimize interference); we chose a board size of 4” x 4.5”. All external
sensors will be connected to the main board via headers to facilitate easy modifications in
placement and to distance the PCB and microcontroller from potentially harsh environments.
7.0 Schematic Design Considerations
The RoboSiM is a robotic vehicle capable of navigating an object filled terrain to a designated
location where it will record an audio conversation. Navigation will be possible by utilizing a
GPS module with location accuracy of 2.5 meters [38], and a digital compass with 0.5 degree
A-28
heading accuracy [39]. Object detection will occur by way of three ultrasonic sensors with range
detection of 6.45 meters [40] attached to the outside of the vehicle; one will be placed on the
front with the other two located on both sides of the chassis. While traveling to its designated
location, the robot will provide information to the user by way of a 16x2 character LCD display.
This display will inform the user of information such as percentage of battery life remaining,
current GPS coordinates, and distance to the designated location where surveillance will occur.
Upon arrival, an audio conversation will be recorded using an omni-directional microphone for a
period of time designated by the user. Once complete, the robotic will once again navigate the
terrain back to the user where the audio captured can be analyzed.
1.0 Theory of Operation
The project can be separated into five areas connected to a single microcontroller:
object detection, navigation, motor control and power, audio capture, and display and data
storage. Object detection is achieved by the three ultrasonic sensors communicating with the
microcontroller. Navigation deals with traversal of the terrain using GPS and a digital compass.
Motor control and power consists of two motors on the chassis along with a 9V battery powering
all components on the robot. Audio capture deals with recording audio with a simple
microphone and amplifier assembly. Display and data storage consists of an external SD card for
storing and reading data, and 16x2 character LCD used to display information to user. Appendix
A summarizes all sections of operation and shows how they communicate with the
microcontroller.
Object detection will occur by way of three ultrasonic sensors attached to the outside
of the chassis. Each sensor will output a measurement 98ms after startup, and every 49ms
thereafter in continuous scan mode [40]. The sensors will be operated at 3.3V, and each will
communicate to the microcontroller using a single ADC channel. The microcontroller will be
programmed to sample each channel with 12-bit resolution; this was chosen over the default 10-
bit to ensure the most accurate sensor reading possible. Due to the resolution chosen, the
microcontroller will be unable to simultaneously sample all sensors; therefore, sequential
sampling will occur between all three channels. To improve SNR, the last two digits of the 12-
bit value determined by the ADC will be discarded.
Navigation will be accomplished by way of location readings from the GPS, along
with direction readings from the digital compass. Both of these devices, along with an active
A-29
antenna for the GPS, will be run at 3.3V. The GPS will operate at the factory update frequency
of 1Hz, and the digital compass will be in continuous mode with an update frequency of 20Hz.
This update rate was chosen for the digital compass in order to match the output rate of the
ultrasonic sensors, thus allowing us to having object location and direction information available
at the same time. This will be useful when the compass, sensors, and motors are working in
unison to navigate around objects. The GPS will transfer information to the microcontroller over
a UART interface; information is formatted as an NMEA string that will need to be parsed to
determine current location. These coordinates will then be compared to the destination location
to determine the distance to the target; this information will be then be displayed on the LCD
display.
RoboSiM’s power supply will consist of two switched-mode dc/dc converters. The
first will accept an unregulated 9V nominal (8V-11 typical range) input from the battery pack and
output a regulated 7.2V. This supply is a buck converter that uses a switching controller to set
and maintain the output voltage by appropriately switching an external MOSFET. On the
preliminary schematic submitted, the 7.2V regulator appears at the top of the power supply sheet.
The 9V input will be connected through a two-pin header, and the regulated 7.2V output will be
connected to motor control circuitry described later. The second regulator will accept the
regulated 7.2V output and step it down to 3.3V. Similar to the 7.2V supply, the 3.3V regulator is
a switched-mode buck converter. In this case however, controller chip used contains an internal
N-channel MOSFET to handle switching. As a result, fewer external components are necessary
to realize the circuit. On the preliminary schematic, this regulator appears at the bottom of the
power supply sheet. Note that for both regulators, the catch diode is shown as an ordinary PN
junction diode; however, a low-barrier Schottky diode will be used to appropriately handle the
high-switching frequencies (up to 1MHz) of the MOSFETs.
Motor control will be handled by a pair of H-Bridge controllers. Each device will be
operated at 7.2V that the power supply system provides. As long as the voltage to each controller
is above 7.0V, the input pins can be driven by the microcontroller at 3.3V. This allows no level
translation between the devices. The internal circuitry of the H-Bridge isolates the input pins
from the H-Bridge transistors, so no galvanic isolation will be implemented. H-Bridges allow a
dc motor to operate in four modes: forward, reverse, brake, and idle (depending on the logic
levels of the input pins). RoboSiM is expected to run in the forward mode during most of its
A-30
journey and in the idle mode during the audio recording phase. When maneuvering around
obstacles, the robot may need to reverse movement or operate only one of the motors for sharp
turns; these modes are not expected to be common. To control the motors, the microcontroller
will drive each of the four input pins (two per device) of the H-Bridge controllers with a PWM
signal. Higher duty cycles will provide more power to the motors, causing the robot to
accelerate. The PWM frequency will be set at 18 kHz so that switching noise will not be audible
for higher duty cycles.
A simple omni-directional microphone and preamplifier circuit will be used for audio
capture; the ADC will sample the microphone at 12-bit resolution mode once the robot has
reached its destination location. This was chosen over 10-bit mode for greater accuracy, similar
to the case with the sensors. The last two digits from this value will also be discarded to improve
the SNR. Audio will be encoded in adaptive differential pulse-code modulation (ADPCM)
format using freely available libraries from Microchip [41]. This audio will then be stored on the
SD card for later playback.
Display and storage will be accomplished by utilizing a SD card to read and store data,
and a 16x2 character LCD to display information to user. The SD card will be operated at 3.3V
and will use SPI to communicate with the microcontroller. The LCD display will also use 3.3V
and communicate to the microcontroller by way of 11 general purpose I/O pins. Data is written
to the display by sending different combinations of binary values, as specified by the LCD driver.
Eight pins are used to write values to an eight bit data or instruction register on the LCD; two
other pins are used to determine which register is being written to [42]. The final pin is used to
start a data write [43].
2.0 Hardware Design Narrative
The project will be utilizing five peripherals and 11 general I/O pins on a single
microcontroller. The ADC module will be used in 12-bit resolution mode for sampling sensor,
microphone, and battery charge level. The I2C module will be used for the digital compass to
receive direction information and set options such as update rate. The GPS device will be
communicating by way of the UART module where the mode of operation setting can be written,
and location information can be read. The PWM module will be used to control motor operation,
where the pulse generated will control the speed of the two rear motors. The SPI module will be
used for reading the destination location from the SD card, and writing the recorded audio file in
A-31
ADPCM format. The 11 general I/O pins will be used for sending data to the LCD for display by
the user.
Ports for each peripheral were chosen based on the interface that was used. Devices
using modules with dedicated pins were chosen first, followed by modules that shared pins. This
method was chosen to ensure pins used for one device would not overlap with those chosen for
another device. After examining the datasheet, it was determined that any pins not being used by
a peripheral could be used for general I/O. This lead us to designate the 11 pins for our LCD as
the last step
3.0 Summary
The goal of RoboSiM is to successfully navigate an object filled terrain to a location
where audio will be captured. This is accomplished through five key areas as can be seen in
Appendix A. The microcontroller in charge of all operations will run at 12MHz and will utilize
the ACD, I2C, UART, PWM, and SPI peripherals. Each component using these modules will be
run at speeds sufficient enough for the robot to accomplish its task. Power will be supplied by a
9V rechargeable battery that will be regulated to 7.2V for the motor control devices, and 3.3V for
all other components. An audio conversation will be captured and stored on an SD card using
ADPCM format where it can later be heard by the individual.
8.0 PCB Layout Design Considerations
1.0 Introduction
RoboSiM is a mobile robotics platform designed to utilize a variety of sensors
(magnetic orientation, ultrasonic proximity, GPS, etc.) to autonomously navigate an environment
while avoiding obstacles. After reaching the user-programmable destination (via selected
waypoints), the robot will record audio for a predetermined amount of time, then return to the
base station.
Although the set of devices that comprises RoboSiM is reasonably small, failure to
carefully design a printed circuit board (PCB) layout according to the requirements of each
device may render the entire platform buggy at best, or inoperable at worst.
A-32
There are three main areas of concern for this robot: analog inputs, the
microcontroller circuit, and the power supply. In particular, the dependence on reliable ultrasonic
range data for navigational decisions requires that noise on the analog input lines be minimized.
Especially on boards with high-frequency switching and many digital lines, this can be a difficult
task without proper PCB layout planning. Section 2.0 details the protective measures taken to
guarantee analog data integrity.
The PIC microcontroller at the heart of RoboSiM is arguably the most important
component on the board. Unfortunately, it is also very sensitive to power supply connections and
high-frequency noise. Section 3.0 describes the layout conditions that will minimize these
deleterious effects.
One of the most troublesome (in terms of PCB layout design) blocks of the robot is the
power supply. The high switching frequencies and large current transients (during motor stall and
direction switching) can cause disruptions throughout the entire system without appropriate
prevention. Additionally, the voltage regulation performed tends to generate relatively large
amounts of heat. Without thermal protection, power supply failure – and subsequently failure of
the entire system – is a possibility. Section 4.0 covers the design decisions made to account for
these possible effects.
2.0 PCB Layout Design Considerations - Overall

One of the most important overall considerations for RoboSiM’s PCB layout is the
physical placement of the main functional blocks. Specifically, the board will be partitioned into
the power supply, the motor control circuit, the microcontroller circuit, and the analog circuitry.
This situation is described visually in Appendix B.
Two voltage regulators will be used to obtain the 7.2V and 3.3V levels required for the
selected components. Due to their switching topographies, they will be physically separated from
the analog circuitry and the microcontroller. The high currents sourced through the 7.2V
regulator will be primarily delivered to the motor control circuitry, which will also be placed far
from the sensitive components mentioned. The separation of these two functional blocks forms a
high-power PCB section that will be placed towards the rear of the robot – physically close to the
battery pack and dc motors as well.
A-33
The microcontroller and required external circuitry will be placed towards the front of
the robot. All digital headers, such as those for the GPS and digital compass, will be placed
physically close to the microcontroller pins and on one side of the chip. The other side will be
populated with the analog circuitry: ultrasonic sensor inputs and audio data. This separation is
intended to prevent digital switching noise from contaminating the sensitive analog signal lines.
Additionally, smart placement of the subsystem headers will allow for minimization of trace
lengths (reducing parasitic effects and noise coupling) and a more compact power supply plane.
Filter capacitors for the power supplies, microcontroller, and H-Bridges will be placed
as close to the devices as possible. In addition, current loop sizes will be shortened as much as
reasonable achievable in order to prevent EMI radiation to the rest of the board. The low-power,
digital components at the front of the PCB will be compactly placed to prevent the
aforementioned deleterious effects. While this may pose a technical challenge when mounting
components to the PCB and routing traces between components, it will also save critical
integration and debugging time by preventing most problems outright.
3.0 PCB Layout Design Considerations - Microcontroller

The Microchip PIC24HJ128GP306 microcontroller serves as RoboSiM’s computational
center. Since it uses an internal oscillator circuit and very simple interfaces between peripherals,
the PCB layout considerations are very simple and reasonably easy to implement.
Four decoupling capacitors will be used to provide reserve charge for instantaneous current
changes. According to the PIC24 datasheet (and conventional microcontroller routing
knowledge), these capacitors should be placed as physically close to the designated VDD and
VSS pins as possible[47]. This action reduces trace inductance for quick charging characteristics
under transient loads.
For proper power sequencing, these decoupling capacitors will be placed closer to the
power supply than the device pins. This allows the capacitor to compensate for line transients
before they reach the microcontroller, reducing the effects seen by the controller. For large
voltage and current ripples, this is critical – especially when dealing with the sensitive analog
inputs installed on RoboSiM.
If trace routing allows, additional noise immunity can be gained by placing ground planes
around signal and power traces. This may not be practical for the entire board, but it will be
A-34
emphasized for the connection of the three ultrasonic sensors. These analog lines are very
sensitive to board noise, and data integrity for this trio of signals is critical for accurate
navigation decisions. As discussed previously, this effect will be partnered with physical
isolation of the analog lines from digital and power lines to ensure useful proximity readings.
Section 4.0 expands on the issues of reducing high-frequency noise due to the power supply,
but it is important to provide an alternative barrier at the microcontroller level. The decoupling
capacitors on the power supply pins can be placed in parallel with smaller (0.001µF to 0.01µF)
ceramic capacitors to reduce high-frequency noise sources. With the necessary precautions taken
to prevent such noise, this approach will probably not be necessary. However, extra components
will be placed on the schematic so that pads on the PCB can be included. This allows for the
installation of these extra capacitors if necessary without the need for fly-wiring.
The next section provides more detailed information about power trace routing and sizing,
but it is important to note that components should be placed on the board to create an intuitive,
compact path for power and ground planes. Smaller power planes carry less EMI and have lower
impedances than larger planes. In some high-current operating modes, this can be important for
proper operation. Also, routing power and ground planes in parallel will help attenuate noise
sources[44]; components will be placed such that a ground plane on the bottom PCB layer will run
underneath the power plane on the top layer.
4.0 PCB Layout Design Considerations - Power Supply

In most designs, proper power supply PCB layout is critical for device operation; this
application is no different. The RoboSiM power supply is comprised of one 7.2V regulator
(nominal 9V input) and one 3.3V regulator (nominal 7.2V input); both systems are buck-type
switching regulators. Layout considerations are similar for each regulator, so they will be
discussed together.
Buck converters operate, in essence, by switching between two current paths rapidly.
Because of the high-current nature of motor operation (peak currents at 4.8A), as well as the
potentially high current draw of the electronic components (as much as 0.25A), high current
switching will occur in the power supply. A direct product of this type of switching is high
A-35
voltage spikes, according to the equation V = Ldi/dt. These voltage and current transients are well-
known to generate electromagnetic interference (EMI) on printed circuit boards.
The first line of defense against this type of EMI is the reduction in size of current loops.
Referring to the schematic included in Appendix A, one such loop occurs between CIN_7_2,
M1_7_2, and D1_7_2. By placing these components physically close to each other and the
switching controller IC (U1_7_2), EMI radiation from the current loop can be reduced greatly.
Additionally, placing these components close to the controller IC shortens the clock signal that
drives the MOSFET gate (also reducing EMI radiation). By repeating this process for each of the
switching current loops (in both regulators), the risk of design failure due to power supply noise
can be greatly alleviated.
Both converters are expected to generate significant amounts of heat during high current
draw conditions (such as start-up and motor stall). As a result, thermal considerations must be
made to protect the devices from failure. The first line of defense lies in component selection.
Both switching controllers are offered in packages with large exposed ground pads for better
thermal connection to the PCB. Additionally, the power MOSFET in the 7.2V regulator is housed
in a package with a large ground pad for the same purpose. To complement these packaging
features, wide ground planes under these components will help dissipate the heat generated over
a wider area for faster cooling. If routing conflicts can be avoided, it is also possible to create
copper pours on the bottom PCB layer below these components and connect them with vias. The
heat will flow to the opposite side of the board, allowing for more effective cooling.
The pair of brushed dc motors used for RoboSiM’s drive system can draw up to 2.4A each
during stall conditions. Accounting for both motors and the maximum predicted current, peak
current draw can total almost 5.1A. The creation of wide PCB traces between the voltage
regulators and the load devices will prevent excessive heat build-up (during high-current draw
states) and premature board failure. According to an online PCB trace width calculator [43],
external routing layers (in the case of this two-layer PCB, both layers) require 60.5mil
(1.537mm) traces to handle a 5.4A peak current. These trace widths will be primarily employed
between the battery pack, 7.2V regulator, and H-Bridge circuitry. Because the 3.3V regulated
supply is expected to handle a much less current (<500mA peak), 2.27mil (0.0555mm)-wide
traces will be used to distribute power to all 3.3V components. These conservative trace widths
will guarantee proper power delivery, even under unexpected loading conditions.
A-36
Another important protection feature in RoboSiM’s design is the physical size of the PCB.
The total surface area of the board that can be utilized will be around 3.2in x 3.5in; this is larger
than necessary to accommodate all components, but it allows for better isolation of the power
supply and motor control circuits from more sensitive, low-power components. Since
electromagnetic field intensity falls exponentially with distance in air, this will prevent a
significant amount of noise from coupling to less noise-tolerant lines.
Trace routing for the power supply is quite simple with the division of functional blocks
chosen (illustrated in Appendix B). Headers for the 9V battery pack on the rear-side of the PCB
will connect directly (through short, 60.5mil-wide traces) to the 7.2V regulator. From the
regulated output, one conduction path (same trace width) will supply the H-Bridge controllers
with both supply voltage and motor-drive voltage. Headers on the rear-right side of the PCB will
connect the motor-drive paths to the motors.
The aforementioned 2.27mil-wide trace will connect the output of the 7.2V regulator to the
input of the 3.3V regulator. Although these supplies will be physically separated, the conductor
will not be excessively long to prevent EMI coupling and radiation. The output of the 3.3V
regulator will carry current to the sensor array, LCD, microcontroller, and audio amplifier circuit.
In all cases, it will be important to route these high-current (potentially-noisy) lines
perpendicular to sensitive analog input lines. This will physically prevent any AC noise coupling.
As suggested in the suggested reading for the course, these power traces will be as compact
as possible to reduce the effects of parasitics and to prevent power supply noise coupling.[44] Part
of the effort to minimize power plane size is the compact, ordered placement of components.
Effort will be invested in placing components so that power and ground connections are
concentrated.
5.0 Summary
This report summarizes the PCB routing techniques that will be employed to account for
potential electromagnetic interference (EMI) coupling, analog signal contamination from
digital switching, high current transients, and head buildup.
In particular, the entire board will be logically partitioned into functional blocks (as seen
in Appendix B) as a first barrier of defense against the aforementioned error sources. In
addition, power and ground planes will be sized and routed to minimize EMI coupling and
A-37
excessive heat dissipation. Traces between high-current devices will be widened to protect
the device under peak loads. Analog inputs will be isolated and protected against noise
sources to guarantee accurate ranging data.
Proper component packaging will be selected to provide good thermal contacts with the
PCB and will be large enough to be easily-soldered – this will help protect the PCB from re-
work. These devices will be routed on the board in compact, neatly-arranged blocks
according to the manufacturer suggestions and the specific goals outlined in this document.
With the proper design techniques and appropriate forethought, it will be possible to
generate a viable design and avoid common pitfalls with PCB design. If those undesirable
situations are circumvented, RoboSiM will be realized in its full capacity.
9.0 Software Design Considerations
1.0 Introduction
Robotic Surveillance in Motion (RoboSiM) is an autonomous vehicle capable of
surveying a remote location. In short, it is a robot capable of traveling to a designated position,
recording audio for a specific amount of time, and returning the data back safely. To accomplish
this task, there are several things that must be accomplished.
Before the vehicle can be sent out on its mission, a home location, a target location,
and a recording time need to be specified on an SD card. This can be easily done using a PC to
write the data to the SD card. After placing the card in the vehicle, it can be powered on. After
initialization is complete, the vehicle’s journey begins.
During transit, the robot periodically samples its onboard GPS module, ultrasonic
sensors, and digital compass. These peripherals allow the vehicle to find its way to the target and
avoid obstacles along the way.
After reaching its destination, the vehicle can begin its surveillance. The robot will
hold its position and record audio for the specified length of time. The captured audio is encoded
and stored on the SD card, so that it can be retrieved and played back when the robot returns to
its home location. After, completing its observation of the target location, the vehicle embarks on
its return trip.
In order to complete all of these steps successfully, the robot’s operating system must
be robust enough to handle any extraordinary events that it encounters while out in the field. But,
A-38
it must also be light enough to perform adequately in an embedded environment. The sections
below will detail the steps taken ensure RoboSiM’s reliable operation, including hardware-
software interface considerations, application organization, and code module functionality. A
software narrative will also be provided to solidify the ideas behind RoboSiM’s software design.
2.0 Software Design Considerations

RoboSiM is an embedded systems project, and as such, requires careful consideration of
all options at each stage of development. Like all designs, each decision has the potential to
affect several aspects of the project. But, unlike general purpose systems development,
embedded systems must be designed within a tighter set of constraints. In particular, embedded
software development is often restricted by limited memory space, little to no abstraction, and
weaker hardware. With the right design choices, however, these restrictions can be overcome,
and may even contribute positively to the outcome of the project.
2.1 Hardware/Software Interface

The design of RoboSiM’s operating system depends largely on the hardware on which it
will run. The vehicle will be equipped with a PIC24H microcontroller containing 128 kB of user-
programmable flash program memory and 16 kB of RAM [49]. The chip is based on a modified
16-bit Harvard architecture, and utilizes 24-bit instructions [49]. Figures 6 and 7 in Appendix C
below show the layout of program and data memory, respectively, for the particular model
chosen for this project.
Program memory is organized into 16-bit words, with each memory address
corresponding to a single word. It is divided into two distinct sections: the User Memory Space
and the Configuration Memory Space [49]. Application-specific instructions are stored in the
User Program Flash Memory section (addresses 0x000200 to 0x0157FE). This section of the
program memory has 87,550 indices, but this doesn’t translate into space for 87,550 instructions.
Since, each index of program memory refers to a 16-bit word, and each instruction is 24-bits
wide, a single instruction must occupy two indices. This means that there is room for about
44,000 instructions. While this does restrict the potential size of the operating system’s control
routines, it is not an unreasonable constraint. With careful planning and code optimization, this
space limitation should not be a problem.
A-39
Data memory, like program memory, is organized into 16-bit words, with each memory
address corresponding to a single word. But, unlike program memory, it is byte addressable. Data
memory is split into three sections: the Special Function Register (SFR) space, Data RAM, and
DMA RAM [49].
The 2kB SFR space contains the microcontroller’s PC registers, working registers (16 in
total), and peripheral configuration registers. RoboSiM will make use of the following peripheral
control registers: Interrupts (0x0080 – 0x00E0); Timer (0x0100 – 0x013C); Output Compare
(0x0180 – 0x01AE); I2C (0x0200 – 0x021C); UART (0x0220 – 0x0238); SPI (0x0240 –
0x0268); and ADC (0x0300 – 0x0372) [49].
The 16 kB Data RAM space is used by the PIC24H’s heap and software stack. This
portion of the address space, while 16 kB in total size, actually encompasses the DMA address
space. When DMA is in use, the microcontroller’s effective data RAM space is reduced by 2 kB.
RoboSiM, however, won’t suffer from this, since DMA is not used. When used in conjunction
with embedded C, the data RAM should provide plenty of working room for all of RoboSiM’s
necessary computations.
2.2 Application Organization

With low-level hardware considerations made, a higher-level application view can be
adopted. Since the operating system’s task is to coordinate the interaction of the system’s
peripherals, it is important to consider the different methods of organizing the application. An
interrupt driven application is well suited to asynchronous environments, such as capturing
keyboard strokes. A state-machine oriented application works well for very structured
environments, like a USB communication protocol. An application built around a polling-loop
works well for situations in which several things may happen, each needing to be checked
regularly.
RoboSiM has a unique operating structure in that there are two exclusive modes of
operation: Navigation, and Surveillance. While travelling to the indicated target, the vehicle will
not be recording audio. Once the vehicle has reached its destination, it stops and surveys the area
by recording audio samples. These two modes require different amounts of “attention” from the
microcontroller, and thus subscribe to different organizational paradigms.
A-40
During the Navigation phase of a given mission, the vehicle will operate in response to
regularly scheduled interrupts. While this may seem to defeat the purpose of an interrupt driven
application, it actually makes implementation very easy. The microcontroller’s Timer module can
be configured to trigger an interrupt at very precise intervals, allowing the robot to sample its
sensors and correct its course periodically.
For example, the Timer module could be configured to interrupt at a rate of 10 Hz.
While handling each interrupt, the microcontroller queries the GPS module, storing the position
response to memory. Only on the tenth interrupt, however, is a course correction performed. The
10 GPS samples are median-filtered to produce the actual position that the course correction will
be based on, reducing the effect of erroneous position samples. This extended sampling scheme
shouldn’t be affected by the movement of the robot, since the vehicle will only be moving a
small distance (6 inches) each second.
Figures 3 and 4 in Appendix A below illustrate how a course correction decision is
performed. For the vehicle to navigate to the intended target location, it only needs to know two
positions: its own position (as indicated by the GPS module), and the target location (as read
from the SD card). Given the robot’s latitude and longitude, R(λr, φr), and that of the target,
T(λr, φr), a signed distance vector and slope can be computed.
Dl = l t  l r
Dj = j t  j r
Dl
m=
Dj
In the equations above, Δλ represents the latitudinal difference between the target and
the vehicle, and Δφ represents the longitudinal difference. These two values, (Δλ, Δφ), make up
the signed distance vector. The slope, m, of this distance vector is simply the quotient of its two
components. Figure 3 shows how the signs of this direction vector and its slope can be used to
determine the cardinal direction in which to proceed.
A-41
Once the target has been reached, the Surveillance phase begins. At this point, the
vehicle holds its position and prepares to record, encode, and store audio samples gathered from
the target area. This mode of operation lends itself very nicely to a state-machine design since
there is a very structured set of operations that need to be performed repeatedly.
Speech recording needs a sample rate of about 44 kHz for effective audio
reproduction. For each of those 44,000 samples, the microcontroller needs to capture a voltage
sample from the microphone, encode it using an ADPCM algorithm, and store it in an
appropriately sized buffer. These steps repeat until the buffer is filled, at which point it is written
to the removable SD card. This entire process continues until the specified recording time has
been reached. The highly repetitive nature of this recording algorithm makes the choice of a
state-machine based design trivial.
Adaptive Differential Pulse Code Modulation (ADPCM) is particularly well suited to
encoding speech due to a high correlation between consecutive speech samples [50]. ADPCM
encodes audio by storing the difference between a predicted value and the actual value of a given
sample. This allows a significant reduction in the number of bits to store a particular sample,
yielding a highly efficient encoding. Luckily, Microchip has made available a very detailed
application note on implementing ADPCM encoding in a computationally efficient manner on
PIC microcontrollers [51].
To store the audio on the SD card in a PC-readable manner, the microcontroller must
support FAT16/32 file formats. Microchip, has also made an application note and library freely
available for this very task [52, 53]. This will allow the operator of the vehicle to play back the
retrieved audio recording easily on any PC.
After completing its surveillance task, the vehicle enters the Navigation phase again.
The vehicle returns to the position it marked as “Home” before embarking on its mission. After,
arriving at “Home”, the vehicle stops so the recorded audio can be retrieved and played back.
3.0 Software Design Narrative

The source code for RoboSiM’s operating system is divided into several different
packages of operation, each encapsulating a specific group of functions to ensure maximum
portability. Each package is further subdivided into modules, each defining an API. Each of the
packages and their member modules are defined in the following sections.
A-42
3.1 Kinetics
The Kinetics package defines motor functionality through a very simple interface. It
consists of an API that encapsulates hardware interaction in an easy-to-use set of high-level
functions. The PWM Module from the System package (detailed below) is used by the Motor
Control API, which provides a simple way for the operating system to issue navigation
commands to the motors.
 Motor Module – Outlined
3.2 Navigation
The Navigation package specifies the navigational decision-making protocols. It is
separate from the Kinetics package to distinguish policy from implementation. The Navigation
package contains a GPS module which encapsulates all the specifics of communication with the
GPS module. This module provides an API for retrieving position updates, and configuration of
the GPS chip. A Decision module makes use of the GPS API and the Sensors Package (explained
below) to decide how to control the vehicle.
 GPS Module - Incomplete
o int gpsConfigureUart(int baudRate, int numStopBits, int
numDataBits, int parity, int memOption) – Configures the GPS chip’s
UART communication interface with the specified characteristics.
o float gpsGetAverageLatitude() – Returns the average of all the latitude
samples for the previous round of GPS samples.
o float gpsGetAverageLongitude() – Returns the average of all the longitude
samples for the previous round of GPS samples.
o float gpsGetDistanceToTarget() – Returns the current distance to the target
o int gpsSystemRestart(int resetMode) – Resets the GPS chip to the specified
mode.
 Decision Module - Outlined
3.3 Sensors
The Sensors package encapsulates all interaction with the ultrasonic sensors and
digital compass. Each has its own API defined to allow other packages (e.g. – the Navigation
package) to easily interface with these components.
 Ultrasonic Sensor Module – Complete
o void sensorInit() – Initializes the Sensor module, setting up the appropriate
ADC channels for sampling.
o int sensorGetDistance(int sensorNumber) – Returns the distance in inches
to the nearest object in front of the specified object.
A-43
 Digital Compass Module – Complete

o int compassGetHeading() – Returns a compass heading in tenths of degrees
from 0 and 3599.
o int compassInit(int c, char opMode, char outMode) – Initializes the
compass on the specified I2C channel with the indicated operational and output
modes. Returns COMPASS_FAIL or COMPASS_SUCCESS.
o int compassSetOpMode(char mode) – Configures the compass’ operational
mode (e.g. – standby, continuous). Returns COMPASS_FAIL or COMPASS_SUCCESS.
o int compassSetOutMode(char mode) – Configures the compass’ output mode
(e.g. – magnetometer readings, heading). Returns COMPASS_FAIL or
COMPASS_SUCCESS.
3.4 Audio
This package defines the functionality of RoboSiM’s audio capture and encoding
routines. It contains modules for interacting with the microphone and for encoding the captured
audio samples. This package is used in conjunction with the Media package to capture and store
audio. The CODEC Module is based on an ADPCM application note provided by Microchip [50,
51].
 Audio Capture Module – Outlined
 Audio CODEC Module – Outlined
3.5 Media
The Media package specifies interaction with the SD card. It is based on a library from
Microchip that takes care of FAT16/32 protocols [52, 53].
3.6 Display
The Display package defines a straightforward interface for printing information to the
LCD screen. The LCD screen module uses the LCD manufacturer’s communication protocol,
and makes several different print-style functions available for easy transfer of data to the screen.
Since the LCD screen connects to the microcontroller through general I/O pins (instead
of UART, for example), it doesn’t use any modules in the Communication package. There is
some communication overhead incurred by the LCD screen’s proprietary protocol, but this is
encapsulated in the API. This makes for a very straightforward interface with the screen,
insulating users of the library from the tedious details of timing constraints and data transmission
formats.
 LCD Screen Module – Complete
o void lcdPrintCharacter(char c) – Prints a character to the LCD screen at the
cursor’s current position.
A-44
o void lcdPrintFloat(float number, int precision) – Prints a floating

point number to the LCD screen with the specified precision at the cursor’s
current position.
o void lcdPrintInt(unsigned int number) – Prints an integer to the LCD
screen at the cursor’s current position.
o void lcdPrintString(const char* string) – Prints a string to the LCD
screen starting at the cursor’s current location. This function uses
lcdPrintCharacter(char c) to print the string one character at a time until a
'\0' is encountered.
3.7 System
The System package contains perhaps the most important of the APIs. All system-level
APIs (e.g. – ADC, TIM) reside in this package, and are used by several other packages for
actually transferring data to the different peripherals in the system. Each API makes simple
send/receive functions available with varying data types, giving lots of flexibility to any
algorithm using these libraries.
 ADC Module – Complete
o void adcChannelInit(int channel) – Initializes the indicated ADC channel
to function as an analog input for sampling.
o int adcGetSample(int buffer) – Returns the sample buffer for the indicated
channel with 10 bits of data.
o float adcGetVoltage(int channel) – Returns the sample buffer converted to
a floating point voltage with respect to the analog voltage reference.
o void adcInit() – Initializes the ADC module with basic sampling functionality.
This does not initialize any specific channels, and must be called before
individual channels can be set up.
o void adcSetInterrupts(unsigned char flag) – Enables/Disables ADC
module interrupts.
 TIM Module – Complete
o void timInit(float interval, int prescale) – Initializes the Timer
module to cycle at the specified interval using the desired prescaler.
o void timSetInterrupts(unsigned char flag) – Enables/disables Timer
module interrupts.
 PWM Module – Incomplete
 UART Module – Complete
o int uartInit(int channel, int desiredBaudRate, int numStopBits,
int numDataBits, int parity) – Initializes the specified UART channel with
the desired properties. Returns UART_FAIL or UART_SUCCESS.
o int uartReceiveCharacter(int channel, char* c) – Receives a character
from the specified channel and places it in the provided character variable.
Returns UART_FAIL or UART_SUCCESS.
A-45
o int uartReceiveData(int channel, char* buffer, int length) –

Receives bytes from the specified channel and places them in the provided buffer.
Returns UART_FAIL or UART_SUCCESS.
o int uartSendCharacter(int channel, const char character) – Sends out
a character on the specified channel. Returns UART_FAIL or UART_SUCCESS.
o int uartSendData(int channel, const char* data, int length) – Sends
out data on the specified channel from the provided buffer. Returns UART_FAIL or
UART_SUCCESS.
o int uartSendString(int channel, const char* string) – Sends out a
string on the specified channel. This function uses uartSendCharacter(int
channel, const char character) to send the string one character at a time
until a '\0' is encountered. Returns UART_FAIL or UART_SUCCESS.
o int uartSetTXInterrupts(int channel, unsigned flag) –
Enables/disables UART module TX interrupts for the specified channel.
o int uartSetRXInterrupts(int channel, unsigned flag) –
Enables/disables UART module RX interrupts for the specified channel.
 2
I C Module – Complete
o int i2cInit(int channel) – Initializes the provided I2C channel. Returns
I2C_FAIL or I2C_SUCCESS.
o int i2cReceiveData(int channel, char slaveAddr, char* data, int
length) – Fills the provided data buffer with data from the indicated slave
address on the specified channel. Returns I2C_FAIL or I2C_SUCCESS.
o int i2cSendData(int channel, char slaveAddr, char* data, int
length) – Sends data to the indicated slave address from the provided buffer.
Returns I2C_FAIL or I2C_SUCCESS.
o int i2cSetMasterInterrupts(int channel, unsigned flag) –
Enables/disables I2C module master device interrupts for the specified channel.
o int i2cSetSlaveInterrupts(int channel, unsigned flag) –
Enables/disables I2C module slave device interrupts for the specified channel.
o int receiveByte(int channel, char* byte) – Retrieves a byte from the
specified channel, placing it the provided variable. Returns I2C_FAIL or
I2C_SUCCESS.
o int sendByte(int channel, char byte) – Retrieves a byte from the specified
channel, placing it the provided variable. Returns I2C_FAIL or I2C_SUCCESS.
o int sendStartSequence(int channel) – Sends an I2C start sequence,
signifying that a transmission is about to begin. Returns I2C_FAIL or
I2C_SUCCESS.
o int sendStopSequence(int channel) – Sends an I2C stop sequence,
signifying that a transmission is ending. This also resets the bus for any future
communications. Returns I2C_FAIL or I2C_SUCCESS.
 SPI Module – Outlined
4.0 Summary
A-46
The success of RoboSiM depends on not just the quality of its hardware, but the
reliability of the software that controls it. If the necessary steps are not taken to strengthen the
design of its operating system, RoboSiM’s reliability cannot be guaranteed. However, if the
provisions specified in the preceding sections are implemented correctly, the Robotic
Surveillance in Motion project has a very high probability of success.
10.0 Version 2 Changes
If there were to be a RoboSiM 2.0, several things could be improved. The vehicle
would benefit significantly from a better chassis, a more comprehensive array of sensors, and a
more reliable audio capture system. With these improvements RoboSiM would a far more
effective reconnaissance platform.
When selecting another chassis, it would be important to consider ground clearance
and base type. Currently RoboSiM has trouble traveling through grass because of its low ground
clearance and tracked design. Grass gets caught in the track assembly very easily, halting its
forward progress completely. If a chassis with more ground clearance and an open wheel base
design were used, this would solve its terrain limitations and increase its ground speed.
RoboSiM’s obstacle detection and avoidance is currently hindered by its limited
sensor array. The three orthogonally mounted ultrasonic sensors don’t provide the perfect
information about the vehicle’s surroundings needed for making intelligent navigational
decisions. RoboSiM 2.0 would benefit from a larger number of sensors and a different mounting
scheme (e.g. - diagonally mounted on the forward facing corners of the vehicle). Also, a different
sensor type may provide more reliable data.
The vehicle’s surveillance capabilities are severely hampered by its poor audio capture
system. For a second iteration of the project, it would be wise to consider a professionally
manufactured pre-amp for the microphone. This would yield a more reliable audio capture
system without increasing project cost too much.
11.0 Summary and Conclusions
Through RoboSiM’s development the team learned the importance of planning ahead.
Without forethought, many design decisions would force a project’s progress to halt irreversibly.
A-47
Also, without effective team communication, individual expectations won’t line up, and a team’s
effectiveness will plummet.
Keeping these things in mind helped the RoboSiM team successfully complete their
project. The team was able to design and construct a working prototype that performed GPS
navigation calculations, basic obstacle detection, and audio recording. Although the audio quality
was poor, and the robot occasionally stalled because of obstacles with corners, all of the major
design goals of the project were met, and the team considers RoboSiM to be a success.
12.0 References
[1] Sparkfun Electronics, "Basic 16x2 Character LCD - Red on Black 5V," Sparkfun
Electronics. [Online]. Available: http://www.sparkfun.com/commerce/product_info.php ?
products_id=791. [Accessed: Jan. 28, 2010].
[2] Sparkfun Electronics, "20 Venus GPS Logger with SMA Connector," Sparkfun Electronics.
[Online]. Available: http://www.sparkfun.com/commerce/product_info.php ?
products_id=465. [Accessed: Feb. 04, 2010].
[3] Sparkfun, "SD/MMC Socket for Secure Digital Disk or Multi Media Cards," Sparkfun
Electronics. [Online]. Available: http://www.sparkfun.com/commerce/product_info.php?
products_id=136. [Accessed: Feb. 04, 2010].
[4] Freescale Semiconductor, "MC9S12C Family, MC9S12GC Family Reference Manual,"

Freescale Semiconductor. [Online]. Available: http://www.freescale.com/files/
microcontrollers/doc/data_sheet/HC9S12C128V1.pdf?pspll=1. [Accessed: Jan. 28, 2010].
[5] Atmel, "ATxmega256A3, … Preliminary," Atmel, Nov. 2009. [Online]. Available:

http://www.atmel.com/dyn/resources/prod_documents/doc8068.pdf. [Accessed: Feb. 04,
2010].
[6] Analog Devices, " ADSP-21261/ADSP-21262/ADSP-21266 Summary," Analog Devices,

Aug. 2009. [Online]. Available: http://www.analog.com/static/imported-files/data_sheets/
ADSP-21261_21262_21266.pdf. [Accessed: Jan. 28, 2010].
[7] Giovino, Bill, "New Microchip dsPIC33 Digital Signal Controller Family,"
microcontroller.com, Oct. 10, 2005. [Online]. Available: http://www.microcontroller.com/
news/microchip_dsPIC33.asp. [Accessed: Jan. 28, 2010].
[8] MaxBotix, "LV-MaxSonar-EZ0 High Performance Sonar Range Finder," MaxBotix, Nov.
2009. [Online]. Available: http://www.maxbotix.com/uploads/LV-MaxSonar-EZ0-
Datasheet.pdf. [Accessed: Feb. 04, 2010].
A-48
[9] Honeywell, “Digital Compass Solution HMC6352,” Honeywell, Nov. 2009. [Online].
Available: http://www.sparkfun.com/datasheets/Components/HMC6352.pdf. [Accessed:
Feb 04, 2010].
[11] "United States Patent: 5758352." USPTO Patent Full-Text And Image Database. Web. 31
Mar. 2010. <http://patft.uspto.gov/netacgi/nph-Parser?
Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO
%2Fsrchnum.htm&r=1&f=G&l=50&s1=5758352.PN.&OS=PN/5758352&RS=PN/575835
2>.
0>.
6>.
[14] "File Allocation Table -." Wikipedia, the Free Encyclopedia. Web. 31 Mar. 2010.
<http://en.wikipedia.org/wiki/FAT32#FAT_licensing>.
[15] United States Department of Defense, “Military Handbook on Reliability Prediction of

Electronic Equipment,” Dec. 1991. [online]. Available:
https://engineering.purdue.edu/ece477/Homework/CommonRefs/Mil-Hdbk-217F.pdf.
[Accessed: 1 April 2010].
[16] National Semiconductor, “LM22672 1A Simple Switcher,” Nov. 2008. [online].

Available:
A-49
http://download.siliconexpert.com/pdfs/2008/12/31/semi_ap/manual/nat/ds/lm22672.p
df. [Accessed: 1 April 2010].
[17] Alpha & Omega Semiconductor, “AOD413: P-Channel Enhancement Mode Transistor,”
[online]. Available: http://www.aosmd.com/pdfs/datasheet/AOD413.pdf. [Accessed: 1
April 2010].
[18] AVX Corporation, “TPS Series Capacitors,” [online]. Available:

http://www.avx.com/docs/Catalogs/tps.pdf. [Accessed: 1 April 2010].
[19] Microchip, “PIC24HJXXGPX06/X08/X10 Data Sheet,” [online]. Available:

http://ww1.microchip.com/downloads/en/devicedoc/70175H.pdf. [Accessed: 1 April
2010]
[20] Toshiba, “TA8429H Full-Bridge Driver for DC Motor,” [online]. Available:

http://www.toshiba.com/taec/components2/Datasheet_Sync//261/3610.pdf. [Accessed 1
April 2010].
[21] B. Dabek, “5 Reasons To Use Rechargeable Batteries,” aboutmyplanet.com, Jan. 10, 2008.
[Online]. Available: http://www.aboutmyplanet.com/science-technology/green-
household-batteries [Accessed: Apr. 15, 2010].
[22] D. Noréus, "Substitution of rechargeable NiCd batteries,” Arrhenius Laboratory, Stockholm

University, Aug. 2000. [Online]. Available:
http://ec.europa.eu/environment/waste/studies/batteries/nicd.pdf [Accessed: Apr. 15,
2010].
[23] D. Xiang, P. Mou, J. Wang, G. Duan, and H. C. Zhang, “Printed circuit board recycling
process and its environmental impact assessment,” The International Journal of Advanced
Manufacturing Technology, vol. 34, pp. 1030-1036, Oct. 2006.
[24] S. Anitei, “Top 7 Ultrasound Emitting Animals,” news.softpedia.com, Dec. 20, 2007.
[Online]. Available: http://news.softpedia.com/news/Top-7-Ultrasound-Emitting-
Animals-74541.shtml [Accessed: Apr. 15, 2010].
[25] "ThinkGeek :: SRV-1 Blackfin Mobile Surveillance Robot." ThinkGeek :: Stuff for Smart
Masses. Web. 09 Feb. 2010. <http://www.thinkgeek.com/geektoys/rc/8698/?cpg=cj>.
A-50
[26] "WowWee Rovio Mobile Webcam - RobotShop." RobotShop - Personal and Professional
Robots, Robot Parts, Robot Kits, Robot Repair. Web. 09 Feb. 2010.
<http://www.robotshop.ca/wow-wee-rovio-spy-robot-2.html>.
[27] “DFRobot Mobile Tank Base - RobotShop." RobotShop - Personal and Professional
Robots, Robot Parts, Robot Kits, Robot Repair. Web. 11 Feb. 2010.
<http://www.robotshop.ca/dfrobot-mobile-tank-base-1.html>.
[28] "SparkFun Electronics - Ultrasonic Range Finder - Maxbotix LV-EZ0." SparkFun
Electronics - News. Web. 09 Feb. 2010.
<http://www.sparkfun.com/commerce/product_info.php?products_id=8502>.
[29] "668-1155-ND (Manufacturer - POM-2735P-R)." Digi-Key. Web. 11 Feb. 2010.
<http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=668-1155-ND>
[30] "PIC24HJ128GP306-I/PT-ND (Manufacturer - PIC24HJ128GP306-I/PT)." Digi-Key. Web.

11 Feb. 2010. <http://search.digikey.com/scripts/DkSearch/dksus.dll?
Detail&name=PIC24HJ128GP306-I/PT-ND>.
[31] "SparkFun Electronics - Basic 16x2 Character LCD - White on Black 3.3V." SparkFun
Electronics - News. Web. 11 Feb. 2010.
[32] "BATT PACK 7.2V AA BUTTON NIMH - HR-3U-2500L2X3." DigiKey Corp. | Electronic
Components Distributor | Greece Home Page. Web. 11 Feb. 2010.
<http://gr.digikey.com/1/1/782327-batt-pack-7-2v-aa-button-nimh-hr-3u-2500l2x3.html>.
[33] "SparkFun Electronics - Compass Module - HMC6352." SparkFun Electronics - News.

Web. 11 Feb. 2010. <http://www.sparkfun.com/commerce/product_info.php?
products_id=7915>.
[34] "SparkFun Electronics - SD/MMC Socket for Secure Digital Disk or Multi Media Cards."
SparkFun Electronics - News. Web. 11 Feb. 2010.
[35] "SparkFun Electronics - Venus GPS Logger with SMA Connector." SparkFun Electronics -
News. Web. 11 Feb. 2010. <http://www.sparkfun.com/commerce/product_info.php?
products_id=9171>.
A-51
[36] "SparkFun Electronics - Antenna GPS 3V Magnetic Mount SMA." SparkFun Electronics -
News. Web. 11 Feb. 2010. <http://www.sparkfun.com/commerce/product_info.php?
products_id=464>.
[37] "PG164120-ND (Manufacturer - PG164120)." Digi-Key. Web. 11 Feb. 2010.

<http://search.digikey.com/scripts/DkSearch/dksus.dll?
WT.z_header=search_go&lang=en&site=us&keywords=pg164120-nd&x=0&y=0>.
[38] “VENUS634FLPx Data Sheet,” 2008. Available:
http://www.sparkfun.com/datasheets/GPS/Modules/Skytraq-
Venus634FLPx_DS_v051.pdf. [Accessed: Feb. 16, 2010].
[39] “Digital Compass Solution HMC6352 Data Sheet,” Available:

http://www.sparkfun.com/datasheets/Components/HMC6352.pdf. [Accessed: Feb. 16,
2010].
[40] “LV-MaxSonar-EZ0 High Performance Sonar Range Finder Data Sheet,” Available:
http://www.maxbotix.com/uploads/LV-MaxSonar-EZ0-Datasheet.pdf. [Accessed: Feb.
16, 2010].
[41] “ADPCM using the PIC 16/17,” Available: http://www.microchip.com/stellent/idcplg?

IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011118. [Accessed: Feb. 17,
2010].
[42] “Sitronix Dot Matrix LCD Controller/Driver Data Sheet,” Available:

http://www.sparkfun.com/datasheets/LCD/st7066.pdf. [Accessed: Feb. 16, 2010].
[43] The Circuit Calculator Blog, “PCB Trace Width Calculator,” Online Circuit Calculators.
[Online] Available: http://www.circuitcalculator.com/wordpress/2006/01/31/pcb-trace-
width-calculator/. [Accessed: 24 Feb 2010.]
[44] Glenewinkel, Mark, “System Design and Layout Techniques for Noise Reduction in MCU-
Based Systems,” Tech. Motorola Semiconductor. [Online] Available:
https://engineering.purdue.edu/ece477/Homework/CommonRefs/AN1259.pdf.
[Acessed 19 Feb 2010]
[45] Microchip Technology, “PIC24HJXXXGPX06/X08/X10 Data Sheet,” Microchip
Technology. [Online] Available:
http://ww1.microchip.com/downloads/en/devicedoc/70175H.pdf. [Accessed 24 Feb
2010]
A-52
[46] National Semiconductor, “LM25085A 42V Constant On-Time PFET Buck Switching
Controller with 0.9V Reference,” National Semiconductor. [Online] Available:
http://www.national.com/ds/LM/LM25085A.pdf. [Accessed 24 Feb 2010]
[47] National Semiconductor, “LM22672 1A SIMPLE SWITCHER, Step-Down Voltage

Regulator with Features,” National Semiconductor. [Online] Available:
http://www.national.com/ds/LM/LM22672.pdf. [Accessed 24 Feb 2010]
[48] Toshiba, “TA8429H/HQ,” Toshiba. [Online] Available:

http://www.toshiba.com/taec/components2/Datasheet_Sync//261/3610.pdf [Accessed 24
Feb 2010]
[49] Microchip, “PIC24HJXXXGPXXX Data Sheet,” Microchip, 2009. [Online]. Available:

http://ww1.microchip.com/downloads/en/DeviceDoc/70175H.pdf. [Accessed: Mar. 25,
2010].
[50] Microchip, “Adaptive Differential Pulse Code Modulation Using PIC Microcontrollers”,
Microchip, 2007, Available:
http://ww1.microchip.com/downloads/en/AppNotes/00643c.pdf. [Accessed: Mar. 25,
2010].
[51] Microchip. (2007). AN643 Source Code [Online]. Available:

https://engineering.purdue.edu/477grp11/software/an643.zip. [Accessed: Mar. 25,
2010].
[52] Microchip, “Implementing File I/O Functions Using Microchip’s Memory Disk Drive File
System Library”, 2008, Available:
http://ww1.microchip.com/downloads/en/AppNotes/01045b.pdf. [Accessed: Mar. 25,
2010].
[53] Microchip. (2008). Microchip MDD File System 1.2.1 Installer [Online]. Available:
https://engineering.purdue.edu/477grp11/software/libSD.zip. [Accessed: Mar. 25, 2010].
Appendix A: Individual Contributions
A-53
A.1 Contributions of Bryan McDonnel:
As the lead software developer for RoboSiM, Bryan’s chief contributions were during
the second half of the project’s life cycle. He was responsible for the design of the vehicle’s
operating system architecture, development of navigation and obstacle avoidance algorithms, and
team website maintenance. Even though his contributions were primarily during the latter half of
the semester, he made every effort to assist during all phases of the project.
During the initial hardware design phase, Bryan was tasked with choosing an
appropriate microcontroller. Initially, the team decided to use an ATmega chip, but later
discovered that it lacked certain necessary features. It fell to Bryan to find a suitable replacement
microcontroller, and at the suggestion of the TAs, he began to consider Microchip’s PIC24 series.
With the availability of development boards in the lab, this became an easy choice.
After selecting a suitable microcontroller, it was up to Bryan to construct a proper
microcontroller circuit, complete with reset and programming functionality. With the help of the
device’s datasheet and some online tutorials, he came up with an appropriate circuit for Ryan to
include in the schematic.
Since Ryan took care of the PCB layout, there was very little hardware design to
which Bryan could contribute. In order not to waste any time, Bryan (with the help of Miles)
started working with the lab-provided PIC24 development board. He had several APIs (an LCD
driver, system level modules, and general functionally organization) thoroughly defined before
the PCB was even back from the manufacturer.
While waiting for the PCB to be manufactured, Bryan worked on specifying
RoboSiM’s operating system architecture. It was important for this to be done before the
hardware was completed so that software testing on the constructed PCB wasn’t stalled. In
hindsight, this helped enormously to smooth the transition from the development board to the
team’s specific hardware.
Once the PCB had been delivered, and the power supplies had been soldered and
tested, Bryan was responsible for soldering the microcontroller to the board. Having practiced
for such a delicate operation several times over the preceding days, he completed it with
confidence.
A-54
During the remainder of the project, Bryan focused on the development and testing of
navigational and obstacle avoidance algorithms. The success of the project hinged on the quality
of these algorithms, so the testing was extensive and thorough. He also helped integrate Ryan
and Miles’ contributions and ensured that all encapsulation and modularity guidelines were met.
Throughout the entirety of RoboSiM’s development, Bryan acted as webmaster. He
designed and implemented from scratch a website to keep the team up-to-date with all the
contributions of its members. This task was of vital importance for providing access to all of the
team’s documents at all of the different locations in which work was performed throughout the
semester.
A.2 Contributions of Michael Mize:
Michael started the semester by going over HTML coding examples and setting up an
initial team webpage. He then worked with the team to determine what the capabilities of the
project would be, and what the Project Specific Success Criteria (PSSC) would include. Michael
worked with the team on creating the final proposal, and was involved in looking up parts for the
initial block diagram. After the final proposal, he then examined part vendors for items that
would be suitable for the project. He compared a variety of suitable products, and determined
which ones would be best for our initial microcontroller choice; his findings were used in the
Design Constraint Analysis homework as the initial parts list. Michael then worked with the rest
of the team in thoroughly going over all parts that would be used in a spreadsheet application
online; he specifically made comparisons between the ATmega328PA microcontroller and
dsPIC33F DSP as options for the project. After these comparisons were made, Michael then
reviewed a previous team’s final report to determine how their choice of parts compared to our
own; he specifically looked for challenges that were faced based on their choice of parts.
After reviewing the team’s report, Michael began working on the first homework he
was responsible for, the Theory of Operation and Hardware Design Narrative. He reviewed the
final list of parts that had been chosen, and determined how each device would be
communicating with the microcontroller. Michael then reviewed programs used for making
block diagrams online, and learned to use a program called Dia to create the bock diagram used
for the report; this diagram was then updated and modified to use in other areas as the project
A-55
progressed. He then discussed control of the motors and the power supply system with Ryan,
which was then added to the report by Ryan. Michael’s review of parts and their communication
with the microcontroller along with Ryan’s work on motor control and power completed the
Theory of Operation and Hardware Design Narrative homework.
After the homework, Michael worked with the team on matching the PCB layout to
parts that were received to ensure a correct fit. At this time, he also tested the motors and the H-
bridge controllers; he determined the PWM signal that was needed to run each motor, and tested
the chassis by hooking it up to a power supply and function generator that provided a PWM
signal. He then tested the type of terrain the chassis was capable of running on by setting up a
course using materials in the lab, and having the robot travel it. Michael then worked on
choosing a battery that was suitable for the project; he reviewed batteries available online and
determined the type, size, and output that would be suitable for the robot; at this time, he also
researched wire gauge and connector types to determine which would be best for the choice of
battery.
A.3 Contributions of Ryan Taylor:
During the planning phase of the project, Ryan helped develop RoboSiM’s initial
kinetics and obstacle detection hardware. He also researched the chassis and dc motor options
that were commercially available since he was the only team member who had experience with
motors.
Ryan also contributed to the component selection near the beginning of the schematic
development. In particular, he determined that ultrasonic sensors would be useful for object
detection, and that a digital compass breakout board from Sparkfun would allow for accurate
bearing measurements (rather than computing heading from GPS samples). Finally, he selected a
small, tracked robot chassis from an online distributor.
The power supply system was designed by Ryan, with some help from National
Semiconductor’s WEBENCH simulation software. Both the high- and low-power supplies had to
be characterized (in terms of expected/peak current draw and anticipated power consumption) in
order to appropriately select components.
He also determined a control scheme for the two dc motors: h-bridge controllers
driven by PWM signals from the microcontroller. Once these systems, as well as the
A-56
microcontroller/sensor hardware and the audio circuit, were designed, Ryan translated the system
circuit into a schematic capture program, PADS Logic.
As the only team member with previous PCB layout experience, Ryan completed the
entire circuit board layout using PADS Layout. Although it took many hours to complete, the
final design had no significant DFM errors, and was submitted with no issues to fabrication
house. When the PCB was delivered, Ryan soldered all of the components (except for the
microcontroller, which Bryan handled) and discovered that there were no hardware issues: all of
the power supplies had outputs that were very close to the nominal voltages under load, the
microcontroller executed code perfectly, and the motor control hardware drove both dc motors
with no issues. Since he was the most experienced at soldering, Ryan also built most of the
connectors used to interface with the various peripherals (LCD, ultrasonic sensors, GPS, etc).
Although Ryan had little experience with embedded software outside of the work done
in ECE362 (with Assembly), he felt compelled to contribute to at least one functional block of
RoboSiM’s code. He wrote the basic functionality of both the LCD code and the audio encoding
software. Though the code required some clean-up (which Bryan and Miles handled), they were
functional.
Ryan spent many hours in the lab with Bryan and Miles debugging the navigation and
obstacle detection software towards the end of the semester. Although he didn’t write any code
personally, he was able to provide a second (or third) pair of eyes to help catch mistakes and
solve issues.
At the end of the semester, Ryan had logged over 300 hours working on RoboSiM. He
feels that his most significant contributions were made to the project concept and hardware
design, although he attempted to engage with all aspects of the project.
A.4 Contributions of Miles Whittaker:
Miles wrote the initial software for the I2C module, Sensors, Motor Control, PWM
module, and Digital Compass. He also helped with other portions of the software that Bryan and
Ryan initially wrote. During the testing phase he developed valuable solutions to navigational
problems.
Miles wrote functions for sending and receiving individual bytes as well as multi-byte
messages, sending a start sequence, sending a restart sequence, and sending a stop sequence for
A-57
the I2C module so that the Digital Compass could communicate to the PIC24H. The Compass
module has functions for sending multi-byte messages as well as configuration messages for
configuring such things as Operation Mode and Output Mode. The most important function is
the function the sends the “get heading” command to the compass and returns the current
heading of the compass with accuracy up to 0.1 degrees. Unfortunately we were only able to
receive the first byte of the heading so RoboSiM is not that accurate.
The Motor Control module was configured to allow forward movement and reverse
movement, hard turning and soft turning, and stopping. In order for these functions to work,
Miles wrote functions for setting the duty cycle of a given channel in the PWM module. He also
wrote some functions in main.c that allowed the Compass to be integrated into the Motor Control
so that RoboSiM could turn and face North, South, East, West, Northwest, etc. These functions
helped simplify the navigational algorithm that Bryan wrote.
Miles modified the ADC module initially written by Bryan to allow the Sensors to be
integrated. He added functions for returning the ADC buffer as an 8-bit voltage value, 8-bit
value, or a 10-bit value. The Sensor module would get the buffer value as an 8-bit value and then
do some basic math in order to calculate the distance to an object.
In the main.c file, Miles also wrote functions for reading the target destination off of
the SD Card and a simple wait loop that waits for a given amount of time. He also helped with
the navigation algorithm that Byran wrote, and helped clean up and reduce redundancies in the
Audio module and LCD module that Ryan wrote.
Miles did homework 4 which was the initial packaging constraints. He created a CAD
diagram of what was believed to be the packaging at the time. Packaging was later taken over by
Michael. Miles also did homework 10 which described a few patents that may have been
infringed upon and potential solutions for preventing lawsuits.
A-58
Appendix B: Packaging
Figure B.1 – Initial Packaging Design
Figure B.2 – Final Packaging Design
B-1
Figure B.3 – Prototype Model
B-2
Appendix C: Schematic
Figure C.1 – Power Supply Schematic
Figure C.2 – Motor Control Schematic
C-1
Figure C.3 – Microcontroller Schematic
C-2
Appendix D: PCB Layout Top and Bottom Copper
Figure D.1 – PCB Top Copper
D-1
Figure D.2 – PCB Bottom Copper
D-2
Appendix E: Parts List Spreadsheet
Vendor Manufacturer Part No. Description Unit Cost Qt Total Cost
Digi-Key Atmel ATxmega256A3 8/16-bit microcontroller $9.14 1 $9.14

Sparkfun Maxbotix LV-EZ0 Ultrasonic Range Finder $27.95 3 $83.85
Sparkfun Xiamen Ocular GDM1602K 16x2 Character LCD - Red on Black 5V $14.95 1 $14.95
Purdue Microchip dsPIC33 Digital Signal Controller $10.62 1 $10.62
Digi-Key FDK America Inc HR-3U-2500L2X3 7.2V 2300mA Battery Pack $33.46 1 $33.46
Sparkfun Honeywell HMC6352 Digital Compass $34.95 1 $34.95
Sparkfun 4UCON Technology PP-14446 SD card socket $3.95 1 $3.95
RadioShack RadioShack 33-3039 Omni-directional Dynamic Microphone $24.99 1 $24.99
Sparkfun Sparkfun GPS-09171 GPS Logger with SMA Connector $59.95 1 $59.95
HobbyTron - - Mercedes 4WD R/C Car $55.00 1 $55.00
- - - Motor $15.00 2 $30.00
- - - Supporting Hardware (Wiring, Passives) $25.00 1 $25.00
E-1
TOTAL $385.86
E-2
Appendix F: FMECA Worksheet
Table F.1 – Decision Engine Block
Failure Failure Mode Possible Causes Failure Effects Method of Criticality Remarks
No. Detection
A1 PµC > 73mW[5] Core clock fault; Heat Observation; High Excessive heat or
faulty power supply accumulation, heat and smell; battery draw can pose a
connection; fighting decreased part Potential LCD fire hazard and/or risk
on output pins lifetime, and motor of burn injury
navigation glitches control glitches
A2 Erroneous Connector failure due Intermittent LCD Observation; Low Occasional glitches may
communication to mechanical wear; display errors, visual be difficult to detect;
between PIC and stuck-at fault on PIC complete loss of observation of will not affect RoboSiM
LCD GPIO; LCD power display LCD functionality
loss; timing errors[5]
A3 Software fails to Destroyed RoboSiM will not Observation Low Reliability could be
execute microcontroller; µC function in any improved by mounting
power-up failure; capacity the microcontroller in a
faulty power supply; socket.
software error
A4 Inability Faulty connection to Software updates Observation; Low Production level
download code to programmer; µC impossible programmer versions of RoboSiM
microcontroller power-up failure; will not connect will not be
destroyed component to device reprogrammed by the
user
F-1
Table F.2 – Motor Control Block
No. Detection
B1 Vmotor stuck at 6V Microcontroller One or both Observation; Elevated Component damage
PWM failure motors driven at RoboSiM will may result from
(hardware or full speed; be unable to excessive heat and
software); H-Bridge excessive heating turn normally or current. A built-in self
controller failure[6]; in H-Bridges, 6V avoid obstacles test may help identify
noise on PWM traces Supply, and this condition before
battery damage occurs.
B2 Vmotor stuck at 0V Loss of power to H- One or both Observation; if Low Nuisance failure. No
Bride controllers[6]; motors stationary;only one motor component damage or
faulty connection to RoboSiM faults, RoboSiM personal injury will
motor headers; µC motionless or will move in result
power failure moving circles; if both
erratically motors affected,
no motion will
occur
B3 Motor operating Stuck-at fault on If PWM control Observation; Low No risk of component
modes reversed PWM control lines; line is stuck or motors will failure or injury
H-Bridge controller floating; operate
logic failure operating mode of erratically
motor may be
reversed;
RoboSiM
movements
erratic or halted
F-2
Table F.3 – Power Supply Block
No. Detection
C1 3.3V rail = 0V 3.3V buck converter Excessive Observation; heat High Possible burn risk with
diode shorted to currents, heat and smoke likely; heated components.
ground; destroyed µC build-up; erratic/no Battery fire potential;
or op-amp; regulator destroyed behavior of shortened component
IC failure; MOSFET components; system lifetimes[2]
failure[3] battery fire
C2 3.3V rail > 3.3V Regulator IC Possible damage Observation; Elevated Damage to 3.3V
destroyed; damage to to µC, LCD, elevated heat, components likely[2]
feedback resistors; no digital compass, decision engine
load current audio circuit, and glitches
ultrasonics
C3 3.3V rail < 3.3V Battery under- Digital Observation; Low Nuisance failure
voltage; losses on components on possible software
power traces; the bus fail to reboot; loss of
Regulator IC failure operate; GPS lock
brownout on
analog
components
C4 3.3V rail open Power trace(s) RoboSiM unable Observation; Low Nuisance failure
circuit destroyed; faulty to make Uncontrolled
connection to battery navigation motion
decisions or
obstacle detection
F-3
No. Detection
C5 6V rail = 0V 6V buck converter Excessive Observation; heat High Possible burn risk with
diode failure; failure currents; and smoke likely; heated components;
of output capacitor[4];destroyed erratic behavior Battery fire potential;
regulator IC failure components; of motor control shortened component
motor control lifetimes
system failure
C6 6V Rail > 6V Regulator IC Excessive heat Observation; high Elevated Possible damage to 6V
destroyed; damage to and currents on temperatures; components with time
feedback resistors; no motor windings; faster motor
load current heat operation
accumulation in
H-Bridge
controllers
C7 6V Rail < 6V Battery Under- Motor efficiency Observation; Low Nuisance failure;
voltage; losses on drops slower motor; efficiency drop in
power traces; motor may heat
regulator IC failure windings slightly
C8 6V Rail Open Power traces RoboSiM loses Observation; No Low Nuisance failure
Circuit destroyed; faulty motor control motor
connection to battery; functionality movement/control
regulator IC failure
F-4

Display On VGA Without SDRAM

Uploaded by

Copyright:

Available Formats

You might also like

Display On VGA Without SDRAM

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Display On VGA Without SDRAM

Uploaded by

Copyright:

Available Formats

ECE 477 Final Report  Spring 2010

#1: Bryan McDonnel Signature: _Bryan McDonnel_______ Date:

#2: Michael Mize Signature: _Michael Mize_ ______ Date:

#3: Ryan Taylor Signature: __Ryan Taylor ________ Date:

#4: Miles Whittaker Signature: __Miles Whittaker______ Date:

CRITERION SCORE MPY PTS

Appendix D: PCB Layout Top and Bottom Copper ?

RoboSiM (Robotic Surveillance in Motion) is a fully autonomous, GPS-guided platform

1.0 Project Overview and Block Diagram

2.0 Team Success Criteria and Fulfillment

1. An ability to display the current status of the robot on an external display

2. An ability to read and write data from a portable media device

4. An ability to move robot using steering and motor drive

5. An ability to record and encode audio

3.0 Constraint Analysis and Component Selection

1. Display the current status of the robot on an external display.

3.0 Component Selection Rationale

4.0 Patent Liability Analysis

2.0 Results of Patent and Product Search

2.1 Common Name Space For Long and Short Filenames

2.2 Autonomous Navigation System and Method

2.3 Sonar Scanner

3.0 Analysis of Patent Liability

4.0 Action Recommended

4.0 Reliability and Safety Analysis

5.0 Reliability Analysis

5.1 Components at Risk

5.2 Failure Rate Analysis

Component: AOD413 6V NPN MOSFET

πA Application Factor Power FET 2.0 6V supply switch

Component: TA8429A H-Bridge Controller

Nc1 Number of Discrete - 1 1 Power MOSFET

Component: LM22672MR-ADJ 3.3V Regulator Switching Controller

Nc1 Number of Discretes - 1 1 Power MOSFET

Component: TPSB476K010R0250 6V Output Capacitor

Parameter Description Qualifier Value Comments

Parameter Description Qualifier Value Comments

6.0 Failure Mode, Effects, and Criticality Analysis (FMECA)

Low: nuisance failure; no risk of component damage or personal injury

5.0 Ethical and Environmental Impact Analysis

RoboSiM is a robotic platform designed for surveillance purposes. This involves

2.0 Ethical Impact Analysis

3.0 Environmental Impact Analysis

on the environment than their disposable counterparts[21].” Choosing a rechargeable battery

6.0 Packaging Design Considerations

[1] Commercial Product Packaging

[2] Project Packaging Specifications

[3] PCB Footprint Layout

7.0 Schematic Design Considerations

8.0 PCB Layout Design Considerations

2.0 PCB Layout Design Considerations - Overall

3.0 PCB Layout Design Considerations - Microcontroller

4.0 PCB Layout Design Considerations - Power Supply

9.0 Software Design Considerations

2.0 Software Design Considerations

2.1 Hardware/Software Interface

2.2 Application Organization

#3: Ryan Taylor Signature: Ryan Taylor ______ Date:

#4: Miles Whittaker Signature: Miles Whittaker____ Date: