ee 477 final report · web viewthese connections can be accomplished through general purpose...

ECE 477 Final ReportSpring 2006

Prashant Tim Clark Andy

Team Code Name: 2-Bit Robit_________________________________ Team ID: __2___

Team Members (#1 is Team Leader):

#1: Clark Malmgren Signature: ____________________ Date: _________

#2: Andy Brezinsky Signature: ____________________ Date: _________

#3: Prashant Garimella Signature: ____________________ Date: _________

#4: Timothy Sendgikoski Signature: ____________________ Date: _________

ECE 477 Final Report Spring 2006

-ii-


REPORT EVALUATION

Component/Criterion Score Multiplier Points

Abstract 0 1 2 3 4 5 6 7 8 9 10 X 1

Project Overview and Block Diagram 0 1 2 3 4 5 6 7 8 9 10 X 2

Team Success Criteria/Fulfillment 0 1 2 3 4 5 6 7 8 9 10 X 2

Constraint Analysis/Component Selection 0 1 2 3 4 5 6 7 8 9 10 X 2

Patent Liability Analysis 0 1 2 3 4 5 6 7 8 9 10 X 2

Reliability and Safety Analysis 0 1 2 3 4 5 6 7 8 9 10 X 2

Ethical/Environmental Impact Analysis 0 1 2 3 4 5 6 7 8 9 10 X 2

Packaging Design Considerations 0 1 2 3 4 5 6 7 8 9 10 X 2

Schematic Design Considerations 0 1 2 3 4 5 6 7 8 9 10 X 2

PCB Layout Design Considerations 0 1 2 3 4 5 6 7 8 9 10 X 2

Software Design Considerations 0 1 2 3 4 5 6 7 8 9 10 X 2

Version 2 Changes 0 1 2 3 4 5 6 7 8 9 10 X 1

Summary and Conclusions 0 1 2 3 4 5 6 7 8 9 10 X 1

References 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix A: Individual Contributions 0 1 2 3 4 5 6 7 8 9 10 X 4

Appendix B: Packaging 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix C: Schematic 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix D: Top & Bottom Copper 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix E: Parts List Spreadsheet 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix F: Software Listing 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix G: FMECA Worksheet 0 1 2 3 4 5 6 7 8 9 10 X 2

Technical Writing Style 0 1 2 3 4 5 6 7 8 9 10 X 8

CD of Project Website 0 1 2 3 4 5 6 7 8 9 10 X 1

TOTAL

-iii-

Comments:


TABLE OF CONTENTS

Abstract 1 1.0 Project Overview and Block Diagram 2 2.0 Team Success Criteria and Fulfillment 3 3.0 Constraint Analysis and Component Selection 4 4.0 Patent Liability Analysis 8 5.0 Reliability and Safety Analysis 11 6.0 Ethical and Environmental Impact Analysis 20 7.0 Packaging Design Considerations 26 8.0 Schematic Design Considerations 29 9.0 PCB Layout Design Considerations 3110.0 Software Design Considerations 3311.0 Version 2 Changes 3712.0 Summary and Conclusions 3713.0 References 37Appendix A: Individual Contributions A-1Appendix B: Packaging B-1Appendix C: Schematic C-1Appendix D: PCB Layout Top and Bottom Copper D-1Appendix E: Parts List Spreadsheet E-1Appendix F: Software Listing F-1Appendix G: FMECA Worksheet G-1

-iv-


Abstract

Producing consistent and coherent large-scale recreations of images usually requires either

expensive printing or the hiring of a professional painter. In this paper, we put forward the

design of the 2-Bit Robit, a ‘robotic dot-matrix printer’ created specifically for the task of

painting low resolution large-scale (tens of feet by tens of feet) images on flat horizontal

surfaces. A detailed overview of the project is provided below, followed by the current status of

the project.

In order to properly complete this project, many different considerations needed to be

made. The first portion of this paper includes the following ‘professional’ design considerations.

A project concept and initial design were created, along with a list of components. This design

concept was checked for possible patent infringement. Later, as the design neared completion,

an analysis of the design’s reliability and general safety was performed. At this time,

recommendations for improving the environmental friendliness of the Robit’s production and

disposal, as well as some suggestions for solving the ethical responsibilities of the manufacturer,

were also proposed.

The process of designing the Robit itself began with a concept for the product packaging.

This was followed by initial designs for circuit schematics and printed circuit boards. As the

hardware phase progressed, software for the embedded systems was designed and tested.

Concluding the paper will be a list of proposed changes for a Version 2 of the design and a

summary of the major topics covered in this paper.

-1-


1.0 Project Overview and Block Diagram

The 2-Bit Robit is a ‘robotic dot-matrix printer’ designed for printing low-detail images

(such as company logos) on large, flat surfaces. The Robit can use support printing images with

up to 4 cans of spray paint or spray chalk. Images are first converted to a direction file using PC

software and then transferred to the Robit via a wireless network connection. Included in the

system are two IR/sonar beacons, which allow the Robit to maintain a proper heading while

printing the image. Current estimations allow for printing up to a 10’ x 10’ area on a single

battery charge. Below is a more in-depth description of the Robit’s operation.

The Robit design acts much like a standard printer. However, instead of spooling a page

through the printer, the robot will traverse the print area. The design has several major

components necessary for achieving our goal. The first, and most obvious, is the spray can

assembly.

There is an array of four cans, aligned perpendicular to the path of the Robit. Each can is

triggered by a solenoid mounted underneath the Robit. Having the cans arrayed perpendicular

allows us to print using more than one can at a time as we transverse the grid. Print times can be

decreased in this manner by loading additional cans of the same color in the assembly.

The robot is driven using two high torque stepper motors. The initial design included

four wheels, two on each side, with each motor driving both wheels on its side through a chain

and sprocket drive-train. After testing, we determined that the weight of the additional wheels

and the loss of torque in the chain were limiting our ability to maneuver the robot. As a result

we switched to a three-wheel system with a single front wheel and two rear wheels. In the

current set-up, each of the front wheels has its own motor connected by a short chain. Turns are

achieved by increasing the speed of one side or for a sharp turn and reversing the direction on the

other side. While the positioning is determined using dead reckoning, we have added an

additional positioning system to correct for any error accrued. By using the difference in the

speed of sound and the speed of light we are able to calculate our distance to one of two beacons

placed diagonally on the far corners of the print grid.

Included on the Robit are a wireless connection and an embedded web server.

Through the web interface a user is able to control the operation of the device. Direction files

-2-


uploaded to the Robit are stored in on-board serial FLASH, which gives a file limit of 2MB.

Below is a block diagram of the Robit’s main-board (Figure 1).

Figure 1-1. Block Diagram

2.0 Team Success Criteria and Fulfillment

Below is a listing of the Project Specific Success Criteria and the status of their completion:

1) An ability to spray fixed-size circles of chalk at specified (X,Y) coordinates.

Fulfillment: We have not completed this success criteria. A motor problem has prevented us

from demonstrating our software.

2) An ability to accurately determine location (X,Y) and heading (N/S/E/W) of Robit based on

fixed markers in print grid.

Fulfillment: We have not completed this success criteria. We experienced a serious noise issue

in the ultrasonic transmitter which was incorrectly triggering our timers.

-3-


3) An ability to traverse print the grid in a "progressive scan" fashion, with no more than 10%

error.

Fulfillment: We have not completed this success criteria. A motor problem has prevented us

from demonstrating our software.

4) An ability to "rasterize" an image file into a series of "spray dot of C/Y/M/K at location

(X,Y)" commands.

Fulfillment: We have successfully completed this success criteria.

5) An ability to control the function of and report the status of the Robit via an embedded web

server.

Fulfillment: We have successfully completed this success criteria.

3.0 Constraint Analysis and Component Selection

Most of the major constraints for the robot revolve around the ability of the robot to

operate autonomously. The robot needs a mode of wireless communication with a PC. Weight

will restrict the mobility and efficiency of the design. The robot will also have to be power

efficient enough to paint a large image without the need to recharge. In order for the image to

have any accuracy, the robot must have a positioning system accurate within a few centimeters.

The robot will also require sufficient on-chip memory to paint a image on the order of 10,000

square feet.

3.1.0 Computation Requirements

The robot is going to have several computational loads to service simultaneously.

Accurately triangulating the position will prove to be one of the most taxing issues the robot will

need to overcome. In response to this issue, the robot will have a dedicated microcontroller

dedicated to the positioning system.

In addition to both of these microcontrollers, the robot will require two or more

stationary beacons at known positions to calculate its position. They will need to decode an

-4-


incoming infrared signal and simultaneously send back both infrared and sonar acknowledge

signals.

This positioning module's most important feature will be a very accurate timer. Since it will be

measuring the time for a sound wave to travel a distance, a slow timer would not give significant

resolution for our project. It will also need to calculate the position based on the timing data fast

enough that it the position is still valid. To increase standardization and modularity, it will

communicate with the main microcontroller via I2C.

The main microcontroller will be responsible for the rest of the robot's functions. The

microcontroller will host a web interface which will allow the user to upload an instruction file.

It will utilize external ram to store the painting instructions. The microcontroller will run two

stepper motors to navigate the print area. It will also drive four solenoids to spray each can. The

microcontroller will use both dead reckoning and triangulation data to calculate its position. It

will need to try to correct for discrepancies in both position and vector.

3.1.1 Interface Requirements

Each of the microcontrollers will have a different set of interface requirements. The

main microcontroller needs Ethernet, and I2C built in. It will also need to interface with the

external ram, solenoids and stepper motors. These connections can be accomplished through

general purpose I/O. The positioning microcontroller needs to have I2C built in. It will also

interface with infrared transmitters, an infrared receiver, and a sonar receiver. The beacon

microcontrollers will interface with infrared transmitters, an infrared receiver, and a sonar

emitter.

3.1.2 On-Chip Peripheral Requirements

The main microcontroller will utilize Ethernet to host the wireless router and I2C to

communicate with the positioning system. The positioning microcontroller will have I2C to

transmit location data to the main microcontroller and will need a high resolution timer channel.

In order to achieve acceptable resolution, the timer will have to be at least 16 bits.

3.1.3 Off-Chip Peripheral Requirements

-5-


To expand the capabilities of the robot, it will have off chip RAM. This will interface

with the main microcontroller. The robot will therefore also require an address decoder chip to

sit between the microcontroller and the RAM itself.

3.1.4 Power Constraints

The robot will be powered by a single DC battery. The battery will be the largest

contributor to the weight of the overall design. Therefore, it is important to reduce the power

needs of the robot and in turn reduce the size of the battery. The largest consumers of power in

the system will be the stepper motors, solenoids, and infrared transmitters.

3.1.5 Packaging Constraints

The main design issues are weight and size. As with any mobile robot, smaller and

lighter robots are better. They will reduce the required power characteristics of the drive train.

The battery and stepper motors will likely account for approximately 75% of the entire weight.

The other parts are not as bounded by weight and size because of their comparatively small sizes.

3.1.6 Cost Constraints

Because of the project's uniqueness, there are very few products to compare it to.

There are no commercial products for sale that do large scale dot matrix printing. The most

expensive parts for the robot are the stepper motors and the battery.

3.2 Component Selection Rationale

The main microcontroller's main requirement is that it has an integrated Ethernet

system as well as I2C or an equivalent serial standard. It also will need to have a significant

processing speed to handle the position correction system. These restraints narrowed the

possibilities to the MC9S12NE64 and several Rabbit cores. The best Rabbit for the design is the

RCM3710. The major advantage of the RCM3710 is its on board 10-Base-T RJ-45 connection.

On the other hand, the module is 3 inches long and only has 33 I/O ports. Instead of I 2C, it has

SPI. This is harder to implement and will have less standardization. The module costs $49 a

piece [1]. The MC9S12NE64 will need an external transformer and a RJ-45 jack, but it will still

-6-


have a smaller footprint than the Rabbit. It also has 70 I/O pins and is available in a surface

mount for only $8.22. It has I2C as well as SPI [2]. This will add extra expandability to the

project. For these reasons, we believe the MC9S12NE64 to be the best candidate for the main

microcontroller.

The positioning microcontroller's two main requirements are that it have a very fast

and accurate timer module as well as an I2C interface. The first microcontroller that we looked at

was the PIC16C62B. This microcontroller is inexpensive and meets the major requirements.

It has I2C natively on the chip. The PIC also has a 16 bit timer and runs at a 20 MHz clock

signal [3]. This will give us a possible resolution of approximately 17 microns. We also

sampled the Atmel ATmega8. This microcontroller is only a few cents more expensive and has

all the same major properties as the PIC. The advantage of the Atmel is that it runs a RISC

architecture with 130 instructions. Since they have the same clock speed, the ATmega8 should

prove more powerful than the PIC [4]. Since the positioning microcontroller will constantly

doing triangulation calculations, the ATmega8 will power the positioning system. To improve

modularity, we will use the ATmega8 for the beacons as well.

For the external ram, the largest concern was response time. Anything over 4MB will

provide sufficient expandability to allow for very large images. We looked at two reasonably

priced models from Cypress Semiconductor Corporation. The first, model number

CY7C1041CV33, had a storage capacity of 4 MB and a response time of 10 ns. The advantage

of this chip is it has only 44 pins [5]. The CY7C1367A has a capacity of 9 MB and a fast

response time of 2.5 ns. Its drawback is that it has 100 pins [6]. As it is a surface mount part, it

is not huge, but larger than the 4 MB counterpart. Despite this downside, the response time is

important so that the robot can print freely without having to stall to wait on data. Therefore, we

have chosen the 9MB CY7C1367A.

Our stepper motor is the base of all movement for the robot. It is important that the

motor be capable of powering the entire robot. Despite this, the stepper motor should have a

reasonably small power consumption and small size. Stepper motors are in general quite large,

so there is a limit to what we can save. We looked at Anaheim Automation's 34D307. It has a

step size of 1.8º and produces 300 oz-in. It weights 7.8 lbs and has a current draw of 3.5 amps

per phase [7]. Lin Engineering's model 5718L-01S also has a step size of 1.8º and produces 294

oz-in. It weights only 2.2 lbs and has a current draw of 1.4 amps per phase. It also is only 2.3

-7-


inches in diameter in comparison to Anaheim's 3.4 inches [8]. The Lin Engineering model is the

best choice for the robot.

The battery for the robot will need to source a large current for a significant amount of

time to allow the robot to finish painting an entire picture. We considered a deep cycle marine

battery from Sportsman Marine Battery. The 12 V battery weighs nearly 53 lbs but provides 110

amp hours. It also is 12” wide which would increase the size of our robot [9]. We also looked at

the maintenance free YTX5L-BS by Yuasa Battery Inc. It provides 4 amp hours at 12 V. It only

weights 3.5 lbs and is only 5” wide [10]. At $30, the Yuasa battery is half the cost of the most

affordable deep cycle batteries. We have chosen the Yuasa because it will save us weight and

space on our robot.

4.0 Patent Liability Analysis

Infringement on a patent can come in one of two forms; literal infringement and

infringement on the doctrine of equivalents [11]. Literal infringement occurs when a device

performs a function the exact same way as a patented device. These types of infringements are

typically easy to spot and are easy to prove infringement on. An infringement under the

Doctrine of Equivalents occurs when a device performs the same function in substantially the

same way. In the following analysis, three patents will be described and compared to our project.

4.1 Results of Patent and Product Search

A patent search with the US Patent and Trademark Office was conducted using search

terms and concepts use in our project. As a result, we were not able to find any patents of any

similarity to the overall project. This required a modification to search parameters to focus more

upon subsystems than the design itself. Search terms related to the positioning system, the

spraying system, the file uploading via web browser, the positioning algorithm to process the

position data, etc were all used and a number of results turned up.

Patent 6,702,415 “Ink-jet printing method and apparatus” [12] filed on June 5, 2002,

describes a method for discharging ink for each pixel onto a printing medium while scanning an

ink-jet across the medium. In addition it describes the use of a computer to control the printing

