Senior Design Project CDR

Document Sample
Senior Design Project CDR Powered By Docstoc
					    Capability Enhancements for
Autonomous Mobile Wireless Sensors
Team 05506
May 13, 2005
Comprehensive Design Report

                      Mobile Sensor Platform Design

                            Team Members
                  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
Executive Summary
       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
Page #
  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.

1.4 Stakeholders

        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
        • Motors

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
                                   Platform Development

              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
0.1-degree increments.

                             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
  perform well?
     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-
thought of.
       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. 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
heading error.

                                 Figure 10 - Differential Drive

                                                                                            22 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. 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.

                                                                                        23 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
two wheels.

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. 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

                                                                                            25 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

2.4.4 Motors

       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
stepper motors.
       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
desired goals.

                              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
measurement distance.

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
it useless:

        -     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.      Motors

          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
outlined below.

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
following objectives:

       -   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
following objectives:

       -   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
           varying distances.
       -   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
be observed:

       -   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
           part failure.
       -   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.

5.1 Hardware

       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
robot model.

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

          5.0 Volt
                               Compass                      Mica2dot Communication
                                Sensor                               Mote

                                Figure 19 - System Block Diagram 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. 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.

                                                                         Sonar Measurements


  Time Between Pulses (microseconds)




                                                                                            Expected (us)
                                       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. 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
surprising information.
          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. 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. 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.

5.2 Software

       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
time limit.
       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:

                                                0.5s
                                Figure 25 - Time Per Counter Tick

       This means that the sonar ping will travel:

                                        * 0.5s  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 *
                                            0.09424778cm

       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.

5.2.3 Communications

       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.

5.2.4 Topology

          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. 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
range. 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. 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.

Magnetic Shielding:
        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.

Ball Castor:
       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:
       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, 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)

    VS 1
      *  Dist Clock              (2)
     2 f

   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.

7.0 Testing/Redesign
        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.

Magnetic Shielding:
       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.

Castor Ball:

                             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
battery pack.

                              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
per robot.

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, 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,, 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:

      Administrative rights:

           -   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.

      Downloading packages:

           -   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.

      Serial Cable:
           -   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:
           Expanded TextArea
           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.

Secondary Testing

       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

                   Min                                   Max

         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
                                                                 Activate Sonar
                                                                  & Measure

      Move Forward
      1 Meter
                                                                     Is Distance >
                                                                     then Desired?
                                                           No                            Yes


      Move In Arc for                Robot              Move Backward           Move Forward
      ¼ Meter                       Detected?

      Move Forward
      ¼ 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
failure arises.
        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
  & Measure

                             Scan Counter-            Move to 15 cm            Activate Sonar
  Move Forward                Clockwise                from Target              & Measure

                        Detected?                                                Done
              No                       Yes

      Store                              Store Yes

                      Aim Back To
                     Initial Heading
                                                                                     Scan For
                                                               Match To               Center
                                                                50 cm                 Object
                    Activate Sonar &
                        Measure                          Yes

                                                                          No          Move to
                   Move In an L shape                     Robot                      Final Spot
                    depending upon                       Detected?
                     Stored Value
                                       Figure 38 – Box Formation Flowchart

9.0 Conclusion
         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         $8.99      $35.96
     Battery Charger           1        $26.99      $26.99
    Acrylite FF sheets         4           $9.99      $39.96
      Ball Bearings            2           $9.99      $19.98
          Tires               16           $5.99      $95.84
     Stepper Motors           16           $6.49     $103.84
Devantech SRF04 Ranger         6         $36.00     $216.00
     Sharp IR Sensor          16         $16.50     $264.00
    R117-COMPASS               5         $51.00     $255.00
UC3770 Motor Controller       24          $5.56     $133.44
      PIC18F4320               8          $8.17      $65.36
        MAX233                 8          $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

              PIC18F4320 Microcontroller

              Mica2Dot Wireless Controller

Max233 TTL to RS-232 Converter

   MC3479 Motor Controller

UC3770 Motor Controller

LM317T Voltage Regulator

Thank You, From Project Team 05506


Shared By: