Capability Enhancements for
Autonomous Mobile Wireless Sensors
May 13, 2005
Comprehensive Design Report
Mobile Sensor Platform Design
Andrew Mullen Adam Haun
Edgar Martin Darnelle Haye
Stephen Ortiz Khoa Nguyen
Kate Gleason College of Engineering
Rochester Institute of Technology
76 Lomb Memorial Drive
Rochester, NY 14623-5604
This comprehensive design report summarizes the progress made by the
Capability Enhancements for Autonomous Mobile Wireless Sensor Senior Design Team.
The goal of this project is to design, fabricate, and test four autonomous sensor platform
which will be able to communicate using wireless technology to other identical
platforms. Upon completion of the four sensor platforms, an algorithm will be designed
and implemented allowing the platforms to reorganize themselves into different
formation topologies. This project mimics the use of a group of robots to accomplish a
task and work together as a team.
The team used the Engineering Design Planner™ methodology to design the
mobile sensor platform. The first five aspects of this process have been successfully
completed. The first aspect of the report, recognizing and quantifying the need, discusses
the goals, motivation, and background for the project. The second aspect presents an
overview of concept development process as well as the concepts generated by the team.
The next section presents the feasibility assessment the team conducted for the generated
concepts and the recommendations of the team. The fourth aspect presents a detailed
description of the goals of the project and the specifications to which the project must
adhere. The fifth, analysis and design, is the bulk of the report. It describes the analyses
that have been done to design the sensor platform as well as the progress that has been
made so far. The remaining portion of the report chronicles the Design, Testing, and
Redesign of the sensor platform.
Utilizing the Engineering Design Planner™ allowed the team to develop a more
efficient design. Through the framework presented, the project was given focus and
direction. The generation and analysis of concepts stages were important in allowing the
project team to view the final product from a different angle and produce a better product.
The team successfully designed and constructed a set of five mobile sensor platforms
with an array of different sensors. The sensors were selected for specific tasks which
optimized their effectiveness. The sponsor upon demonstration of the final product was
pleased with the results.
Table of Contents
Executive Summary 02
Table of Contents 03
List of Figures 06
1 .0 Recognize and Quantify Need 07
1 .1 Mission Statement 07
1 .2 Product Description 07
1 .3 Scope Limitations 08
1 .4 Stakeholders 08
1 .5 Top Level Critical Financial Parameters 08
1 .6 Financial Analysis 08
1 .7 Primary Markets 09
1 .8 Secondary Markets 09
1 .9 Innovation Opportunities 09
1 .10 Background Research 10
1 .11 Formal Statement of Work 11
2 .0 Concept Development 12
2 .1 Delineation of Concepts 12
2 .2 Communication System Concept 13
2 .2 .1 PC Based Communication 14
2 .2 .2 Mica2dot RF Communication 14
2 .3 Electronics and Sensor Concept 15
2 .3 .1 Infrared Sensors 16
2 .3 .2 Ultrasonic Sensors 17
2 .3 .3 Compass Sensors 18
2 .3 .4 Motor Controllers 19
2 .3 .5 PIC Microcontroller 19
2 .4 Locomotion Concept 20
2 .4 .1 Chassis Concept 21
2 .4 .1 .1 Differential Drive 22
2 .4 .1 .2 Synchro Drive 23
2 .4 .1 .3 Car Type Drive 23
2 .4 .1 .4 Skid Steer Drive 24
2 .4 .2 Four Wheels 25
2 .4 .3 Two Wheels 25
2 .4 .3 .1 Caster Pivots 25
2 .4 .3 .2 Ball Bearing Pivots 26
2 .4 .4 Motors 26
3 .0 Feasibility 28
3 .1 Communication System Feasibility 28
3 .1 .1 PC Based Communication 28
3 .1 .2 Mica2dot RF Transceiver 29
3 .1 .3 Communication System Conclusions 29
3 .2 Electronics and Sensor Feasibility 30
3 .2 .1 Infrared Sensors 30
3 .2 .2 Ultrasonic Sensors 30
3 .2 .3 Compass Sensors 31
3 .2 .4 Motor Controllers 32
3 .2 .5 Electronics and Sensor Conclusions 33
3 .3 Locomotion Feasibility 34
3 .3 .1 Pre-Built Chassis 35
3 .3 .2 Custom Built Chassis 36
3 .3 .2 .1 Motors 37
3 .3 .3 Locomotion Conclusions 37
3 .4 Feasibility Conclusion 38
4 .0 Performance Objectives and Specifications 39
4 .1 Mechanical Design Objectives 39
4 .2 Electrical Design Objectives 40
4 .3 Software Design Objectives 40
4 .4 Mechanical Performance Specifications 41
4 .5 Electrical Performance Specifications 42
4 .6 Software Performance Specifications 42
4 .7 Design Practices Used 43
4 .8 Safety Issues 44
5 .0 Analysis of Problem and Synthesis of Design 45
5 .1 Hardware 45
5 .1 .1 Mechanical Design 45
5 .1 .1 .1 Initial Prototype Designs 46
5 .1 .1 .2 Current Prototype Design 47
5 .1 .1 .3 Final Design Plans 48
5 .1 .2 Electrical Design 48
5 .1 .2 .1 Performance Testing 49
5 .1 .2 .2 Sensor Performance 49
5 .1 .2 .3 Motor Performance 51
5 .1 .2 .4 Power Management 52
5 .1 .2 .5 Electrical System Schematics 53
5 .2 Software 56
5 .2 .1 Movement Processes 56
5 .2 .2 Sensing Process 57
5 .2 .3 Communications 59
5 .2 .4 Topology 60
5 .2 .4 .1 Procedure for Orientation 60
5 .2 .4 .2 Procedure for Creating and Forming Topology 61
5 .2 .4 .3 Movement of the Entire Network 61
5 .3 Analysis and Design Conclusions 61
6 .0 Initial Design 62
6 .1 Chassis Design 62
6 .2 Electrical Design 63
6 .3 Wireless Design 64
6 .4 Debug Environment Design 66
6 .5 Code Design 69
7 .0 Testing/Redesign 72
7 .1 Chassis Testing/Redesign 72
7 .2 Electrical Testing/Redesign 75
7 .3 Wireless Testing/Redesign 75
7 .4 Debug Environment Testing/Redesign 81
7 .5 Code Testing/Redesign 82
8 .0 Final Design 84
8 .1 Chassis Design 84
8 .2 Electrical Design 85
8 .3 Debug Environment Design 87
8 .4 Code Design 87
9 .0 Conclusion 91
9 .1 Photographs of completed components 92
9 .2 Schedule for the Senior Design Team 95
9 .3 Overall Budget 95
9 .4 Future Improvements 96
A Electrical Pinouts
B Mechanical Design Package
B .1 SolidWorks 2004 Model Diagrams
B .2 Dimesion Diagrams
C Code Developed for the Project
C .1 Object Tracking Demonstration Code
C .2 Serial Communicator GUI Interface Code
D Specifications Document
List of Figures
12 Figure 1 – Concept Focus Groups
14 Figure 2 – PC Based Communication
15 Figure 3 – Mica2Dot Mote
16 Figure 4 – Infrared Distance Measurement
17 Figure 5 - Sharp Infrared Sensor
17 Figure 6 - Devantech SRF04
18 Figure 7 - Devantech Compass
19 Figure 8 - Motor Controller Driver
20 Figure 9 - PIC Microcontroller
22 Figure 10 - Differential Drive
25 Figure 11 - Castor Pivot
26 Figure 12 - Ball Bearing
27 Figure 13 - DC Stepper Motor
31 Figure 14 - Sonar Beam Pattern
35 Figure 15 - Pre-Built Robots
36 Figure 16 - Initial Prototype for Weight Testing
47 Figure 17 - Second Prototype
47 Figure 18 - Current Prototype Chassis
49 Figure 19 - System Block Diagram
50 Figure 20 - Sonar Sensor Measurement Test
53 Figure 21 - 5-Volt Regulator
54 Figure 22 - MC3479 Motor Controller Implementation
55 Figure 23 - Close-up of Single UC3770 Motor Controller Implementation
55 Figure 24 - Complete UC3770 Motor Controller Interface Implementation
58 Figure 25 - Time Per Counter Tick
59 Figure 26 - Mica2Dot Packet Format
63 Error! Reference source not found.Error! Reference source not found.
64 Figure 28 – Prototype with Breadboard
67 Figure 29 – Initial GUI Design
69 Figure 30 – 05506 - Team Logo
73 Figure 31 – Final Mast Design
74 Figure 32 - Castor Bearing Option 2
74 Figure 33 – Ideal Castor Bearing
85 Figure 34 – Completed Robot Design
86 Figure 35 – Printed Circuit Board Design
87 Figure 36 – Final GUI Design
89 Figure 37 – Object Tracking Flowchart
90 Figure 38 – Box Formation Flowchart
92 Figure 39 - Completed Printed Circuit Board
93 Figure 40 – Side View of Final Product
93 Figure 41 – Frontal View of Finished Product
94 Figure 42 – Squad of Sensor Platforms
95 Figure 43– Project Plan for Senior Design II
1.0 Recognize and Quantify the Need
1.1 Mission Statement
The mission of the Capability Enhancements for Autonomous Mobile Wireless
Sensor Team multidisciplinary design project group has two main objectives. The first
objective is to develop a robust mobile sensor platform, which is small, agile, and power
efficient. Once one robot is completed, additional robots will be built to form a robotic
sensor network where sensor platforms (robots) may communicate with one another and
move from their original deployment locations, so as to form a desired topology that
offers full and energy efficient coverage.
1.2 Product Description
Recent technological advances in the design and functionality of wireless devices
have made it possible to create wireless motes the size of a quarter which can transmit
data to receivers over 100 feet away. Not only are these transmitters small and energy
efficient, but they also have significant programming capability in terms of receiving and
processing information before passing it on to another mote.
Sensor networks can be made of up tens, hundreds, or even thousands of these
small devices. Using an ad hoc transmission protocol, a sensor network may be formed
to achieve sensing tasks that were previously infeasible with a single powerful sensor. A
key design challenge when creating such a network is to maximize the overall capability
and efficiency with the finite resources available on the individual sensors.
The network, which will be constructed for this project, will initially consist of
approximately five wireless motes. The protocol in the communication will, however, be
able to support significantly more wireless motes. These motes will be connected to
individual mobile sensing platforms and will be capable of communication with other
platforms effectively. The platforms will be able to move individually or coordinate the
movements as a group to create a specified topology dependent on the mission and
resources at hand.
The future of this project is to successfully create a group of small mobile robotic
sensor platforms that could be deployed as a sensor network to perform a task easily and
1.3 Scope Limitations
The sensor platforms will be designed and constructed by a group of 4th and 5th
year ME, EE, and CE students. The initial project should last no longer than two
academic quarters, yet allow for future teams to enhance or produce more of the mobile
platforms. At the conclusion of this project, a functioning group of sensor platforms is
desired for demonstration.
Stakeholders for this project include the group of ME’s, EE’s, and CE’s working
on the project itself. Additional stakeholders include the Kate Gleason College of
Engineering and the project sponsor: The Intelligence Community.
1.5 Top Level Critical Financial Parameters
The following describes the critical financial parameters related to this project.
• The preferred size of the sensor platforms is as small as feasibly possible.
• The majority of the components used should be from previous design groups
• The communication scheme preferred is RF.
• The number of sensor platforms constructed must be between three and five.
• The sensors must be robust and not easily destroyed.
• Off the shelf programmable parts must be used due to the time constraint.
1.6 Financial Analysis
A budget of $1000 has been proposed for the robotic sensor network. This budget
• Four robotic platforms.
• Four PIC micro controllers.
• Four transceiver units.
• Four sensing kits
• Distance Sensors
• Direction Sensor
• Rechargeable power supplies
• Motor Controller Interfaces
1.7 Primary Markets
The primary market for the robotic sensor network is the military and the project
sponsor: The Intelligence Community.
1.8 Secondary Markets
Secondary markets include scientific based corporations such as surveying
companies or educational/research groups looking to examine distributed group behavior.
The functionality of the robotic network created is limited mainly in the types of sensors
that are currently adapted to robot itself.
1.9 Innovation Opportunities
Although algorithms have been created to allow for general topologies to be
created by small mobile devices, they are all far too complex to implement on a small
PIC microcontroller. However, with the additional information gathered by the sensor
package on the robot, we should be able to develop a unique autonomous algorithm
allowing the robots to move into formations without the help of a leader or controller.
1.10 Background Research
Simply watching current events show that there is a considerable interest building
in the military and other groups in order to build autonomous vehicles. DARPA, the
Defense Advanced Research Projects Agency, recently sponsored the DARPA
Challenge. The DARPA Challenge is a cross-country race of autonomous vehicles
across the California and Nevada desert, with the first place winner receiving a one
million dollar prize. Because of the publicity of the DARPA Challenge, there has been a
recent boom in research done on autonomous vehicles. Unfortunately most of the
algorithms and concepts found are too intricate and expensive to implement on a project
of such a small scale. However, in the abstract, concepts such as obstacle avoidance, best
path to objective, and object detection can be useful in the design of similar algorithms
for this project.
Several government agencies and colleges have begun to focus heavily on
research to design autonomous vehicles that can work together as a team or unit to
complete a given task. These tasks vary from battlefield scenarios to searching for
victims of a natural disaster. Several colleges have sponsored design competitions where
students must design and construct a group of small robots that can work together as a
team to perform such tasks as playing soccer. These robots can effectively work together
as a team, however they often other wireless protocol such as Bluetooth, which do not
help us in our implementation.
Very little is known about the primary focus of the project, formation topology,
and what is available is often theoretical and possibly simulated at best. Selection of the
best formation for the mission at hand often depends heavily upon the specific sensor
capabilities of the robot, expected lifetime of the robot, as well as the number of robots
present. All of the pre-designed robots (in our price range) are efficient at completing the
tasks for which they were designed, however they leave little room for improvement
because of limitations on Input/Output, processor power, and robot memory. Therefore,
the use of a pre-designed robot is a poor option because the final version would not be
robust enough to overcome simple operational barriers or allow future research to be built
on top of the existing platforms.
The goal of this project is to design a robot that can handle these complex
problems in a simple, efficient, and cost-effective manner. This includes constructing a
mobile sensor network that can move into a specified topology, communicate effectively,
and be robust enough to handle operational barriers such as the loss of a robot during
1.11 Formal Statement of Work:
The project team agrees to have the following items completed by the end of the first
stage of the design process:
• Facets 1-6 of the design process completed (completed PDR)
• A design for a prototype sensor platform (chassis, electrical layout, software)
• A completed plan for prototype testing (software development & debugging)
• One constructed prototype to be used during software testing
By the end of the second phase of the design process the team agrees to have completed
the following items:
• Facets 1-10 of the design process completed (completed CDR)
• A final design for the sensor platforms (chassis, electrical layout, software)
• Four constructed sensor platforms to be used for testing and demonstration
• A complete test data package (to be used in future projects)
• A detailed project website
• A completed technical paper
2.0 Concept Development
2.1 Delineation of Concepts
The first task of the group as a whole was to examine the project and its desired
outcomes and break down the project into manageable components in order to work more
efficiently on each part. In this way, the team could be further divided into specialist
groups. Since the project was a six-member team, three main categories for research and
development were selected. These major categories are shown in the second row of
Figure 1 – Concept Focus Groups below.
Mobile Wireless Sensor
Chassis Design Electronics & Communication
Materials Selection PIC controller selection PC Based
Locomotion Method Motor controller selection Communication
Castors Infrared Mica2dot RF
Ball Bearings Ultrasonic Transceiver
Figure 1 – Concept Focus Groups
The first focus group, chassis design, was primarily concerned with the overall
layout of the chassis, the number of motors to integrate, how to make the robot pivot
smoothly, and the possible materials which could be used to create the chassis itself. The
second focus group, electronics & sensors, was centered on selection of controllers and
sensors for the robot, as well as the electrical layout of all of the components. This group
had the largest task, because the PIC requires a significant amount of coding and research
in order to become functional, and it is the heart and mind of the robot. The sensor
options, infrared and ultrasonic, are the primary ways in which the robot interacts with
the environment. The final focus group, communication, examined the most puzzling
aspect of the robot design, the Mica2dot RF Transceiver interface. It was requested that
the Mica2dot motes be used for the wireless communication for the project, yet nothing
was known by the team members, or the vast majority of the educational community as a
whole at the beginning of the project. The Mica2dot is a relatively new, and complex,
development in Wireless motes.
2.2 Communication System Concept
One of the major goals of the project is to develop an autonomous wireless mobile
sensor platform. What this means is that each individual robot must have the capability
to make decisions on its own related to the surrounding environment, and through
communication move into a formation topology in relation to other platforms.
Ineffective communication would render the network, and thus the robots, useless.
Efficient communication is essential to the completion of the project.
However, at the request of our mentor, our first priority for wireless
communication was to implement the desired protocol in the Mica2dot mote. If this
proved to be unfeasible, an alternative would be selected. One of the considerations
however that went into the development of the communication for the robot was whether
or not to implement a simple communication protocol using Java on the PC wired
directly to the robot. This would allow testing of the packet framework as well as give us
access to more complex simulation algorithms, which would require the processing
power of a PC.
The requirements of the communications system do however raise many issues
that have to be solved with the Mica2dot mote. The mobile sensor platforms need to be
capable of effective communication over short distances. This requires a robust interface
implementation that will resend any lost packets of information in order to insure that all
data is delivered without errors to every sensor platform. Secondly, the robots must be
able to remain connected and communicating throughout the duration of their life spans.
Connectivity cannot be lost to any of the robots while attempting to create a formation,
because the loss of a robot would require the formation to be altered. Lastly, there must
be a method to regulate communication interference so that two sensor platforms do not
attempt to send a Radio signal at the same time, thereby corrupting both transmissions.
2.2.1 PC Based Communication
This option was considered primarily because of its simplicity of design and the
incomparably low cost per unit. Implementing PC Based communication merely requires
a serial cable and some simple Java code.
The development of the code would not be
overly complex because of the libraries
included in the Java programming language.
However, because the PIC chip is
programmed in assembly, the interface
responding back to the PC would be more
Figure 2 – PC Based Communication
difficult to design, yet a serial
communication protocol would need to be implemented on the PIC whether or not PC
Based Communication was selected. The obvious benefits of implementing PC Based
Communication are ease of setup and testability.
However, use of PC based communication would greatly impact the effectiveness
of the project because the robots would need to be “tethered” to a computer and
dependant upon it for the exchange of information. This would cause many issues in
terms of movement with multiple robots and greatly decrease their effectiveness.
2.2.2 Mica2dot RF Communication
The Mica2dot motes are rather complex and sophisticated wireless modules.
They contain far more hardware then a simple wireless antenna. The Mica2dot motes use
an RF transceiver which has it’s own protocol which is used in all Mica2 products. The
protocol has support for implementation of many of the desired features such as ambient
monitoring to ensure that transmission does not begin from one mote until there is not a
mote currently transmitting. The Mica2dot device also has an Atmel ATMega
microcontroller soldered onto its circuit board. This allows the mote itself to be
programmed with code to handle different types of instructions, or possibly recode the
mote itself during runtime. However, all of the additional functionality makes the
objective of simply transmitting information a far more complicated task.
All wireless transmissions made by the Mica2dot are still accomplished by an RF
transceiver. The signal sent uses a 916 MHz transmission that has a range of
approximately 145 meters. All RF devices inherently have multi-cast, 360 degree,
transmission, allowing all Mica2dot motes within range to receive the same signals. This
simplifies transmission algorithms because it does not require message forwarding, yet at
the same time opens up more opportunities for wireless crosstalk to occur.
Figure 3 – Mica2Dot Mote
The Mica2dot motes are programmed in a specialized version of modular C code.
The code runs on a micro-operating system called TinyOS that uses task scheduling in
order to complete actions requested during runtime. As shown in Figure 3 – Mica2Dot
Mote above, the Mica2dot is approximately the size of a quarter, easily allowing its
integration onto the mobile sensor platform. The interface between the Mica2dot mote
and the PIC controller would be theoretically simple by the use of the UART (Universal
Asynchronous Receiver Transmitter), which is used for all serial communication with the
mote, including reprogramming. It also contains an array of analog and digital
Input/Output ports in case more are needed.
2.3 Electronics and Sensor Concept
The electronics on the robot consist of three main elements, a PIC to control the
sensor platform’s actions, a set of motor controller chips which will interface output from
the PIC to the motors themselves, and sensors which will be used to sense objects and
terrain around the sensor platform. There are two main types of range sensors that can be
used in this project, which are infrared sensors, and ultrasonic sensors. The robot will
need to utilize one of these types of sensors in order to determine the location to which it
must travel. In order to simplify algorithms on the robot as well as to give the formation
a group bearing, compass sensors were examined as well.
2.3.1 Infrared Sensors
Infrared sensors function by emitting a special wavelength of light invisible to the
human eye unaided, infrared, and then calculating the angle of return of the light. This
method uses simple trigonometry to determine the distance the sensor is from an object.
However, if the light is blocked or reflected away from the sensor, it will not be able to
detect the object. The method of measuring distance is shown below in Figure 4 –
Infrared Distance Measurement.
Figure 4 – Infrared Distance Measurement
The infrared sensor, which would fit the project most aptly, is the Sharp R144-
GP2Y0A02YK infrared sensor. It has a range of 20 cm to 150 cm, which should have
sufficient range for our purposes, but it was mainly chosen for the cost. The minimum
range of the sensor is incurred because the angle of return becomes too wide for the width
of the sensor, causing the emitted infrared beam to be unable to be sensed.
Figure 5 - Sharp Infrared Sensor
Each infrared sensor device would cost approximately $15, allowing multiple
such sensors to be placed on the robot. Most infrared sensors do not have a maximum
range as far as the R144-GP2Y0A02YK, unless they are significantly more expensive. If
the chassis of the robot is a mere 20 cm across the sensor will need to be capable of
sensing at least 150 cm in order to allow the mobile platforms to move freely.
2.3.2 Ultrasonic Sensors
A second option for sensor selection considered by the team was the ultrasonic
sensor, also known as a sonar sensor. Sonar sensors detect objects by emitting a very
high frequency sound wave, inaudible to the human ear. The sound wave will then travel
until it reflects off an object and back to the sensor itself. Recording the time the pulse of
sound took to return and multiplying it by the distance sound travels per second can then
measure the distance.
Figure 6 - Devantech SRF04
The sonar sensor selected by the project team is the Devantech R93-SRF04
Ranger. This sensor has a range of 3 to 300 cm, but costs nearly twice as much as the
infrared sensor. The minimum distance of the sonar sensor is incurred because there
must be a time delay between sending the sonar pulse and enabling the receiver.
The benefits of the sonar sensor are not to be taken lightly. The measurement
given by the sonar sensor is linear instead of a voltage curve as is the case for an infrared
sensor, making it much simpler to interpret. The minimum range is significantly smaller,
allowing closer objects to be sensed, as well as doubling the maximum sensing distance.
The only downfall of such an option is that there is generally more interference between
multiple sonar sensors operating at the same time. This occurrence is known as crosstalk.
2.3.3 Compass Sensor
The PIC controller on the mobile platform has limited processing power and
memory. In order to simplify the formation topology algorithms, as well as give the
robot more accuracy in movement direction, a compass sensor may be integrated onto the
circuit board. The compass sensor would also be able to give the group of robots a global
direction, allowing them all to face in the same heading and travel as a team.
A compass sensor works by having two magnetic field sensors, which are
sensitive enough to detect the Earth's magnetic field. Two of them mounted at right
angles to each other can be used to compute the direction of the horizontal component of
the Earth's magnetic field. The sensor can then return a value from 0 to 360 degrees in
Figure 7 - Devantech Compass
The majority of compass sensors are quite expensive; however the Devantech
R117-COMPASS chip should be accurate enough for our needs. The integration of a
compass sensor is not essential to the project, but it would add a significant degree of
robustness and simplicity to the project, making it well worth looking into.
2.3.4 Motor Controllers
In order to interface the PIC’s simple TTL output signals to the motors
themselves, they command signals must be sent through either a single motor controller
or a pair of motor controllers in order to send the proper command signals. There are
significant advantages to both of the aforementioned options. If a single motor controller
design is selected, a chip such as the MC3479 Motor controller driver can be used. This
controller is simple because each pulse sent to the controller translates into a single pulse
sent to the motor. Motor rotation is controlled by sending either logic one or zero to the
direction input pin to go forward or backward respectively. However, the motors require
a significant amount of current to move and if all of the current is passing through the
motor controller driver, it will overheat. The second option is to use two chips such as
the UC3770 High performance stepper motor drive circuit. This chip requires two
signals pulsing with the same amplitude, but differing phase. Depending on the relative
phase of the two signals, the motor will move either forwards or backwards. While this is
slightly more complex, these chips can handle significantly more maximum current,
which produces more torque in the motors, yet allows the current to be limited while the
robot is not moving.
Figure 8 - Motor Controller Driver
2.3.5 PIC Microcontroller
The PIC microcontroller selection was overwhelming at first. There are
thousands of versions of PIC microcontrollers and it is simple to waste time getting
caught up choosing the part. Previous CE design teams have used the PIC18F4320 by
Microchip and there are a significant number of them available for student use at RIT.
The PIC18F4320 has nearly 40 Input/Output ports and a very significant amount of
specialized functionality that can be implemented using control registers. It has an
internal clock that can be run at 8MHz, which should be more than ample speed for our
Figure 9 - PIC Microcontroller
Aside from being free, it is one of Microchip’s newer PIC versions and free
samples can be obtained for educational projects. Using a PIC instead of another
microcontroller is effective for the project because of the low power requirements and
2.4 Locomotion Concept
In order to make the robot move effectively, an efficient method for locomotion
was desired. The rest of the chassis can be designed around the chosen method, since
mobility is so important to the project. The first step in choosing a method was to
brainstorm. The chassis frame needs to be able to support all of the equipment, sensors,
controllers, etc., while being stable and agile. It needs to be able to move both forwards
and backwards as well as turn either counter clockwise or clockwise. The precision of
the platform’s movement is also of major importance. This is because measuring motor
rotations will be the majority of the calculations for how far the robot has moved. An
analysis of some of our options is shown in the table below.
Treads Eight Wheels Four Wheels Two Wheels Legs
Skills available? Yes Yes Yes Yes No
Implementation Yes Yes Yes Yes No
Will it meet Yes Yes Yes Yes Yes
Equipment Yes Yes Yes Yes Yes
Will the robot No No Yes Yes No
Is the cost Yes No Yes Yes No
Is this method an No No Yes Yes No
The first option, treads, was discarded because of the power requirements for
overcoming the friction would be difficult to achieve with the rechargeable batteries
available to the team, making the robot slow and less agile then desired.
The second option, more than four wheels, was discarded because it is cost
prohibitive as well as inefficient to have so many motors running at the same time. Once
again battery power is limited and the friction incurred by all of the motors attempting to
move at the same time would cause a serious loss of mobility.
The last option, legs, was discarded because of the complexity involved. There
are pre-built chassis available which implement the use of legs to move a robot, however
they are costly and require a decent amount of controller power to implement. In order to
save on complexity and design simplicity, this option was not feasible.
2.4.1 Chassis Concept
A major consideration in the chassis design is the weight of the mobile platform.
The lighter the platform is, the less energy it will require to move, and the more agile it
will be. In order to reduce the weight to a minimum, a very compact chassis must be
The largest component to be integrated into the mobile sensor platform will most
likely be the circuit board. After a preliminary design has been proved to be efficient, a
printed circuit board can be made which will allow multiple robots to be fabricated easily
and correctly without a lot of painstaking soldering. Generally, the minimum size for
cheaply made printed circuit boards is around two and a half inches by four inches. In
order to accommodate any orientation of a printed circuit board, the chassis will need to
be a minimum of four inches in both horizontal directions. Using this as a guide, the
chassis will only be expanded in order to accommodate components previously un-
From our research, we focused on four different drive systems. One of these
included the original four-wheel drive system. This was included as a means of
comparing the other options available. As a result, we were able to make a wise decision
on the best locomotion system for our design.
220.127.116.11 Differential Drive
The differential drive system is very simple; often the drive wheel is directly
connected to the motor (usually a gear motor--a motor with internal gear reduction--
because most motors do not have enough torque to drive a wheel directly).
Unfortunately, it can be difficult to make a differential drive robot move in a straight
line. Since the drive wheels are independent, if they are not turning at exactly the same
rate the robot will veer to one side. Also, the non-driven wheel or castor wheels can
cause problems if the robot reverses its direction. This may result in a translational
Figure 10 - Differential Drive
18.104.22.168 Synchro Drive
The synchro drive system is a two motor, three/four wheeled drive configuration
where one motor rotates all wheels to produce motion and the other motor turns all
wheels to change direction:
Separate motors for translation and rotation make control much easier. Straight-
line motion is guaranteed mechanically--there is no need for interrupt-based control as in
the case of the differential drive method, but the mechanism that permits all wheels to be
driven by one motor and turned by another motor is fairly complex. Also, wheel
alignment is critical.
22.214.171.124 Car Type Drive
Car-type locomotion is very common in the "real world," but not as common in
the "robot world." A pair of driving wheels and a separate pair of steering wheels
characterizes car-type locomotion. It is one of the simplest locomotion systems to
implement with one caveat: the turning mechanism must be precisely controlled, but
planning is difficult because the system is non-holonomic.
126.96.36.199 Skid Steer Drive
Skid-steer locomotion is commonly used on tracked vehicles such as tanks and
bulldozers, but is also used on some four- and six-wheeled vehicles.
It is closely related to the differential drive system, replacing the caster wheel
with extra drive wheels. It has the same disadvantage: moving in a straight line requires
the wheels on each side to be turning at the same speed, which can be difficult to
achieve. The advantage of skid-steer is increased traction and no "caster wheel effect".
2.4.2 Four Wheels
Four wheels will allow the team to design a very stable platform that will be able
to support and move a significant amount of weight. This design is rather common on
robots and has proven to be successful. The only immediately obvious point against a
four motor design is that it would require more power to move than a design with only
2.4.3 Two Wheels
While two wheels alone would not allow for a stable chassis, a pivot point can be
added in order to help stabilize the robot and keep it from tipping or tilting. Selection of
a proper pivot will be discussed shortly. The major advantages of a two wheel design are
the small amount of power required to turn only two motors, as well as the fact that the
wheels would never be straining against one another when the robot needs to pivot. In
terms of rotating the robot smoothly, the two-wheel design has a significant advantage.
188.8.131.52 Castor Pivot
Castor pivots are common in everyday life, as most conventional tools use them
(projectors, shopping carts, etc…). A castor pivot is very simple and easily purchased at
many stores. However, they have one major disadvantage. When a castor needs to
change direction, they often do not do so smoothly. There is a certain amount of force
that is needed to rotate the caster so that the wheel if facing in the proper direction before
it can spin smoothly. This could become a major problem since the robot is constantly
using the number of rotations of the motor as a method to measure distance.
Figure 11 - Castor Pivot
184.108.40.206 Ball Bearing Pivot
A ball bearing pivot would be slightly more difficult to obtain, yet it would
remove the concerns of not moving smoothly upon direction changes. Ball bearings are
generally heavier and slightly more difficult to work with, yet have is a significant
Figure 12 - Ball Bearing
A rather significant issue, which has been mostly glossed over so far, is the
decision on what type of motor should be installed on the chassis. There are two major
categories for motors that must be examined. These are continuous DC motors, and
DC motors are more common and easily available. They are generally more
powerful, easier to interface to, and allow the robot to move faster. However, despite
these advantages, they also have a serious disadvantage. They have no method for exact
control of the distance to travel. They simply turn on and drive and slowly turn off. This
is a problem for our project because the robot needs to have a method by which it can
drive a specified distance and stop to survey its surroundings. It would be possible to
implement our own control device to determine the number of rotations of the wheel by
having a laser get interrupted each time the wheel has rotated. However, this
measurement is not very precise and therefore the DC motor must be examined critically
in order to interface it properly with the rest of the mobile platform and achieve the
Figure 13 - DC Stepper Motor
Stepper motors function by sending pulses of power to the motor rather then a
constant signal. Each pulse of power corresponds to a single step of the motor, thereby
giving the controller a direct way to measure the distance traveled. These motors
however also require a much larger amount of current to maintain accuracy. This is
because each motor has a large magnet that controls the stepping and must be energized
at all times, even if the robot is not moving.
3.0 Feasibility Assessment
In order to remain constant in the overview of the project, the feasibility
assessment will be broken down into the same three main categories as the concept
development. These categories are Chassis Design, Electronics & Sensors, and
Communications. At the end of each section are the initial part selections as well as the
cost associated with each part.
3.1 Communication System Feasibility
The main concern with the implementation of the communication system is ease
of implementation. If the mobile sensor platforms can communicate with outside objects,
it becomes much simpler to test and debug the platform. If either the wireless
communication or the PC based communication is successful, information can be easily
sent to the PC via the wireless mote programmer or the direct link. With this option
added, much more powerful tools are available to overcome obstacles on the project.
3.1.1 PC Based Communication
PC based communication is rather simple to implement in an object oriented
programming language such as java. Java contains many packages and libraries, which
can handle much of the inbound and outbound communication, allowing a useful
interface to be designed without the need to delve into different protocols on the PC. The
team contains three computer engineers who are all proficient in the Java programming
language, and implementing an interface should not be overly time consuming and
should not incur any additional expenses to the project. However, the robots must be
autonomous by the end of senior design II, so if PC based communication is to be
developed it must be able to be directly ported into an interface into a wireless controller.
Otherwise, the time spent on developing a communication interface will be mostly
wasted, as the interface will have to be rebuilt before the end of the project.
3.1.2 Mica2dot RF Transceiver
The integration of the Mica2dot RF Transceiver adds a significant amount of
functionality to the system. The wireless communication no longer becomes overhead,
but instead gives the system increased processing power. This is because the Mica2dot
mote has a built in microcontroller of its own. This means that the interface between the
main PIC microcontroller and the wireless interface can be simplified because once data
is transmitted to the Mica2dot mote the data can be processed, packaged, and then sent
intelligently in order to avoid data collisions.
The Mica2dot mote also has some basic power saving features that allow the
motes, which are battery operated, to have a longer lifespan and reduce network drain.
The API available for programming the Mica2dot motes allows for efficient network
regulation, and effective transmission. The motes are programmed using a modular
version of C, which should be familiar to most of the programmers in the group. In terms
of effectiveness and ease of use, the Mica2dot motes should be excellent. The only
drawback of the mote is the price tag, which comes to nearly $135. However, as our
mentor requested this method of communication, this price should not be weighed to
3.1.3 Communication System Conclusions
Although it would be very beneficial to implement basic PC communication
quickly, after a review by the team, it has been decided to work on directly implementing
the wireless communication first. There are two main reasons for this decision. First,
manpower is limited and much of the work that would go into developing PC based
communication would be nearly worthless by the end of the project. Secondly, the
wireless motes use a modular version of C, which would be very difficult to interface
with a Java program written in for PC based communication. In this aspect, very little
would be learned about the necessary interface for the mobile platform during a Java
Implementing the Mica2dot is therefore one of the main focuses for the team as a
whole. The integrated microcontroller and development API should allow for easy
integration with the other microcontrollers present on the mobile sensor platform. Easy
integration will allow the team to concentrate more on the development of the platform
itself and less on the background tasks of developing a communication interface.
Component Price Quantity
Mica2dot Mote $135.00 1 Per Platform + 1 Base Station
Mica PC Interface Board - MIB510CA $95.00 1 For Programming Motes
3.2 Electronics and Sensor Feasibility
The effectiveness of the sensor package integrated onto the mobile platform is of
primary concern. However, there are significant physical limitations on size and weight
of the robot as well as power consumption, cost, and measurement accuracy. All of these
considerations together limit the selection of the sensors.
3.2.1 Infrared Sensors
Infrared sensors are characteristically used for object avoidance. This is because
the sensors are very cost effective and require very little power to sense whether there is
an object in its path. However, because of the nonlinear output it is difficult at best to
determine the exact distance to an object, thereby making IR sensors only useful to
determine if there is an object present. IR sensor require more calculations in order to
process the information received, as well as a more difficult implementation code to
successfully integrate the sensor onto the circuit board.
3.2.2 Ultrasonic Sensors
Ultrasonic sensors are characteristically used for more exact distance
measurement. They are easily implemental because the measurement returned is the
amount of time taken for the sonar wave to be sent and return to the sensor. This
measurement is linear and since the speed of sound through air is known, the exact
distance can be calculated if the microcontroller can acknowledge the return of the signal
fast enough. Most microcontrollers can be run at approximately 8 MHz that is more than
enough when converting the time delay into centimeters traveled.
Figure 14 - Sonar Beam Pattern
Unfortunately sonar sensors require more power, are more expensive, and sense
objects at a larger angle then an IR sensor. The increased field of view can be both a
benefit and a hindrance. As shown in the figure above, the Sonar Sensor can see in
approximately a 45-degree arc with the majority of the focus within 15 degrees of
directly ahead. This means that while there is the possibility that the sonar will detect
objects slightly to the side, the majority of the time, the sonar will only sense what is
directly in front of it.
In a direct comparison between an IR sensor and an Ultrasonic sensor, a few main
points become apparent. The IR sensor is cheaper and more power efficient, while the
Ultrasonic sensor is easier to interface to a microcontroller and more accurate in terms of
3.2.3 Compass Sensor
A compass sensor is functionally desirable because it would add a global direction
to the group of mobile sensor platforms. In order to achieve the maximum benefit out of
the compass, it needs to be calibrated to its current latitude. Once the compass sensor has
been calibrated, it will achieve a resolution of 0.1 degrees accurately.
There are two significant drawbacks to adding a compass sensor. It adds complexity near
the beginning of the integration process and is priced at around $50. The compass sensor
would have to be integrated onto the circuit board and connected with the main
microcontroller. Both of these tasks would require a significant amount of manpower
because of debugging issues. However, it would simplify algorithms that would need to
be developed during senior design II.
3.2.4 Motor Controllers
Using a single motor controller, the MC3479, would be a very efficient method
for controlling the mobile sensor platforms. There is a direct relationship of one
controller for each motor, it can draw a maximum of 400mA of power, and it would be
simple to code an interface into the main microcontroller to utilize the motors themselves.
The MC3479 is also cheaper then the alternative and would require less time to integrate.
However, there is one significant drawback to its use. This problem is that 400mA of
current would be very near the minimum possible current to rotate the motors accurately.
This is a significant problem because if the motors are underpowered and sometimes do
not rotate properly because of friction, measurements will be off and the robot will
become significantly less effective.
Using two UC3770 high performance stepper motor drive circuits is less efficient,
but it would undoubtedly increase the functionality of the robot. The UC3370 will allow
approximately one amp of current through each chip at a time, allowing for significantly
more power to the motors at any given time. This causes a significantly larger drain on
the battery. However, it also has built in current limiters that can allow the
microcontroller to reduce the current from 100% to 20% in 20% intervals. This would
allow the project team to put a huge amount of current through the motors while
movement is desired, yet severely limit the amount of current through the motors during
periods where the robot is stationary. It is believed that this method of control would
allow longer battery life overall while giving the motors greater power during times of
The drawback of using these controllers would be the difficulty of integration.
The addition of two UC3770 controllers per motor adds a significant degree of
complexity to the mobile sensor platform’s electronics as well as utilizing more
Input/Output ports on the microcontroller. The increase in complexity for coding the
microcontroller is not overly significant, but it should not be ignored in any case.
3.2.5 Electronics and Sensor Conclusion
In order for the mobile sensor platform to move, sense, and interpret its
surrounding environment accurately and efficiently, the following selections were made.
- Distance sensing will be done using ultrasonic sensors, namely the Devantech
SRF04 Ranger. This will give the robot the accuracy and precision necessary
to locate objects and move to a precise location without significant algorithms
needed to understand the reading given by an IR sensor.
- A Compass sensor will be integrated onto the chassis as well. While this will
add significant complexity to the earlier stages of the project, it will allow for
a far more robust and simplified final design. The team believes that this
addition will be a benefit rather than a hindrance.
- The UC3770 high performance stepper motor drive circuit chips will control
the motors. While this method also increases the complexity of the project it
allows for more advanced control of the motors themselves increasing the
effectiveness of the electrical design.
- The PIC 18f4320 will be integrated as the main microcontroller. This chip is
readily available to the project team, is cost effective, and more than sufficient
for any requirements that are foreseeable in the near future.
The overall pricing for the electrical components analyzed in this section is
summarized in the table below.
Component Price Quantity
Devantech SRF04 Ranger $36.00 2 Per Platform
R117-COMPASS $51.00 1 Per Platform
UC3770 Motor Controller $5.56 2 Per Motor
PIC18F4320 $8.17 1 Per Platform
3.3 Locomotion Feasibility
There are two main concerns in the area of chassis feasibility. These concerns
focus mainly on the topic of a pre-built platform. The two questions that need answers
Should a pre-built platform be used, and if so which one?
If the team constructs its own design what will be the method of locomotion?
Since the project team includes two mechanical engineers, building an entirely
new chassis should not be that difficult with the plethora of models available as well as
the machine shops on campus. Materials should also not be overly difficult to obtain as
RIT has a supply of commonly used materials.
3.3.1 Pre-built Chassis
The advantage of getting a pre-built chassis is rather enormous as long as the
design specifications of the project are within the operating specifications of the chassis
purchased. This is rather simple, but massively important. The concept behind this fact
is simple. A pre-built chassis is designed to be cost effective to produce whatever results
it is designed for. It must be cost effective; otherwise a similar, cheaper robot that
produces the same results will outsell it and remove the more costly robot from the
market. To this effect, pre-made robots have limited functionality.
The group looked at a significant number of pre-built robots that were designed
for a variety of purposes, playing soccer, maze walking, robot to robot combat, and more.
The initial response was that a pre-built chassis is a great idea. The chassis is solidly
constructed, looks good, and has a significant amount of functionality built into the robot
itself. However, upon closer examination, some of these advantages became
disadvantages. All of the designs had at least one of the following flaws, which rendered
- Limited Input and Output on the available microcontroller, cannot add sensors
- The motors cannot measure the distance traveled
- The motors cannot travel a precise distance based upon commands
- The microcontroller does not have enough processing power to handle the
tasks to which it will be assigned
- The built in functionality is too complex to modify and therefore is rendered
Figure 15 - Pre-Built Robots
For these reasons, too much functionality would have to be removed from a pre-
built chassis in order to add on components that would allow us to meet the specifications
that the project requires. This would be a waste of both time and money. In order for the
group to be more efficient however, some of the chassis designs were noted and the
group used these as a model to select how the project’s chassis design would develop.
3.3.2 Custom Built Chassis
Designing our own chassis for the mobile sensor platform is a significant task to
undertake, however, the group contains two mechanical engineers who felt they could
complete the task without too much difficulty. Their confidence allowed the team to rest
assured that project would progress with a robust, malleable chassis that could be
upgraded to suit the needs of the project, instead of modifying the project around a
chassis which it would be unwise to alter.
After examining the concepts for locomotion, two important options arose for
locomotion. The sensor platform would use the 39BYG Motors available to us from the
projects lab, with either two or four motors attached to each chassis. After examining the
strength of the motors during an early test, the group decided that two motors should be
sufficient to provide motion to the chassis. Since two motors were proven to be effective
with approximately 3 pounds of additional cargo weight, there was no need to upgrade
the chassis to utilize four motors. Four motors have the following disadvantages:
- Requires more complex code on the PIC to control the direction and speed
- Requires more Input/Output pins on the PIC to talk to the motors
- Requires more power, reducing battery life of the platform
- Increases the friction encountered when turning the robot
These four disadvantages swayed the opinion significantly allowing the project
team to proceed, designing the mobile platform to handle two motors instead of the
possible four. A two-wheel design also had a benefit that was unexpected; it allowed
rotation about the central point of the robot to be made more easily. This allowed the
code for the robot to be written in such a way as to internally model the robot as a circle
whose diameter was the width of the platform.
As a means of making the platform light and cheap, the team decided to utilize
Acrylite FF sheets. Acrylite is a lightweight (1/2 the weight of glass & 43% the weight
of aluminum), rigid, and weather-resistant thermoplastic. It is also, dimensionally stable
and resistant to breakage, and can be easily sawed, machined, heat-formed and cemented.
It was also decided that the sensor platform would have multiple levels upon
which different components would be attached. The bottom level would hold the battery
and ball bearing pivots, the mid-level would hold the sensors, and the upper level would
contain the electronics giving easy access for modifications.
Initially, the team performed a preliminary analysis on the motors, before actually
making the model, based on specifications found on the Internet. From this analysis, we
came up with a weight range for which the motors should be able to tolerate. This helped
in seeing the feasible size and weight of the overall robot design. Also, from empirical
studies, it was recommended that we needed at least 8 ounce-inches (576 gm-cm) of the
motor’s dynamic torque per pound of robot. This would provide minimum movement.
This also yielded a required minimum of 0.02825 N∙m/lb per motor. Using the minimum
holding torque value rated on the motor specifications, we calculated that our dynamic
torque was approximately 0.0325 N∙m/lb per motor. Therefore, we estimated that each
motor was strong enough to move at least one and a quarter pounds of robot mass, and
therefore our model should be designed to weight no more than 2.5 lbs.
3.3.3 Locomotion Conclusion
In order for the mobile sensor platform to meet all of the desired requirements
without introducing unneeded overhead, the project team decided to design and build a
chassis instead of buying a pre-fabricated one. In order to save on power consumption
and processing power, the platform will be designed with two wheels using a ball bearing
as pivot points. The overall pricing for the components analyzed in this section is
Component Price Quantity
Tires $5.99 2 Per Platform
Stepper Motors $6.49 2 Per Platform
9.6V Rechargeable Battery $8.99 1 Per Platform + Backup
Battery Charger $26.99 1 For The Project
Acrylite FF sheets $9.99 1 Per Platform
Ball Bearings $9.99 1 Per Platform
3.4 Feasibility Conclusion
Upon completion of the feasibility analysis of the three major components, many
concepts had been evaluated and discarded for their complexity or inefficiency. The final
selection of concepts requires more work on the part of the project team, but should allow
the design of a far more robust and upgradeable final product.
The cost for the initial prototype will be significantly more than the cost
associated with the mass-produced sensor platforms because of the need from
programming tools, battery chargers, and components broken during the testing phase. A
summary of the costs incurred by the project is shown below.
Aspect Initial Cost Additional Unit Cost
Communications $365.00 $135.00
Electronics & Sensors $142.29 $142.29
Locomotion $89.91 $43.94
Totals $597.20 $321.23
4.0 Performance Specifications
In order to efficiently build a chassis, design must first take place. The
performance of the system as a whole can be broken down into three major categories:
Mechanical Design, Electrical Design, and Software Design.
The group was charged with the task of constructing of a prototype mobile sensor
platform by the end of Senior Design I. This prototype must be completely functional;
however, it is not necessarily the final version of the platform. It must be able to move
independently and smoothly, utilize its sensors, and communicate using wireless
4.1 Mechanical Design Objectives
Although the design will not necessarily be complete the prototype must meet the
- Independence – The platform must be able to support and carry all of the
equipment needed to achieve functionality
- Platform Size – In order to achieve minimum weight, the platform must be as
small as possible.
- Weight - The weight of the platform with all components attached must be as
light as possible.
- Speed – The platform must be able to move quickly to any position on a flat
- Mobility – The platform must turn smoothly around it’s center without
- Ease of Assembly – The platform must be easily assembled in a
straightforward and concise manner.
4.2 Electrical Design Objectives
Although the design will not necessarily be complete the prototype must meet the
- Idle Power Consumption – Components that are not actively in use should be
shut off in order to minimize the amount of wasted power on the robot.
Proper power management should be implemented to insure reduced power
consumption for communication and waiting for messages.
- Platform Uptime – Battery lifetime should exceed at a bare minimum the
amount of time to perform the selected topology and show functionality
- Heat Regulation – Heat generation during runtime should be kept to a
minimum so that components will not be damaged by allowing the platform to
work under heavy stress continuously.
- Jitter Toleration – All electrical signals should have a noise margin that allows
for error in transmission caused by environmental interference.
4.3 Software Design Objectives
In any software system, especially an embedded system, program size or memory
constraints play a major role in the design of the system. This is because for embedded
system, there is usually very limited space available for the programmer to use. This
constraint is even more severe because on embedded systems, the program is usually not
as easy to debug or upgrade, forcing the programmer to be more robust and thorough in
design and implementation.
The microcontroller selected, the PIC18F4320, controls all major functionality of
the mobile platform, aside from communication. It has 8 kilobytes of memory storage,
while the Mica2dot contains 128 kilobytes of memory storage. While the Mica2dot
contains much more code space, it is also a much more complicated device which has a
custom-built operating system installed, called TinyOS. TinyOS controls most of the low
level functionality of the wireless mote, allowing programmers to develop event driven
code that reacts to incoming messages.
Since the code is written to the PIC chip, it must be removed and reprogrammed
for any code changes to take effect. In order for the mobile platform to function in
differing environments, without constant reprogramming, the code must be robust enough
to allow the system to be capable of dealing with unforeseen obstacles and interference,
whether electrical or physical.
The final code design must meet the following objectives.
- Movement Control – The platform must be able to move effectively to any
desired location either visible or relayed based upon the platform’s current
position. This included turning accurately to varying angles and traveling
- Communication Control – The platform must be able to communicate
effectively with other platforms in order to send information on its current and
future status. This information is critical to allowing the platform to work as a
coherent team. In this manner, all messages sent should be received and
acknowledgements of receipt or lack of receipt must be sent to ensure all data
arrives at the appropriate destinations.
- Sensor Control – The platform must be able to effectively use all of its sensors
to examine and navigate through unknown terrain without collisions that
could be damaging.
- Topology Control – The platform must be able to differentiate between
commands relating to different formation topologies and interact appropriately
with the other platforms to carry out the mission of the selected topology.
- Timing Control – The platform must be able to delay for periods of time in
order for it to be able to wait for user commands or delay so that
communications do not overlap one another.
4.4 Mechanical Performance Specifications
In order to achieve the mechanical design objectives, certain specifications must
- Overall Platform Size: The final dimensions of the platform cannot exceed the
dimensions 8” x 8” x 8”.
- Overall Platform Weight: The final weight of the platform cannot exceed five
- Assembly: The final platform will be constructed with removable fasteners to
allow for disassembly.
4.5 Electrical Performance Specifications
Any electrical component attached to the platform has voltage and current
requirements associated with it, which must be observed in order for the final product to
function properly. A listing of these specifications is as follows:
- System Power: One 9.6 volt 1600 mAhr battery will power the entire
- Motor: 2 Motors with maximum 12-volt inputs with a maximum operational
current of 2 Amps.
- Motor Controllers: 4 controller chips with maximum input of 5 volts at 1
- PIC Microcontroller: One PIC with a maximum input of 5 volts and 15 mA
- Mica2dot Mote: 1 communication processor drawing 50 mA peak at 3 volts
- Ultrasonic Sensors: 2 sonar sensors drawing 50 mA peak at 5 volts
- Compass Sensor: 1 compass sensor drawing 20 mA peak at 5 volts
Using an effective power management scheme it is expected that battery lifetime
will exceed 30 minutes.
4.6 Software Performance Specifications
In order to achieve the software objectives, the following specifications must be
obtained in the final product.
- Software Coding: All coding on the PIC will be done with assembly and
verified on a regular basis. All coding for the Mica2dot mote will be done in
modular C and follow the coding standards for TinyOS.
- System Testing: The system will be designed in a modular fashion allowing
testing of individual components as well as the system as a whole.
- System Robustness: The system will be able to handle minor errors which are
expected to possibly occur during runtime.
4.7 Design Practices Used
The team discussed a number of design practices to implement during the course
of the senior project. The practices selected are:
- Design for Systems Integration: All components were purchased well ahead of
schedule in order to allow for ample time to examine the interface before
integration. All components that were selected for the project were examined
for compatibility before being purchased.
- Design for Manufacturability: All manufacturability components on the
chassis were expected to be designed and fabricated on equipment found on
the RIT campus.
- Design for Recovery: The completed platform allows for disassembly of the
components to allow for minor upgrades or replacement in the situation of a
- Design for Low Cost: All components were selected for both their
functionality and their cost efficiency.
- Design for Efficiency: Since the system is largely embedded, resources are
very limited on the platform. Therefore, all components need to work
efficiently without waste to ensure proper robot lifetime.
4.8 Safety Issues
There are no set safety standards for this project as it is an experiment being
conducted by in institute rather than an industrial process. However, there are some
safety issues that were dealt with.
- The team must be careful in handling the robot at all times during the
prototyping stage. The design will not be solidly constructed until it has been
determined that the design is acceptable.
- All team members using machine shops will follow all safety guidelines
during fabrication of any parts.
5.0 Analysis of Problem and Synthesis of Design
The initial problem the project team as a whole was faced with was the design and
implementation of a single prototype platform. The platform must be fully functional,
easily reproducible, and have the proper resources available to implement the more
complex group functionalities desired for the second half of the Senior Design process.
In order to organize the amount of information necessary for analysis of the
project, it has been broken down into two major categories, Hardware and Software. The
hardware aspect of the design focuses mainly on the chassis design and electrical layout
and functionality. The chassis design is chronicled in the Mechanical Design section
while the electrical layout is in the Electrical Design section. The Software aspect of the
platform will examine the code used for sensing, movement, and communication while
briefly examining plans to implement topology formation, which will not be possible
until multiple platforms have been built.
The hardware design encompasses both the physical chassis construction as well
as the electrical layout of components on the circuit board. These two issues will be
discussed in detail in the following sections.
5.1.1 Mechanical Design
Aside from size and overall weight, motor performance played an essential role in
our mechanical design concept. Because we were working with motors that were
formerly available, a lot of the design was catered to how well they would work with
added weight. It was not until after we performed a pilot test of the chassis’ payload
versus the motor performance that we were able to design a fully functional and attractive
5.1.1 .1 Initial Prototype Designs
For our initial prototype we set out to build a compact chassis in order to
minimize the amount of material used. This not only helped us to decrease the overall
weight, but also provided us with a more durable and sturdy robot. Due to the flexible
nature of our material, decreasing the overall dimensions enabled us to overcome any
significant deflections. Because of our desire to use a two-wheel design, there was also
the issue of stabilizing the robot in order to keep it balanced. Our size constraints limited
us to using screws that were inserted into the bottom of the base plate at the front and
back of the robot, and made level with the wheels. This was advantageous as it kept the
weight to a minimum and made the fabrication process easier. However, the screws
caused an increase in friction, which was a concern. The increased friction had a
negative effect on the robots ability to turn accurately, as the screws are only suitable for
very smooth surfaces.
In order to account for this problem our second prototype design included the use
of two castor ball bearings in place of the screws, which encounter only rolling friction
regardless of the robots direction of movement. This enabled us to turn more accurately,
but required us to increase the dimensions to account for the larger castor ball. While the
ball bearings increased the overall weight of the robot, this additional weight was not
significant enough to cause concerns of exceeding our weight limit.
The prototype designs that were discarded are displayed below.
Figure 16 - Initial Prototype for Weight Testing
This prototype was too heavy and did not rotate around the center of mass.
Figure 17 - Second Prototype
This prototype was far more effective, however it did not have sufficient space to
mount all of the necessary sensors in locations where the sonar would have object to
reflect off of.
5.1.1 .2 Current Prototype Design
Figure 18 - Current Prototype Chassis
This design has proved to be the most economical and space efficient model to
date and is currently working effectively.
5.1.1 .3 Final Design Plans
For our final design we intend to continue investing ways to optimize our
prototype design. This includes locating and incorporating a new type of castor ball
bearing that is more suitable for our current robot. The new castor should be smaller and
lighter, providing more leeway on desired dimensions and weight restrictions. The castor
should also be more suitable for mounting purposes and improved aesthetics is
Final design plans also include determining the best option for mounting a
compass chip. Since the magnets in the stepper motors can interfere with the readings
from the compass, its location is critical. Currently, our options include developing a
mast that would hold the compass an appropriate height above the motors. Another and
more appealing option is to develop a shielding device using magnetic steel sheet metal.
This would allow us to place the compass on or near the circuit board.
5.1.2 Electrical Design
A single 9.6 volt 1600 mAhr rechargeable battery will power the electrical
system. This allows the entire platform to get power without having to worry about if
separate components are low on power. The PIC microcontroller is essentially the heart
of the mobile platform, as it connects to and controls the functionality of all of the
electrical components. A simple block diagram of the system layout is shown below.
2 Motor Controllers Motor
9.6 Volt UC3770
2 Motor Controllers Motor
Rear Sonar Microcontroller Front Sonar
Sensor PIC18F4320 Sensor
Compass Mica2dot Communication
Figure 19 - System Block Diagram
220.127.116.11 Performance Testing
In order to understand the strengths and limitations of the selected components,
performance testing is a primary concern for early development. Upon receipt of the
motors, motor controllers, ultrasonic sensors, compass sensor, and Mica2dot motes each
component was examined to see if it met the project requirements as its documentation
The power consumption was also examined for each component to help regulate
the amount of power drained from the battery during periods of use.
18.104.22.168 Sensor Performance
The sonar sensors selected, the SRF04 Ranger from Devantech, was surprisingly
accurate during our testing. The sonar sensor functions by sending out a sonar pulse,
enabling a receiver, and waiting for the signal to be returned. The distance is measured
by tracking the time spent between enabling the receiver and waiting for the signal to be
returned. The distance can then be directly measured by multiplying by the speed of
sound (343 m/s in air).
This measurement is very straightforward and simple, allowing the accuracy of
measurement to be very high. In order to establish that the sonar sensor was indeed as
accurate as expected, a test was done to measure the amount of time passed for the sonar
to discover an object at a selected distance. The graph of the results is shown below.
Time Between Pulses (microseconds)
3000.0 Measured (us)
0 50 100 150 200 250 300 350
Distance to Object (cenimeters)
Figure 20 - Sonar Sensor Measurement Test
The sonar was actually more accurate than expected. However, this degree of
accuracy may not translate directly into increased performance. The number of
mathematical instructions available to use on a PIC chip is very limited (add, subtract,
and multiply), and there is no decimal precision. This means that the accuracy of the
mobile platform is now limited by the program written on it and no longer by the distance
sensor itself (under good conditions) because there will be more error during the
conversion to centimeters in the code then there will be by the sensor.
Examining the accuracy of the compass sensor was far more complicated then the
sonar sensor. The only known method for the group of evaluating the accuracy was by
eye. A normal magnetic compass was brought and compared to the digital heading
reading given by the magnetic sensor. The values appeared to correspond exactly and if
the documentation is believed, the sensors will be accurate to within 1/10th of a degree.
Unfortunately, more in depth testing will have to wait until a second platform can be
constructed and directed to travel at a certain heading. The variance between the two
platform’s final locations will allow the project team to estimate the amount of error
present on the compass sensors themselves.
22.214.171.124 Motor Performance
The motors and their controllers are of critical importance to the mission of the
mobile sensor platforms. In order for the project team to get an idea of the weight
distribution requirements, an early test was done to determine the maximum amount of
weight available to distribute atop the chassis. This would give us some critical design
parameters even though increased performance could be obtained by enhancing the
This test was carried out before many critical parameters of the system had been
fully specified, so a minimalist chassis was developed upon which weights could be
added in 200-gram increments. The initial motor controllers tested were the MC3479
motor controllers that were easily available on campus. While these controllers did not
have the power requirements of the UC3770 controllers, they would be able to provide a
basis for the test. Two motors were then attached to the chassis and electrical signal
generators were attached to the motor controller leads in order to give the proper signals
in order to move the motors.
The chassis was then tested for accuracy of movement by switching on the signal
generators and examining the path of travel by the platform. The platform was also
tested for turning accuracy in the same method. The results of the test revealed some
First, the platform could handle approximately an additional three pounds of
weight beyond the current chassis and battery pack. This was a significantly larger
amount of leeway then the project team expected because faculty had questioned the
performance of the motors.
The second piece of surprising information was that the robot was significantly
more adept at rotating in place with a large load then it was at directional travel. This
came as a surprise because teams with similar projects have had difficulties on obtaining
smooth rotation for their platforms.
The results of this test allowed early weight limits to be set, as well as testing the
basic concept of a two motor design. It was very successful in building confidence in the
team of the functionality of our ideas and methods.
126.96.36.199 Power Management
The battery chosen to power the mobile sensor platform is a 1600 mAhr
rechargeable NiMh battery. The terminal voltage of the battery is specified as 9.6 volts,
however, after being fully charged, the voltage is actually larger. The voltage has been
measured as high as 10.4 volts, but is generally around 10.2 or 10.3 volts. In order to
conserve power, since battery life is limited, a couple basic power saving strategies will
be implemented on the platform.
The first and most important power management strategy will be implemented on
the motors themselves through the motor controllers. The motor’s power requirements
are vastly larger than all of the other platform’s components combined. Since the power
regulation of the motors is so critical, a motor controller was found that could regulate the
amount of current sent to the motors in real time. The chip would then need to be
controlled by the PIC, which would have to determine the desired actions of the platform.
With this increased functionality added into the controllers, the PIC can now move the
motors to full power during periods of movement, and return the motors to a low current
state during periods of inactivity.
Stepper motors are unique because the motor requires, if unregulated, the same
amount of current for movement as for inactivity. This is because the current that is
required is used to lock a built in magnet that will only allow the wheel to move a small
degree each time a pulse is applied to the motor controller. In order to maintain accuracy
during runtime, the current to the motor cannot be completely shut off because the wheels
would unlock and the robot’s position may change.
The second power management strategy that will be employed will be used to
turn the sensors on and off when fresh sensor readings are not of importance. The sonar
sensor will continue to draw small amounts of current in order to be able to recognize
when it is supposed to send its initial sonar pulse, and the compass sensor will continue to
take readings as long as it has power. Therefore, moderate power savings can be gained
by employing a basic power switching circuit for both sensors that will remove power to
the components when there is no need for sensor readings.
The Mica2dot currently has its own power supply, a 3.3-volt battery, with an
expected lifetime of 7 years with the power management strategies employed by its
operating system, TinyOS. Therefore, no power management strategies were needed for
the communication aspect of the design.
188.8.131.52 Electrical System Schematics
After examining the datasheets for the various components, the following
schematics have been designed and implemented on the mobile platform.
Figure 21 - 5-Volt Regulator
The 5 Volt regulator was implemented in order to provide the proper voltage to
power the PIC18F4320 as well as the Ultrasonic and Compass sensors.
Figure 22 - MC3479 Motor Controller Implementation
The MC3479 was readily available to the project team and as such it was used in
some early experimentation with the PIC and the Stepper motors. After examining the
functionalities of the MC3479 controller a more suitable controller was selected for use
in the final version of the project.
Figure 23 - Close-up of Single UC3770 Motor Controller Implementation
Figure 24 - Complete UC3770 Motor Controller Interface Implementation
The UC3770 schematic is a final version, and will be used in the final
implementation of the mobile sensor platform as shown above.
The project team was divided into three groups in order to make progress on
different aspects of the platform. This left two group members to do the majority of the
coding. In order to develop code that was efficient and modular, each area of the
software was worked on in a methodical order, utilizing knowledge from previous
modules. The individual modules that need development are the Movement Process, the
Sensing Process, the Communication Method, and the Formation Topology.
5.2.1 Movement Processes
In order to make the robot move, the motor controllers require a pulse for each
step the motor is expected to turn. Since the motor step is 1.8 degrees, there are 200 steps
for each complete turn of the motor. Two hundred steps will allow the mobile platform
to travel slightly under 19 centimeters. Thus, the number of motor ticks for the motor to
travel over 25 centimeters will be larger than one byte. Furthermore, the variety of
mathematical operations is severely limited on a PIC chip making conversions difficult.
In order to maintain a high precision distances stored on the mobile platform should be
converted to and stored as a number of motor ticks. While this measurement does not
make much sense from a human perspective, from the platforms’ perspective, it is the
easiest way in which to perceive the surrounding environment.
Once the distances are stored as motor ticks, movement is merely a matter of
sending a regularly patterned pulse to the motor controllers, properly timed so that the
robot does not attempt to travel too fast. The faster the platform travels, the greater the
chance slipping will occur, causing error in the platform’s trajectory. Timing the pulse
was found to be simplest by utilizing one of the onboard timers to toggle an output bit
each time it interrupted declaring that the timer had expired. Utilizing the Timers and
Interrupts on the PIC required a significant amount of research as well as debugging.
However, the final product was well worth the wait because it created an easily updated
method for movement that was completely independent from the rest of the code.
The code was designed in such a fashion as to be completely modular with the
movement command in a unique subroutine that could be called or replaced with ease as
long as the interface to the subroutine remained the same.
After debugging the code, a simple routing to make the robot travel in a figure
eight was developed and run for 15 minutes to determine the accuracy of the distances
traveled and the rotation of the platform. As time progressed, the figure eight pattern
rotated slightly but remained largely unchanged. After approximately fifteen iterations
through the pattern the ends of the figure eight had moved approximately one inch. With
a compass chip integrated into the platform, such a minor error can be corrected by taking
a heading reading at the end of each movement and adjusting accordingly.
5.2.2 Sensing Process
Integrating the ultrasonic sensors onto the chassis was no small feat either.
Interfacing with the sonar sensors required a few set features that had to be implemented.
In order for the sonar sensor to send a sonar signal, it must receive an electronic pulse
with a length greater than 15µs, delay until the output signal changes, and then record the
time passed until the signal changes again. This time measurement must then be
converted into a distance measurement using the speed of sound as a constant.
For this to be achieved, delays had to be set up in the assembly code that would
allow the program to stall for specified periods of time. By calculating the speed at
which instructions are executed, it was trivial to create a loop that would delay the proper
Measuring the time until the sonar ping was received was accomplished by
implementing one of the timers as a counter. This required setting some specialized
registers in order to keep the timer from interrupting or overflowing. The timer is started
when the return sonar signal is toggled and stopped when the return signal is toggled
again. In order to keep the number of clock ticks within acceptable limits (16 bits is the
maximum the counter can handle), the counter needed to be set to toggle on every fourth
clock tick. Each clock tick will be:
Figure 25 - Time Per Counter Tick
This means that the sonar ping will travel:
* 0.5s 0.01715cm
For each tick of the counter. This distance must now be converted into a specified
number of wheel ticks. The wheel measures 3cm in diameter and it takes 200 ticks in
order for the wheel to make a full rotation. This means that the wheel travels:
3* 2 *
For each tick it makes. After a little mathematical examination it can be shown
that in 11 clock cycles, the sonar ping will travel 0.18865 centimeters and that two motor
ticks equals 0.18850 centimeters. Therefore, 11 clock ticks translate into almost exactly
two motor ticks with a percent error of less than 0.1%. Even more advantageous is that
the sonar ping must travel twice the distance to the object, once there and once back to
the initial location. Therefore, the distance to the object is equal to the number of clock
cycles counted during the ping divided by 11.
However, since division is not supported by the microcontroller, a rather complex
algorithm that intelligently subtracts 11 and increments the count was devised. Having
the mobile platform travel the distance it measures and stop once reaching it, allowed for
verification of the code. Simply using a hand now allowed the team to examine the
accuracy of the sonar sensor.
The sensing of other objects will take place by rotating the platform 90 degrees
while taking object readings. The distances will then be stored with angles relative to the
group heading, once the compass sensor is functioning.
Integrating communication through the onboard UART required a significant
amount of research in new areas. However, it was not overly difficult to implement for
testing purposes. A loop can be created that travels along a series of bytes that have the
values to be sent stored in them and send them one at a time. Interpreting this
information will be slightly more complicated when data is being received from the
Mica2Dot controller, but will be accomplished be essentially reversing the algorithm
used to send the information.
The packet structure that must be sent to the Mica2Dot is formatted as follows.
Figure 26 - Mica2Dot Packet Format
The packet can be interpreted as follows. The destination address comes first.
This is used by the TinyOS protocol to filter messages to different groups that are
assigned upon installation of code to the Mica2Dot motes. The handlerID declares the
last object that received this message. This is used when an Ad Hoc network is created
that must pass messages along before they reach their final destination. The group ID is
the group ID that was assigned to the last mote that sent the message for the same reasons
as the Handler ID. The Message length declares the number of bytes following, which
can be up to a maximum of 29.
The rest of the information implements what has been designed of the mobile
platform interface. The information following the message length is what will be sent
directly to the PIC microcontroller. The information included in this packet will be the
source address of the platform that sent the information, a counter informing the
platforms what message this is, allowing platforms to recognize if a packet was missed.
The following data is the sensor readings that must be shared in order for the platforms to
gain information on what the other sensor platforms can see.
The goal for the second half of the Multidisciplinary Senior Design Project is to
build three additional sensor platforms and develop and algorithm by which the sensor
platforms can organize themselves into differing topologies. It is assumed that the
starting positions of the sensor platforms will be randomized.
The general tasks that the sensor platform must be able to perform are:
- The platform must be able to identify objects in its environment and determine
which are other platforms
- The platform must be able to effectively communicate its current location and
- Determine the optimal positioning for all of the platforms in the topology
- Travel to its selected destination without collisions with any stationary objects
In order for the platform to be able to accomplish these tasks, the platform must
be able to build an accurate representation of the relative locations of the other platforms
through wireless communication. If the platforms are able to build identical
representations independently, then any algorithm to select platform destinations will
have the same results for each, allowing proper destination selection.
184.108.40.206 Procedure for Orientation
In order for each sensor platform to build an internal representation of its
environment, it will have to spin, sensing objects in a 360-degree turn. Objects will be
recorded as a distance measurement and a heading measurement using the compass chip.
The platform will then transmit this data and wait for replies from other platforms. It will
then match the data received for identical distances and opposite headings. In this
method, the platforms will be able to identify which objects are “alive” and which are
Some objects may be in the way of others, but as long as two platforms can
identify one another, the positional data can then be sent to all platforms within wireless
220.127.116.11 Procedure for Creating and Forming Topology
Once orientation has successfully occurred, the selection of a destination should
be found by a deterministic algorithm, which will yield the same results for all sensor
platforms that view the pattern. Once a destination is selected, the platform will use its
obstacle avoidance code to travel to its assigned location.
After all platforms signal that they have achieved the proper location, they will
one again perform an orientation on order to verify that the location is correct.
18.104.22.168 Movement of the Entire Network
Once the mobile sensor platforms have entered formation, moving in formation
simply requires the platforms to agree on a selected direction heading and proceed to
travel in that direction based on compass input. Individual object avoidance will still be
in place, and after objects are avoided, a brief re-synchronization will have to occur to
make sure that the platforms are still in formation.
5.3 Analysis and Design Conclusions
The preceding sections discussed the analysis of the mobile sensor platform. The
design selected integrated the results from the individual component analysis as well as
design specification factors. Through experimentation on new ideas and improvements,
the chassis has been redesigned into a form that is very efficient in terms of space usage
and code design. The electrical components have been interfaced together, and function
properly. However, they are not being used as efficiently as the team would like.
Improving upon the design will be a major consideration during Senior Design II.
6.0 Initial Design
With the initial prototyping already in place, the team has secured the validity of
the concepts which have been developed and assured their feasibility. The next step in
the design process is to create an initial version of the final design. In order to create the
best possible product, the team decided to approach this step and create a product which
we believed could be used as the final design. Any testing and improvements upon this
design would hopefully be aesthetic only in nature. This section will detail changes made
to the prototype design shown in Figure 18 above. All development was done with
respect to the specifications document shown in Appendix D.
6.1 Chassis Design
After our initial prototype was built we investigated ways to improve our overall
design and incorporate additional components. Our first prototype did not include the
compass chip, which was needed for navigational purposes in order to improve the
accuracy of our robots movement. Due to the magnetic interference from the motors it
was necessary that the compass chip be placed no closer then six inches from the motors
themselves. It was also important that the compass chip be level and securely fastened in
order to eliminate the possibility of any changes in its positioning.
In order to ensure the proper functioning capabilities of the compass, we decided
to include a mast that would extend six inches from the second layer. The mast would be
equipped with a small platform at the top with mounting holes to secure the compass
chip. For the mast, an 8-32 threaded steel rod was selected for its rigidity. The mast
would be screwed directly to the second layer and extend through a clearance hole in the
circuit board for improved location and additional stability.
Another possible option that we considered instead of a mast was a magnetic
shield. We planned to fabricate a rounded shield that would extend over the top surface
of each motor. This would allow us to place the compass chip directly on the circuit
board or in a more convenient location.
From our prototype design, we also investigated ways to improve the ball castor
units used at the front and rear of the robot for stability. Our original ball castor was an
inconvenient design for mounting purposes as it had to be inverted and partially slotted
through a hole in order to balance the robot appropriately. Through research we were
able to find two other ball castors that appeared more suitable for our design.
Figure 27 – Platform Castor Attachment
6.2 Electrical Design
The electrical system of the robot needed to meet several requirements. It had to
provide power to the motors, the microcontroller, the sensors, and other miscellaneous
hardware. It also had to be robust enough to survive the robot's vibration. This concern
appeared during early testing of the prototype. The stepper motors, while accurate, are
not the smoothest of devices. This is because the motor wheels must lock between ticks
in order to ensure that the motor has moved exactly 1.2 degrees. This can case significant
vibration especially when the robot is following an arcing path where the individual
movements are small. All large movements however occur with relative smoothness. A
second concern was the power supply. The power supply was a single 1600 mAhr
battery. While this appeared to work fine, the team had concerns that this would not be
enough power to meet the specifications. In order to improve this, the team purchased an
additional set of batteries which were 2000 mAhr. This was important because during
the testing phase it would be mandatory that there were more batteries then platforms so
that testing would be able to progress at a reasonable rate. Each battery takes over four
hours to charge, and could be drained in around 20 minutes.
Figure 28 – Prototype with Breadboard
For the prototype, shown in Figure 28, a breadboard was used. The breadboard
was convenient for development and testing because it allowed for easy construction of
rapidly-changing circuits. Components could be attached to the board either by plugging
directly in or using intermediate wiring. Examination of the electrical system of the
prototype platform revealed a few interesting factors. The breadboard was not suitable
for the final design, since it was delicate (the wires came loose easily), space-limited, and
difficult for outside people to work with. One of the main concerns of the team is to
develop a robust, extensible platform. If future groups cannot decipher the design
without significant documentation, then the design is a failure.
6.3 Wireless Design
The Mica2dot mote, a product of Crossbow Technology Inc., was chosen as the
wireless communication device for this project as stated earlier. Our sponsor, Shanchieh
Jay Yang, had already purchased several motes and steered the team towards the use of
these. Therefore, several Mica2dot motes, along with the Programming and Serial
Interface Board MIB510, were already available to use.
The specifications of the Mica2dot are phenomenal. It has a long range of 150
meters, high bandwidth of 19.2 kb/s, built in power saving features, it is reprogrammable,
and best of all it is very compact. With all of these advantages, it was an easy selection.
Each Mica2dot mote is equipped with its own operating system, TinyOS. TinyOS
is a small software operating system, developed by UC Berkeley University, allows the
motes to be programmed to handle different instructions and communicating among peer
motes. TinyOS is a community-based operating system where its source code and
software development tools are publicly available at: http://webs.cs.berkeley.edu/tos.
TinyOS was installed on a desktop personal computer in the Research Lab of the
Computer Engineering Department for wireless coding and testing purposes. The
installation was successful and passed both software and hardware verification. Software
testing is performed to verify TinyOS installed successfully. The purpose of hardware
check is to verify that the hardware (motes and the programming board) are functioning
properly. If there are bugs in the applications when coding, we want to make sure that the
problem does not lie on the hardware.
After TinyOS installation, open-source code was downloaded and analyzed.
Mica2dot motes are programmed using a “specialized version of modular C code,” called
nesC. Online tutorial lessons, posted on UC Berkeley University TinyOS website at
www.tinyos.net, were completed to further strengthen the understanding of TinyOS and
how the motes communicate wirelessly. However, the tutorials and open-source codes
were developed specifically for the MICA2 motes. There are several differences between
the Mica2 and Mica2dot motes, which operate on at different frequency rates. One
example is that the Mica2 has 3 LEDs of different colors while Mica2dot has only one
red LED. Thus, problems were arising when following the tutorials. The codes had to be
modified accordingly to the Mica2dot characteristics.
Unfortunately, while the motes and their features were impressive, TinyOS was
anything but impressive. TinyOS was not developed with user friendliness in mind. It
was developed for performance. It was not until well into the project that the team began
to realize that we were in over our heads. This was because the environment that TinyOS
needs to run was poorly documented and required significant understanding of TinyOS
that the team did not have. The man hours, as well as the expertise, were lacking in this
area of the project. Nevertheless, the team forged ahead, intent on successfully meeting
all of the design objectives.
6.4 Debug Environment Design
Very early in the coding process the team recognized that there was a very serious
problem. While there existed a debugging utility for the assembly code which was being
developed on the PIC microcontroller, it was insufficient for our needs. This was
because of the simple fact that most of the errors in the code were occurring as a result of
processing, storing, or interpreting sensor data. The flaw in the debugger was that it
could not be used to examine data being retrieved from a real time system. While it was
possible to create a few carefully specified and timed events which could simulate sensor
readings, this would not effectively test the code anywhere near as well as actual sensor
input would. Therefore, in order to proceed, the team needed a method by which the PIC
microcontroller would be able to communicate interactively with the programmer. If this
need was accomplished, the programmer would be able to send the raw data from the
sensors and its interpretation to a logging mechanism so that the computation could be
examined and verified for accuracy.
In order to implement this communication the team examined the options
available on the PIC. The primary method for communication is the UART, or Universal
Asynchronous Receiver Transmitter. A UART, connected to a MAX233 protocol
conversion chip can be directly connected to a PC serial cable allowing information to be
transmitted to the PC. This method is the same as the communication interface to the
Mica2dot. Therefore, appropriate baud rate settings were applied so that the Mica2dot
Transceiver could be connected as well without changing any of the communication
interface settings. A serial cable needed to be stripped and spliced in order to obtain
access to the transmit and receive signals of the cable.
A debug environment was very necessary and crucial in understanding the
communication from PIC chip on the platform. A graphical-user interface (GUI) was
created to help debug the exact packets sent and received by the PIC. All of the formation
algorithms, collision avoidance, and data readings were implemented directly in
assembly. In order to ensure proper functionality, the code was tested in stages.
Integration of a GUI into the testing process greatly decreased the amount of time spent
debugging by increasing the effectiveness of the team’s time.
In developing the GUI, the initial functionality needed was to initial data
reception on the serial cable by means of a start button and to discontinue receiving data
by pressing a stop button. Also, the GUI needed to allow the user to send data on the
transmit wire by utilizing both a text-field and send button. All data received and
transmitted was to be shown in a text area in user-friendly format to allow for simple
understanding of the data. All buttons of the GUI were tested to ensure that they triggered
a proper change in the system. Also, all updates to the GUI are also tested to ensure that
the user obtains proper and updated information from the GUI. The initial design of the
GUI is shown in Figure 29.
Figure 29 – Initial GUI Design
The code was written in Java and handled most high level actions that needed to
be conducted by the system. The GUI interacted with the user by obtaining parameters
from the user and displaying results to the user.
The Java program contains two classes and an image file. The serial
communicator is the main class. The class creates the user interface, initializes all serial
communication, handles all user input, and outputs data to the user interface. The
SerialCommunicator class is used to interface the program with the serial port of the
computer where the code is residing in. The Graphical User Interface class is executed by
the SerialCommunicator class. The GUI class creates the window with the all the
framework of the GUI such as buttons, panel, text-fields, etc. The GUI then handles all
user interaction with the serial communicator
The user interface initially contained the following elements:
Start button to open communication and start receiving data
Stop button to close communication and stop receiving data
Send text-field to allow user to send desired data in hex format
Send button to send data typed in the text-field on the transmit wire
Information panel to provide up to date information to the user on the events
occurring in the system
During the development process of the GUI, the team decided that it needed a
logo. The logo the team developed is rather simple. It incorporates several squares
around a focal point with each square containing a number from the team’s assigned
number (05506). A simple interpretation of the logo is that it represents the four robots
surrounding an object of interest, much in the way the final demo will occur. The image
file of the logo was then finalized and it was decided that it should be placed in the GUI.
The logo, developed by Adam Haun, is shown below in figure 30.
Figure 30 – 05506 - Team Logo
6.5 Code Design
Developing code for a project of this size is no trivial matter. In order to keep
track of all of the functionality that has been developed, it is mandatory that a method of
version control will be implemented so that changes in the code can be tracked. It is also
important make sure that the code is well designed and modular so that functionality can
be reused with ease. Lastly, it is important that the code is well commented with a
regular format so that future programmers can understand and easily evaluate what is
occurring in any given portion. With these guidelines in mind, the code for this project
was developed from the ground up.
In order to begin testing of the platform, the initial routines set up were the
movement routines. The movement routines consisted of three parts. A setup function
which would ensure that the motor control signals started at the correct values, the toggle
flag was cleared, and that the system was ready to begin a movement. The movement
routine can then be called. The movement routine initializes a timer which will cause an
interrupt to occur each time it counts high enough to overflow its 16 bit counter value.
Once this counter is initialized, the movement function simply polls two register values
which keep track of the number of times the motor has ticked. In this way, the movement
routine will sit waiting until the number of ticks has reached a specified value before it
turns off the timer and allows normal program execution to continue.
The actual wheel movement is therefore done in the interrupt handler for the
timer. Each time the timer interrupts; the interrupt handler evaluates the state of the
motors and decides which out of the four possible motor signals should be toggled. In
order to send the proper signals to the motor controllers, the interrupt handler has to shift
the phase of each pair of signals in order to select the wheel direction. The actual phases
for wheel direction are as follows:
Two signals in phase – Forward
Two signals 90 degrees out of phase – Backward
The task becomes complicated when it becomes apparent that there are often
times where it is desirable for the wheels to be spinning in opposite directions, namely to
turn. The three movement functions work together as a unit, but their separation is
important. The setup function only works on data gathered from a sensor, but a macro
was developed to allow the programmer to specify short movement commands.
In order to measure both the ultrasonic sensor signals and the compass signals, the
team decided to utilize a timer which would count the number of clock ticks it would take
for the signal to pulse. This allowed the program to determine the time it took for the
pulse to complete. This was useful because for an ultrasonic sensor, the speed of sound is
roughly constant. Therefore, if the time is known for a pulse’s travel, the distance can be
easily calculated. The compass sensor used a similar mechanism whereby the number of
milliseconds of the pulse could be converted to a degree reading by subtracting 1 and
dividing by 0.0001.
In order to convert the time measurement for the ultrasonic sensor into a meaningful
result, the following two equations were developed.
* (2r ) Dist Pulse (1)
* Dist Clock (2)
Vs = Speed of Sound – 343m/s
f = Clock Frequency of the microcontroller
∆ = Degree of wheel rotation per motor pulse =1.8
r = Radius of the wheel = 3 cm
Equation 1 shows the distance the platform travels each time the motor receives a
pulse from the microcontroller. Equation 2 shows the distance the ultrasonic pulse will
travel for a given clock frequency. This distance is approximately 0.0942 cm. In order to
minimize error during conversion, a clock frequency had to be selected that would allow
for a conversion between the two distance measurements. After much testing it was
found that with a clock frequency of 2 MHz, 11 Clock ticks would equal 4 motor pulses
with a percent error of less then 0.1%.
Conversion of the compass sensor data was far simpler. After examining the
relationship between possible clock frequencies and the degree reading, it was
determined that if the clock rate was set to 4 Mhz, it would be possible to simply use the
high byte of the timer in order to evaluate the degree reading. The high byte of the timer
would travel from 0x03 to 0x93 in hexadecimal. This would equate to roughly 2 ½
degrees per bit value. The accuracy is excellent because the robot will rotate slightly
over 2 ½ degrees with a single motor tick.
With two basic sensor readings and a movement routine developed, the team
began to perform more strenuous integration testing.
At this point in the process, the team has done a significant amount of individual
component testing. The component testing discovered a large number of flaws in the
design and helped tailor the design in more appropriate and efficient ways.
Unfortunately, the majority of the difficulty in building a product is centered on the
integration of the individual components into a coherent system. Up until this point, the
system as a whole has not been tested at all. Therefore, this section will describe the
changes which had to be made after the first system integration test.
7.1 Chassis Testing/Redesign
Before constructing the mast, we discovered during testing that the steel threaded
rod would not be suitable. The rod itself was magnetized and therefore caused
interference with the compass chip. In order to eliminate this problem we decided to use
the same plastic material for the mast that was used for the two platform layers on the
chassis. However, we used a thicker 1/4 inch piece instead of the 1/8 inch that was used
for the platforms. The mast was also cut to have a wider base of half an inch. With these
dimensions we were able to minimize any deflection in the mast that would occur during
the robots movements without requiring excessive space and material. The final design
of the mast which was constructed for the compass is shown below in Figure 30.
Figure 31 – Final Mast Design
In order to improve the stability of the mast, a slot was cut in the second layer to
allow the mast to be secured to the bottom layer with a screw. This also eliminated the
need for the mast to go through the circuit board, as this would have complicated the
circuit board layout. The total length of the mast is 8 inches providing 6 and ½ inches of
clearance between the compass chip and the motors. A smaller platform was also created
with supports to secure the compass chip to. By placing the chip above the platform with
the supports, we were able to keep the compass in the center without complications from
the pins. From the tests that we ran with the mast in place, no interference was
encountered involving the compass chip.
Because we lacked an efficient method for testing any magnetic shielding design,
we decided to eliminate this option. Fabrication would have proven to be complicated as
any cutting, bending or machining of sheet metal can significantly alter the magnetic
properties, reducing its permeability and overall effectiveness. As a result, we would
have had no way of knowing if any shield design was suitable without going through a
trial and error process. This would have required an excessive amount of man hours.
The steel material would have also added a significant amount of weight. Since our mast
proved to be successful, we decided not to investigate a shielding device any further.
Figure 32 - Castor Bearing Option 2
The first new castor ball that we looked at was desirable because of its slightly
lighter weight. This design proved to make fabrication for the bottom platform layer
more complicated though, due to its unique shape. There were also no holes for
mounting as a separate mounting bracket was required, which was excessively large
creating an inefficient use of space that would have complicated the placement of the
Figure 33 – Ideal Castor Bearing
The second castor ball that we looked at would have been ideal for our robot as the
mounting holes would have been in direct contact with the bottom platform.
Unfortunately due to budget constraints we were unable to purchase these particular
castors as they were significantly more expensive then our current castors, costing $25
7.2 Electrical System Testing/Redesign
Surprisingly enough, the electrical system as a whole functioned without
significant flaws. It was determined that more capacitance was needed in a few areas in
order to supply the current required for the sensors, as well as to reduce noise in sensor
readings. Overall, the layout was proven to be effective allowing the team to progress
with the development of a Printed Circuit Board (PCB) which would be integrated into
the final design instead of the breadboard.
7.3 Wireless Testing/Redesign
An unexpected catastrophe happened as the first quarter of the project winding
down. The entire Computer Engineering network was hit by computer virus during the
last week of the quarter. Among the infected machines was the computer that this project
was currently working on. As the result, all computer hard drives were quarantined and
unable to use. This was a tremendous setback to the project since all of the code and
installation files were on the machine. The team had backup files, but the most important
information, the installation environment was lost. In addition, due to limited availability,
there wasn’t any computer that was available for the project to continue on. The only
available option at the time was to wait for the Computer Engineering network
administrator to reformat the hard drive of the infected machine. This wouldn’t be
accomplished until the beginning of the second quarter of the project.
At the beginning of the second quarter of the project, we received a notice from
the Computer Engineering network administrator that the infected machine wouldn’t be
fixed until later in the quarter due to a malfunctioning hard drive. Due to time constraints,
the team had no other option except to look for available computers in other places
outside of the Computer Engineering Department.
The team contacted the Electrical Engineering for information regarding the
availability of a computer to continue with the project. After the initial discussion and
explanation of the situation with the network administrator of the Electrical Engineering
department, we were given a computer in the Electrical Engineering Projects Lab..
The project leader then created a timeline with milestones designed to get the
project moving and back on schedule. The next step after obtaining the computer was to
restore the project back to the stage before the computer was hit with the virus. First was
to install TinyOS on the new computer. This “trivial” task turned out to be the most time
consuming and the biggest bottleneck of the project because of many unforeseen
The installation of TinyOS was done following the exact procedures as in the first
installation on the computer in the Computer Engineering department. The same
installation files were downloaded and installed. However, TinyOS did not pass either
software or hardware checks and there were no indications of an unsuccessful
installation. The initial debugging of the error didn’t give any solution to the problem.
Software manuals were also consulted, but gave no information regarding the error
message. The team then decided to uninstalled and re-install TinyOS. TinyOS once again
failed the software and hardware checks, with a different error message this time.
Debugging once again did not give any solution. The software was once again re-
installed, and failed again. Crossbow Technology was contacted in order to troubleshoot
the error and offer assistance on the installation. After several days of delay, the answer
we got was that they do not provide technical support for programs provided by TinyOS.
Their “recommendation” was to re-install the software. To make the matter worse, each
un-installation and installation of TinyOS took several hours to complete. During these
hours, the computer couldn’t be used for other purposes since the installation took up an
extremely large amount of “limited” CPU and memory resources.
After contacting Crossbow Technology failed to solve the problem, we focused
our attention to the TinyOS “community.” As mentioned before, TinyOS is an open-
source operating system where users contributed codes and ideas to make TinyOS
become more proficient. We found a community forum on the TinyOS website, located
on www.tinyOS.net, where users post problems they experience with TinyOS. The
problems are of variety of topics, from installation to programming. We joined the forum
in hope of someone will know the solution to our problem. Searching through the forum
showed that users have experienced the some of the problems we had. However, different
users gave different “advices” on how to fix the problem, and re-installation was one of
the “suggested” solutions. All of the recommended solutions were followed, but they did
not solve the problem. TinyOS still did not pass the software check.
One observation drawn from the installations was that every installation gave a
different error message, ranging from Java, incorrect paths, to serial port and many other
reasons. This analysis suggested that the problem might lie on the computer TinyOS
installed to. We found that the currently assigned computer had problem with Java in the
past. After consulting with the network administrator of the Electrical Engineering
Department, the computer was reformed and reinstalled with Microsoft Windows XP
Professional Edition. TinyOS was installed again on this “clean” computer. This
procedure did not solve the problem. TinyOS continued to fail the software check.
Research on the Internet also did not give any solution to the problem. Most of the
information found about TinyOS was abstracts and description of TinyOS. The others
pointed back to the TinyOS online site, www.tinyOS.net, for information regarding
installation and debugging.
In another attempt to find the solution, we looked to other academic apartments
for assistance. We looked for anyone, faculties and students, who might have known
about TinyOS. We found three people that have heard or known about TinyOS, Dr. Dan
Phillips, Mark Seideman, and Jing Jing Zhu.
Dr. Phillips is the professor in the Electrical Engineering Department. He has
heard of TinyOS, but is unfamiliar with the installation process. From Dr. Phillips’
information, we are not the only team that has problem with TinyOS installation.
Students at Rensselaer Polytechnic Institute (RPI) and other universities have also run
into problems with TinyOS installation.
Mark Seideman is a Computer Engineering graduate who was in one of two teams
who previously involved with this project. Mark was invited in to help us with the
installation. Once again, TinyOS was removed and re-installed. The result was the same.
There were installation packages missing and TinyOS failed the verifying process.
Jing Jing Zhu was a graduate student of Computer Science Department. Dr.
Kwon, a Computer Science professor, introduced Jing to the team when we contacted
him for assistance. She had been involving with TinyOS for the past six (6) months for
her thesis. For several weeks, she worked closely with us to help out with the installation
process. TinyOS was uninstalled and re-installed multiple times. Numerous attempts
were made to resolve the errors, but to no prevail. TinyOS failed software check. Jing
suggested installing TinyOS on a different computer. From her information, she is
currently the Teacher Assistant (TA) for a class currently taught by Dr. Ankur Teredesai
of the Computer Science Department. The objective of this class is an introduction to
TinyOS. The class had also tried to install TinyOS on all of the machines in one of the
Comptuer Science labs. Out of all the twelve machines tried, TinyOS was installed
successfully on one machine. We talked to Dr. Teredesai about the possibility of sharing
that computer for our project. Dr. Teredesai granted the permission. We waited for a
week before given accesses to the lab by the Computer Science Department. When the
motes kit was brought over to the CS lab to test out, TinyOS passed the software check,
but failed the hardware check. We received a confirmation from Jing that indeed she
didn’t run the hardware check when installing TinyOS on the machine. This hardware
failure can’t be ignored, because programs were unable to load into the mote. For the
purpose of this project, programs have to be written and load onto the motes, enabling
data transfer between motes. Both software and hardware checks have to pass before the
wireless communication can be implemented
Time was running out to get the wireless communication up and running. The team
decided to give one more week in a last attempt to get the wireless communication
working. That included a successful TinyOS installation and implementing a one-to-one
communication between the motes. A different version of TinyOS was installed, and
failed again. However, further investigation into the problem resulted in some important
findings and the possible causes of the unsuccessful installations. They are listed below:
- TinyOS must be installed on the user account with the “true”
administrative rights. That means the account that has the local
administrative rights to the computer. For example, an account of a
computer in a network might be of either 2 types of administrator:
administrator that has the administrative rights and the other that is the
actual local administrator of the computer.
Due to its huge installation size, when installing, TinyOS downloads
packages from the TinyOS server onto the computer it is installing to.
When TinyOS was installed on the machine in the Electrical Engineering
lab, it was installed under an account that has administrator rights. This
did not give sufficient rights. Since this account is not the local
administrator, certain packages that modify the computer system settings
were prevented to be downloaded and installed. The “monitor” mode in
the computer will prevent installed software to modify the system settings,
unless it is given the “true” administrator rights. If the computer is not
under any layer of network (for example: personal computer or a laptop),
an account that has admin rights would be sufficient. For the best result,
installation should be performed on the account’s name “administrator.”
This is the reason why WindowsXP Professional preferred. WindowsXP
Home Edition can only be logged under administrator in the “Safe Mode.”
Previously installed softwares:
- When installing, TinyOS will also install Java and Cygwin. If there is
previously installed Java or Cygwin on the machine, TinyOS will
complain. This is the main reason that causes Java error when performing
software check. Cygwin will point to the Java version previously installed
on the system, instead of pointing to the Java version comes with the
TinyOS installation. TinyOS does not automatically point to the correct
Java path. The same process goes for Cygwin. However, Cygwin can not
be removed automatically. It has to be removed manually, include deleting
in the registry keys. Failure to uninstall Java or Cygwin properly will
cause TinyOS to fail the software check at a later point. It’s best to install
TinyOS on a “clean” computer that does not have any TinyOS, Cygwin, or
Java already installed.
- Although happens in rare cases, TinyOS can sometimes does not
download all of necessary packages. This can cause by bad internet
connection, server timeout, or network congestion that causes packages to
be dropped during downloading.
- Although happens in rare cases and there are no official recognition of
this, there have been reports of users experiencing problems with the RS-
232 DB9 Serial cable. The cable can sometimes cause communication
problem between the programming board and the computer.
After following these findings, TinyOS was successfully installed and passed both
software and hardware checks. One to mote communication was coded, but did not work
as anticipated. Additional days were spent to debug the codes but did not give positive
results. Unfortunately, due to time constraints and the tremendous number of hours have
already input into this task, no further testing was completed. The wireless
communication objective was put on hold. Man power was divided and used for different
tasks that would strengthen and benefit the project.
Note: The installation guide, TinyOS_Installation_Guide, was written for future teams
who might involve in this project. All of the findings, recommendations, and
results are documented. This document can be accessed by contacting Shanchieh
Jay Yang in the CE Department
7.4 Debug Environment Testing/Redesign
With the completion of the GUI components laid out in the Initial Design section,
the team was ready to begin using the GUI to aid in the debugging process. Testing was
done to fully illustrate the event handling related to starting and stopping of serial
communication/ Testing was also done to verify that the correct results were displayed to
the appropriate text areas. Upon completion of first test with the GUI, a few obvious
attributes needed to be implemented to the GUI.
Four obvious deficiencies were related to the main text field. The text area was
much too small and needed to be expanded. Secondly, the text area needed to resize as
the window resized. The text area also needed to be scrollable and needed to refresh to
the bottom to allow for maximum use of screen real estate. A button to clear the text area
would be useful to allow user to erase all previous data to allow for future testing.
There were also errors related to the text-field related to sending data from the PC
to the PIC. The send text-field did not check for hex values or a valid number of bytes in
a packet. Error checking code was written to accurately send data. The result is that data
is only sent with even number of bytes and can only be sent when hex data is typed in the
send text-field. If bad data is typed in the text-field and the user attempts to send it,
exceptions are thrown and caught. Debug messages explaining the error in user-friendly
format is sent to the information text area.
The user interface upgrades are the following functional elements:
Layout allows for resizing and maximizing window.
Implemented scrollbar on TextArea and allowed for scroll to automatically
lower when data fills area.
Created a Clear button to clear all data in TextArea
Fixed Send textfield to only send data when an even number of bytes in hex
format is placed in the the send TextField. Printed error messages are placed
in TextArea when data is not proper.
After initial testing was complete and all needed components were added,
secondary testing began. After much use with the GUI as an interface to the platforms,
other components were necessary to better create a more user-friendly environment. Java
code was written to convert data obtained from the PIC into readable text placed in the
information text area. The text would be set up in columns for easy packet reading. The
header packets are separated into the columns and the data packets are displayed on the
following line. A verbose checkbox seemed sensible to allow for less or more
information to be displayed depending on what tests were completed. When the checkbox
is selected, the GUI is placed in “verbose” mode and all possible data is placed in the
information panel. When unselected, only the minimum necessary data is displayed.
The user interface final upgrades are the following functional elements:
Converted data obtained from PIC into user-friendly text
Set up columns for easy readings from the packet
Created a Verbose checkbox to allow for user to determine how much
information is printed in the textArea
7.5 Code Testing/Redesign
Once testing on the code began, errors began to crop up which did not make much
sense at first. When the sensors were tested by hand, before integration they all appeared
to work fine judging by oscilloscope readings. Unfortunately, it appeared that there was
a significant amount of bad readings occurring on the sensors. While this was
disappointing, it was not altogether unexpected. It is well known that the quality of the
sensor depends heavily upon its price. Since one of the team’s design constraints was a
low cost product, the sensors chosen were not top of the line.
In order to make the platform robust, a system had to be designed where poor
information could be rejected from the sensor readings. The first step in this process was
to quantify exactly what types of errors were occurring with the sensors. For this portion
of the testing, the GUI was used to display and tabulate data from the PIC chip as it
obtained sensor data.
The first sensor examined was the ultrasonic sensor. The ultrasonic sensor
appeared to be getting readings which were either reflections off of the ground directly in
front of the robot or some similar nearby object. The vast majority, over 80 percent, of
the errors were readings of less then 5 centimeters of distance. Because these values
could be horrendously far from the desired object, it is impossible to use an averaging
method in order to obtain a proper value. For this reason, the team decided after some
significant testing to select the maximum value of two median of threes. This means that
six ultrasonic sensor readings are taken each time platform decides that it needs to
measure a distance. The possible selected values are shown in the diagram below in
Six ordered Sensor Readings
This algorithm allows the majority of the low values, found to be more error
prone, to be rejected, while also rejecting the maximum value. Implementation of this
algorithm proved to be very effective at removing the error from the ultrasonic sensor
The compass and infrared sensors had a much more regular error pattern. Both of
these sensors returned values which were all heavily clustered. This meant that there was
no need to ignore large portions of the data and that a simple median value of three
sensor readings could be used.
8.0 Final Design
The testing phase found significantly more flaws in the design then the team had
anticipated. However, this is a good thing because it means that the testing was rigorous
and that the final design will have fewer flaws. This section will detail the final changes
made to the platform before the CDR presentation.
8.1 Chassis Design
From our initial prototype we incorporated the compass chip with the use of the
mast that we developed. We also had to include two new additional IR sensors to go
along with the sonar sensor. In order to fit the IR sensors, we reversed the location the of
the sonar sensor by placing it on the top surface of the second layer. This allowed us to
secure the IR sensors to the bottom surface of the second layer. However, due to the size
of the IR sensors and the location of the motors and ball castors, we no longer had easy
access to the battery pack for removal and replacement. In order to account for this
problem we cut a radial slot in line with one of the screw fasteners for the sensor. This
allowed us to rotate the sensor around the axis of the second fastener in order to create an
opening for the battery pack.
The complete design is detailed in the drawings in appendix B. A completed
image is shown below in Figure 34.
Figure 34 – Completed Robot Design
8.2 Electrical Design
A printed circuit board (PCB) was constructed for the final design. The PCB fixed
the problems of the breadboard -- it simplified the physical structure of the system,
provided sturdy connections for external components, and still allowed for the
expandability necessary for the product. There were two options for manufacturing the
PCB. The more expensive option allowed for a solder mask and a silkscreen layer. The
silkscreen layer could be used to label all of the components and connectors, and thus
make the board self-documenting, which would allow future groups to more easily work
with the robot. In addition, the solder mask made it easier to solder components onto the
board by hand. Thus, it was decided that the more expensive manufacturing process was
worthwhile. Figure 35 below shows the completed printed circuit board.
Figure 35 – Printed Circuit Board Design
The board uses screw terminal connectors for all external connections. These
terminals allow components to be connected and disconnected using only a flathead
screwdriver, and provide a solid electrical connection. All of the PIC microcontroller's IO
pins are brought out to connectors, so the full capability of the system can be utilized
without board redesign. Other connectors are provided for the motors, the battery, the
power from the regulators, and the converted serial signal.
The electrical system consists of the PIC18F4320 microcontroller, four
UC3770AN motor controllers, a MAX233 serial converter, and two LM1117-T voltage
regulators. The regulators provide 5V and 3.3V power to sensors. The serial converter
converts the TTL-level serial signals from the microcontroller into RS-232 form. The
motor controllers provide sufficient power to move the robot under full load, and also
provide power management capability in the form of an IO pin that turns the motor
current off. The full system was tested for battery life, and it was found the under full
load the robot could operate for over 50 minutes without power failure.
Assembly of the PCBs was done by hand. It took approximately three hours to
solder all of the components onto a PCB and hook up the sensors and power connectors.
8.3 Debug Environment Design
The final GUI design has been completed with the ability to implement additional
components if necessary. The Java code is well-commented and any experienced Java
programmer can add any necessary components. A team logo was designed and placed in
the GUI for aesthetic value. The final GUI is shown in Figure 36.
Figure 36 – Final GUI Design
8.4 Code Design
The overall structure of the code was completed during the testing phase. The
infrared sensors (front and rear) were properly integrated, and can be selected for
measurement through function parameters. All returned sensor values were selected from
a pool of multiple initial values through code analysis. Communication was integrated
into the platform, with the data sent as a parameter to the function call. In this manner,
the basic functional units of the sensor platform had been completed and tested. All of
these components were developed in a modular manner, allowing final algorithms to be
developed merely by grouping calls to these basic functionalities.
However, in order to simplify the utilization of the code additional functions were
developed to allow for specific functionalities that would prove to be the most useful.
One of these was the ability to tell the robot to match itself a specific distance from an
object which it has determined is in front of it. While this may seem simple, it is quite a
complicated task. Because sensor readings are mostly stored in two registers, a high a
low byte, for accuracy, mathematical computations become more complex. In order to
perform this simple task, the platform must first take six sonar readings, evaluate them,
and select the reading which it believes is the most accurate. This value must then be
compared against the desired distance. In order to complete this comparison, the
program first examines if the high bytes are equal. This must be done in order to decide
which value is larger. If the high bytes are equal, the low byte will determine the larger
of the two values. If the high bytes are unequal, a comparison of them will determine
which is larger. Once the larger value is determined, the direction of robot travel must be
set accordingly, and the lower values (high and low bytes) must be subtracted from the
larger values, making sure that any carries are properly taken care of.
While there is significantly more functionality in the code then that detailed so far
in this presentation, the main functionalities have been covered. The complete code (all
1400 lines) is included in appendix C.
The two major demonstrations which were exhibited at the completion of this
product are flowcharted below. The first demonstration exhibits the ability of the
platforms to travel together as a unit utilizing both the infrared and ultrasonic sensors to
their maximum capability. This demonstration is called the object tracking
In order for the platform to track the object in front of it, it must use the infrared
sensor to evaluate if an object exists. The platform will then set its distance to 15
centimeters from the object it detects. In this way, if the lead platform begins to back up,
all of the remaining platforms will do so as well. The complete algorithm is laid out in
block diagram fashion in Figure 37 below.
Object Tracking Demonstration
Use IR to Examine
Area in Front
Is Distance >
Move In Arc for Robot Move Backward Move Forward
¼ Meter Detected?
¼ Meter Brief Pause
Move In Arc for Scan For the Take IR
¼ Meter Robot Reading
Figure 37 – Object Tracking Flowchart
The second demonstration which was developed was significantly more complex.
It involved the robots entering a box formation around a particular object which the lead
platform had detected. In order to make this code autonomous, the rear robots only know
that stopping means that the lead platform has found an object which the robots will now
form around. Each robot waits for the robot in front of it to move out of the way. Once
the robot in front is out of it’s way, it uses it’s sensors to scan the area around it to
determine where other robots are heading and where the object is. Once it determines
this, it selects a point around the final object where it will set it’s destination to. The
timing, and analysis of the platforms for this demonstration was very complex, and if any
of the sensors fail too frequently, or something interrupts the demonstration, potential for
The exact algorithm is flowcharted below in the Box Formation Demonstration
shown in Figure 38.
Box Formation Demonstration
Use IR to Examine
Area in Front
Detected? Use IR to Examine Robot
No Area in Front Detected?
Activate Sonar No
Scan Counter- Move to 15 cm Activate Sonar
Move Forward Clockwise from Target & Measure
Store Store Yes
Aim Back To
Match To Center
50 cm Object
Activate Sonar &
No Move to
Move In an L shape Robot Final Spot
depending upon Detected?
Figure 38 – Box Formation Flowchart
The MERIT design process has been completed. The facets are the Needs
Assessment, Project Objectives, Project Specifications, Concept Development,
Feasibility Assessment, Analysis and Synthesis of Design, Initial Design,
Testing/Redesign, and Final Design.
The mobile sensor platforms developed are capable of utilizing their array of
sensors (Infrared, Ultrasonic, and Compass) in order to evaluate their environment and
understand that which is going on around them. While these functionalities may seem
trivial in some respects, it was no simple feat and allows complex algorithms to be
developed. The team merely scratched the surface in terms of the complexity of an
algorithm that could be developed in order to allow the robots to perform a vast array of
The concept development and feasibility assessment phases allowed the project
group to brainstorm ideas, which ultimately led to a more robust design. The concepts
developed were then assigned to different team members under the categories of
Electronics and Sensors, Chassis Design, and Communication Implementation. Dividing
up the tasks allowed group members to specialize in particular areas. Many options were
explored implemented and discarded, improving the chassis design through three separate
During the requirements and design phases, the team examined the specifications
to which the project must adhere and modified the concepts accordingly. A prototype
chassis was laid out and built, allowing the functionality of all, important components to
be tested. The mobile sensor platform that has been constructed meets the budget
requirements as well as the size and weight constraints placed upon the project by the
The testing and redesign phases allowed the project team to get a more practical
understanding of the sensor platform and its abilities. The reality of the project is far
more complex then it appears on paper, and the team’s perspective changed as a result of
this. In order to make the project successful the design needed to be simplified in a few
main areas, namely the code and electrical layout. By creating a PCB and ensuring that
the code was modular and well documented, the design became significantly more
manageable and understandable.
Overall the project team was able to meet the constraints placed upon it by the
project sponsor in all areas except wireless communication. In order to allow future
groups to easily integrate the wireless sensor, the PIC uses protocol which essentially
allows a single pair of wires to be placed from the PIC to the Mica2dot, enabling
communication. If the team had a better understanding of TinyOS, Mica2dot’s operating
system, integration of wireless would have been possible.
Overall, the sponsor was quite happy with the final design. It is very robust,
extensible, and under what was expected for a budget per robot. This project could not
have been completed without a dedicated team, and a team advisor who constantly
pressed the team to achieve a higher standard.
9.1 Photographs of completed components
As mentioned earlier in this document, the team developed a printed circuit board
in order to improve the design. A photograph of this is shown below.
Figure 39 - Completed Printed Circuit Board
In order to meet the project specifications, the team developed a set of 5 mobile
sensor platforms. An individual platform is shown below in figures 40 and 41, while a
team is shown in figure 42.
Figure 40 – Side View of Final Product
Figure 41 – Frontal View of Finished Product
Figure 42 – Squad of Sensor Platforms
9.2 Schedule for the Senior Design Team
The schedule below is a Gannt chart of the tasks which were completed during the
senior design process. While the schedule is not exact, it should give an accurate
estimate of the complexity of the issues the team surmounted in such a short time as well
as the time spent on each issue.
Figure 43– Project Plan for Senior Design II
9.3 Overall Budget
The prices below reflect the current pricing of components without shipping and
handling. Since the products are being bought through RIT, tax does not apply. With the
components listed below, each sensor platform will have one distance sensors, one
compass, two infrared sensors, and two rechargeable batteries. The listed products will
allow the project team to build three additional sensor platforms.
Part Name Qty Vendor Price Total
9.6V Rechargeable Battery 4 www.RCfinders.com $8.99 $35.96
Battery Charger 1 www.RCfinders.com $26.99 $26.99
Acrylite FF sheets 4 www.Jameco.com $9.99 $39.96
Ball Bearings 2 www.Jameco.com $9.99 $19.98
Tires 16 www.Jameco.com $5.99 $95.84
Stepper Motors 16 www.Jameco.com $6.49 $103.84
Devantech SRF04 Ranger 6 www.acroname.com $36.00 $216.00
Sharp IR Sensor 16 www.acroname.com $16.50 $264.00
R117-COMPASS 5 www.acroname.com $51.00 $255.00
UC3770 Motor Controller 24 www.digikey.com $5.56 $133.44
PIC18F4320 8 www.digikey.com $8.17 $65.36
MAX233 8 www.digikey.com $3.17 $25.36
Total Cost for Senior Design $1,281.73
9.4 Future Improvements
The sensor platform is by no means completed, and the project team hopes that
future groups will be able to build upon our design and create more effective algorithms.
One major improvement that the team would like to recommend is the addition of an in
circuit programmer for the PIC chip. During the testing of the final design, this would
have been greatly appreciated, however, the team no longer had the budget to pursue this
type of improvement.
A – Pinouts
Mica2Dot Wireless Controller
Max233 TTL to RS-232 Converter
MC3479 Motor Controller
UC3770 Motor Controller
LM317T Voltage Regulator
Thank You, From Project Team 05506