-8-


process (claim 4) as well as the storage of a printable file to describe the contents to print (claim

5).

Patent 5,709,321 “Apparatus for remotely discharging the contents of an aerosol

container” [13] filed February 22, 1996 describes an electromechanical solenoid used to

remotely discharge an inverted aerosol spray can. It also covers the holding of the inverted can

and mounting of the can on a vehicle. The claims stated in this patent indicate its intended usage

relate to the remote spraying of an aerosol can from an operator while the can is mounted to a

vehicle and in motion.

Patent 6,850,024 “Navigation method and system for autonomous machines with

markers defining the working area” filed May 16, 2002 [14] is a robot which uses fixed position

markings to navigate an area. The position markers consist of a boundary placed around the

perimeter of the area where the robot is to work. Upon startup the robot moves around the entire

working area and memorizes the positions of the boundaries. Then, from a fixed starting

position, it moves around the work area, comparing its internal memory map of the area with its

on board sensors and corrects for any discrepancies.

4.2 Analysis of Patent Liability

Patent 6,702,415 [12] describes a method for printing ink on a medium. In a way, we

are “printing” our spray paint (ink) on the ground (medium). There is a significant difference in

the operation of our device and the patent description related to the advance of the print head in

the y-direction. As described in the patent, the print head travels across the medium in the x-

direction. Upon completion of the line, it returns to the “home position” and the medium is

advanced underneath the head. Because our medium is not movable, instead moving the print

head in the y-direction, and we do not return to home after every x-pass, the robot should not

infringe on this patent literally. However since the basic operation of depositing ink on a

medium is identical, it could be argued that we are infringing under the doctrine of equivalents.

Numerous commercial products exist which perform this printing function in a similar way to

what is laid out in the claims above. This technology can be found in most ink-jet printers.

-9-


We are literally infringing on patent 5,709,321 [13] with the robot device. Since we

need to spray the cans under control of the microprocessor, we are required to use a solenoid

device. Under examination of the diagrams, the proposed method of spraying is identical to

what is being designed for the use of our project. Furthermore, the claim for mounting the cans

on a vehicle is a fundamental requirement of our design and thus results in infringement.

Patent 6,850,024 [14] describes a system for using correction data to correct a

vehicle's position based an internal memory map of the area. The Robit's design uses correction

data from a positioning beacon to correct its location according to the internal spray memory

image. Despite the large differences in how this is accomplished and the overall usage, the

possibility of an infringement of claim 1 based on the doctrine of equivalents could be argued.

4.3 Action Recommended

While the first and third patents described above are close to describing operation of

the device created, only patent the first patent generates enough concern to warrant a deeper

investigation into infringement. Since the patent is quite general describing the ink-jet system,

the movement across the page and due to the fact that it can be compared to writing on a piece of

paper with a pen (an ink-jet like device), the defense of patenting a trivial operation could be

used to defeat the patent.

The third patent discussed above is a direct infringement and must be licensed for the

project to continue. Without developing a new method of controlling the cans using a

technology other than solenoids or another type of electromechanical device, there is no way of

firing the cans and the basic functionality of the robot is non-existent. The cheapest and easiest

method of resolving this infringement is licensing.

5.0 Reliability and Safety Analysis

In order to analyze the reliability of the 2-bit Robit, the reliability of certain key

components is considered. These components, and their function in the Robit, are

-10-


1) Freescale MC9S12NE64, main microcontroller

2) Linear LT1940, regulator in main power supply

3) Fairchild TIP-122, motor & solenoid control

4) Linear LTC1983-5, -5V charge pump for ultrasonic receiver

5) Fairchild LM2931A, voltage regulator in beacon power supply

Each component was chosen because of its importance to the system and the higher strain

the device will be operating under. For calculating component reliability, values were taken

from the Military Handbook on Reliability Prediction of Electronic Equipment [15].

Calculations are for the predicted number of failures per 106 hours. The models used are

described in table 5-1 below, and their parameters in table 5-2.

Table 5-1, Reliability Models

Model [15] Application

λP = (C1 * πT + C2 * πE) * πQ * πL Microcircuits, Gate/Logic Arrays, and

Microprocessors

λP = λb*πT*πA*πR*πS*πQ*πE Low Frequency Bipolar Transistors

λP = λb*πR*πQ*πE Fixed Film Resistors

λP = λb*πT*πS*πC*πQ*πE Low Frequency Diode

Table 5-2, Parameter Descriptions

Parameter Description [15], [16]

λP Predicted number of failures per 106 hours of operation

C1 Die complexity

πT Temperature coefficient

C2 A constant based on the number of pins

πE Environmental constant (Ground, Mobile for all components)

πQ Learning factor

πL Quality factor

λb Base failure probability related to construction

-11-


πA Application factor

πR Power Rating factor

πS Stress factor

πC Construct Construction Factor

In the following analyses, parameters for each component are listed in a table along with

the reasoning for their selection.

Table 5-3, Freescale MC9S12NE64 Microcontroller

λP = (C1 * πT + C2 * πE) * πQ * πL

Parameter Value Justification [15]

C1 0.28 16-bit Microcontroller

C2 .046 112-pin SMT device

C2 = 2.8 * 10-4 * (NP)1.08, NP = 112

πT 1.8 Based on worst-case temperature of 105oC [2]

πE 4.0 Ground, Mobile environment

πQ 10 Commercial Screening Level

πL 1.0 Years in Production ≥ 2

Results

λP 6.89 Failures per 106 hours of operation

MTTF 145137.88

hours

~ 16.56 years

The MC9S12NE64 was chosen for reliability analysis because it is the main component

of the design. All systems in the Robit depend on the proper operation of the 9S12. Using the

values listed in table 5-3, λP for the MC9S12NE64 is 6.89 per 106 hours. This gives a mean time

to failure (MTTF) of 145137.88 hours, or about 16.56 years. In choosing values for analysis,

only the factors πT and πQ were estimated, all other values were based on values in the MIL

handbook and the 9S12 data sheet.

-12-


Table 5-4, Linear LT1940 Voltage Regulator

λP = (C1 * πT + C2 * πE) * πQ * πL


C1 .020 Estimation based on 101 to 300 transistor linear device

C2 .006 Based on 17-pin, Hermetic device

C2 = 2.8 * 10-4 * (NP)1.08, NP = 17





Results


MTTF 60976.10

hours

~ 69.56 years

This component was included in the reliability analysis because it provides power to the

microcontroller and all other components of the main PCB and will be operating at a high

temperature. Based on the values listed in table 5-4, the failure rate per 106 hours is 1.64, which

translates to a mean time to failure of approximately 61,000 hours, or 70 years. Again, the

values for πQ and πL were not estimated. πT was chosen as the worst-case scenario for this

component. C1 was estimated based on the size of the component with a tendency towards a

higher value so that any error would be ‘on the side of caution.’

-13-


Table 5-5, Fairchild TIP-122 Darlington Transistor, NPN Transistors

λP = λb*πT*πA*πR*πS*πQ*πE (2 x NPN Transistors)


λb .00074 NPN type bipolar transistor, low frequency

πT 8.1 Based on worst-case temperature of 150oC (maximum junction

temperature) [18]

πA 0.70 Switching application

πR 10 Rated at up to 500 Watts [18]

πS .065 πS = .045 exp (3.1(VS)), VS = VCE / VCEO (VCEO rated value, 100 V

[18])

πQ 5.5 Unknown quality, non-plastic


Results


MTTF 7.41E6

hours

845 years

Two components in the TIP-122 Darlington Transistor are a pair of NPN transistors. For

this calculation, worst case values are assumed for temperature. All other values are based on

calculations or standards in the MIL handbook.

Table 5-6, Fairchild TIP-122 Darlington Transistor, Fixed Value Film Resistors

λP = λb*πR*πQ*πE


Λb .0012 Based on Stress Factor of 0.1 (36 W / 500 W) and ambient

temperature of 90oC [15]

πR 1.0 / 1.1 Value for resistance (0, 0.1MΩ) / Value for resistance [0.1MΩ, 1

MΩ]

πQ 15 Unknown Quality Level

-14-



Results

λP 0.144 /

0.158

Failures per 106 hours of operation, for 0.12kΩ and 3kΩ

respectively

MTTF

(hours)

6.94E6 /

6.33E6

~ 792.22 years / 722.02 years

Two components in the TIP-122 Darlington Transistor are a pair of resistors, rated at 3kΩ

and 0.12kΩ. For the purpose of selecting values, the resistors are assumed to be film type with

fixed values. The TIP-122 component is rated for up to 500 Watts [18] though it is expected that

worst case VCE will be 12V at 3A, or 36 Watts. All values are based on calculations or standards

in the MIL handbook.

Table 5-7, Fairchild TIP-122 Darlington Transistor, Low Frequency Diode

λP = λb*πT*πS*πC*πQ*πE


λb .0020 Voltage Regulator diode


temperature) [18]

πS 1.0 Voltage Regulator diode

πC 1.0 Metallurgically bonded



Results


MTTF 1.85E6

hours

~ 211.26 years

-15-


The fifth component of the Darlington Transistor is a diode across the collector and

emitter of one transistor. All values listed above are based on values listed in the MIL handbook.

Table 5-8, Fairchild TIP-122 Darlington Transistor, Final Values

Results

λP 1.112 Failures per 106 hours of operation (sum of λP values of

components [15])

MTTF 8.99E6 hours ~ 102.6 years

There are a total of 12 TIP-122s on the main board. Motor control and solenoid

triggering are handled by the TIP-122s, as such they are critical components in the functionality

of the Robit. Also, depending on their frequency of triggering, these may face significant heat

gain. Because the device features multiple internal components, its λP and MTTF were

calculated as per a hybrid device, which entails calculating for the components and summing

these for the final value. According to the calculations performed based on information in the

MIL handbook and the TIP-122 data sheet, these devices will have a λP of 1.112 failures per 106

hours of operation and a mean time to failure of ~102.6 years.

Table 5-9, Linear LTC1983-5

λP = (C1 * πT + C2 * πE) * πQ * πL


C1 .010 Estimation for Linear MOS component of 1-100 gates

C2 .0019 6-pin, Hermetic device

C2 = 2.8 * 10-4 * (NP)1.08, NP = 6





Results

λP .776 Failures per 106 hours of operation

-16-


MTTF 1.29E6

hours

~ 147.01 years

The Linear LTC1983-5 is used to provide the -5 V supply to an OPAMP in the sonar

receiver circuit of the main board. Because this is a voltage supplying component, it is likely to

operate at well above ambient temperature, and thus, where down more quickly than other

nearby components. Calculations for this device show an expected .776 failures per 106 hours of

operation, and a mean time to failure of ~147.01 years.

Table 5-10, Fairchild LM2931A

λP = λb*πT*πA*πR*πS*πQ*πE


λb .00074 Base value for bipolar transistor


temperature) [20]

πA 1.5 Transistor performing linear amplification

πR 1.56 Max power (Pr) of 3.3 Watts [20], πR = (Pr)0.37

πS .050 πS = .045 exp (3.1(VS)), VS = VCE / VCEO (VCEO rated value, ~28 V

[20])

πQ 5.5 Assumed Lower Quality level


Results

λP .035 Failures per 106 hours of operation

MTTF 2.86E7

hours

~ 3.26E3 years

Per 2

Devices

λP = .07 MTTF = 1.43E7 hours, ~ 1.63E3 years

-17-


This component is the voltage regulator for the beacon system. Because it is the power-

supply component for a key feature of the design, it is included in this reliability analysis. The

LM2931A package contains two bipolar transistors, and thus is calculated as a hybrid

component. It is expected to have .07 failures per 106 hours of operation and a mean time to

failure of about 1.63E3 years.

Considering each of the mean times to failures separately, the shortest time to failure (or

the component most likely to fail) is the main microcontroller. Its rating for failures per 106

hours is 6.89, the highest of any component. The sum of all λP values for components in the

main board is 22.72, which gives the system an estimated mean time to failure of 4.4E4 hours, or

about five years. This may seem like a small value in comparison to many of the other

components, but there are other factors that should be considered.

In looking at the MTTF of the Robit, the difficulty to repair a broken component must be

considered, as well as the expected life of the Robit as a retail product. The design of the Robit

is such that the main board can easily be replaced: current specifications state that the main board

will be enclosed in its own housing with all peripherals connected via headers. Any

malfunctions in the main board can then be fixed by sending a new main board to the consumer,

rather than replacing the entire Robit or having the Robit shipped to a repair location. Likewise,

because the beacons are physically independent, any malfunctions can be fixed by sending out a

replacement unit. As to the life-span, a production version of the Robit would most likely have a

retail life of no more than 2-4 years, depending on the rate at which improvements to the

software and hardware are developed. Thus, for the majority of consumers, by the time the

product fails, they would likely be looking to purchase an upgraded system.

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

In considering the Robit from the standpoint of possible failure modes and their effects, it

became apparent that three levels of criticality were necessary. Below (Table 5-11) is a

description of these three levels of criticality and the maximum probability for each.

Table 5-11, Criticality Levels for Robit System

Criticality Level Description Acceptable Failure Rate

-18-


Low System does not operate

as expected

λ < 10-5

Medium Possibility of excessive

spraying, may lead to

‘permanent’ marking of

surface

λ < 10-7

High Possible harm to user λ < 10-9

The value for the acceptable failure rate for Low criticality was chosen based on the lack

of danger to the user for failures of this type, and because the Robit’s main board is easily

replaced in case of any component failures (reducing the inconvenience to the user).

Medium criticality is designated as occurring when there is a system failure in which the

Robit could spray outside of the intended pixel matrix. In this case, there is a greater

inconvenience to the user because not only might they need to repair the Robit, but they also

would need to clean the print area before attempting another printing. In the case of spray chalk,

this can be accomplished by hosing down the area with water and letting it dry, but if spray paint

were used, then chemicals would be required to remove the errant paint. In either case, this leads

to a higher dissatisfaction with the product than a simple board failure because the user now has

to expend resources on clean-up of the area before they can attempt another print. Also, it is

possible the user may demand that the Robit manufacturers pay for the cleanup, or in extreme

cases, they may pursue litigation for damages to property. Considering these factors, the value

of 10-7 was selected for medium criticality.

High criticality was assigned the standard failure rate. For the Robit, it is not expected

that users will have frequent contact with the device while it is in operation. Instead, they are in

the most danger during the initialization of the Robit, while changing spray cans during

operation, and when collecting the Robit after printing. These times account for a small

percentage of the Robit’s active time, and so it is not necessary to consider any more extreme

measures.

Key functional blocks of the Robit are assigned descriptor characters in table 5-12

below. The column labeled “Key Component” is a listing of the component in each block listed

-19-


as the most likely to suffer a failure. Schematics for these components are included in appendix

C while their safety analyses are in appendix G.

-20-


Table 5-12, Functional Blocks

Block Descriptor

Block Name Key Component

A Main Microcontroller Circuit MC9S12NE64B Optoisolation & Amplifiers TIP-122C Power Supply Linear LT1940D Positioning System LTC1982-5E Beacon ATmega8

6.0 Ethical and Environmental Impact Analysis

A major concern in this project is keeping the spray painting process clean and tidy

without causing any inconvenience to the user while minimizing the harmful effects on the

environment. The Robit has been analyzed from all possible aspects to provide the best quality

product to the user. Testing the product under several appropriate conditions, placing the

appropriate warning labels, and providing cautions in the user manual are some of the possible

ways of overcoming the shortcomings while designing the Robit. Details regarding the ethical

challenges, its solutions and other environmental challenges are discussed in detail in the

following sections.

6.1 Ethical Impact Analysis

According to the code of ethics by National Institute for Engineering Ethics (NIEE),

“Fundamental principles of conduct of engineers includes truth, honesty and trustworthiness in

their service to society, and honorable and ethical practice showing fairness, courtesy and good

faith toward clients, colleagues and others.”[21] While designing the Robit, there were several

ethical considerations which needed to be addressed in order to ensure the safety and reliability,

as well as the robustness, of the product. It is noteworthy that the product needs to be thoroughly

tested under a variety of operating conditions before it is launched. Following is the account of

some of the important ethical challenges considered before releasing the product into the market.

-21-


6.1.1 Testing under variety of conditions:

The various components of the Robit, like the positioning system, power supply, the serial

flash memory, and other critical components, are controlled through the main microcontroller on

board via software. Any sort of software flaw can cause malfunctioning of the microcontroller of

the system which, in turn, can have severe effects on the Robit’s performance, leading to a great

degree of uncertainty for the user.

A. Failure in the positioning system

Any kind of software flaw can cause malfunctioning of the microcontroller of the system,

which may have critical effects on the user, ranging from low severity to high. The most

essential test was to make sure that the positioning system of ultrasonic / IR receivers and

transmitters on the Robit were able to communicate with the beacons all the time. The failure of

the positioning system is a critical error within the Robit system, as the Robit’s microcontroller

cannot position itself at the correct location on the print area and will fail to function correctly.

Sometimes, software failures can also make the Robit to behave in an unpredictable fashion, like

printing outside its regular path and running over user’s foot and leading to some kinds of minor

injuries or bruises. Another time, the user might want to print some logo on the grass field with

flower beds on the edges. Software bugs can cause Robit to lose its track and can potentially

damage the flower beds by trampling all the tender plants.

To prevent the Robit from printing on random surfaces outside its printing range, the

positioning system should be thoroughly tested against flaws in the software. In case of detection

of loss of communication with the beacon system, the Robit should be programmed to

temporarily disable itself until it is properly reset.

B. Failure in the Serial Flash Memory

Another software constraint considered while designing the Robit was failure in the serial

flash memory. The direction file of the user selected image is stored in this memory. This

memory should be cleared each time before loading new direction file. Due to some software

bugs, if this memory is not cleared, then there is a possibility of the memory being overwritten

and the Robit will be unable to access following segments of the file. This failure can be

-22-


troublesome for the user, as the Robit memory will be overwritten each time, thus causing it to

print old images that may be present in the memory.

This problem can be solved through several software checks. Before loading the new

segments of the file, the software should estimate the actual space left in the memory. In case of

insufficient space left in the memory, it should clear the old segments from the memory to create

more space for new segment of the directional file. The older segments of the file can be

discarded because the Robit has already completed printing those segments on the surface.

C. Failure in Triggering the Solenoids and Motors

Triggering of the solenoids and the rotation of the motors are also controlled by the main

microcontroller. Incase of a software bug, solenoid control can get stuck on. This case is

unethical from the user’s point of view, as the solenoids will keep firing and spraying excessive

paint in the printer area. If a permanent paint is being used, this can cause destruction of the

surface being printed on. Similarly, there is a possibility of the motor’s control signal being stuck

on. By keeping the coil of the motor active, current is being dumped directly across a low

resistance wire acting as a short to the battery. This the battery at danger of catching fire and

causing damage to the Robit and potentially the user. The solution to above mentioned problem

is to detect the fault in the motors and solenoids via software routines and hardware interlock

checks. If any faults are detected the Robit should disable itself until reset by a qualified

operator.

Another possible fault related to the motors that should be kept in mind for user safety is the

maintenance of temperature of the motors and solenoids. Large amounts of heat are generated in

the motors during their normal operation. Under abnormal operating conditions (such as hot

summer day), the motors may overheat. This can cause damage to the motors and present a burn

risk to the user. There is a similar risk of damage from water if operated in damp or rainy

conditions. Both heat and water issues can be solved by using fan cooled motors and adding

proper waterproofing to the motors. Also, effort should be made to make sure that any motor

housing is well ventilated or louvered so that hot air is not trapped inside [22].

-23-


6.1.2 Placement of warning labels

The user can be warned of the potential hazards associated within the product by placing

appropriate warning labels on the product. Some of these warning labels include:

1) The power supply circuit may cause some of the components including the main

microcontroller to overheat and possibly catch fire as a result of excessive output voltage

from the circuit. This can cause injury to the user or persons nearby. This problem can be

solved through use appropriate fuses in the circuits, so that they may prevent damage to

the main components.

2) There will be a general warning label issued informing the user to follow any warnings

issued by the spray paint company regarding the harmful effects of inhaling the emissions

from these paints. These emissions may cause dizziness, nausea or breathing problems

[23]. This problem can be solved to some extent by using non-toxic paints or water-based

natural paints that give off almost no fumes. These paints are better for the user’s health

and the environment [24].

3) The drive train assembly exposes the user to a pinch and crush hazard. A shield should

be placed around the motors and wheels to stop a user from placing their hands in the

chain. Proper placards and labels should be also placed in the region.

6.1.3 Providing cautions in the user documentation

There also exists a greater possibility that the Robit may malfunction due to

mishandling by a user rather than a fault in either the software or the hardware. Thus it is critical

to make the user aware about the safe functioning of the product through the user manual. This

will help to ensure the reliability of the Robit in the long run, as well as the safety of the user. As

an example, the user should be cautioned against operating the Robit in a closed environment

due to risk of harmful emissions from the spray cans. Additionally, the user should be warned

that Robit should not be run for extended periods of time during the summers or in damp

conditions, as there is a risk of damaging the electrical components of the Robit. The manual

shall contain all the necessary information about the product and detailed operating instructions

for the safe use of the product.

-24-


6.1.4 Adding Safety Mechanisms

Certain safety mechanism can also be built-in, which will ensure the safety of the customers.

These include:

1) Incase of high output voltage passing through the major components, the same can be

prevented by adding current sinking resistors or fuse.

2) The solenoid system or motor system shall be disabled to prevent the Robit from either over

spraying or getting stuck at one point on the ground.

3) Provide proper insulation between power supply and microcontroller to avoid potential noise

which can affect the functioning of other components.

6.2 Environmental Impact AnalysisThe code of ethics of the National Institute for Engineering Ethics also states that

“Engineers shall examine the societal and environmental impact of their actions and projects,

including the wise use and conservation of resources and energy, in order to make informed

recommendations and decisions” [22]. This section of the paper will highlight the environmental

impact of the design in various stages of its life cycle

A. Product Manufacture

The Robit system utilizes three printed circuit boards (PCB), one for the main robot system

and one for each of the beacons. Considerable hazardous waste materials are generated in the

production of a PCB [25]. Some of the typical waste products include: Industrial wastewater and

treatment residue, spent process baths, alkaline acids used for cleaning equipments, copper

sulfate crystals and reflow oil. Improper disposal of these waste materials can lead to future

liabilities of this manufacturing process. The waste materials from PCB should be treated

separately from non-hazardous materials. An alternative solution to the problem could be to use

non-toxic chemicals for the manufacture of the boards [26].

Lead fumes are generated while soldering components on the board. These fumes, if

inhaled, can lead to lead poisoning and ailments of the nervous-system. One solution is to outfit

the manufacturing environment with an appropriate ventilation system, including air filters

which can absorb all the harmful gasses and fumes from the mass manufacturing of the product.

Also, lead-free soldering solutions can be considered. [27]

-25-


B. Normal Use

The 2-bit Robit uses spray cans which release low level toxic emissions into the air and

pollute the environment. Some of these spray cans contain CFC gases (aerosol), the gas

responsible for depleting the ozone layer. These spray cans’ propellants are generally flammable

and create a fire hazard [28]. An alternative solution to this problem is to use non-toxic or water

based spray paints or spray chalks which are non-aerosol based.

The Robit is powered by sealed lead acid marine batteries. This is a potential environmental

hazard as a result of improper disposal of damaged or extinguished batteries. An alternative

solution to lead acid batteries could be to use Nickel Metal Hydride batteries which are used in

high-voltage electric and hybrid vehicles. These batteries have longer life expectancy than lead-

acid batteries and can be recycled easily using electrochemical technologies, thus avoiding

potential air emissions associated with the recycling process [29].

C. Disposing / Recycling

There are few critical concerns regarding the disposal of the product after it completes its

lifespan. As mentioned above, the components used in the Robit are not all environmentally

friendly, and thus careful measures need to be taken by the users to avoid problems leading to

environmental degradation.

Following are a few possible ways of disposing off the parts of the Robit:

1) Since the printed circuit board contains several toxic chemicals, they should be disposed of

carefully [30]. Many elements, such as gold, silver, and copper, can be recovered and recycled

from the boards. Thus, many companies are offering recycling services for PCBs, returning their

salvage value to the producer.

2) When lead-acid batteries are disposed of in landfills, their toxic contents may leach into the

groundwater. Thus, special care has to be taken in disposing of lead batteries. According to the

Environmental Protection Agency (EPA) nearly 80% of lead-acid batteries are recyclable [31].

During disposal, `the sulfuric acid is purified and recycled. The lead plates in the batteries are

melted, refined, and recycled. The plastic case used outside can be shredded and recycled.

-26-


The required information regarding the disposal of waste products from the Robit should be

furnished in the user manual to minimize the environmental hazard.

7.0 Packaging Design Considerations

The uniqueness of the project is evident in the lack of prior commercial art found for the

design. A design review analysis as performed on the project. Following is a similar project for

the spray subsystem as well as a commercial robotic platform.

7.1.1 Product #1

The “Bikes against Bush” [32] project was designed as a protest tool for the 2004

Republican National Convention. Using a series of spray cans mounted on the back of bicycles,

protesters were able to quickly print large amounts of text banners on the ground with messages

provided via SMS messaging.

Illustration 7-1: "Bikes against Bush" ChalkWriter

Designed by Joshua Kinberg, the system features 5 spray cans side by side. A series

of solenoids placed along the bottom of the nozzles provide the necessary mechanical action to

trigger the spray. Metal U-hooks attach the cans to the Plexiglas box containing the electronics.

The transparency of the Plexiglas gives individuals an inside look into the inner

workings of the project. The ability to easily mold and shape Plexiglas to create a nice box is a

-27-


plus. However the project is mainly to be used outdoors and this is not a good choice for harsh

environments.

We plan on basing our can spray system off of this design as it's almost exactly what

we're attempting to do. The cans however will be mounted over a slot cut in the middle of the

robot instead of hung off the back like this design. We also plan on using Plexiglas for the

housing of the electronics and the battery cover. This is due to the ease of working with

plexiglass and the quality of the end result. This should give us a crisp cover for the battery and

solid and clean base for the electronic mount.

Since we are using a robotic platform as a driving mechanism compared to a bicycle

we have a few different requirements for mounting the spray cans. The solenoids will be

mounted in a vertical manner to minimize the width of the robot. If the cans were mounted on

the robot as shown in Illustration 1, the robot would need to be twice as wide as shown.

Mounting them vertically as opposed to horizontally also clears up room on the sides of the robot

for the stepper motor mountings.

7.1.2 Product #2

The Workman Robotic Platform by Kadtronix [33] is designed to be a platform to

expand upon. Constructed out of ABS plastic it provides a complete system of motors,

controllers, and a battery to decrease development time of projects.

Illustration 7-2: Kadtronix Workman Robotic Platform

-28-


The robot measures 15”L x 19”W and weighs in at 20 lbs. It is driven by 2 high

torque 12v motors. The plastic casing allows for easy modification for mounting of sensors and

additional electronics. The design includes two front wheels and a rear floating castor.

The robot has an easy design because there are only two drive motors. This allows

you to spin the robot in place over an axis between the front wheels. The motors are simple

worm-gear driven devices that do not have any type of feedback as to position. This has a

disadvantage of not allowing you to know where you were without adding sensors. In addition

the ABS plastic and overall construction is not robust enough for outdoor use.

Our original design called for two powered wheels with a caster as this design uses,

however since our rotation axis needs to be around the center of the robot and not around the

center of the powered wheel axis, we need to drive both pairs of wheels directly. We plan on

expanding the use of ABS plastic for the shell in our design by using Plexiglas for its ability to

easily be modified and worked with.

The Robit will be powered by stepper motors instead of standard DC motors. This

gives us the necessary precision to detect our location using dead-reckoning and the ability to

precisely move our robot to the proper position to place the spray in the proper location.

7.2 Project Packaging Specifications

The Robit is built out of ¾” plywood [34] with 2 front mounted wheels and a back

mounted caster. The robot is powered off of a 4 amp hour 12V Sealed Gel Acid battery. [35]

The spray system is also built out of plywood with power door lock actuators as solenoids to

trigger the cans. The drive system is comprised of 2 stepper motors connected to both wheels via

a sprocket and chain. [8]

Running in a perpendicular direction to the motion are 4 spray cans. Directly infront

of them are the motors and behind that, the battery. Mounted on behind the support for the spray

cans is the circuit board and position system since the position sensor must be the tallest item on

the robot.

-29-


8.0 Schematic Design Considerations

There are several functional blocks on the main board to accomplish the given task of

spray painting on the surface. These blocks include the main control unit, the power supply, the

voltage regulator, infrared / ultrasonic receivers and transmitters, solenoids and motors.

Apart from these blocks, there are few functional blocks placed in the beacon system

which help in tracking the position of the Robit. There are two separate design systems; The

Robit (main system) and the beacon system which help in tracking the robot.

Theory of Operation

(A) The ROBIT

i) Microcontroller (Free scale MC9S12NE64)

The microcontroller MC9S12NE64 is the main functional block of the 2-Bit Robot.

Most of the design considerations, like determining the supply voltage of 3.3 V and operating

frequency of 25 MHz, were determined from the recommendation of the manufacturer as

provided in their datasheet [2]. This microcontroller also consists of BDM (Background Debug

Mode) which would be useful for the in circuit programmable configuration.

The onboard microcontroller is loaded with the design from the user, transferred via a

wireless connection from the user’s PC to the robot through the RJ-45 connector [36]. The

supply voltage for the RJ-45 connector is determined to be 5V. The microcontroller enables the

stepper motors to drive the wheels of the robot, as well as triggers the solenoids in order to spray

paint in the paint grid. To track its current position, the microcontroller also communicates with

the beacons through the IR/Ultrasonic receivers and transmitters. There are also provisions for an

expansion PLD [39] operating at 3.3V supply along with this module. This module is to be used

for any future I/O needs not currently implemented on the microcontroller.

ii) Power Supply

Determining an appropriate power supply was one of the critical decisions of the Robit

design as different blocks on the main board had different power requirement. The solenoids and

motors required a 12 V supply. A 3.3V supply is required to power the main microcontroller,

while 5V supply is required for the IR/Ultrasonic receivers, and other components such as the

Darlington array transistors. On the main board, a dual current mode PWM step down DC/DC

-30-


converter chip, LT1940 [17] is used to step down 12V from our main power supply, a 7 AH

(Amp Hour) Scaled Lead Acid battery, to generate a 3.3 V and 5 V power as required by the

major components of the Robit. An LTC1983-5 [19] chip i.e. an inverting charge pump DC/DC

converter is used to supply -5V DC power to the LM6154 chip of the ultrasonic receivers.

LTC1983-5 inverter inputs 5V DC and outputs

-5V DC.

In order to regulate the power supply in the beacons, LM2931A chip is [20] used. It is

a three-pin low dropout voltage regulator. It is used to output +5V supply to the microcontroller,

IR / Sonar transmitters and receivers on the beacons.

iii) Solenoids and Motors

The TIP120 transistors [40] drive the solenoid’s driver circuits. Its operating voltage is

determined to be12V, which could be justified, as lot of power is drawn by the solenoids to pull

the nozzle of the spray cans. There are four different solenoids for four different color cans. Each

solenoid is triggered by the microcontroller, which in turn pulls the nozzle of the spray cans,

effectively spraying color on the surface.

The motor system is similar to the solenoid system. Once again, the TIP120 [40]

transistors drive motor’s driver circuits. The operating voltage is 12 V. Two stepper motors are

required in this design which is used to drive the wheels of the robit. Each of these motors is

controlled by a single PWM channel from the microcontroller.

iv) Ultrasonic / IR Receiver

These systems make up the positioning unit on the main board. It is used to direct the

robot while painting on the surface in a certain area to ensure accuracy of the painting process.

These ultrasonic/IR receivers communicate with the IR/Sonar transmitters of the beacons (off the

board) to track the robot’s current position with respect to the direction file. The operating

voltage of this system is 5V. This system also consists of LM6154 [41] chip which is a Dual

Quad 75 MHz GBW Rail-to-Rail Operational Amplifiers. This chip serves the purpose of signal

conditioning amplifier, amplifying the received signal for the main microcontroller (9S12). The

-31-


microcontroller will then calculate its position based on the difference in the timing between

infrared and sonar signal received from the beacons.

(B) The BEACONS

i) ATmega8 (Secondary microcontroller for the beacons)

The ATmega8 microcontroller is the main control unit in the beacon system. The

operating frequency for the microcontroller was determined to be 8 MHz by the manufacturer, as

mentioned in the datasheet [4]. The supply voltage for the microcontroller was also determined

to be 5V in comparison to the 3.3V of the microcontroller on the Robit board. This

microcontroller also uses its own internal RC-oscillator as a clock source. The purpose of this

secondary microcontroller was to monitor infrared signal received from the robit and trigger the

IR/Sonar transmitters from the beacons system to accurately guide the robit on a correct path.

ii) Infrared Receivers

To receive IR signals from the robit, the beacon is equipped with four standard IR

receiver modules, TSOP 1740 [38] chips operating at 40 kHz and 5V supply voltage. The

sensitivity of this modules is very good, thus they can recognize fairly weak signals. Four

receivers are placed at 90° angles to provide full coverage of arriving signals.

iii) Infrared / Sonar Transmitter

The beacon sytem has an ultrasonic loud speaker and high power infrared diode

TSAL7400 [42] operating at 5V. This diode is used for transmitting infrared signal to the main

robot when enabled by the ATmega8 microcontroller. The transmitted signal is amplified by

Darlington array transistors L603 [43] operating at 5V supply.

9.0 PCB Layout Design Considerations

In designing the Robit’s PCB, it was necessary to design two separate boards. The first

was the main board which houses the majority of the system’s functionality. Second, there was

the board to be used in the positioning beacons. On the main-board, components were grouped

in a manner similar to that shown on the schematic as explained below.

Main Board ‘modules:’

-32-


1) Micro-controller – system’s main microcontroller [2] and it’s necessary external

components including the 25MHz oscillator

2) Ethernet – external components necessary to the operation of the Ethernet port and the

actual RJ-45 jack [36]

3) Expansion PLD – a PLD placed for future expandability

4) Main Power Circuit – provides the 5V and 3.3V supply [17] for the system from the

12V battery

5) Secondary Power Circuit [19] – provides the -5V needed by the op-amp array in the

ultrasonic receiver circuit

6) Motor Control – headers, resistors, and transistors used in operating both stepper

motors

7) Solenoid Control – headers, resistors, and transistors used in firing the four solenoids

8) Ultrasonic Receiver – header for the actual receiver component [37] and circuit used

in analyzing the input from the receiver and detecting the appropriate frequency

9) IR Tx/Rx – circuit with components for powering the IR transmitting diodes and IR

receivers [38] along with headers for connecting them

Figures C-1, C-2, and C-3 show the board with its components organized into their

groupings.

Because of its small component count, the PCB for the beacon did not need to be divided

into modules. Its components are an Atmel ATmega8 microcontroller [4], IR receiver, IR

transmitter, Ultrasonic transmitter [37], and a DC voltage regulator [20]. This can be seen in

Figures 2 and 3. At present, the beacons were prototyped on two breadboards. For production,

however, producing the beacons on PCBs would be preferable.

With regards to the main PCB, there were few major design considerations. These

included

1) The need for power rails capable of supplying 10A

2) Providing 3.3V and 5V to the various components on board

3) Ordering pin-outs such that the number of traces which cross-over are minimized

4) Minimizing EMI from analog components

-33-


5) Heat dissipation of ICs

In order to allow for the 10A of current that the motors and solenoids require, a copper

pour runs along the edges of the board (rather than a large trace) where the solenoid and motor

headers are placed. The 3.3V runs along two outside edge of the board while a 5V rail runs

along the opposite edges. Ground rails are routed on the bottom of the PCB. Power rails, along

with other traces for the board, can be seen in Figures 4 and 5.

Although specifying an orderly pin-out seems like a trivial task, this actually requires

much trial-and-error in order to reach a configuration which adequately reduces the number of

crossed traces. To minimize the effects of EMI on the digital logic, all analog circuits were

placed far away from the microcontroller and other digital ICs. Distanced components include

transistors for the motors and solenoids, power circuits, and the op-amp array. For heat

dissipation in the Linear voltage control ICs, the placement of large copper pours under each

chip, as recommended in their data sheets, is adequate.

For the majority of our components, the standard trace size was adequate for providing

the needed current from the power rails. However, for a majority of components, the actual trace

size used is 30-40 mils. Through this increase in trace size, it is hoped that the system’s

durability will increase, specifically in the case of a malfunctioning component drawing an over-

large amount of current.

10.0 Software Design Considerations

The overall operation of the device will at times be very taxing on the microcontroller.

This is why it is important that the device not be bogged down by any specific process at any

given point in time. The robot may be waiting to receive a beacon acknowledge at the same time

that it should be stepping the motors. Therefore the program will be a largely polling based loop

with flags to store the state of the process at any given point in time.

The project will require utilize several peripheral components. The positioning system

will use the timer module to accurately time the difference between the infrared and sonar

signals. The main loop is interrupt driven. This interrupt is periodically triggered by the timer

module. The infrared and sonar receive signals both trigger interrupts for the location system.

The robot also uses the Ethernet to host its web interface.

-34-


The software must also host a web interface and accept incoming data from a PC via

wireless internet. The microcontroller has an integrated Ethernet device which will be connected

to a wireless router. All of the web functionality will be handled using interrupts.

The robot will use the timer modules to regulate the time to complete each poll of the

main loop. It will use another timer channel to calculate the time difference between infrared

and sonar signals. Both of these will need to be scaled down to prevent an overflow, but the

positioning timer will be significantly faster. Since it is a 16-bit timer and we want the device to

be capable of handling distances up to 25 ft, the timer will be clocked down to approximately 3

MHz.

There are only a few variables involved with the program. Most of the variables stored

will be flags that are a single bit wide. These variables will be in RAM along with a large area

reserved for the chunks of direction file that will be loaded into the microcontroller. The

program itself will be stored in flash. If empirical testing shows that the robot needs to load in

more data at once, it can also use the flash to store the direction file on the microcontroller.

The robot will utilize the standard memory model for the MC9S19NE64. This is largely

because the standard model meets all our requirements for our project. A 13 foot by 13 foot

image requires only 2 kilobytes of memory. Even if the entirety of that image was stored in

RAM, there is still 8 kilobytes of RAM remaining for program variables. The code itself is

stored in a 16 kilobyte block of flash. This is more than enough as the code that has been

generated so far occupies significantly less than 1 kilobyte.

The external devices are mapped to make the greatest sense in the PCB layout while also

preserving a sensible grouping of pins for each interface. All the beacon communication data is

received on Port H and transmitted from Port G. The motors share Port A, but it is split such that

all the lines stayed together on the PCB. The solenoids are triggered from Port B.

Table 10-1 - External Interface Port Mappings

Interfaces Port Name Pins

Left Motor Port A 0 .. 3

Right Motor Port A 4 .. 7

Solenoids Port B 0 .. 3

-35-


Interfaces Port Name Pins

Infrared Transmit Port G 0 .. 7

Infrared Receive Port H 0 .. 3

Sonar Receive Port H 4

10.1 Software Design Narrative

Main Loop

As shown in Figure A1, the main loop is a polling loop that will call each of the more specific

functionalities of the robot. Figure B1 shows at the highest level which functions are called by

the main loop. At startup, the robot must wait until it receives the file from the PC. Then it

enters a loop consisting of updating the memory, calculating its position, moving the robot and

spraying the cans. Some of these functions will do nothing unless the proper flags are set in

different functions. The program will continue through this loop until the entire image has been

printed and then will wait for another file to be loaded. The main loop has been written except

that currently the file is hard coded and not loaded into the program.

Load Flash

The load flash module is responsible for loading the user's direction file into the off-chip flash.

It will accept data from the PC and then immediately burn it into flash. It will not be concerned

with keeping any data on the microcontroller itself until it starts the actual polling loop. This is

used to load an entire direction file into the project at once. Currently, this module is in pseudo-

code and has not been tested.

Load SRAM

The load SRAM module will read information from flash and store it into the on-board memory

for rapid accessing during the main loop of the program. This runs whenever the SRAM is

empty or if the robot has read all the data currently in the SRAM and needs new data to move

forward. This module is also been written in pseudo-code and has not been tested.

Calculate Position

The calculate position module serves two purposes. The function is evoked every pass though

the main loop, but does nothing unless the proper flags are set. If they are set, it determines the

robot's position. It finds its position by triangulating the distances between two known points.

-36-


Assuming that it can only be on one side of the beacons, it can determine its position. If the

correction flag is set, it will calculate new speeds for the right and left wheels to correct its

heading. It will only try to correct its path every 6 inches or 2 pixels. This is because the

resolution is not good enough and more frequent correction attempts will likely give conflicting

results. Using the current, previous and target positions, the robot will be able to determine how

much it should turn and subsequently update the counters used to trigger the stepper motors. The

positioning algorithm has been written for the embedded system but still needs to be tested. This

algorithm is based off of information from a previous beacon system [44]. Figure A2 shows the

flowchart for calculating the position. The correction algorithm has been coded and tested with

known solutions on a PC. That code needs to be transferred to the microcontroller.

Drive Motors

Figure A3 shows the drive motors function which decrements values for the right and left motors

until they reach zero. When either reaches zero, it steps the motors and resets the counters. The

counters represent the rate at which each motor steps. Different rates will cause the robot to turn.

When the left wheel steps, a global counter is decremented which is used to tell the spray cans

function when it should have reached the next pixel. This function is written, but has not yet

been tested because the stepper motor circuit is not finished. Originally the robot was going to

be driven by 6-wire unipolar stepper motors, but will instead be powered by 4-wire bipolar

stepper motors. This setup requires an H-bridge. The robot will implement a circuit that will

require the robot to simply shift a single asserted bit through its 4-bit output [45].

Spray Cans

The spray cans function, depicted in Figure A4, reads the pixels one at a time and keeps track of

the robots position throughout the file. If it reaches the end of the file, it exits and waits until the

PC sends a new file. If it is at the end of a row, it shifts down a row and then reverses direction

and starts on the next row. This function will call the position correction code at regular

intervals and also when shifting down a row. The reason why the position correction code is

called from this function is because the spray cans function will know when the robot is at the

end of the row. This is the most important time for the robot to change its course because it has

to be done. Also, the robot will correct its position every few pixels. This function is written but

has not been tested.

Ping

-37-


The ping function sends out a frequency modulated encoded infrared signal to the beacon. This

is used to specifically address a single beacon at a time. This address consists of 6 bits. The first

three are start bits (010) followed by a two bit address and a parity bit. This code has written and

tested. It shows the correct output, but has not yet been tested with the beacons. This

communication is vital to the positioning system working correctly.

11.0 Version 2 Changes

A second version of the Robit would be designed with the mechanics before the

electronics. With a proper drive train and motors, the reliability of the spray would be greatly

increased. Additionally, instead of discrete spray cans, the design would benefit from a paint

mixing system to improve on the colors available for us. If it were to go into commercial

production, we would replace the beacon system with a differential GPS position system for

much more accurate positioning without the requirement for the users to place beacons before

the spraying begins.

12.0 Summary and Conclusions

Completing the Robit project taught the entire team the difficulties in completing a large scale

design from scratch. The entire process was foreign to the team from picking parts to laying

them out to actually getting things working. It has been the first experience we’ve had in tying

together years of theory into something that has to work.

13.0 References

[1] Rabbit Semiconductors, RCM 3700 Microcontroller Datasheet, April 2006, http://www.rabbitsemiconductor.com/products/rcm3700/rcm3700.pdf

[2] Freescale Semiconductor, MC9S12NE64 Datasheet, April 2006, http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC9S12NE64V1.pdf

[3] Microchip Technology Inc., PIC16C62B Datasheet, April 2006, http://ww1.microchip.com/downloads/en/DeviceDoc/35008b.pdf

[4] Atmel Corporation, ATmega8 Datasheet, April 2006, http://www.atmel.com/dyn/resources/prod_documents/doc2486.pdf

-38-

http://www.atmel.com/dyn/resources/prod_documents/doc2486.pdf

http://ww1.microchip.com/downloads/en/DeviceDoc/35008b.pdf

http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC9S12NE64V1.pdf

http://www.rabbitsemiconductor.com/products/rcm3700/rcm3700.pdf


[5] Cypress Semiconductor, CY7C1041CV33 Datasheet, April 2006, http://rocky.digikey.com/WebLib/Cypress/Web%20Data/CY7C1041CV33.pdf

[6] Cypress Semiconductor, CY7C1367A Datasheet, April 2006, http://rocky.digikey.com/WebLib/Cypress/Web%20Data/CY7C1366A,67A_%20GVT71256C,512C.pdf

[7] Anaheim Automation, D Series Standard Step Motors, April 2006, http://www.anaheimautomation.com/standard.htm

[8] Lin Engineering, Model 5718 High Torque Motor, April 2006, http://www.linengineering.com//site/products/5718.html

[9] Defender Industries Inc., Deep Cycle Marine Battery, April 2006, http://www.defender.com/product.jsp?path=-1|328|51495|306219&id=51496

[10] Yuasa Battery Inc., Yuasa Batteries http://www.yuasabatteries.com/yuasa05/battery.asp?bID=B6&vID=567

[11] D.G Meyer, “Module 10: Patent Infringement Liability,” 2006 [Online]. Available: http://shay.ecn.purdue.edu/~dsml/ece477/Notes/PDF/4-Mod10.pdf

[12] H. Kanda and Y. Nakagawa, “Ink-jet printing method and apparatus,” U.S. Patent 6,702,415, March 9, 2004. Available: http://patft.uspto.gov/netacgi/nph-Parser?u=/netahtml/srchnum.htm&Sect1=PTO1&Sect2=HITOFF&p=1&r=1&l=50&f=G&d=PALL&s1=6702415.WKU.&OS=PN/6702415&RS=PN/6702415

[13] T. Smrt, “Apparatus for remotely discharging the contents of an aerosol container,” U.S. Patent 5,709,321, January 20, 1998. Available: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=/netahtml/search-adv.htm&r=5&f=G&l=50&d=PTXT&p=1&p=1&S1=3,485,206&OS=3,485,206&RS=3,485,206

[14] K. Tanaka, “Navigation method and system for autonomous machines with markers defining the working area,” U.S. Patent 6,850,024, February 15, 2005. Available: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=ptxt&s1=6,856,630&OS=6,856,630&RS=6,856,630

[15] Reliability Prediction of Electronic Equipment, MIL-HDBK-217F, April 2006, http://shay.ecn.purdue.edu/~dsml/ece477/Homework/Spr2006/Mil-Hdbk-217F.pdf

[16] George Novacek, ”Designing for Reliability, Maintainability, and Safety,” April 2006, http://shay.ecn.purdue.edu/~dsml/ece477/Notes/PDF/4-Mod13_ref.pdf

-39-

http://shay.ecn.purdue.edu/~dsml/ece477/Notes/PDF/4-Mod13_ref.pdf

http://shay.ecn.purdue.edu/~dsml/ece477/Homework/Spr2006/Mil-Hdbk-217F.pdf

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=ptxt&s1=6,856,630&OS=6,856,630&RS=6,856,630



http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=/netahtml/search-adv.htm&r=5&f=G&l=50&d=PTXT&p=1&p=1&S1=3,485,206&OS=3,485,206&RS=3,485,206



http://patft.uspto.gov/netacgi/nph-Parser?u=/netahtml/srchnum.htm&Sect1=PTO1&Sect2=HITOFF&p=1&r=1&l=50&f=G&d=PALL&s1=6702415.WKU.&OS=PN/6702415&RS=PN/6702415



http://shay.ecn.purdue.edu/~dsml/ece477/Notes/PDF/4-Mod10.pdf

http://www.yuasabatteries.com/yuasa05/battery.asp?bID=B6&vID=567

http://www.defender.com/product.jsp?path=-1%7C328%7C51495%7C306219&id=51496

http://www.linengineering.com/site/products/5718.html

http://www.anaheimautomation.com/standard.htm

http://rocky.digikey.com/WebLib/Cypress/Web%20Data/CY7C1366A,67A_%20GVT71256C,512C.pdf

http://rocky.digikey.com/WebLib/Cypress/Web%20Data/CY7C1366A,67A_%20GVT71256C,512C.pdf

http://rocky.digikey.com/WebLib/Cypress/Web%20Data/CY7C1041CV33.pdf


[17] Linear LT1940 Data Sheet, April 2006, http://www.ortodoxism.ro/datasheets/lineartechnology/1940fa.pdf

[18] Fairchild TIP-122 Data Sheet, April 2006, http://www.fairchildsemi.com/ds/TI/TIP122.pdf

[19] Linear LTC1983-5 Data Sheet, April 2006, http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1039,C1133,P2152,D2135

[20] Fairchild LM2931A Data Sheet, April 2006, http://www.fairchildsemi.com/ds/LM/LM2931A.pdf

[21] NIEE Code of Ethics, April 2006, http://www.niee.org/EthicsPrinciples.htm

[22] Operating motors in wet or damp, April 2006, http://www.motorsanddrives.com/cowern/motorterms26.html

[23] Harmful effects of Spray Cans, April 2006, http://www.acfr.usyd.edu.au/ohsrm/docs/workcover/Guide%20to%20Spray%20Painting%20(spray_painting).pdf

[24] Harmful effect of Spray Paints, April 2006, http://eartheasy.com/live_nontoxic_paints.htm

[25] Printed Circuit Board Fact Sheet, April 2006, http://www.p2pays.org/ref/10/09835.htm

[26] Pollution Prevention Opportunities in Printed Circuit Board, April 2006, http://www.p2pays.org/ref/03/02982.pdf

[27] Lead Free Soldering, April 2006, http://www.aimsolder.com/leadfree_tdss.cfm?product=accessoryproducts

[28] EC Safety Data Sheet, April 2006, http://www.kavousa.com/downloads/msds/04117630.pdf

[29] Alternatives to Lead-Acid Batteries, April 2006, http://www.cleancarcampaign.org/FactSheet_BatteryAlts.pdf

[30] Recycling Printed Circuit Boards, April 2006, http://p2library.nfesc.navy.mil/P2_Opportunity_Handbook/2_II_8.html

[31] Recycling Lead Acid Batteries, April 2006, http://p2library.nfesc.navy.mil/P2_Opportunity_Handbook/2_II_7.html

-40-

http://p2library.nfesc.navy.mil/P2_Opportunity_Handbook/2_II_7.html

http://p2library.nfesc.navy.mil/P2_Opportunity_Handbook/2_II_8.html

http://www.cleancarcampaign.org/FactSheet_BatteryAlts.pdf

http://www.kavousa.com/downloads/msds/04117630.pdf

http://www.aimsolder.com/leadfree_tdss.cfm?product=accessoryproducts

http://www.aimsolder.com/leadfree_tdss.cfm?product=accessoryproducts

http://www.p2pays.org/ref/03/02982.pdf

http://www.p2pays.org/ref/10/09835.htm

http://eartheasy.com/live_nontoxic_paints.htm

http://www.acfr.usyd.edu.au/ohsrm/docs/workcover/Guide%20to%20Spray%20Painting%20(spray_painting).pdf

http://www.acfr.usyd.edu.au/ohsrm/docs/workcover/Guide%20to%20Spray%20Painting%20(spray_painting).pdf

http://www.motorsanddrives.com/cowern/motorterms26.html

http://www.niee.org/EthicsPrinciples.htm

http://www.fairchildsemi.com/ds/LM/LM2931A.pdf

http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1039,C1133,P2152,D2135

http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1039,C1133,P2152,D2135

http://www.fairchildsemi.com/ds/TI/TIP122.pdf

http://www.ortodoxism.ro/datasheets/lineartechnology/1940fa.pdf


[32] “Bikes Against Bush,” April 2006, http://a.parsons.edu/~jk/thesis/vital_info.html

[33] Workman Mobile Robot by Kadtronix, April 2006, http://www.kadtronix.com/workman.htm

[34] Plexiglashttp://www.professionalplastics.com/cgi-bin/pp.pl

[35] Powersports X5LB Batteryhttp://www.batterystuff.com/power-sports-battery/X5LB.html

[36] Molex 48025-0001, April 2006, http://www.newproduct.molex.com/datasheet.aspx?PN=480250001&PRODUCTID=120645&BV_SessionID=@@@@0389351921.1140767952@@@@&BV_EngineID=cccgaddhdkijgfmcflgcehedffgdfmk.0&num=1301

[37] Kobitone Audio, 255-400SR16-RO / 255-400ST16-RO Datasheet, April 2006, http://www.mouser.com/catalog/specsheets/KT-400244.pdf

[38] Vishay Semiconductors, TSOP11.. Datasheet, April 2006, http://www.vishay.com/docs/82006/82006.pdf

[39] Atmel, ATF22LV10CZ PLD Datasheet, April 2006, http://www.atmel.com/dyn/resources/prod_documents/doc0779.pdf

[40] STM Electronics, TIP120 Datasheet, April 2006, http://www.st.com/stonline/products/literature/ds/4128/tip120.pdf

[41] National Semiconductor, LM6152 Datasheet, April 2006, http://www.national.com/ds.cgi/LM/LM6152.pdf

[42] Vishay semiconductor, TSAL 7400 Datasheet, April 2006, http://www.vishay.com/doc?81014

[43] STM Electronics, L603 Datasheet, April 2006, http://www.st.com/stonline/products/literature/ds/1370/l603.pdf

[44] Jaakko Ala-Paavola, Location Beacon, April 2006 http://vodka.tky.hut.fi/~jap/Eurobot/doc/beacon.htm l

[45] Art Theremin, Bipolar Stepper Motor Control Circuit, April 2006 http://home.att.net/~theremin1/Circuit_Library/bioplar_stepper_motor.htm

-41-

http://home.att.net/~theremin1/Circuit_Library/bioplar_stepper_motor.htm

http://vodka.tky.hut.fi/~jap/Eurobot/doc/beacon.html

http://www.st.com/stonline/products/literature/ds/1370/l603.pdf

http://www.vishay.com/doc?81014

http://www.national.com/ds.cgi/LM/LM6152.pdf

http://www.st.com/stonline/products/literature/ds/4128/tip120.pdf

http://www.atmel.com/dyn/resources/prod_documents/doc0779.pdf

http://www.vishay.com/docs/82006/82006.pdf

http://www.mouser.com/catalog/specsheets/KT-400244.pdf

http://www.newproduct.molex.com/datasheet.aspx?PN=480250001&PRODUCTID=120645&BV_SessionID=@@@@0389351921.1140767952@@@@&BV_EngineID=cccgaddhdkijgfmcflgcehedffgdfmk.0&num=1301



http://www.batterystuff.com/power-sports-battery/X5LB.html

http://www.professionalplastics.com/cgi-bin/pp.pl

http://www.kadtronix.com/workman.htm

http://a.parsons.edu/~jk/thesis/vital_info.html


Appendix A: Individual Contributions

A.1 Contributions of Clark Malmgren:

For the project, I served as the project leader. So this position required me to not only

assign general parts of the project to group members, but also required me to span both the

software and hardware aspects of the design to not only accomplish my own work, but to assist

others and answer general design questions.

My original area of expertise was software, but as the project progressed, I worked on

large parts of the hardware design as well. I found and ordered components that met the

criterion of our project that were also cost effective. I designed a large majority of the schematic

for the main board as well as the entire schematic for the beacon board. I designed the PCB for

the beacons and created custom footprints for the main PCB. When the PCB’s arrived, I

soldered many of the parts including the microcontroller, power supply, and sonar amplification

circuits. I also tested many of the subsystems on breadboards. I made several trips to get

components for the robot as well as made countless part orders. I mounted the motors and redid

the drive chain several times. I also did a rebuild of the 5 and 3.3 volt power supply circuits. I

was also involved with a lot of the wiring and implementation of the robot.

I wrote the PC side software to create a direction file from a bitmap image. I later

expanded the program to include 8-bit as well as true-color images. I wrote all of the software

for both the beacon and main microcontroller except for the Ethernet controller code. I wrote the

code to generate the proper 38 kHz PWM encoded infrared signals. I also wrote the algorithm to

interpret it. I wrote the code to step the motors as well as print the image itself.

A.2 Contributions of Andy Brezinsky:

I was responsible for all of the hardware used on the Robit, including the physical

construction of the robot frame and the PCB. I handle the creation of the main PCB and

corrected a number of issues with the schematic. Once the board arrived I assisted in the

population and handled the debugging of the complex circuits including the op-amp and the

beacon arrays. I ordered all of the major components including the motors and the solenoids and

traveled many times to home depot to pickup the necessary parts to construct the Robit.

A-1


I handled the rebuild of the Robit when we determined that it was too big and built the

new motor controllers when we found that the motors were of the wrong type. I also handled the

debugging of the drive train system.

I assisted Clark with the software by writing the web server component and providing

a second opinion when necessary with the rest of the software coding.

A.3 Contributions of Prashant Garimella:

In this project 2-bit Robit, I have worked on the hardware and software

implementation. I worked on creating the schematics for the majority of our components and

assisted my team members in creating the layout for our PCB. I also worked with Tim in

developing software for the PC and microcontroller.

In the beginning of the semester, I assisted my team in selecting the different parts and

components which would be appropriate for our project. After selecting all the major

components, I started to design schematics for our project with the help of Tim. While doing the

schematic, we had to revise our schematics a couple of times, as some of the components were

changed or dropped. After creating schematics, I also assisted my team in creating the custom

footprints for some of our components.

I also worked on the software development for our project. Along with Tim, I worked

in developing conversion software for creating a direction file for the user selected image. My

main focus was to read the image file in terms of pixels and go through each pixel and determine

the four most common colors in the whole image. I decided to use Matlab to write the algorithms

as the software had built–in functions to read the image files and convert them into matrices of

pixels. I wrote the algorithm in Matlab which stored the RGB pixel values of the common colors

in three different output files. Since we needed the direction file in binary format, Tim and I

wrote a separate algorithm in C that reads the three output files and generated the direction file

from it. Clark too had developed image processing algorithm, and we decided that we would use

his simple algorithm compared to our complex code.

I also worked along with Tim, in developing a code for SPI communication between

the 2M serial flash and the microcontroller using the Code Warrior software. It was a productive

learning experience for me to write embedded software using Code Warrior.

A-2


Apart from that, I also worked on Circuit Design and Theory of Operation, and Ethical

and Environmental Analysis homework. I also worked with Tim to develop the Final Design

Report, ECE Senior Design Report and User Manual.

A.4 Contributions of Tim Sendgikoski:

My contributions to the 2-Bit Robit project involved both the hardware and software

systems. On the hardware end, I did work on both the schematic and PCB. For software, I

worked closely with Prashant to develop software for the PC and for the microcontroller. Also, I

completed the requisite two homework assignments, as well as some other documentation.

Earlier in the semester, I worked with Prashant in designing the original schematic.

After we received the parts list from Andy & Clark, as well as a schematic component for the

microcontroller which Clark was kind enough to make, we worked on the initial schematics for

the Robit. This process went through several revisions as some components were changed or

altogether dropped. After the schematic was finished, we handed it off to Andy & Clark to do

the PCB layout. However, during the PCB layout, I was asked to create custom footprints for a

number of our components. After getting some help from Brian, I created all the necessary

footprints and encapsulated them in a library. Later, after we received the physical PCB, I

performed a cursory visual inspection as well as ‘ohming out’ much of the board.

On the software side of things, I started by working with Prashant on an early version

of the software for converting an image file into a direction file. We came up with some image

processing algorithms in MatLab for the purpose of simplifying the image and finding the most

common colors. After that, we moved on to C code where we began work on reading the

MatLab output and choosing the most common colors so that the user can best select paint colors

to use. By the time we were generating an output file, it was decided that this method, although

effective in getting an accurate recreation of the image, was too convoluted. As such, this

system was scrapped in favor of a simpler one-step program developed by Clark.

Later, I again teemed up with Prashant to develop code. This time we were working

on some embedded C for the microcontroller to control the serial FLASH module. Doing this

required us to learn a bit about CodeWarrior as well as how to do embedded C. Overall it was,

A-3


to me, one of the more satisfying parts of the project as it let me take something I already knew

(C coding) and apply it in a new arena which I had some interest in (embedded applications).

The two homework papers I was assigned were the Printed Circuit Board and the

Reliability and Safety Analysis. Both papers developed into interesting challenges as I had to

learn new skills to complete each. Although, in the end, I did not do the PCB layout, I did still

make use of the software for designing the custom footprints (as previously mentioned). I wrote

the PCB paper based on information given to me by Andy. For the Reliability and Safety

Analysis homework, I had to learn to use the MIL handbook [15] for probability of failure

analyses.

My final contributions to the team were my work on the final report and user manual.

As the end of the semester neared, it was decided that Prashant and I should work on the

documentation while Andy and Clark worked on debugging the Robit. I took the final report,

giving Prashant the final design report, and we decided to split the user manual. For the user

manual, I filled in an outline and contributed some questions for the product debugging section.

In writing the final report, I have done all of the compilation except for sections 8, 11, and 12,

the individual member contributions, and the software listing appendix.

A-4


Appendix B: Packaging

Figure B-1. Product Packaging

B-1


Appendix C: Schematic

Figure C-1. Schematic, Main Microcontroller and Peripherals

C-1


Figure C-2. Schematic, Power Supply and Solenoid/Motor Control

C-2


Figure C-3. Schematic, IR/Sonar Systems

C-3


Appendix D: PCB Layout Top and Bottom Copper

Figure D-1. Main Board PCB Layout Top Copper with Silk Screen

D-1


Figure D-2. Main Board PCB Layout Bottom Copper with Silk Screen

D-2


Figure D-3. Beacon PCB Top Layer with Silk Screen

Figure D-4. Beacon PCB Bottom Layer with Silk Screen

D-3


Vendor Manufacturer Part No. Description Unit Cost Qty Total CostDigi-Key Freescale MC9S12NE64CPV 16-bit Microcontroller 8.22 1 $8.22Digi-Key Atmel ATmega8-16PI 8-bit RISC Microcontroller 3.66 3 $10.98Control Sales, Inc. Lin Engineering 5718L-01S 1.8º Stepper Motor 108.00 2 $216.00Tri-State Battery Yuasa YTX5L-BS Motorcycle Battery 29.95 1 $29.95Mouser Kibitone 255-400ER18 Ultrasonic Transducer 40 kHz Receive 7.25 1 $7.25Mouser Kibitone 255A-400ET18 Ultrasonic Transducer 40 kHz Transmit 3.70 2 $7.40Mouser Fairchild Semiconductor F5E2 Infrared Emitting Diode 2.51 9 $22.59Digi-Key Fairchild Semiconductor BPW37 Hermetic Silicon Phototransistor 1.65 3 $4.95

TOTAL $307.34Appendix E: Parts List Spreadsheet

E-1


Appendix F: Software Listing

Main.c – Program which handles all the main functions of the system

/****************************************************************************** * * (c) Freescale Inc. 2004 All rights reserved * * File Name : main.c * Description : * * Version : 1.0 * Date : Jun/22/2004 * ******************************************************************************//* Including used modules for compilling procedure */#include "debug.h"#include "datatypes.h"#include "timers.h"#include "system.h"#include "ethernet.h"#include "arp.h"#include "ip.h"#include "tcp_ip.h"

#include "http_server.h"#include "smtp_client.h"

#include "ne64driver.h"#include "ne64api.h"#include "mBuf.h"#include "ne64config.h"#include "udp_demo.h"

#include "address.h"

#include "MC9S12NE64.h"

/* Network Interface definition. Must be somewhere so why not here? :-)*/struct netif localmachine;

extern void RTI_Enable (void);

extern tU16 gotxflowc; /* Global Variable For Determination of Flow Control Packets are sent in Full Duplex */extern tU08 gotlink; /* Global Variable For Determination if link is active */

#if ZERO_COPY#else tU08 ourbuffer [1518]; /**< Space for packet temporary storage if zero copy not used*/#endif

#if USE_SWLEDtU16 LEDcounter=0;#endif

#define MAX_ROW 38

F-1


#define MAX_COL 32#define MAX_STP 1000#define STP_DIF 200#define PIX_STP 105

typedef union { byte whole; struct { byte one : 4; byte two : 4; } each;} PIX;

/* My Global Variables */char pinging;word p_start;word p_stop;

const PIX data[MAX_ROW*MAX_COL/2] = { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x80,0x88,0x88,0x88,0x88,0x88,0x88,0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x80,0x00,0x00,0x00,0x00,0x00,0x00,0x88,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x80,0x00,0x00,0x00,0x00,0x00,0x00,0x80,0x08,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x80,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x88,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x80,0x99,0x11,0x91,0x99,0x99,0x19,0x00,0x80,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x91,0x11,0x91,0x11,0x11,0x99,0x01,0x80,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x91,0x11,0x91,0x11,0x11,0x91,0x11,0x80,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x81,0x00,0x00,0x98,0x11,0x81,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x81,0x88,0x88,0x08,0x11,0x81,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x01,0x00,0x00,0x00,0x11,0x89,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x01,0x00,0x00,0x00,0x91,0x09,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x01,0x00,0x00,0x10,0x99,0x01,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x91,0x99,0x99,0x99,0x19,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x91,0x11,0x11,0x11,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x91,0x11,0x11,0x11,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x81,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x81,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x81,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x81,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x81,0x00,0x00,0x00,0x00,0x00,0x62,0x26,0x02,0x00,0x00,0x00, 0x00,0x00,0x80,0x11,0x81,0x00,0x00,0x00,0x00,0x20,0x02,0x20,0x22,0x04,0x00,0x00, 0x00,0x80,0x88,0x11,0x81,0x88,0x00,0x00,0x00,0x00,0x00,0x00,0x22,0x04,0x00,0x00, 0x00,0x80,0x00,0x11,0x01,0x80,0x00,0x00,0x00,0x00,0x00,0x20,0x62,0x04,0x00,0x00, 0x00,0x80,0x00,0x11,0x01,0x80,0x00,0x00,0x00,0x00,0x00,0x22,0x46,0x00,0x00,0x00, 0x00,0x80,0x00,0x11,0x01,0x80,0x00,0x00,0x00,0x00,0x20,0x62,0x04,0x00,0x00,0x00, 0x00,0x80,0x99,0x99,0x99,0x89,0x00,0x00,0x00,0x00,0x22,0x46,0x00,0x00,0x00,0x00, 0x00,0x00,0x11,0x11,0x11,0x01,0x00,0x00,0x00,0x20,0x22,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x11,0x11,0x11,0x01,0x00,0x00,0x00,0x20,0x66,0x66,0x66,0x04,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}; const char STEPS[8] = {9,8,10,2,6,4,5,1};

int running;

F-2


int percent;int total_percent;int uploaded;float xposition;float yposition;

int row;int col;word step_l;word step_r;dword stp_cnt;unsigned char mot_l;unsigned char mot_r;word max_r;word max_l;char dir;

/* Function Declarations */void init_eth(void);void poll_eth(void);void step_mot(char,char);void motors(char,char);void my_init(void);dword ping(char *);void turn(void);void paint(void);

/* main stuff */void main(void){ // dword i; char addr[6] = {0x00,0xFF,0x00,0x00,0xFF,0x00}; //dword dist;

running = 1; percent = 0; uploaded = 0; init_eth(); my_init();// ping(addr);

/* main loop */ //dist = ping(addr);

for (;;){ //PORTB=0xFF; //PORTB=0x00;

poll_eth();// if (running == 1) {

step_mot(dir,dir); paint(); //turn();

// } else {// PORTA=0x00;// }

//for(;;);}

}

F-3


void paint(void) { dword i; if (stp_cnt>=PIX_STP) { // Spray PORTA=0; stp_cnt=0; if (col%2==0) { PORTB = data[row*MAX_COL/2+col/2].each.one; PORTK = data[row*MAX_COL/2+col/2].each.one;// PORTB=0x02;

} else { PORTB = data[row*MAX_COL/2+col/2].each.two; PORTK = data[row*MAX_COL/2+col/2].each.two;// PORTB=0x04; }// PORTB=0x01<<(col%4);// PORTK=0x01<<(col%4); for(i=0;i<40000;i++); PORTB=0x00; PORTK=0x00; col+=dir; if (col>=4) { row++; col--; turn(); if (row>=MAX_ROW) { running=0; } } else if (col==-1) { row++; col=0; turn(); if (row>=MAX_ROW) { running=0; } } }}

void turn(void) { int i;

while(stp_cnt<500) { step_mot(dir,dir); poll_eth(); } dir = -dir; stp_cnt=0;

for(i=0;i<300;i++){ poll_eth(); } while(stp_cnt<150) { step_mot(dir,0); poll_eth(); } stp_cnt=0;

F-4


while(stp_cnt<300) { step_mot(0,dir); poll_eth(); } stp_cnt=0; while(stp_cnt<220) { step_mot(dir,dir); poll_eth(); } stp_cnt=0;}

void step_mot(char dl, char dr) { step_l--; step_r--; if (step_l <= 0) { // move motor motors(0,dl); step_l=max_l; stp_cnt++; //stp_cnt--; } if (step_r <= 0) { // move motor motors(1,dr); step_r=max_r; }}

void motors(char mot, char n) { int i; if (mot == 1) { // step right accordingly PORTA=PORTA&0xF0; mot_r=((unsigned char)(mot_r+n))%8; for(i=0;i<100;i++); PORTA=PORTA|STEPS[mot_r]; } else { // step right accordingly PORTA=PORTA&0x0F; mot_l=((unsigned char)(mot_l+n))%8; for(i=0;i<100;i++); PORTA=PORTA|(STEPS[mot_l]<<4); }}

dword ping(char *addr) { int i,j; dword k; dword waste; pinging = 0xFF; p_start = 0; p_stop = 0; for(i=0;i<6;i++) { if(addr[i] == 0x00) { for(j=0;j<18;j++) { waste++; PTG = 0xFF; for(k=0;k<8;k++);

F-5


waste++; PTG = 0x00; for(k=0;k<8;k++); }

for(k=0;k<665;k++); } else { for(j=0;j<36;j++) { waste++; PTG = 0xFF; for(k=0;k<8;k++); waste++; PTG = 0x00; for(k=0;k<8;k++); } for(k=0;k<336;k++); } } //for(k=0;k<2;k++); //while(pinging!=0); return waste;}

void my_init(void) { /* Motor Initilization */ row=3; col=0; step_l=0; step_r=0; stp_cnt=0; mot_l=1; mot_r=0; max_r=MAX_STP; max_l=MAX_STP; dir=1; running=0; /* PORT A Initialization */ DDRA = 0xFF; // Output PORTA = 0x00; // Initialize /* PORT B Initialization */ DDRB = 0xFE; // Output PORTB = 0x00; // Initialize /* PORT K Initialization */ DDRK = 0xFF; // Output PORTK = 0x00; // Initialize /* PORT G Initialization */ DDRG = 0xFF; // Output RDRG = 0x00; // No Reduced Drive PERG = 0x00; // No Pull Device PIEG = 0x00; // No Interupts PTG = 0x00; // Initialize /* PORT H Initialization */ DDRH = 0x00; // Output 7:5, Input 4:0 RDRH = 0x00; // No Reduced Drive PERH = 0x00; // No Pull Device PPSH = 0x00; // The IR is falling edge triggered PIEH = 0x0F; // 5:0 Has interrupts /* Timer Initialization */

F-6


TSCR1 = 0x80; TSCR2 = 0x07;}

interrupt void ReallyDum_Interrupt(void) { if (PIFH_PIFH4==1) { // sonar if (PTH_PTH4==1) { p_stop = TCNT; pinging = 0x00; PIFH_PIFH4 = 1; } } else { // infrared //p_start = TFLG2; p_start = TCNT; PIFH = 0x0F; }}

//==================================================//=========DEMO SUPPORT ============================//==================================================//#pragma CODE_SEG NON_BANKED//interrupt void PortHInterrupt (void) { for(;;); }//#pragma CODE_SEG DEFAULT

//==================================================//==================================================

void init_eth(void) { /* System clock initialization */ CLKSEL=0; CLKSEL_PLLSEL = 0; /* Select clock source from XTAL */ PLLCTL_PLLON = 0; /* Disable the PLL */ SYNR = 0; /* Set the multiplier register */ REFDV = 0; /* Set the divider register */ PLLCTL = 192; PLLCTL_PLLON = 1; /* Enable the PLL */ while(!CRGFLG_LOCK); /* Wait */ CLKSEL_PLLSEL = 1; /* Select clock source from PLL */

INTCR_IRQEN = 0; /* Disable the IRQ interrupt. IRQ interrupt is enabled after CPU reset by default. */

/* initialize processor-dependant stuff (I/O ports, timers...). * Mostimportant things to do in this function as far as the TCP/IP stack * is concerned is to: * - initialize some timer so it executes decrement_timers * on every 10ms (TODO: Throw out this dependency from several files * so that frequency can be adjusted more freely!!!) * - not mess too much with ports allocated for Ethernet controller */

init();

/* Set our network information. This is for static configuration. * if using BOOTP or DHCP this will be a bit different. */ /* IP address */ localmachine.localip = *((UINT32 *)ip_address); /* Default gateway */

F-7


localmachine.defgw = *((UINT32 *)ip_gateway); /* Subnet mask */ localmachine.netmask = *((UINT32 *)ip_netmask);

/* Ethernet (MAC) address */ localmachine.localHW[0] = hard_addr[0]; localmachine.localHW[1] = hard_addr[1]; localmachine.localHW[2] = hard_addr[2]; localmachine.localHW[3] = hard_addr[3]; localmachine.localHW[4] = hard_addr[4]; localmachine.localHW[5] = hard_addr[5];

/* Init system services */ timer_pool_init();

/* Initialize all buffer descriptors */mBufInit ();

/*interrupts can be enabled AFTER timer pool has been initialized */ /* Initialize all network layers */ EtherInit(); __asm CLI; /* Enable Interrupts */

#if USE_EXTBUS ExternalBusCfg();#endif arp_init(); (void)udp_init(); (void)tcp_init();

/* Initialize applications */ (void)https_init ();smtpc_init ();(void)udp_demo_init();

RTI_Enable ();}

void poll_eth(void) { INT16 len; /* take care of watchdog stuff */ #if USE_SWLED UseSWLedRun(); #endif if (gotlink) { /* Try to receive Ethernet Frame */ if( NETWORK_CHECK_IF_RECEIVED() == TRUE )

{ switch( received_frame.protocol)

{ case PROTOCOL_ARP:

process_arp (&received_frame); break; case PROTOCOL_IP: len = process_ip_in(&received_frame);

if(len < 0) break; switch (received_ip_packet.protocol)

{

F-8


case IP_ICMP: process_icmp_in (&received_ip_packet, len);

break; case IP_UDP: process_udp_in (&received_ip_packet,len);

break; case IP_TCP: process_tcp_in (&received_ip_packet, len); break; default: break; } break;

default: break;

} /* discard received frame */

NETWORK_RECEIVE_END(); }

/* Application main loops */ /* manage arp cache tables */ arp_manage(); /* TCP/IP stack Periodic tasks here... */ (void)udp_demo_run();

/* manage opened TCP connections (retransmissions, timeouts,...)*/ tcp_poll();

https_run (); smtpc_run();

}}

Vectors.c – Vectors for interrupts

/****************************************************************************** * * (c) Freescale Inc. 2004 All rights reserved * * File Name :Vectors.c * Description : * * Version : 1.0 * Date : Jun/22/2004 * ******************************************************************************/

extern void near _Startup(void); /* Startup routine */extern void near RealTimeInterrupt(void); extern void near emac_ec_isr(void);extern void near emac_lc_isr(void);extern void near emac_b_rx_error_isr(void);extern void near emac_rx_b_b_o_isr(void);extern void near emac_rx_b_a_o_isr(void);extern void near emac_rx_error_isr(void);extern void near emac_mii_mtc_isr(void);extern void near emac_rx_fc_isr(void);extern void near emac_f_tx_c_isr(void);extern void near emac_rx_b_b_c_isr(void);extern void near emac_rx_b_a_c_isr(void);

F-9


extern void near ephy_isr(void);extern void near ReallyDum_Interrupt(void);

//************************************************************************// SOFTWARE TRAP FUNCTION// DESCRIPTION:// Function that traps all unexpected interrupts. Used for debugging // software to find runaway code.//************************************************************************

#pragma CODE_SEG __NEAR_SEG NON_BANKED /* Interrupt section for this module. Placement will be in NON_BANKED area. */ __interrupt void software_trap(void){ for(;;); }#pragma CODE_SEG DEFAULT /* Change code section to DEFAULT. */

//************************************************************************

typedef void (*near tIsrFunc)(void);const tIsrFunc _vect[] @0xFF80 = { /* Interrupt table */ software_trap, /* 0 Default (unused) interrupt */ software_trap, /* 1 Default (unused) interrupt */ software_trap, /* 2 Default (unused) interrupt */ software_trap, /* 3 Default (unused) interrupt */ software_trap, /* 4 Default (unused) interrupt */ software_trap, /* 5 Default (unused) interrupt */ software_trap, /* 6 Default (unused) interrupt */ software_trap, /* 7 Default (unused) interrupt */ software_trap, /* 8 Default (unused) interrupt */ software_trap, /* 9 Default (unused) interrupt */ software_trap, /* 10 Default (unused) interrupt */ software_trap, /* 11 Default (unused) interrupt */ software_trap, /* 12 Default (unused) interrupt */ software_trap, /* 13 Default (unused) interrupt */ software_trap, /* 14 Default (unused) interrupt */ software_trap, /* 15 Default (unused) interrupt */ emac_ec_isr, emac_lc_isr, emac_b_rx_error_isr, emac_rx_b_b_o_isr, emac_rx_b_a_o_isr, emac_rx_error_isr, emac_mii_mtc_isr, emac_rx_fc_isr, emac_f_tx_c_isr, emac_rx_b_b_c_isr, emac_rx_b_a_c_isr, ephy_isr, software_trap, /* 28 Default (unused) interrupt */ software_trap, /* 29 Default (unused) interrupt */ software_trap, /* 30 Default (unused) interrupt */ software_trap, /* 31 Default (unused) interrupt */ software_trap, /* 32 Default (unused) interrupt */ software_trap, /* 33 Default (unused) interrupt */ software_trap, /* 34 Default (unused) interrupt */ software_trap, /* 35 Default (unused) interrupt */ software_trap, /* 36 Default (unused) interrupt */ software_trap, /* 37 Default (unused) interrupt */ ReallyDum_Interrupt, /* 38 Default (unused) interrupt */ software_trap, /* 39 Default (unused) interrupt */ software_trap, /* 40 Default (unused) interrupt */ software_trap, /* 41 Default (unused) interrupt */ software_trap, /* 42 Default (unused) interrupt */

F-10


software_trap, /* 43 Default (unused) interrupt */ software_trap, /* 44 Default (unused) interrupt */ software_trap, /* 45 Default (unused) interrupt */ software_trap, /* 46 Default (unused) interrupt */ software_trap, /* 47 Default (unused) interrupt */ software_trap, /* 48 Default (unused) interrupt */ software_trap, /* 49 Default (unused) interrupt */ software_trap, /* 50 Default (unused) interrupt */ software_trap, /* 51 Default (unused) interrupt */ software_trap, /* 52 Default (unused) interrupt */ software_trap, /* 53 Default (unused) interrupt */ software_trap, /* 54 Default (unused) interrupt */ software_trap, /* 55 Default (unused) interrupt */ RealTimeInterrupt, /* 56 Default (unused) interrupt */ software_trap, /* 57 Default (unused) interrupt */ software_trap, /* 58 Default (unused) interrupt */ software_trap, /* 59 Default (unused) interrupt */ software_trap, /* 60 Default (unused) interrupt */ software_trap, /* 61 Default (unused) interrupt */ software_trap, /* 62 Default (unused) interrupt */ _Startup /* Reset vector */ };

http_server.c – Basic webserver implementation#include"datatypes.h"#include"globalvariables.h"#include"debug.h"#include"system.h"#include"tcp_ip.h"#include"http_server.h"

UINT8 https_enabled = 0; /**< Defines whether https_init has already been invoked or not */

/** \brief Used for storing state information about different HTTP sessions * * This is an array of http_server_state structures holding various state * information about the HTTP sessions. HTTP server uses this information * to determine actions that need to be taken on sockets. */struct http_server_state https [NO_OF_HTTP_SESSIONS];

extern int running;

/** \brief Initialize HTTP server variables * \author * \li Jari Lahti ([email protected]) * \date 13.10.2002 * * This function should be called before the HTTP Server application * is used to set the operating parameters of it */INT8 https_init(void){

UINT8 i;INT8 soch;

for( i=0; i<NO_OF_HTTP_SESSIONS; i++)

F-11


{https[i].state = HTTPS_STATE_FREE;https[i].ownersocket = 0;https[i].fstart = 0;https[i].fpoint = 0;https[i].flen = 0;https[i].funacked = 0;

soch = tcp_getsocket(TCP_TYPE_SERVER, TCP_TOS_NORMAL, TCP_DEF_TOUT, https_eventlistener);

if(soch < 0){

DEBUGOUT("HTTP Server uncapable of getting socket\r\n");RESET_SYSTEM();/*return(-1);*/

}

https[i].ownersocket = soch;

kick_WD();

soch = tcp_listen(https[i].ownersocket, HTTPS_SERVERPORT);

if(soch < 0){

DEBUGOUT("HTTP Server uncapable of setting socket to listening mode\r\n");

RESET_SYSTEM();/*return(-1);*/

}

}

https_enabled = 1;

return(i);

}

/********************************************************************************Function: https_run

Parameters: void

Return val: void

Date: 13.10.2002

Desc: This function is main 'thread' of HTTP server programand should be called periodically from main loop.

*********************************************************************************/

void https_run (void){

UINT8 i;INT16 len;static UINT8 ses = 0;

if( https_enabled == 0)return;

F-12


/* Walk thru all sessions untill we found something to send or so */

for(i=0; i<NO_OF_HTTP_SESSIONS; i++){

kick_WD();

if(ses >= NO_OF_HTTP_SESSIONS)ses = 0;

/* Keep sockets listening */

if(tcp_getstate(https[ses].ownersocket) < TCP_STATE_LISTENING){

(void)tcp_listen(https[ses].ownersocket, HTTPS_SERVERPORT);

ses++;continue;

}

if(https[ses].state != HTTPS_STATE_ACTIVE){

ses++;continue;

}

if(https[ses].funacked != 0){

ses++;continue;

}

if(https[ses].fstart == 0){

ses++;continue;

}

/* End of data? */

if( https[ses].fpoint >= https[ses].flen){

(void)tcp_close(https[ses].ownersocket);(void)tcp_abort(https[ses].ownersocket);https_deletesession(ses);

ses++;

return;

}

/* More data to send */

len = https_loadbuffer(ses, &net_buf[TCP_APP_OFFSET], NETWORK_TX_BUFFER_SIZE - TCP_APP_OFFSET);

if(len<0)return;

len = tcp_send(https[ses].ownersocket, &net_buf[TCP_APP_OFFSET], NETWORK_TX_BUFFER_SIZE - TCP_APP_OFFSET, len);

F-13


if(len<0){

(void)tcp_close(https[ses].ownersocket);https_deletesession(ses);

ses++;

return;

}

https[ses].funacked = len;

/* Serve another session on next run */

ses++;

return;

}

}

/********************************************************************************Function: https_eventlistener

Parameters: INT8 cbhandle - handle to TCP socket where event is coming from

UINT8 event - type of eventUINT32 par1 - parameter the meaning of depends on

eventUINT32 par2 - parameter the meaning of depends on

event

Return val: INT32 - depends on event but usually (-1) is error of somekind and positive reply means

OK

Date: 13.10.2002

Desc: This function is given to TCP socket as function pointer to be

used by TCP engine to make callbacks to inform about events

on TCP e.g. arriving data. *********************************************************************************/

INT32 https_eventlistener (INT8 cbhandle, UINT8 event, UINT32 par1, UINT32 par2){

/* This function is called by TCP stack to inform about events */

INT16 i;INT16 session;int action_found = 0;par2 = 0;

F-14


if( https_enabled == 0)return(-1);

if(cbhandle < 0)return(-1);

/* Search for rigth session */

session = https_searchsession(cbhandle);

switch( event ){

case TCP_EVENT_CONREQ:

/* Do we have a session for requesting socket? */

if(session < 0)return(-1);

/* Try to get new session */

session = https_bindsession(cbhandle);

if(session < 0) /* No resources */return(-1);

return(1);

case TCP_EVENT_ABORT:

if(session < 0)return(1);

https_deletesession((UINT8)session);

return(1);

case TCP_EVENT_CONNECTED:


https_activatesession((UINT8)session);

return(1);

case TCP_EVENT_CLOSE:


https_deletesession((UINT8)session);

return(1);

case TCP_EVENT_ACK:


F-15


https[session].fpoint += https[session].funacked;https[session].funacked = 0;

return(1);

case TCP_EVENT_DATA:

/* Check for GET request */


if(https[session].fstart == 0){

if(par1 <= 3)return(1);

/* Check for GET */

if(RECEIVE_NETWORK_B() != 'G') return(1);if(RECEIVE_NETWORK_B() != 'E') return(1);if(RECEIVE_NETWORK_B() != 'T') return(1);

par1 -= 3;

/* Search for '?' */

for(i=0; i<(INT16)par1; i++){

if(RECEIVE_NETWORK_B() == '?'){

action_found = 1;break;

}}

par1 -= i;

/* someone must have requested some type of action */ if (action_found) { // THIS IS A BAD WAY TO DO THIS!!! if(RECEIVE_NETWORK_B() == 'c'){ if(RECEIVE_NETWORK_B() == 'm'){ if(RECEIVE_NETWORK_B() == 'd'){ if(RECEIVE_NETWORK_B() == '='){ if(RECEIVE_NETWORK_B() == 'S'){ if(RECEIVE_NETWORK_B() == 't'){ if(RECEIVE_NETWORK_B() == 'a'){ running = 1; // start the robit } else { running = 0; // stop the robit } } } } } } }

F-16


}

https[session].fstart = (void *)0; https[session].funacked = 0; https[session].flen = 0; https[session].fpoint = 0;

return(1);

}

return(1);

case TCP_EVENT_REGENERATE:


if(https[session].state != HTTPS_STATE_ACTIVE)return(-1);

i = https_loadbuffer((char)session, &net_buf[TCP_APP_OFFSET], (UINT16)par1);

if(i<0)return(-1);

(void)tcp_send(https[session].ownersocket, &net_buf[TCP_APP_OFFSET], NETWORK_TX_BUFFER_SIZE - TCP_APP_OFFSET, i);

return(i);

default:return(-1);

}

}

void https_deletesession (UINT8 ses){

https[ses].state = HTTPS_STATE_FREE;https[ses].fstart = 0;https[ses].fpoint = 0;https[ses].flen = 0;https[ses].funacked = 0;

}

INT16 https_searchsession (UINT8 soch){

UINT8 i;


if(https[i].ownersocket == soch)return(i);

F-17


}

return(-1);

}

INT16 https_bindsession (UINT8 soch){

UINT8 i;


if(https[i].ownersocket == soch){

if(https[i].state == HTTPS_STATE_FREE){

https[i].state = HTTPS_STATE_RESERVED;return(i);

}}

}

return(-1);

}

void https_activatesession (UINT8 ses){

https[ses].state = HTTPS_STATE_ACTIVE;

}

/* read two encoded bytes from HTTP URI and return * decoded byte */UINT8 https_read_encoded(void){

UINT8 temp,ch;

temp = RECEIVE_NETWORK_B();if ((temp>='0') && (temp<='9')){

ch = (temp-'0')<<4;} else{

if ((temp>='a') && (temp<='f')){

ch = (temp-'a'+10)<<4;}else{

ch = (temp-'A'+10)<<4;}

}

temp = RECEIVE_NETWORK_B();if ((temp>='0') && (temp<='9')){

ch |= (temp-'0');}

F-18


else{

if ((temp>='a') && (temp<='f')){

ch |= (temp-'a'+10);}else{

ch |= (temp-'A'+10);}

}return ch;

}

INT16 https_calculatehash (UINT32 len){

UINT8 hash=0;UINT8 ch;UINT8 i;

/* Read Max 60 characters */

if(len > 60)len = 60;

for( i=0; i<len; i++){

ch = RECEIVE_NETWORK_B();

if ( ch ==' ') /* End reached? */break;

/* encoded HTTP URI ? */if ( ch == '%'){

ch = https_read_encoded();

/* is this UNICODE char encoded? (for now allow only * one byte encoded UNICODE chars) */if ( ( ch & 0xe0 ) == 0xc0 ){

/* yes */ch = ( ch & 0x1F ) << 6; (void)RECEIVE_NETWORK_B(); /* skip first % */ch |= (https_read_encoded() & 0x3F);

}}

hash *= 37;hash += ch;

}

if(i==len)return(-1);

/* construct address for Hash table */

if(hash == 0) /* User asked defaul file */{

/* Set hash to index.html value */

F-19


// hash = 0x0B;

/* Set hash to index.htm value */

hash = 0x73;

}

/* Now we have hash value calculated */

return( hash );

}

https_callbacks.c –Callbacks for the http server

#include"datatypes.h"#include"debug.h"#include"globalvariables.h"#include"system.h"#include"http_server.h"#include <string.h>

#include "FileSys.h"

/** \brief File not found message * * Message that will be displayed if a file with appropriate name (hash * value) was not found. */const char https_not_found_page[] = "HTTP/1.0 200 OK\r\nLast-modified: Mon, 17 May 2004 15:02:45 GMT\r\nServer: ESERV-10/1.0\nContent-type: text/html\r\nContent-length: 400\r\n\r\n<HEAD><TITLE>Viola Systems Embedded WEB Server</TITLE></HEAD><BODY><H2>HTTP 1.0 404 Error. File Not Found</H2>The requested URL was not found on this server.<HR><BR><I>Viola Systems Embedded WEB Server 2.01, 2004<BR><A HREF=http://192.168.2.3/index.htm>Did you wish 192.168.2.3/index.htm?</I></A><BR><A HREF=http://www.violasystems.com>www.violasystems.com - Embedding The Internet</A></BODY>";

extern int running;

/** \brief Brief function description here * \author * \li Jari Lahti ([email protected]) * \date 09.10.2002 * \param hash Calculated file-name hash value. Used so that the whole * file name doesn't need to be stored in RAM * \param ses HTTP session identifier * \return * \li -1 - This function should return -1 if no file has been found * \li 1 - This function should return 1 if a file with appropriate * hash value has been found. * \warning * \li This function <b>MUST</b> be implemented by user application * to work with local configuration * * This function is invoked by the HTTP server once a hash value of a * requested file name has been calculated. User application uses this * hash value to check if appropriate file is available to web server. * Appropriate https session entry is then filled accordingly.

F-20


* */INT16 https_findfile (UINT8 hash, UINT8 ses){

/* Access the File table on FLASH with given hash key */ unsigned char file_not_found = 1; unsigned char* file_start_address = (void *)0; unsigned short file_length = 0; unsigned short file_pointer = 0; unsigned char i = 0;

/* Access the File table on FLASH with given hash key *//* and modify session File parameters */

for (i=0; FAT[i].hash; i++){

if (hash == FAT[i].hash){

file_not_found = 0;file_start_address = (unsigned char

*)FAT[i].file_start_address;file_length = FAT[i].file_length;file_pointer = 0;

}else

continue;}

if( file_not_found ){

/* File not found, initialize return message */

//https[ses].fstart = 0xFFFFFFFF;https[ses].fstart = (void *)(~0);https[ses].funacked = 0;https[ses].flen = __strlen((UINT8 *)&https_not_found_page[0],

1000);https[ses].fpoint = 0;

return(-1);}

/* OK, file found. */

/* Modify structure */https[ses].fstart = file_start_address;https[ses].flen = file_length;https[ses].fpoint = file_pointer;https[ses].funacked = 0;

return(1); }

/** \brief Fill network transmit buffer with HTTP headers&data * \author * \li Jari Lahti ([email protected]) * \date 09.10.2002 * \param ses HTTP session identifier * \param buf Pointer to buffer where data is to be stored * \param buflen Length of the buffer in bytes

F-21


* \return * \li >=0 - Number of bytes written to buffer * \warning * \li This function <b>MUST</b> be implemented by user application * to work with local configuration * * This handlers' job is to fill the buffer with the data that web server * should return back through the TCP connection. This is accomplished * based session identifer and values of variables in appropriate * https entry. */INT16 https_loadbuffer (UINT8 ses, UINT8* buf, UINT16 buflen) {

UINT16 i; UINT16 buffsize; char *temp_buf; UINT8 temp_buf_len=0;

const char robit_header[] = "HTTP/1.0 200 OK\r\nLast-modified: Mon, 17 May 2004 15:02:45 GMT\r\nServer: ESERV-10/1.0\nContent-type: text/html\r\nContent-length: 400\r\n\r\n<HEAD><TITLE>ROBIT!!!</TITLE></HEAD><BODY><h2>Robit Mission Control</h2>"; const char robit_footer[] = "</BODY></HTML>"; const char robit_main_page_prestatus[] = "<h3>Robit Status</h3><ul>"; const char robit_main_page_poststatus[] = "</ul><h3>Control</h3><form method=get><input type=submit name=cmd value=Start><input type=submit name=cmd value=Stop></form>";

const char robit_running_yes[] = "<li>Running: Yes</li>";const char robit_running_no[] = "<li>Running: No</li>";

// if( https[ses].fstart == 0xFFFFFFFF )/*

if( https[ses].fstart == (void *)(~0) ){

kick_WD();

for(i=0; i < (https[ses].flen - https[ses].fpoint); i++){

if(i >= buflen)break;

*buf++ = https_not_found_page[https[ses].fpoint + i];

}

return(i);

}*/

buffsize = 0;

// Put our header infor (i=0; i< __strlen((UINT8 *)&robit_header[0], 1000); i++){ if(i+buffsize >= buflen)

break; *buf++ = robit_header[i];}buffsize += i;

for (i=0; i< __strlen((UINT8 *)&robit_main_page_prestatus[0], 1000); i++){ if(i+buffsize >= buflen)

F-22


break; *buf++ = robit_main_page_prestatus[i];}

buffsize += i; if (running == 1) { temp_buf = &robit_running_yes; temp_buf_len = __strlen((UINT8 *)&robit_running_yes[0],1000); } else { temp_buf = &robit_running_no; temp_buf_len = __strlen((UINT8 *)&robit_running_no[0],1000); } for (i=0; i< temp_buf_len; i++){ if(i+buffsize >= buflen)

break; *buf++ = temp_buf[i];}

buffsize += i; /*static int running; static int percent; static int total_percent; static int uploaded; static float xposition; static float yposition; */

kick_WD();

for (i=0; i< __strlen((UINT8 *)&robit_main_page_poststatus[0], 1000); i++){ if(i+buffsize >= buflen)

break; *buf++ = robit_main_page_poststatus[i];}

buffsize += i;

// Last, our footerfor (i=0; i< __strlen((UINT8 *)&robit_footer[0], 1000); i++){ if(i+buffsize >= buflen)

break; *buf++ = robit_footer[i];}buffsize += i;

/* Access some storage media (internal/external flash...)*//*for(i=0; i < (https[ses].flen - https[ses].fpoint); i++){

if(i >= buflen)break;

;

*buf++ = https[ses].fstart[ https[ses].fpoint + i ];

}*/

return(buffsize);}

F-23


beacon.c – Beacon code

/*****************************************************This program was produced by theCodeWizardAVR V1.24.8 StandardAutomatic Program Generator© Copyright 1998-2006 Pavel Haiduc, HP InfoTech s.r.l.http://www.hpinfotech.com

Project : 2-Bit Robit BeaconVersion : 1.0Date : 03/29/2006Author : Clark MalmgrenCompany : Purdue University Comments:

Chip type : ATmega8LProgram type : ApplicationClock frequency : 8.000000 MHzMemory model : SmallExternal SRAM size : 0Data Stack size : 512*****************************************************/

#include <mega8.h>#include <delay.h>

// Declare your global variables here

void main(void){// Declare your local variables here int i=0; int j=0; int sum=0; int buff[240]; int code;

DDRB=0xFF; DDRC=0x1F; DDRD=0xFF;

while (1) { code=0; PORTD=0x00; PORTB=0x00; while (PINC.5==1) {} for(i=0;i<240;i++) { buff[i]=PINC.5; for(j=0;j<12;j++); sum++; sum++; } for(i=0;i<6;i++) { sum = 0; for (j=0;j<40;j++)

F-24


{ sum += buff[40*i+j]; } if(sum<20) { code+=(1<<(5-i)); } } PORTD.0=1; if (code==18) { for(j=0;j<400;j++) { PORTB.0=!PINB.0; PORTB.1=!PINB.1; PORTB.2=!PINB.2; #asm nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop #endasm } } }}

defcans.c – Defines the configuration file for the direction file

// Filename: defcans.c// Author: Clark Malmgren// Date: 4/11/06// Description:// Creates configuration file used by bmp2df

#include <stdio.h>#include <stdlib.h>

typedef unsigned char byte;typedef unsigned short word;typedef unsigned long dword;

typedef struct tagPIX{ byte red; byte green;

F-25


byte blue; int can;} PIX;

int main(){ FILE *fp = NULL; PIX Avail_Colors[5];

Avail_Colors[0].can = 0; Avail_Colors[1].can = 1; Avail_Colors[2].can = 2; Avail_Colors[3].can = 3; Avail_Colors[4].can = 4;

printf("Define can colors:\n"); printf(" Background (0):\n"); printf(" red: 0x"); scanf("%x", &Avail_Colors[0].red); printf(" green: 0x"); scanf("%x", &Avail_Colors[0].green); printf(" blue: 0x"); scanf("%x", &Avail_Colors[0].blue); printf(" Can 1:\n"); printf(" red: 0x"); scanf("%x", &Avail_Colors[1].red); printf(" green: 0x"); scanf("%x", &Avail_Colors[1].green); printf(" blue: 0x"); scanf("%x", &Avail_Colors[1].blue); printf(" Can 2:\n"); printf(" red: 0x"); scanf("%x", &Avail_Colors[2].red); printf(" green: 0x"); scanf("%x", &Avail_Colors[2].green); printf(" blue: 0x"); scanf("%x", &Avail_Colors[2].blue); printf(" Can 3:\n"); printf(" red: 0x"); scanf("%x", &Avail_Colors[3].red); printf(" green: 0x"); scanf("%x", &Avail_Colors[3].green); printf(" blue: 0x"); scanf("%x", &Avail_Colors[3].blue); printf(" Can 4:\n"); printf(" red: 0x"); scanf("%x", &Avail_Colors[4].red); printf(" green: 0x"); scanf("%x", &Avail_Colors[4].green); printf(" blue: 0x"); scanf("%x", &Avail_Colors[4].blue);

fp = fopen("can.conf","wb"); fwrite(Avail_Colors, sizeof(PIX), 5, fp); fclose(fp);}

Bmp2df.c – Converts a bitmap to a robit direction file// Filename: bmp2df.c

F-26


// Author: Clark Malmgren// Date: 4/11/06// Description:// Converts a bitmap to a directional file usable by// the 2-Bit Robit.

#include <stdio.h>#include <stdlib.h>#include <math.h>

typedef unsigned char byte;typedef unsigned short word;typedef unsigned long dword;

typedef struct tagPIX{ byte red; byte green; byte blue; int can;} PIX;

typedef struct tagSPRAY{ byte first :4; byte second :4;} SPRAY;

typedef struct tagBITMAP /* the structure for a bitmap. */{ dword width; dword height; dword offset; word planes; word bpp; dword comp; dword size; dword hsize; dword fsize; dword colors; PIX *pixels;} BITMAP;

void fskip (FILE *, int);void load_bmp (char *, BITMAP *);

int main(int argc, char *argv[]){ FILE *fp = NULL; BITMAP *pic = NULL; SPRAY *out = NULL; PIX avail[5]; int i, j, can, diff, min_diff, owidth, oheight;

pic = malloc(sizeof(BITMAP)); load_bmp (argv[1], pic);

fp = fopen("can.conf","rb"); fread(&avail, sizeof(PIX), 5, fp); fclose(fp);

for (j=0; j<pic->height*pic->width; j++) { min_diff = 10000000; //significantly larger than difference btw black & white

F-27


for(i=0; i<5; i++) { diff = abs(pic->pixels[j].red-avail[i].red)+ abs(pic->pixels[j].green-avail[i].green)+ abs(pic->pixels[j].blue-avail[i].blue); if (diff < min_diff) { min_diff = diff; pic->pixels[j].can = i; } } }/* printf(" Index Red Green Blue Can\n"); printf(" ------- ----- ------- ------ -----\n");

for (i = 0; i < pic->height; i++) { for (j = 0; j < pic->width; j++) { printf(" 0x%0.2x",i*pic->height+j); printf(" 0x%0.2x",pic->pixels[i*pic->width+j].red); printf(" 0x%0.2x",pic->pixels[i*pic->width+j].green); printf(" 0x%0.2x",pic->pixels[i*pic->width+j].blue); printf(" %d\n",pic->pixels[i*pic->width+j].can); } }*/ owidth = ceil(pic->width/2); oheight = pic->height+6;

out = (SPRAY *)malloc(sizeof(SPRAY)*owidth*oheight);

// printf("\n");

for (i = 0; i < oheight; i++) { for (j = 0; j < owidth; j++) { out[i*owidth+j].first = 0; out[i*owidth+j].second = 0; for (can=1; can<=4; can++) { if((i+can-4>=0)&&(i+can-4<pic->height)) { if(pic->pixels[2*owidth*(i+can-4)+2*j].can==can) { out[i*owidth+j].first += (int)pow(2,can-1);// printf("out[%d][%d].first += 2^(%d-1)\n", i, j, can); } if(2*j+1<pic->width) { if(pic->pixels[2*owidth*(i+can-4)+2*j+1].can==can) { out[i*owidth+j].second += (int)pow(2,can-1);// printf("out[%d][%d].second += 2^(%d-1)\n", i, j, can); } } } } } i++; if (i<oheight) { for (j = 0; j < owidth; j++) { out[i*owidth+j].first = 0; out[i*owidth+j].second = 0; for (can=1; can<=4; can++) { if((i+can-4>=0)&&(i+can-4<pic->height)) { if(pic->pixels[2*owidth*(i+can-4)+2*j].can==can) { out[i*owidth+j].first += (int)pow(2,can-1);// printf("out[%d][%d].first += 2^(%d-1)\n", i, j, can); } if(2*j+1<pic->width) { if(pic->pixels[2*owidth*(i+can-4)+2*j+1].can==can) {

F-28


out[i*owidth+j].second += (int)pow(2,can-1);// printf("out[%d][%d].second += 2^(%d-1)\n", i, j, can); } } } } } } }

printf("\nPrinting...\n"); for (i = 0; i < oheight; i++) { for (j = 0; j < owidth; j++) { if(out[i*owidth+j].first!=0) printf("%.1x", out[i*owidth+j].first); else printf(" "); if(out[i*owidth+j].second!=0) printf("%.1x", out[i*owidth+j].second); else printf(" "); } printf("\n"); }

fp = fopen("robit.df","wb"); fwrite(&pic->height, sizeof(dword), 1, fp); fwrite(&pic->width, sizeof(dword), 1, fp); fwrite(out, sizeof(SPRAY), oheight*owidth, fp); fclose(fp);

return 0;}

/******************************************************************* * load_bmp * * Loads a bitmap file into memory. * * Originally taken from: * * http://www.brackeen.com/home/vga/source/bc31/bitmap.c.html * *******************************************************************/

void load_bmp(char *file,BITMAP *b){ FILE *fp; PIX *palette; long index; word num_colors; int x; byte temp;

/* open the file */ if ((fp = fopen(file,"rb")) == NULL) { printf("Error opening file %s.\n",file); exit(1); }

/* check to see if it is a valid bitmap file */ if (fgetc(fp)!='B' || fgetc(fp)!='M') { fclose(fp); printf("%s is not a bitmap file.\n",file); exit(1);

F-29


}

/* read in the width and height of the image, and the number of colors used; ignore the rest */ fread(&b->fsize, sizeof(dword), 1, fp); fskip(fp,4); fread(&b->offset, sizeof(dword), 1, fp); fread(&b->hsize, sizeof(dword), 1, fp); fread(&b->width, sizeof(dword), 1, fp); fread(&b->height,sizeof(dword), 1, fp); fread(&b->planes,sizeof(word), 1, fp); fread(&b->bpp,sizeof(word), 1, fp); fread(&b->comp,sizeof(dword), 1, fp); fread(&b->size,sizeof(dword), 1, fp); fskip(fp,8); fread(&b->colors,sizeof(dword), 1, fp);

printf("Width: %d\n", b->width); printf("Height: %d\n", b->height); printf("Planes: 0x%.4x\n", b->planes); printf("Bits/Pix: 0x%.4x\n", b->bpp); printf("Colors: 0x%.8x\n", b->colors); printf("File Size: 0x%.8x\n", b->fsize); printf("Header Size: 0x%.8x\n", b->hsize); printf("Offset: 0x%.8x\n", b->offset); printf("Compression: 0x%.8x\n", b->comp); printf("Size: 0x%.8x\n", b->size);

/* try to allocate memory */ if ((b->pixels = (PIX *) malloc(sizeof(PIX)*b->width*b->height)) == NULL) { fclose(fp); printf("Error allocating memory for file %s.\n",file); exit(1); }

if (b->bpp == 0x18) { printf("True Color Image...\n\n"); fseek(fp, b->offset, 0); /* read the bitmap */ for(index=b->height-1;index>=0;index--) { for(x=0;x<b->width;x++) { b->pixels[index*b->height+x].blue=(byte)fgetc(fp); b->pixels[index*b->height+x].green=(byte)fgetc(fp); b->pixels[index*b->height+x].red=(byte)fgetc(fp); } fskip(fp,(b->width)%4); } printf("\n"); } else if (b->bpp = 0x08) { printf("8-bit Image...\n\n"); fseek(fp, 54, 0); // Start of palette

if ((palette = (PIX *) malloc(sizeof(PIX)*b->colors)) == NULL) { fclose(fp); printf("Error allocating memory for file %s.\n",file); exit(1); }

for (x=0; x<b->colors; x++) { palette[x].blue = (byte)fgetc(fp);

F-30


palette[x].green = (byte)fgetc(fp); palette[x].red = (byte)fgetc(fp); fgetc(fp); // Assuming Widows Format } for(index=b->height-1;index>=0;index--) { for(x=0;x<b->width;x++) { temp = (byte)fgetc(fp); b->pixels[index*b->height+x].blue=palette[temp].blue; b->pixels[index*b->height+x].green=palette[temp].green; b->pixels[index*b->height+x].red=palette[temp].red; } fskip(fp,4-((b->width)%4)); } printf("\n"); }

// Would have closed the file, except that causes the program to crash}

/******************************************************************* * fskip * * Skips bytes in a file. * * Originally taken from: * * http://www.brackeen.com/home/vga/source/bc31/bitmap.c.html * *******************************************************************/

void fskip(FILE *fp, int num_bytes){ int i; for (i=0; i<num_bytes; i++) fgetc(fp);}

F-31


Appendix G: FMECA Worksheet

Failure No.

Failure Mode Possible Causes

Failure Effects Method of Detection

Criticality

A1

Unable to access serial flash

Failure in Serial Flash module, failure of C53, Software Bug

Cannot access next segment of file

Observation, software diagnostic Low

A2Incorrect clock signal

Failure in Y4, C27, C28, C31, C35, C36

Unpredictable behavior Observation High

A3

User cannot log into Robit via web interface

Software failure, damaged uC, failure of C40, R19, R20, R23, R24

Cannot upload file to Robit or begin printing Observation Low

A4

IR Rx signal stuck in High or Low

Failure in IR Receivers, port pins, or circuit short

Incorrect positioning data

Observation, software diagnostic Low

F-1


Failure

No. Failure ModePossible Causes Failure Effects

Method of Detection Criticality

B1

Motor Control stuck High / Low

Failure in U21, U22, U23, TIP-122, software bug

Motor will not spin Observation Low

B2

Solenoid control stuck High


Solenoid always in active position (continual paint spray) Observation Medium

B3

Solenoid control stuck Low


Solenoid does not fire (no paint sprayed) Observation Low

C1 Output = 0V

Component Failure in C, short circuit

No functionality in circuit, short across battery terminals Observation High

F-2


Failure No. Failure Mode

Possible Causes Failure Effects


C2

Output of 5V Vcc > 5V, Output of 3.3V Vcc > 3.3V

Failure of LT1940

Potential damage to microcontroller, IR LEDs, Serial FLASH, ultrasonics, and PLD Observation High

C3

3.3V or 5V output out of tolerance

Failure of C41, C42, C54, C55, C56, C57, C58, C59, D20, D31, D32, D33


D1

Sonar Rx signal stuck in High or Low state

Failure in LM6154, C63, C64, R146

Microcontroller cannot position Robit

Software test in uC for invalid signal Low

D2

IR LED stuck in High or Low state

Failure in U14, software bug

Microcontroller cannot position Robit

Software test for lack of ping from Beacons Low

F-3





D3Vcc (-5V) = 0V

Failure in LTC1982-5, short circuit

Failure in ultrasonic positioning system Observation Medium

D4Vcc (-5V) < -5V

Failure in LTC1982-5, C60, C61, C62

Possible damage to LM6154 Observation High

D5

Vcc (-5V) output out of tolerance

Failure in LTC1982-5


E1 Vcc > 5VFailure in DC Power Supply

Damage to uC, incorrect operation Observation High

E2

IR Receive Signal stuck High

Failure in IR Receiver circuit, port-pin failure

Incorrect transmission behavior

Software-based detection of bad value Low

F-4





E4

IR or Sonar Tx signal stuck High or Low

Software bug, port-pin failure

Incorrect transmission behavior

Software detection of incorrect response from Beacons Low

F-5

ee 477 final report · web viewthese connections can be accomplished through general purpose...

Documents