EE 477 Final Report - Purdue University
ECE 477 Final Report
Spring 2005
[pic]
Team Code Name: ____________________________________________ Team ID: ______
Team Members (#1 is Team Leader):
#1: ____________________________ Signature: ____________________ Date: _________
#2: ____________________________ Signature: ____________________ Date: _________
#3: ____________________________ Signature: ____________________ Date: _________
#4: ____________________________ Signature: ____________________ Date: _________
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: User Manual |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix H: 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 5 | |
|CD of Website Image and Reports/Poster |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
| |TOTAL | |
TABLE OF CONTENTS
|Abstract |1 |
| 1.0 Project Overview and Block Diagram |1 |
| 2.0 Team Success Criteria and Fulfillment |2 |
| 3.0 Constraint Analysis and Component Selection |3 |
| 4.0 Patent Liability Analysis |7 |
| 5.0 Reliability and Safety Analysis |12 |
| 6.0 Ethical and Environmental Impact Analysis |15 |
| 7.0 Packaging Design Considerations |18 |
| 8.0 Schematic Design Considerations |22 |
| 9.0 PCB Layout Design Considerations |25 |
|10.0 Software Design Considerations |26 |
|11.0 Version 2 Changes |37 |
|12.0 Summary and Conclusions |38 |
|13.0 References |38 |
|Appendix A: Individual Contributions |A-1 |
|Appendix B: Packaging |B-1 |
|Appendix C: Schematic |C-1 |
|Appendix D: PCB Layout Top and Bottom Copper |D-1 |
|Appendix E: Parts List Spreadsheet |E-1 |
|Appendix F: Software Listing |F-1 |
|Appendix G: User Manual |G-1 |
|Appendix H: FMECA Worksheet |H-1 |
Abstract
MAVerick (Motorized Assault Vehicle) is a mobile gun platform controlled by a cellular
phone that has the ability to establish full-duplex communication with a command center in order to transmit control and status signals. It contains a paintball gun attached to the platform which fires at moving targets and has the ability to detect obstacles.
1. Project Overview and Block Diagram
The objective of our project was to design a vehicle capable of firing a paintball gun and be controllable from a cell phone. Our initial customer base was the young adult but the functionality of our project would make it useful for paintball enthusiasts of any age. We imagined our project being used for entertainment purposes or another tool on the paintball field. The design we decided to go with would give our project the ability to detect moving targets using an ultrasonic/IR sensor, the ability to identify and detect obstacles, the ability to encode and send control signals through a cellular phone to control the tank/gun, the ability to receive and decode control signals from the cellular phone, and the ability to send status information from the tank to the controlling device. To meet these criteria, we selected parts that gave us the functionality we needed and then integrated them into our design using each individuals unique set of skills.
[pic]
Figure 1.1 Block Diagram
2. Team Success Criteria and Fulfillment
a. Ability to detect moving targets using an ultrasonic/IR sensor
By implementing an autonomous search mode with the use of an ultrasonic ranging sensor we accomplished this project specific success criterion.
b. Ability to identify and detect obstacles
By the use of infrared proximity sensors, we were able to detect obstacles and turn off the motors before running into them.
c. Ability to encode and send control signals through a cellular phone to control the tank/gun
We used DTMF generator chips to create tones that could be sent to the tank giving us the ability to control it.
d. Ability to receive and decode control signals from the cellular phone
We used DTMF decoder chips to interpret tones received over a cell phone. We used these signals to control the tank.
e. Ability to send status information from the tank to the controlling device
We used the control signals in c and d to send signals in order for us to light LED’s and alert the user to changing conditions around the tank.
Constraint Analysis and Component Selection
Analysis of Design Constraints
There are several key aspects that need to be considered when designing this project. First is the computation requirements. There is a small amount of computation needed. The microcontrollers are mainly used to read sensors and relay control data. To conserve battery power, a microcontroller that has the ability to operate at low frequencies will be used. Second, the interfacing requirements will be very important. There will be several parts interfaced to the microcontroller including: motor controllers, stepper motors, solenoid, multiple infrared sensors, ultrasonic sensor, DTMF encoder and decoder chips, cell phone, LEDs, and a computer joystick. Each of these has special needs, whether they need an analog to digital converter, a driver MOSFET, or level converters. Much of the design will be the integration of each of these components. All of these systems need power, which is the third important consideration. Everything will run on rechargeable batteries. The cell phones will run on their own battery due to special voltage requirements and ease of design. Linear voltage regulators will be needed to take the battery voltage and convert it to the 5 volts required to run the logic devices. The ultrasonic sensor can run at any voltage between 6 and 24 volts. Each sensor has a shutdown transistor that is designed to turn off the sensor when not in use to save power. The mechanical aspect also has to be considered. In order to move around a heavy paintball gun, we will use a powerful stepper motor and a large wheel base. The air tank will be mounted low to lower the center of gravity and make sure it will not tip over easily. The last major consideration is cost. While keeping costs low is important, a balance must be kept between cost and functionality. For example, the ultrasonic sensor must be able to give accurate readings at relatively far distances. However, an industrial sensor with a precision of 1 inch at 30 feet is not necessary. On the other hand, most relatively inexpensive ultrasonic sensors do not have a range that would be effective to achieve any potency on the paintball field. Thus a balance must be made between low cost and high functionality. To achieve this goal, the tank and paintball gun were bought at a low price on E-Bay and the sensors were well-researched over the internet. The microcontrollers are commercially available, so as to be able to search many vendors to find the cheapest price. The DTMF chips were researched to find the parts requiring the least external components while still keeping the price low. Most other parts are commonly available at most electronic supply stores.
Rationale for Component Selection
Microcontroller
The base of this project is the microcontroller. On the tank side, the most computationally intensive task is to activate the ultrasonic sensor and determine the distance returned. From this data and the knowledge of which direction the turret is facing, the microcontroller can determine when and where targets appear. This requires, however, little more processing than storing data to memory and comparing it to a register. This computation only happens when MAVeric is in search mode. The only other tasks that the microcontroller needs to do while in search mode is to control the stepper motors, and occasionally activating the trigger solenoid. When the tank is in normal operating mode, there are more tasks that need to be done. The main motors and stepper motors need to be driven, the infrared collision sensors need to be queried, the DTMF chips need to communicate, and the trigger solenoid needs to be activated. This does not require much work by the microcontroller, but does require many I/O ports. The DTMF chips alone require 10 port pins. For the tank microcontroller, it is required to have four analog to digital converters, two independent pulse width modulation outputs, and a multitude of standard I/O pins. The microcontroller on the command center has slightly fewer interface needs. It needs to communicate with the DTMF chips, interface with a joystick with four axis and four buttons, and several LEDs. It needs three analog to digital converters, and many I/O ports. To simplify design, the same model microcontroller will be used on the tank and the command center. Below is the comparison of the Atmel Mega8 [3.1], Atmel Mega16 [3.2], and the Freescale 9S12C [3.3].
Looking at the chart, we see that the Mega8 is a good fit except it does not have enough I/O pins. The Mega16 fits all the criteria and is still a fairly inexpensive device. The MC9S12C32MFU25 has more than enough of everything compared. The fact that it has so many extra functions leads to extra power drawn that is wasted. It also is more expensive than the other two. This comparison leads our group to pick the Atmel Mega16 as the microcontroller we will use.
DTMF Encoder
The main goal of this component is integration. The fewer external parts needed, the better. The below table compares the Rohm BU8307CS [3.4] and the National Semiconductor TP5089 [3.5].
The TP5089 is clearly better than the BU8307CS. Not only does it require much fewer external parts, it is also cheaper. We chose the TP5089 for our DTMF encoding.
DTMF Decoder
In the same fashion as the DTMF encoder, the goal of this category is to limit the number of external parts. The table below compares the TDK Semiconductor 75T204 [3.6] and the California Micro Devices CM8870 [3.7].
Although the 75T204 needs fewer parts, the two chips are very similar. The CM8870 was chosen because it gave us more options for debugging if we needed them.
Ultrasonic Sensor
Many factors go into choosing the correct ultrasonic sensor. Range, interface, voltage, and price are the main aspects that need to be compared. Below is the comparison between the Devantech SRF04 [3.8], Devantech SRF08 [3.9], and the Senscomp 600 Instrument Grade Smart Sensor [3.10].
Initiate – Echo refers to setting a line high, then waiting for an echo (return sound wave pulse) on another line. This is a simple and effective way to receive distance information. The SRF04 is cheap and easy to interface with, but has a range that would severely restrict operations of MAVeric. The SFR08 has a longer range, but a difficult interface and a higher price. The 600 Smart Sensor has a long range, and easy interface, but has a non-standard voltage requirement and a high price. The group has decided to use the 600 Smart Sensor. The long range makes MAVeric much more potent in the paintball field, giving it the ability to strike relatively distant targets and defend a large area. These abilities are worth the extra cost.
Conclusion
In this project there were many design constraints. Ranging from varying voltage needs to sensor detection range, each of these needs have been met in the various parts chosen to be used. Each fulfills a specific need to the success of the tank and was chosen with great care. There was a balance between simplicity and functionality that was always in the mind of the engineer during the design phase. This balance was kept throughout the project in order to fulfill the requirements of the device.
.
3. Patent Liability Analysis
Results of Patent Search
A search at the United States Patent Office website, [4.1], was conducted in order to determine possible patent infringements on our design. The following patents were investigated for possible patent infringement:
|Patent Number |Title |Filing Date of Patent |
|D425,140 |Toy Tank |May 16, 2000 |
|4,596,900 |Phone-line linked, tone-operated control device |June 24, 1986 |
|4,751,658 |Obstacle avoidance system |June 14, 1988 |
|6,791,976 |Mobile-to-mobile DTMF signaling in tandem free operation |September 14, 2004 |
|5,119,322 |Digital DTMF tone decoder |June 2, 1992 |
|5,598,164 |Vehicle obstacle avoidance system |January 28, 1997 |
|6,683,820 |Method and apparatus for tracking sonar targets |January 29, 2004 |
A search was also conducted on [4.2] to look for commercial products that are similar to our project. A product was found on [4.3], which is a more advanced version of our product with more weapons and better navigation abilities. Searching on concluded no patents for this product.
Analysis of Patent Liability
The patents listed above have similar designs to our own. The patents will be sorted by literal infringements, doctrine of equivalents and no infringements in the discussion that follows.
Literal infringements:
• Vehicle obstacle avoidance system (Pat. No. 5,598,164)
Abstract: A system for warning a vehicle driver of obstacles to the front, rear and sides of the vehicle. If the vehicle is stopped and a front or rear obstacle is detected, the vehicle is prevented from moving forward or reverse, respectively. The inhibition of movement can be overridden by the driver once he acknowledges the obstacle. Similarly, the driver is warned of front, rear and side obstacles while the vehicle is moving. In the case of side obstacles, only when it appears that the driver will move the vehicle toward the obstacle is he warned. [4.5]
Analysis: The same functionality described by this patent is built into the Command Center that controls MAVerick. Infrared sensors are used to detect an object that is in front, front-left, front-right, and rear of the tank. Based on the sensor information, the tank sends control signals to the Command Center which lights up LED’s based on the information. If a sensor is tripped warning the Command Center that something is in MAVerick’s way, the Command Center will prohibit the user from sending a signal to move toward the obstruction unless the override button is pressed. This causes our design to have a literal infringement on this patent because the patented idea is identifying obstacles and prohibiting movement in that direction.
Infringements under Doctrine of Equivalents:
• Mobile-to-mobile DTMF signaling in tandem free operation (Pat. No. 6,791,976)
Abstract: A wireless communication method and arrangement that facilitates and allows a user at one end to send dual tone multiple frequency characters from one wireless unit to a second wireless unit completely within tandem free operation mode without changing to tandem operation mode. By remaining in tandem free operating mode during dual tone multiple frequency signaling the delay and distortion of the CODECs used in tandem operation mode is avoided, and the real possibility of missing bursts of dual frequency multiple frequency characters that exists presently because of existing timing requirements is removed. [4.8]
Analysis: The above patent is similar to our design of sending and receiving DTMF tones except for the tandem free processor that the patent uses. Our design just encodes and sends while the above design uses a few more features. The idea is really close to what we do and a patent lawyer would need to be consulted to determine if the patent is infringed. If our design does infringe this patent it would be under the doctrine of equivalents because we have a very similar setup that is done in the same way, just with a little less functionality than the patent.
No Infringements:
• Phone-line linked, tone-operated control device (Pat. No. 4,596,900)
Abstract: A phone-line-linked, tone-operated control apparatus in accordance with the invention comprises a detecting circuit coupled to a telephone line for detecting at least one predetermined sequence of predetermined tone signals received on the telephone line and for producing a corresponding sequence detection signal. An additional control circuit is responsive to the sequence detection signal for producing a corresponding control signal. Preferably, a break-in prevention circuit prevents access to the control apparatus unless a predetermined access code is first given. [4.6]
Analysis: The patent above uses some similar functionality that we employ in our design but the way in which it is designed is substantially different. Our design decodes a DTMF signal which gets sent into a micro-controller to decode and decide which action to take. In the above patent the DTMF output goes into a logic circuit comprised of flip flops and logic gates which is a different implementation than a micro-controller therefore our design does not infringe on this patent.
• Obstacle Avoidance System (Pat. No. 4,751,658)
Abstract: A system for avoiding obstacles in the path of a vehicle including a sensor assembly having a field of view with a plurality of sectors for detecting the distance of objects within each sector. The system further includes an element for identifying obstructed sensors in which objects are detected within a predetermined range and a device for selecting an unobstructed sector close in alignment to the direction of the path to designate around the object a clear path which is close to the original path. [4.7]
Analysis: The design presented in this patent is similar but much more complex than the idea in the design of MAVerick. The patent above uses sensors to determine obstructions and based upon those readings it maps out a new path that is unobstructed. The simple design of using infrared sensors to detect objects is not novel enough for a patent; the real idea is the processing in order to map out a new path and the different sectors. Therefore our design does not infringe on this patent since our design does not map out a new path if obstructed.
• Digital DTMF tone decoder (Pat. No. 5,119,322)
Abstract: A digital dual tone multi-frequency (DTMF) tone receiver having a detector circuit for scanning incoming audio signals for possible presence of DTMF tones, and a verifier circuit for verifying the presence of the detected DTMF tones. The detector circuit performs successive discrete Fourier transforms on the incoming signal at a first level of accuracy, and in response generates a tone verify flag signal for indicating whether or not a DTMF tone has been detected. The verifier circuit is enabled in the event that the tone verify flag signal indicates detection of a DTMF tone. The verifier circuit then performs further discrete Fourier transforms on the incoming signal at the detected DTMF frequencies as well as frequencies adjacent thereto, at a second level of accuracy greater than that provided by the detection circuit. The verifier circuit generates a tone present flag signal for indicating whether or not the detected DTMF tone is actually present. The detector and verifier circuits are preferably implemented algorithmically within a digital signal processor. [4.9]
Analysis: Both MAVerick and the Command Center have the need to decode DTMF signals. In our design, we do not perform any Fourier transform in order to determine the DTMF tone like the patent above. The patent above states a specific algorithm using Fourier transforms in order to determine the presence of a DTMF tone. Our design uses a simple IC that was purchased so our design does not infringe on the patent.
• Method and apparatus for tracking sonar targets (Pat. No. 6,683,820)
Abstract: A method and apparatus for analyzing newly acquired and faded or lost sonar contacts. Initial processing identifies a list of possible associations between a newly acquired contact and lost contacts. Subsequent processing of the possible associations reduces the number of possible associations that a sonar operator must consider in determining whether an acquired contact represents a new contact, a reacquired lost or faded contact. [4.10]
Analysis: MAVerick’s ultrasonic sensor performs a similar sweep as described by this patent. Our ultrasonic sensor is going to take readings at different angles to measure distance to potential targets and then store those distances. A trip on the infrared sensors will cause the ultrasonic sensor to sweep the designated range of the infrared sensor to check if there are any changes in distance. The patent describes a much more complex algorithm that is performed by our design. The idea behind this patent is the algorithm used to determine if the contact established is the same contact as before or if it is a different contact. Our ultrasonic sensor doesn’t take into account anything as complex as that; it just sends values of distances back to the micro-controller. Therefore our design does not infringe on this patent.
• Toy Tank (Pat. No. D425,140)
Analysis: This patent is a patent of a model toy tank design. Shown below is one of the model sketches from the patent website [4.4], which appears to be the same exact design as MAVerick. Since we purchased the tank from a manufacturer of the patented model no patent liabilities exist.
[pic]
Recommended Action:
Since our design has one literal infringement on patent 5,598,164, we have to either modify our design or license the patent. We would license the patent since we want our design to perform the same actions that were patented in 5,598,164. There really is no way to get around this patent. Since the idea of the patent is not novel we could argue that this patent does not apply to our design because of its simplicity. If that does not work then we would need to license the patent or take the functionality described in our patent out of our product.
The doctrine of equivalents patent would have to be reviewed by a patent lawyer in order to determine if infringement exists. If infringement does exists, we would need to purchase or license the patent since the transferring of DTMF signals is vital to our projects success.
4. Reliability and Safety Analysis
Reliability Analysis
The reliability of the MAVerick was determined using the military handbook “Reliability Prediction of Electronic Equipment.” Two values were calculated for each of the components analyzed, λP and the mean time to failure (MTTF). λP is the number of failures per component in 106 hours, and MTTF is 1/ λP or the number of hours before a failure occurs. [5.2]
Four components of the MAVerick’s design were selected for reliability analysis. First, the ATMega16L microcontroller from the microcontroller block of the tank circuit was analyzed. Second, the 3.58 MHz crystal oscillators from the DTMF blocks of the tank and command center circuits were analyzed. The third components analyzed were the LM7805CT voltage regulators from the power blocks of the tank and command center circuits. And finally, the DC motors from the motor block of the tank circuit was analyzed.
These components were chosen for three reasons. First, all the components represent different blocks of the MAVerick’s circuits. Second, they were chosen for criticality. If any of these components fail, then their respective blocks will fail and the MAVerick will lose a major portion of its functionality. Lastly, they are all different types of components and demonstrate how different parts use their own unique variables, values, and equations to rate their reliability.
1. Microcontroller – Atmel AtMega16L [3]
λP = [C1 * ПT + C2 * ПE] * ПQ * ПL [5.1]
where:
C1 – Die Complexity Failure Rate = 0.14 (8 bit processor)
ПT – Temperature Factor = 1.5 (T < 100oC)
C2 – Package Failure Rate = 0.019 (40 pins)
ПE – Environment Factor = 4.0 (Ground, mobile)
ПQ – Quality Factor = 10 (Commercial, unknown screening level)
ПL – Learning Factor = 1.0 (>2 years in production)
Therefore:
λP = [0.14 * 1.5 + 0.019 * 4] * 10 * 1.0
λP = 2.86 failures per 106 hours
MTTF = 1/ λP
Mean Time To Failure or MTTF = 349,650 hours or 39.9 years
2. Crystal Oscillator – 3.58 MHz
λP = λb * ПQ * ПE [5.1]
where:
λb – Base Failure Rate = 0.019 (Using value for 5MHz)
ПQ – Quality Factor = 2.1 (Non-military spec)
ПE – Environment Factor = 10 (Ground, mobile)
Therefore:
λP = 0.019 * 2.1 * 10
λP = 0.399 failures per 106 hours
MTTF = 1/ λP
Mean Time To Failure or MTTF = 2,506,265 hours or 286.1 years
3. Voltage Regulator – LM7805CT [4]
λP = λb * ПT * ПA * ПQ * ПE [5.1]
where:
λb – Base Failure Rate = 0.012 (MOSFET)
ПT – Temperature Factor = 3.7 (T < 100oC)
ПA – Application Factor = 1.5 (Linear amplification)
ПQ – Quality Factor = 8 (Plastic)
ПE – Environment Factor = 9 (Ground, mobile)
Therefore:
λP = 0.012 * 3.7 * 1.5 * 8 * 9
λP = 4.7952 failures per 106 hours
MTTF = 1/ λP
Mean Time To Failure or MTTF = 208,542 hours or 23.8 years
4. Motor – DC
λP = [(t2 / αB3) + (1 / αW)] * 106 [5.1]
where:
αB – Bearing Characteristic Life = 22,000 (T < 70oC)
αW – Winding Characteristic Life = 110,000 (T < 70oC)
t – Motor Operating Time Period = 5 (Hours at a time)
Therefore:
λP = [(52 / 61003) + (1 / 31,000)] * 106
λP = 9.09 failures per 106 hours
MTTF = 1/ λP
Mean Time To Failure or MTTF = 110,000 hours or 12.56 years
The MTTF of three of these devices could definitely use improvement. The worst device is the DC motor with 110,000 hours on average before the first failure. Because the device would not harm anyone if it failed, this MTTF is acceptable, but there’s always room for improvement. The main cause of this device’s unreliability is the temperature at which it operates. 70oC is a conservative value. Also, the motor operating time period is a conservative value. Most times, they will not be run for 5 hours at a time. In order to increase its reliability, though, heat sinks could be added to the circuit and the actual tank could even be ventilated to allow air to pass over the motors.
The voltage regulator is the next worst when it comes to reliability. It too has a very conservative temperature factor, but the best way to improve its reliability is to simply buy a better part with a much lower quality factor.
The microcontroller comes next on the unreliability scale. In addition to having a conservative temperature factor like the rest, its quality factor is also conservative. Actually, it is the worst value given in that category: the commercial, unknown screening level. Because of these conservative values, in reality it will outperform its MTTF.
The crystal oscillator is very reliable and no change is needed.
FMECA Worksheet for the Entire Schematic
This FMECA worksheet examines different failures that may occur during operation of the MAVerick. The failures are divided into nine blocks. These blocks are illustrated on the circuit diagrams included. They are as follows: (A) Power, (B) DTMF, (C) Microprocessor, (D) Status LEDs, (E) Joystick, (F) Sensors, (G) DC Motors, (H) Stepper Motor, and (I) Trigger. Blocks A, B, and C are on both the tank schematic and the command center schematic. To avoid confusion in these cases, the part labels on the tank schematic (not command center) were used in the FMECA worksheet. The blocks perform the same function on both of the circuits, but have different part labels which would get confusing. All of the failures will include failure mode, possible causes, failure effects, method of detection, criticality, and remarks.
The criticality portion will be divided into high and low. High will represent failures that have the most potential to cause injury to the user. Ideally a high failure rate should have a ( ( 10-9. These failures will deal with unpredictable power scenarios. Conversely, low will represent failures that do not pose a risk to the user. Ideally a low failure rate should have a ( ( 10-6.
For the most part, the MAVerick is a safe product. There are always unpredictable possibilities, but the failure modes defined as high criticality in the FMECA worksheet will probably only damage the circuits and not the user. These modes deal with unpredictable voltages and temperatures in the power supply, the DC motors, and the transistors controlling the DC motors. The low criticality modes pose practically no risk at all to the user.
In order to increase the reliability and safety of the MAVerick, one could add some hardware monitoring to the circuits. You would have to be sure that the reliability of the monitoring hardware is high though, so that the circuit’s unreliability does not get out of control.
5. Ethical and Environmental Impact Analysis
Ethical Impact:
Our project faces some obvious ethical issues, most notably safety. The use of a paintball gun alone allots for considerable safety measure but when used in conjunction with remote control and autonomous usages, the possibility for malfunction and the magnitude of its subsequent damage increase dramatically. To maintain a safe product we must ensure that our electrical, mechanical and software systems are designed in the proper manner. Our ethical responsibility doesn’t end there though. Misuse of the product could potentially cause much more harm then a system failure. The following will discuss these ethical issues and the measures taken to address them.
During our initial designs of the tank, safety was always at mind. When we designed the circuits, we made sure that in their failure mode, they would fail to a safe state. For areas of our circuit like the motors, it was important for us to have the circuit fail open because that allows the device to turn itself off in the event of failure and prevent any possible arcing or excessive heat buildup that could lead to burns as well as fire. [6.2] Some other measures we took were to add pull down resistors on our motors, turret, and trigger. During reset, the signals to activate those mechanisms could float high and cause harm to a user caught off guard. In the layout of the PCB, considerations were made to place all heat generating parts such as the transistors far enough apart so that excessive heat would not build up around them. Thick traces were also created to ensure that current spikes could not flash them and cause unexpected problems. While in design and normal operation our circuitry has been proven, for the product to be taken to market we would have to make sure that we would not reach any hazardous states due to different operating conditions such as heat, cold, or water.
For our mechanical systems, our design is fairly safe. Our tank operates at a very low speed so there is no danger from collision. The turret rotates at a slow speed and upon impact with an object, the stepper does not have enough torque to cause any harm. The only mechanical danger that our tank poses is the gun. An accidental firing of the gun could occur in extreme circumstances. To counteract this, the safety is readily accessible so when the tank is not in use, it can be activated making it impossible to fire the gun. Also, the way the trigger is designed, if for some reason the trigger is pulled and not released, only one shot will be fired instead of a continuous stream.
Our software actually has the greatest potential for error and accidental harm. We have taken great precaution to ensure that there is no way for the software to act in a harmful manner other than what the user tells it to do. One of our biggest worries was the tank being put into autonomous mode, losing a cell phone connection and not being able to connect again to turn it off. While we initially thought it would be nice to be able to “set it and forget it,” the potential of not connecting caused us to redesign that section of code so it continually checks for a connection and if it doesn’t detect one, the tank will reset and wait to be dialed again.
Besides the safety issues with our product, there is the concern of improper usage by the user. A device such as ours has the capacity to cause substantial harm to person and property when used improperly. When selling our product to vendors, we must ensure that the tank only be sold to people of ages 18 and above. The tank could still pose a danger though in the hands of a person who doesn’t know how to use it so it is our responsibility to supply clear and concise directions on how its proper use while placing warnings on the tank, command center, and manual about the potential safety hazards.
Environmental Impact:
Like many of today’s advanced remote devices, we utilize a printed circuit board and a rechargeable battery. If not disposed of properly, these components can have a negative environmental impact. It is our responsibility to take the necessary steps in alerting the public as to their affect and how to properly dispose of them.
Our design called for the use of two printed circuit boards, one in the tank and one in the Command Center joystick. Printed circuit boards contain lead contain hazardous materials such as Lead, Mercury, Arsenic, and Cadmium. [6.3] “Typical wastes generated by the PC board industry are: industrial wastewater and treatment residues, spent process baths, e/acids used for cleaning equipment, copper sulfate crystals, and re-flow oil.” [6.4] The boards we used for our current design contain these hazardous materials and were most likely created in plants that produce that waste. If we were to ever go into production, we could select a manufacturer that uses more environmentally friendly processes. Also, there are currently boards that exist that don’t contain the harmful materials common in most boards. By utilizing both those options, we could reduce the damage to the environment cause by our product and set an example for other developers.
Our design also calls for the use of a rechargeable nickel-cadmium battery. These batteries make use of harmful metals that can include Mercury and Cadmium [6.5] Like the printed circuit board, these elements are harmful to the environment and cannot be simply thrown out with the common trash. Contacting ones nearest recycling center to find if they recycle batteries is an option as well as contacting local electronic stores as they often recycle batteries for their customers. [6.6] While normal disposable batteries was also an option, the amount of batteries a consumer would go through in the normal life cycle of our product would be more harmful to the environment than simply using one rechargeable battery.
The remaining parts of the project should not pose any direct threat to the environment. The motors could be salvaged and be reused in other devices or simply be broken down to be recycled. The shell of the tank and even most of the sensors are almost completely made out of plastic which could be recycled. The barrel of the gun is made out of aluminum which could also be recycled. Any remaining paintballs should be fine to throw out as they are simply made of a biodegradable shell and filled with a substance similar to vegetable oil.
It is our responsibility as the developer of this product to inform the public about these hazards. Too often are these warnings left unmentioned or put someplace where the user will never notice them. The user manual is an obvious place to put the warnings. It is important that we make these visible and easy to understand. If they are simply placed on the last page with no mention of them anywhere else, we are not doing much good. Another place where it would be helpful would to place the warnings directly on the tank. Often, user manuals get lost or misplaced, especially at the end of the products life cycle causing the warnings to go unnoticed. While it may not be feasible to put all pertinent information directly on the tank, we could supply a hyperlink to a document containing the proper disposal methods and maintain that link for as long as we produce the product plus the products typical life cycle. It is not enough to simply have the information; it is our job to make sure it is easily accessible to the user.
Overall this project does not pose a great threat to the environment or its users if operated correctly. By taking the proper precautions, by both the producer and the end user, the product can be used and disposed of safely. While disposal and proper usage rely on that of the user, the necessary steps will have been taken to ensure that they are well informed of the hazards.
6. Packaging Design Considerations
Comparison to Commercial Products
The first product is a military vehicle called the SWORDS that is almost exactly the same in design to the MAVerick. It is pictured in figure B.1. SWORDS stands for Special Weapons Observation Reconnaissance Detection Systems. The SWORDS rides on tank treads and is fitted with many devices to aid in detecting enemies including four cameras, night vision and zoom lenses. The attached weapon is either a M249 or M240 machine gun and can fire 300 rounds before needing to be reloaded. It can travel at a speed of around 4 mph and can overcome obstacles like “barbed wire and rock piles” [7.1].
The design of the SWORDS is very similar to the MAVerick in that the operator Using a video screen to identify and eliminate targets creates advantages for both the SWORDS and the MAVerick if retrofitted with a real gun and used in a military sense. Using a robot instead of a human soldier gives you better accuracy when firing a weapon and simplifies warfare. The lack of a human holding the gun eliminates errors such as “trigger recoil, anticipation problems, and pausing the breathing cycle while aiming a weapon” [7.1] . In addition, the SWORDS and the MAVerick used in a military setting “don’t need to be trained, fed or clothed. They can be boxed up and warehoused between wars. They never complain. And there are no letters to write home if they meet their demise in battle.” [7.1]
The SWORDS and the MAVerick have obvious differences though. Although the designs and functions of the two machines are virtually identical, the packaging of each must fulfill different goals. Needing to brush off enemy fire and move through tough terrain, the SWORDS is a much more rugged machine made of steel, having top of the line sensors, and employing a live machine gun. The MAVerick lacks the overall strength of the SWORDS and is not designed for mortal combat. These advantages come with a price, literally. The SWORDS cost $200,000 a piece, more than 529 times the cost of the MAVerick. In order to compete with the SWORDS the MAVerick would need a real gun, better armor, and a camera with a lot of zoom capability. One possible benefit of using a MAVerick over the SWORDS is the MAVerick’s search mode where it stops and automatically scans for enemies and fires upon them. The SWORDS only fires when a human operator tells it to.
Having looked at the MAVerick’s potential from a military offensive point of view, let’s now look at it from a home or commercial security point of view. This next product is made by Rotundus, pictured in figure B.2. It’s exactly what it looks like, a huge ball. Inside is a pendulum that is “lifted in the direction of travel which moves the ball's center of gravity and sends it rolling.” [7.2] It can reach speeds of up to 20 mph and travel through mud, snow, and water. The Rotundus ball can also be “mounted with cameras, microphones, gas and smoke detectors and heat sensors on a central axis.” [7.2]
There are obvious design differences between the Rotundus and the MAVerick. The Rotundus takes a basic design, a sphere, and turns it into a security robot by having it chase would be criminals away. The simplicity of the concept is amazing compared to the complexity of the MAVerick acting as a security robot in search mode.
In order to use the MAVerick as a non-lethal security robot, you could retrofit a taser gun instead of the paintball gun. The Maverick could then sit in a strategic place in your home in search mode and incapacitate an intruder when one is detected. This would be far more effective than having a big ball chase the intruder away, although not as humorous. The Rotundus can also cause damage to property in your home or commercial business, not to mention it cannot handle stairs. If the Rotundus cannot catch the intruder in time, he could possibly escape. The MAVerick on the other hand, would incapacitate him and stop any danger to your family. Plus, with the built in cell phone, the MAVerick could dial 911 in the event it captures an intruder in your home.
The Rotundus does contain some design advantages though. The MAVerick is superior in closer quarters where it can sit and wait while not having to worry about needing room to accelerate, but in open areas like a factory or other business, the fast Rotundus would be superior to the MAVerick retrofitted with a short-range taser gun. It really isn’t realistic to try and counteract this flaw and design the MAVerick with a real gun for a security use because of ethical and legal issues.
As far as packaging goes, the Rotundus fares well again. A heavy, sturdy ball will not easily be stopped by the unsuspecting intruder. The MAVerick still lacks with it’s weak armor but this is not as glaring a flaw than with it’s military use because in a home security role it would be incognito.
Design Specifications
The MAVerick’s packaging is shown in figure B.3. A number of modifications were made to the original tank design. The turret was modified and integrated with the paintball gun. The top of tank was smoothed down to eliminate some of the detailing that got in the way of the turret’s rotation after all the extra weight was added. The Atmel microprocessor, the cell phone, and the new circuit board are all placed inside the tank. All circuitry will be powered by a 9V battery reduced to a usable 5V. This too will be packaged inside the tank. The new circuit board allows for independent control of the two treads. That way, the tank does not have to stop in order to turn. The existing motors were kept and are powered by the existing battery pack. Four proximity sensors were mounted in order to detect obstacles and warn the user to avoid them. The wireless camera was mounted atop the paintball gun so that wherever the turret points, the camera will see. The actuator, used to physically pull the trigger of the paintball gun, was mounted inside of the turret. It is powered by the existing battery pack in the tank. And finally, the ultrasonic sensor was attached to the barrel to alert the microprocessor when a target is in front of the tank.
None of the sensors are more than a few inches wide in any direction nor are they heavy, so they were easily mounted to the tank with a hot glue gun. The stepper motor was screwed to the top of the inside of the tank.
The turret was more complicated. The front was cut out so that the paintball gun and actuator could be housed inside. The paintball gun and actuator are held down with zip ties, and the actuator is screwed into the paintball gun. The CO2 tank rests on top of the turret secured by a zip tie and the paintball hopper sticks straight up out of the top of the turret.
Materials List
Major Parts(cost over $1.00) Number Total Weight(1bs) Total Cost(US $)
|1. Atmel Mega16 Microprocessor |2 |negligible |13.12 |
|2. Remote Control Tank |1 |8 |59.00 |
|3. Brass Eagle Marauder Paintball Gun |1 |1.3 |33.45 |
|4. Top Gun Joystick |1 |2 |32.45 |
|5. Motokata Wireless Reversing & Parking |4 |.35 |19.00 |
|Sensor | | | |
|6. DTMF Encoder ICS5089 |4 |negligible |5.00 |
|7. DTMF Decoder |4 |negligible |16.00 |
|8. Senscomp Ultrasonic Sensor 615088 |1 |.41 |55.00 |
|9. Senscomp Ultrasonic Housing 619395 |1 |negligible |7.50 |
|10. Link Actuator |1 |.3 |5.50 |
|11. Linksys Wireless-B Internet Video Camera |1 |.53 |106.91 |
|12. Stepper Motor |1 |.6 |30.00 |
Note: Listed prices for the 2 Atmel microprocessors and the Link actuator are for reference purposes only as they were previously owned by a group member and thus did not affect our total cost.
Total Cost To The Top Guns = $484.31
Total Cost If No Parts Previously Owned = $516.05
Total Weight = 14.54 lbs. (Goose the joystick included)
Tooling Requirements
The only tooling requirements needed were a drill, a soldering iron, a saw, a screwdriver, and a hot glue gun for mounting of the sensors.
7. Schematic Design Considerations
Theory of Operation
Microcontroller
The base of this design is the microcontroller [8.1]. Because it is running on a battery, the microcontroller will be set at a low frequency to conserve power. It will, however, run at 5 volts. This is the case because the DTMF decoder chip will not recognize 3.3 volts as a valid high signal. Adding a level converter chip would add in unnecessary complexity and might end up consuming more power than would be saved in the first place. Also, the power MOSFETs used have a turn on voltage that is guaranteed to be as low as 4 volts. A microcontroller running at 3.3 volts will not have enough voltage to control these transistors.
Power Supply
There are several devices on each board that require 5 volts to run. The IR sensors have an especially high current draw, which could be as high as 50mA each. With four running at the same time, a possible 200mA alone limits our power supply choices. The team chose to use a 7805 voltage regulator [8.2]. It is a readily available chip that provides a simple circuit and high current supply with low noise. During testing, it was found that a major obstacle that must be overcome is noise in the DTMF chips’ power supplies. The 7805 provides this low noise environment.
DTMF Chips
The DTMF chips, which were chosen for their simplicity, require a relatively easy circuit, which is included in the datasheet [8.3]. The only circuitry added was a 74HC139 decoder chip to lessen the number of port pins required for the DTMF encoder and capacitors to remove noise in the input voltage.
Motor Controller
The H-bridge model was used to drive the motors. This is where two P-MOSs [8.4] are above two N-MOSs [8.5] and two transistors (one P-MOS and one N-MOS) are turned on to drive current either direction through a motor. The transistors were chosen on a basis of having a very low on resistance and a reasonable price. An interesting problem occurs with this setup. Because the motor controller is running directly from the battery voltage, a logic high is the same voltage as the battery, 9.6 volts. Giving it a high from the microcontroller will not turn the P-MOSs off. To fix this problem, a CD4069 [8.6] chip with a Vdd of 9.6V (the same as the battery) was used to increase the voltage of the signals from the microcontroller. Now the motor controller will understand logic high from logic low correctly.
Stepper Motor Controller
To control the stepper motor, a simple circuit of power MOSFETs [8.7] and arc-suppression diodes are used. Each transistor will power a coil in the stepper motor by providing a path to ground for current to travel through. The transistors were chosen because of the low on resistance and the commercial availability.
Sensors
Each of the sensors are either powered by 9.6 or 5 volts and provide a simple output of 5 volts. The outputs on the IR sensors [8.8] are open collector, and thus require a pullup resistor to give the correct output signal. The output on the ultrasonic [8.9] gives 6.5 volts when high, so a transistor create an inverter circuit with an output of 5 volts, regular levels for the microcontroller. In addition, each of the sensors has the ability to be shut off by means of a transistor in order to save power.
Joystick
The joystick [8.10] came with poor documentation, so much experimentation was required to learn how to interface with it. After much trial and error, it was found that the directional hat connected different resistors to Vcc. So, by adding a known resistance in series, creating a voltage divider, one can determine which resistance is presented by reading the voltage between the resistors. The main directions, X and Y, are a function of voltage. There is a potentiometer that slides one way or another when the stick is pushed from side to side. When the potentiometer is connected to 5 volts and ground, the output is a linear range from 0 to 5 volts dependent on how far the stick is pushed in each direction. The buttons provide the easiest circuit. When a button is pressed, a switch is closed which grounds the output pin. By simply adding a pullup resistor to the output, one can read a 0 or 5 volts on the output pin depending on whether the button is pressed or not. A value of 10KOhm was chosen for the pullups because the port pins can easily sink the current flowing from them, and they would not pull the voltage up too much when a zero voltage is applied to them.
LED Status Display
To give the operator the most information possible and the ability to debug any problems, the status of the IR (obstacle) sensors and the motion sensors are displayed by LEDs in the command center. LEDs also provide data on whether the tank is in search mode, and if it is firing at the moment. Each of the LEDs is set in a configuration to allow the microcontroller to sink their current in order to prevent the pins from burning up. 1KOhm resistors were placed in series with the LEDs to limit the current flowing to protect the port pins on the microcontroller.
Conclusion
In conclusion, each component has its own special requirements. Many times, the most difficult part of design is satisfying each of the part’s needs while not introducing many more. In the case of this project, there are many unique challenges that needed to be overcome. Each has been met in a way to try to maximize the strengths of the design.
.
8. PCB Layout Design Considerations
When designing the boards, placement was of foremost importance. On our tank board, there is a large mixture of analog and digital circuitry. In order to reduce noise, it was necessary for us separate the analog and digital parts as much as possible. Also, on both boards, our circuits will be decoding and encoding signals that are sent vie cell phones, it is extremely important for those signals to be separated from the large analog parts as well.
Once the placing was complete, a routing strategy was necessary. Power and ground were done first as they are a large source of signal noise so it is important to route them as best as possible. For our tank circuit, we needed to separate power levels, one that drove the digital sources and some of the small sensors, and one the powered the motors, stepper, actuator and ultrasonic sensor. The signals were separated as much as possible while also attempting to keep them parallel. Since ground plays a large part in noise, we also made sure not to connect the two grounds anywhere.
The traces on that tank board that led to our more current drawing sources were designed much thicker than any of the other traces on the board. Since we needed to supply a large amount of current to an entire side of our board, we used a 200 mil trace from our power supply to about 2/3 the height of the board. From this line we sourced several high current drawing devices. While nominally, we shouldn’t need a line that thick but there are cases where current could spike high enough and it is safer to have the larger trace. Corresponding to the power trace, there is an equally thick ground trace that flows parallel to the power. The ground trace has several tiers in width as well to help reduce the amount of common impedance which is a known cause of noise (1).
One of the drawbacks about using such large traces is an increased capacitance that could ultimately lead to noise problems in traces nearby them (1). Also, since one of our large traces runs up a fairly large portion of our board, it is inevitable that we would need to send traces across it. To help avoid reduce the noise created by the power trace, all of the lines routed underneath it, were done perpendicular. Doing so helps reduce the cross coupling effects (1).
Another consideration that was made to help reduce noise was the routing of our oscillators. Each board contains two oscillators which, if placed poorly, could cause a lot of noise (9-1). Therefore, we made sure to place and route those right after the power lines so as they could be as close as possible to the ICs that are using them. In doing so we were able to have very minimal trace lengths and avoid routing any other traces through or under those oscillators.
As mentioned before, our signal from the cell phones is obviously important signal for us. If it becomes too noisy, it is possible that the decoder chip will not be able to correctly identify the DTMF tones that are sent to it. When placing the header that will attach to our cell phone, it was difficult to get it close to both the decoder and the encoder. Because of us, it was necessary for us to protect the signal as much as possible on the trace that we had to extend. One method we used to do this was to simply increase the trace width. Another method was to run it in parallel and next to a ground signal. These two methods should help the signal remain clear.
Decoupling capacitors is another obvious way to help reduce noise. They do however tend to become a nuisance because the can be quite large and difficulty to find room for. Even with these problems, placing them as close to possible to their respective IC is a must. We made sure in our design that we placed the capacitors right next to the power and / or ground pins on our ICs and micros. In prototyping, noisy power lines had already caused a failure in our circuit so we made sure to make these a priority.
9. Software Design Considerations
Memory Models:
An Atmel Mega16 is used on both MAVerick and the Command Center. The Mega16 is equipped with 16KB of flash memory for our program, 1KB of SRAM for data and stack, and 512B of EEPROM [1]. The chip provides more than enough flash and SRAM, only use 21% of flash on MAVerick and 8% flash on the Command Center, for our needs and the extra space can be used for future expansion if necessary. The EEPROM is not utilized in our product.
Memory Sections/Mappings:
The Atmel Mega16’s memory is split up into three parts: program memory, data memory, and EEPROM memory [10.1].
Program Memory:
The program memory extends from the address $0000 - $1FFF. The first section of this memory, show in Figure 1, is used for the application program code and the second half is used for a boot loader.
[pic]
Figure 10.1: Program Memory Model [10.1]
Data Memory:
The data memory space is used to hold all data and stack variables. As can be seen in Figure 2, the lowest 32 addresses hold the values of 32 general purpose registers. The next 64 addresses are used to hold the I/O ports and peripheral registers. Lastly, the next 1024 address are dedicated to SRAM which is used for data and stack purposes. [10.1]
[pic]
Figure 10.2: Data Memory Model [10.1]
EEPROM:
The EEPROM is not explicitly used in our code but 512B of it exist if needed for future expansion.
Startup Code:
The startup code for our project is automatically generated by CodeVision [10.2] and programs the following tasks: initializing the stack pointer, allocating space for global variables, copy values of initialized variables to data section, and jump to main().
Organization of Embedded Application Code:
The organization of the embedded application code follows the program-driven model. The code is set up in infinite while loops in order to carry out tasks. On MAVerick, once the calling device, either a phone or the Command Center, is established, an infinite while loop is entered which checks for incoming tones and controls the search mode capability. In the case under Command Center control, the loop has the added functionality of checking status signals. The program mainly runs on receiving DTMF tones from either a phone or the Command Center and performing an action based on the received tone. On the Command Center, an infinite while loop is entered which continuously converts the position of the joystick and sends the position via a DTMF tone and checks for status signals. Both designs do not utilize any interrupts to do any processing. A better way of organizing the code would have been a combination of interrupt driven and program driven, but the software design was not considered until after the schematic was made which limited our ability to use the interrupt port pins.
Software Design Narrative:
Tank:
Function Name: void main( void )
Return Value: None
Parameters: None
Status: Completed/Tested
Description: This function is the entry point of our application. Main calls a function called init which takes care of our all device initializations. After the call to init, main waits for a tone from either the Command Center or a normal cell phone to identify which device is going to control the tank. After receiving the control tone, an acknowledge tone is sent and main calls the function joystick or phone depending on which control signal was received.
Function Name: void init( void )
Return Value: None
Parameters: None
Status: Completed/Tested
Description: This function is called from main and sets all of our device initializations which are summarized in the table below:
|Port/Peripheral |Register Settings |Purpose |
|PORT A |PORTA = 0x00 |Port A is used for inputs from the infrared sensors so the data direction|
| |DDRA = 0x00 |register is set to all inputs and the default values are 0 for all of the|
| | |sensors. |
|PORT B |PORTB = 0x01 |Port B is used for sending DTMF tones and controlling the power to the |
| |DDRB = 0xFF |infrared sensors and ultrasonic sensor. All pins on Port B are set to |
| | |outputs and pin 0 is defaulted to 1 because that pin is an active low |
| | |tone enable for sending DTMF tones. |
|PORTC |PORTC = 0x00 |Port C is used for controlling the turret movement and motor movement. |
| |DDRC = 0xFF |All of the port pins are defaulted to 0, no movement, and all pins are |
| | |set as output pins. |
|PORTD |PORTD = 0x00 |Port D is used for inputting a DTMF tone, controlling the ultrasonic |
| |DDRB = 0xA0 |sensor, and controlling the trigger mechanism. All of the port pins are |
| | |defaulted to 0 and the data direction register is set so the DTMF tone |
| | |pins are inputs and the ultrasonic and trigger pins are set as outputs. |
This function was generated by CodeVision. [10.2]
Function Name: void phone( void )
Return Value: None
Parameters: None
Status: Completed/Tested
Description: This function is called from main if the tank is to be controlled from a phone. This function checks to see if the tank is search mode and, if so, the function checks the appropriate sensors and controls the ultrasonic sensor to determine if a target is present. The tank continues to perform this function until the search mode is disabled. When search mode is disabled, phone waits for a DTMF tone from the cell phone and when it recognizes a correct tone, it calls the function action to take the appropriate action based on that tone.
Function Name: void joystick( void )
Return Value: None
Parameters: None
Status: Completed/Tested
Description: This function is called from main if the tank is to be controlled from a joystick. joystick checks to see if the tank is in search mode and if so, checks the appropriate sensors and controls the ultrasonic sensor to determine if a target is present. The tank continues to perform this function until the search mode is disabled. When search mode is disabled, joystick waits for a DTMF tone from the Command Center and when it recognizes a correct tone, it calls the function action to take the appropriate action based on that tone. The Command Center also checks the sensor inputs and sends control signals to the Command Center if any of the sensor inputs have been tripped. This allows the Command Center to light up LED’s based on the status of the tank.
Function Name: void action( int tone )
Return Value: None
Parameters: int tone – this is a numerical representation of a DTMF tone
Status: Completed/Tested
Description: This function is called from either phone or joystick and takes the appropriate action depending on which tone is sent into the function. This function consists of a switch statement which has cases for each possible action the tank performs. A global variable named Direction is manipulated in this function when a direction tone is received in order to determine the calculated direction. A function called motor is then called in order to control the movement of the motors based on the global variable Direction.
Function Name: void motor( void )
Return Value: None
Parameters: None
Status: Completed/Tested
Description: This function is called from action and controls the motors based on the global variable Direction. The appropriate values on port C are set in order to control the correct direction of the tank.
Function Name: void send_tone( int tone, int duration )
Return Value: None
Parameters: int tone – this is a numerical representation of a DTMF tone
int duration – this is the time in ms that the tone will be sent
Status: Completed/Tested
Description: This function takes the variable tone and sends the corresponding DTMF tone to the Command Center or cellular phone for the length of time specified by the second argument. A switch statement is used to set the appropriate port pins on port B in order to send to encode the correct DTMF tone. An active low tone enable pin is then set low for the duration specified by the second argument. After the delay, the enable is set high and the function exits.
Function Name: int get_tone( void )
Return Value: int – the numerical representation of the DTMF tone that is received
Parameters: None
Status: Completed/Tested
Description: This function checks the valid tone bit to see if the DTMF tone is valid, if a valid tone is not present, the function will return -1, otherwise the function will decode the tone and return it’s numerical representation.
Command Center:
Function Name: void main( void )
Return Value: None
Parameters: None
Status: Completed/Tested
Description: This function is the start of our application. Main calls a function called init which takes care of our all device initializations. After the call to init, main sends a control signal tone to MAVerick identifying itself as being controlled by the Command Center and waits for an acknowledged tone from the tank. After this is complete, an infinite while loop is entered which decodes the joystick input and sends the control signals to MAVerick, checks to see if any control signals are received from MAVerick, and lights up LED’s based on the control signals received by MAVerick.
Function Name: void init( void )
Return Value: None
Parameters: None
Status: Completed/Tested
Description: This function is called from main and sets all of our device initializations which are summarized in the table below:
|Port/Peripheral |Register Settings |Purpose |
|PORT A |PORTA = 0x00 |Port A is used for inputs from the joystick. Since Port A has the |
| |DDRA = 0x00 |analog-to-digital conversion ability we used this port for the joystick |
| | |input. The port is initialized to 0 and all of the pins are set to input|
| | |pins. |
|PORT B |PORTB = 0x00 |Port B is used for sending a DTMF tone. The lower 5 bits of Port B are |
| |DDRB = 0x1F |set to output pins which provide the functionality of sending a DTMF |
| | |tone. The upper 3 bits are no-connects and left as input pins. |
|PORTC |PORTC = 0x00 |Port C is used for driving LED’s displaying status information of the |
| |DDRC = 0xFF |tank. All of the LED’s are initialized to 0 and all of the port pins are|
| | |set as outputs. |
|PORTD |PORTD = 0x00 |Port D is used for driving LED’s on its upper 3 bits, while the rest is |
| |DDRB = 0xE0 |used for receiving DTMF tones. All port pins are initialized to 0 and |
| | |the upper 3 pins are set to output pins and the rest are set to input |
| | |pins. |
This function was generated by CodeVision. [10.2]
Function Name: unsigned char read_adc( unsigned char adc_input )
Return Value: unsigned char – the result of the analog-to-digital conversion
Parameters: unsigned char adc_input – port pin for the analog-to-digital conversion
Status: Completed/Not Tested
Description: This function takes the port pin number as its argument and performs an analog-to-digital conversion on that port pin. The value of the analog-to-digital is returned. This function was generated by CodeVision. [10.2]
Function Name: void send_tone( int tone, int duration )
Return Value: None
Parameters: int tone – this is a numerical representation of a DTMF tone
int duration – this is the time in ms that the tone will be sent
Status: Completed/Not Tested
Description: This function takes the variable tone and sends the corresponding DTMF tone to the Command Center or cellular phone for the length of time specified by the second argument. A switch statement is used to set the appropriate port pins on port B in order to send to encode the correct DTMF tone. An active low tone enable pin is then set low for the duration specified by the second argument. After the delay, the enable is set high and the function exits.
Function Name: int get_tone( void )
Return Value: int – the numerical representation of the DTMF tone that is received
Parameters: None
Status: Completed/Tested
Description: This function checks the valid tone bit to see if the DTMF tone is valid, if a valid tone is not present, the function will return -1, otherwise the function will decode the tone and return it’s numerical representation.
Function Name: void set_led( int tone )
Return Value: None
Parameters: int tone – this is a numerical representation of a DTMF tone
Status: Completed/Not Tested
Description: This function takes the variable tone and lights up the proper LED based on that tone. A switch statement is used to identify the proper LED from the tone and then the LED output gets toggled using the XOR function.
Software Documentation:
Flowcharts:
The following flowcharts are for the MAVerick and the Command Center respectively. MAVerick starts out with initializations and waits for a start bit. When the start bit is received it then checks to see if it is a correct identifying tone and if not it goes back to receive a bit. When a bit is received it goes into an infinite loop depending on the start bit identifying joystick control or cell phone control.
[pic]
The Command Center flowchart starts off with some initializations and then it sends a control code to the tank in order for it to know that it is being controlled by the Command Center. After that it checks for an acknowledge tone to see if a connection exists. After that an infinite while loop is entered to command MAVerick.
[pic]
10. Version 2 Changes
• Interrupt driven code instead of polling
• Y-Axis turret movement
• Faster motors
• PWM for variable motor speeds
• Infrared sensors for aiding target detection
• Video broadcast over the cellular phone
• Better cellular phone integration
• Laser range-finder
Summary and Conclusions
At the beginning of the semester we set out to create a cell phone controlled, paintball tank. There were always obstacles like burning out transistors or turrets that won’t rotate smoothly, but we overcame them all. Now that the semester is over, there were lessons learned. First, prototyping hardware is very important in order to avoid flywiring on your PCB. This kind of forward thinking helps to avoid future problems. Another problem avoided was the ability to in-circuit program the microprocessor. Anticipating problems is key to doing efficient work. Reflecting on problems that we actually encountered, when it comes to high risk parts you should always buy spares. Finally, think about your software while designing your hardware. In our particular case, better pin placement would allow us to more easily transition into interrupt driven software. The main lesson we learned is always think ahead.
References
[3.1]
[3.2]
[3.3]
[3.4]
[3.5]
[3.6]
[3.7]
[3.8]
[3.9]
[3.10]
[4.1] (United States Patent and Trademark Office)
[4.2] (Google)
[4.3] (Defense Review – Armed/Weaponized Infantry Robots for Urban Warfare and Counterinsurgency Ops)
[4.4] (US Patent Office site for patent no. D425,140)
[4.5] (US Patent Office site for patent no. 5,598,164)
[4.6] (US Patent Office site for patent no. 4,596,900)
[4.7] (US Patent Office site for patent no. 4,751,658)
[4.8] (US Patent Office site for patent no. 6,796,976)
[4.9] (US Patent Office site for patent no. 5,119,322)
[4.10] (US Patent Office site for patent no. 6,683,820)
[5.1] Military Handbook for Reliability Prediction of Electronic Equipment
[5.2] ECE477 Class Notes Module 10: Design for Reliability, Maintainability, and Safety
[5.3] Atmel AtMega16L Reference Document
[5.4] LM7805CT Voltage Regulator Reference Document
[6.1] Splitt, Frank G., Engineering Education Reform: A Trilogy, January 2003
[6.2] Fail-safe design
[6.3] Recycling electronics and computers
[6.4] Envirosense – Fact Sheet: Printed Circuit Board Manufacturers (Oct., 1995)
[6.5] Recycling electronics and computers
[6.6] How to Recycle Nickel-Cadmium Rechargeable Batteries
[7.1] Associated Press, “Army Readies Robot Soldier for Iraq,” [Online Document], 2005, Jan 24, [cited 2005 Feb 17] Available
[7.2] Sky News, “Rolling Robot Ball to Bowl Over Burglars,” [Online Document], 2005, Feb 14, [cited 2005 Feb 17] Available
[7.3]
[7.4]
[7.5]
[7.6]
[8.1]
[8.2]
[8.3]
and
[8.4]
[8.5]
[8.6]
[8.7]
[8.8] 0D02YK.pdf
[8.9] ensor.pdf
[8.10]
[9.1] Motorola App Note AN1259
[10.1] Atmel Mega16 Datasheet:
[10.2] Codevision C Compiler:
Appendix A: Individual Contributions
A.1 Contributions of Chad Bjorklund:
My individual contributions to the project have encompassed several different areas. At the onset of the project, I was chosen as team leader. While in no way have I used this position to assert an authority, I’ve always tried to lead by setting a good example. One of our first duties as a team after selecting our project was to find parts that would fit our needs. I spent many hours researching different parts that would fit our needs and always scavenging for the lowest price. I sent out many emails to companies asking if we could get any parts donated or lent to us. Along with searching vendors, I turned to eBay quite often to search for some of our other more commercial parts such as the paintball gun, tank, and joystick. I was able to locate and purchase all of those items at very reasonable prices, especially when compared to their retail equivalents.
Once the parts arrived, it was necessary for us to begin prototyping the different sections of the project. I worked in tandem with Randy on the DTMF circuitry. I contributed in setting up the initial breadboard circuit to test the DTMF decoding and encoding ICs. After studying the datasheets and selecting the proper resistor and capacitor values, I was able to connect the two chips together and generate and decode a tone exactly as we had planned.
Once everything was prototyped and a schematic was made, I got to work on the PCB layout. Before I even began to layout the parts, I spent a lot of time with Paul on the schematic making sure everything was setup properly and we made sure to choose all of the correct footprints. Once I began the actual layout, I devoted many hours making sure everything was not only connected correctly but laid out in a proper and efficient manner. Thankfully the boards worked just as we had planned when we received them with the addition of only one minor flywire.
Over spring break, I didn’t end up going anywhere so I brought the project home with me to work on it. I spent a lot of time working on the turret and coming up with a method of mounting the gun. I restrained from doing any fabrication to the turret because I didn’t have the group’s approval but I began making other parts that we could use. One such part was a connector for wires that we could use in the turret to allow it to spin 360 degrees without tangling the wires inside. While we never implemented it, if we had more time or decided to make this a commercial product, it could be a useful addition.
Once our PCBs arrived, software was my primary concern. Since Randy and I were the computer engineers, we took it upon ourselves to do it. While I spent a lot of time after spring break developing code, the majority of time was spent debugging it and fine tuning it.
Even though most of my time was devoted to software, I still always tried to help out in other areas. With physical construction, I helped setup and mount the stepper for the turret. For hardware, when we ran into a problem with encoding our DTMF tones, I help test different ways of fixing it. For testing the tank, I was always the one with the pleasure of being shot.
A.2 Contributions of Paul Dulle
As one of the two electrical engineers of the group, I mostly worked on the hardware circuit schematic. Along with that, I picked up various mechanical and physical construction duties.
I chose the component rationalization homework as my professional component homework. This assignment included doing research for many different parts that were essential for the operation of the project. From which microcontroller to use, to DTMF selection, to choosing which sensors are most suited for us, this homework made me really consider what we needed and how to best achieve it. I took many factors into account including computational requirements, interface requirements, power supply constraints, packaging, and cost constraints.
Before finalizing the circuit schematic, we decided that it would be best to prototype each block of the circuit to catch any errors. By figuring out exactly what each component took to work correctly, we almost eliminated the need to flywire on our PCB. I was a major contributor in prototyping the motor control H-bridge, the joystick interface, the trigger actuator, power supply, and the sensor integration. Each of these parts worked just as they were supposed to when the circuit was on the PCB.
For my design component homework, I selected the schematic and hardware design. This entailed bringing together all the knowledge and circuits that we had acquired during the prototyping stage on to one coherent circuit. In this homework, I needed to check that what we had tested would work with the rest of the project and add any features (such as pull-up / pull-down resistors and power shutdown transistors) that would aid our project.
As the team’s expert in transistors, I was in charge of designing the interface to the motors. I needed to design the H-bridge, stepper motor driver, inverters, and level translators.
I also populated the PCB of MAVerick (the tank). This required first learning how to solder on practice boards, then putting my new found skills to work attaching all the components to the PCB.
I assisted in the physical construction of MAVerick and Goose. Fixing the paintball gun on to the turret required many modifications to the structure of the tank. We needed to cut holes for screws and slice entire sections free of the turret. Painting the new joystick walls and hot gluing them into place was also something that needed to be done. Along with this, there was a multitude of cables that needed to be made. Whenever we needed a cable or debugging tool to be made up, we would get it constructed.
Along with this, in the debugging stage, I assisted slightly in analyzing our software and recommending changes to the computer engineers. Although I did not write the code, I would try to follow along with the main ideas of each of the modules and make recommendations on fixes where I could.
I think that I contributed greatly to the project, especially in the field of expertise, hardware circuit design. However, in many cases, we worked together, each suggesting thoughts that would improve on each other’s ideas. I feel that we really worked as a team to combine each of our skills to successfully complete our objectives in the project.
A.3 Contributions of Patrick McLaughlin:
The first major individual contribution of mine to the project was the Packaging Specifications and Design homework. This involved comparing the MAVerick to a couple of commercial products, the SWORDS and the Rotundus. More importantly, a complete and thorough design of the MAVerick’s packaging was done, including a CAD drawing, a materials list with weight and part costs, and any tooling requirements that would be needed in completing the physical construction of the MAVerick.
The next major individual contribution was circuit prototyping and testing. Paul needed to complete the Circuit Design and Theory of Operation homework, and we wanted to make sure all the circuits worked before they were officially designed. Most of the circuits and components had datasheets and/or instructions on how to use them or what circuit to build around them for their use. One exception to this was the joystick. I contributed a lot in prototyping this circuit and seeing how all the pins for the buttons worked. Once it was determined which pins connected to which buttons and how, pull-up resistors had to be assigned. Most important was assigning a smart value for the pull-up resistor connected to the directional hat, so that when a voltage was read by the microprocessor, the analog to digital converter had an easy job. With a good resistor value, the differences in the voltages were greater. Also, I contributed in the building, testing, and debugging of the power block, trigger block, and DC motor block of the circuit. Notable mentions to these blocks include making sure enough voltage was provided to the actuator in order to pull the trigger and adding bigger capacitors to the power block in order to deal with multiple components running at the same time.
Next was board population. I populated almost all of the tank PCB. This included the use of flux and a soldering iron, referencing the schematic for correct placement of all parts, and testing to make sure solid connections were made in order to avoid burning out components.
Another major contribution was the Reliability and Safety Analysis homework. This included a reliability analysis of four major components of the MAVerick’s circuitry using military λP and the mean time to failure. Also, a failure mode, effects, and criticality analysis (FMECA) worksheet was completed highlighting what happens when certain components fail and how dangerous these effects are.
As the semester continued on, the technical need for the electrical engineers (Paul and I) diminished while the technical need for the computer engineers (Chad and Randy) increased. The circuits were all designed, built, and functional, while the microprocessor still needed to be coded. Consequently, Paul and I turned to physical construction. As the team member that completed the Packaging Design and Specifications homework, I had a major role in all decisions made and implementation of those decisions. In fact, while the first half of the semester was almost totally devoted to circuits, the second was definitely devoted to physical construction. The highlights were making cuts to the turret many times, mounting the stepper, mounting the actuator, mounting the paintball gun, and increasing the height of the joystick. In addition to the major changes made to the tank and joystick, any minor task that presented itself like the making of wires or fixing of burnt out parts was addressed by myself or Paul.
A.4 Contributions of Randall Scheifele:
Our group worked really well together throughout the entire semester to make a successful project. Each member played a vital role in that success, and following is some of my individual contributions that aided that success.
I was in charge of our patent liability analysis to satisfy one of our professional component homework assignments. When producing a commercial project it is important to investigate patents and other commercial projects that ours would resemble before going to market. I split up my search into four subcategories: use of a toy tank, DTMF encoding/transmitting/decoding, detecting obstacles using an array of passive infrared sensors, and detecting moving targets using an ultrasonic sensor. In the analysis, our design would literally infringe on one patent. This could be a major problem if our design went to market without this knowledge.
I was also in charge of our software design considerations to satisfy one of our design component homework assignments. In investigating the software design considerations I learned that we should have thought about this a lot sooner in the semester. I would have liked to have done some external interrupts but since our schematic and layout was done by the time I thought about software design it was too late.
My most significant contribution to the project was software development for the microcontroller. Chad and I handled all of the software for the entire project. We worked together to create code for both MAVerick and the Command Center and created all of the modules together and tested them to make sure they worked.
I was also involved in other aspects of the project but none as deeply as software. I assisted in some physical construction by drilling holes, gluing sensors on MAVerick, and soldering/connecting wires together. I also helped prototype our DTMF circuitry with Chad in the early stages of our design. Since I was the only one with some HTML experience, I also handled the website and kept that up to date as we turned in our homework assignments.
The success of this project wouldn’t have been complete without the hard work and dedication from each team member. In our team atmosphere it is hard to identify individual contributions because so much of our design was team oriented. Our team was constantly asking for advice and getting help with one another we really functioned as one unit. I believe that our team did an outstanding job and I am glad I was able to work with each of them this semester
Appendix B: Packaging
[pic]
Figure B.1: Picture of the SWORDS
[pic][pic][pic]
Figure B.2: Pictures of the Rotundus rolling ball
[pic][pic]
Figure B.3: Design package, tank and joystick view
Appendix C: Schematic
[pic]
Appendix D: PCB Layout Top and Bottom Copper
[pic]
[pic]
[pic]
[pic]
Appendix E: Parts List Spreadsheet
|Part Description |Part Number |Vendor |Quantity |Unit Cost |Total |
|Atmel Mega 16 Microcontroller |ATMEGA16-16PC |Digi-key |2 |6.56 |13.12 |
|DTMF Encoder |TP5089 |BG Micro |2 |1.25 |2.5 |
|DTMF Decoder |CM8870 |BG Micro |2 |4 |8 |
|Ultrasonic Sensor |615088 |Senscomp |1 |55 |55 |
|Crystal Oscillator |CTX400-ND |Digi-key |4 |1.31 |5.24 |
|Power NMOS MOSFET |IRF540N |Digi-key |4 |1.74 |6.96 |
|Power PMOS MOSFET |IRF5210 |Digi-key |4 |1.91 |7.64 |
|Power NMOS MOSFET |IRF530 |Digi-key |6 |1.08 |6.48 |
|Power PMOS MOSFET |IRF9530 |Digi-key |3 |1.73 |5.19 |
|Dsub 15 pin Female |152-3315 |Mouser |1 |0.99 |0.99 |
|Linear Regulator |7805 |Digi-key |1 |1.16 |1.16 |
|LDO Linear Regulator |MIC5237 |Mouser |1 |1.37 |1.37 |
|Remote Control Tank | |E-Bay |1 |59 |59 |
|Paintball Gun | |E-Bay |1 |33.45 |33.45 |
|Top Gun Joystick | |E-Bay |1 |32.45 |32.45 |
|Stepper Motor | |Jameco |1 |30 |30 |
|Linksys Wireless Webcam | |Amazon |1 |106.91 |106.91 |
| | | | | | |
| | | |Total | |375.46 |
Appendix F: Software Listing
Tank:
/*********************************************
This program was produced by the
CodeWizardAVR V1.23.8d Standard
Automatic Program Generator
© Copyright 1998-2003 HP InfoTech s.r.l.
e-mail:office@hpinfotech.ro
Project : Tank
Version : 1.0
Date : 3/24/2005
Author : ECE477 Group 11
Company : Top Guns
Comments:
That's right Ice Man.....I am dangerous
Chip type : ATmega16
Program type : Application
Clock frequency : 1.000000 MHz
Memory model : Small
External SRAM size : 0
Data Stack size : 256
*********************************************/
#include
#include
// Declare your global variables here
#define ACKNOWLEDGE_TONE 1
#define IMA_PHONE 1
#define IMA_JOYSTICK 15
#define UP 2
#define DOWN 5
#define LEFT 4
#define RIGHT 6
#define X_CENTER 13
#define Y_CENTER 14
#define TURRET_LEFT 11
#define TURRET_RIGHT 12
#define TURRET_CENTER 3
#define FIRE 10
#define SEARCH_MODE 8
#define OVERRIDE 7
int Direction = 5; //global current direction of the tank
int searchMode = 0; //boolean value of search mode or not search mode
int overrideMode = 0;
char currAim = 's';
int steps = 0;
unsigned char stepPos = 0x33;
unsigned char Distance[500] ={0};
/*
Function Signature: int get_tone( int tone )
Return Value: int - numerical representation of a DTMF tone
Parameters: None
Author(s): Chad and Randy
Description: This function checks port D pins 0-4 and
returns the number encoded or -1 if pin 0
is low
*/
int get_tone()
{
int tone = 0;
if ( PIND.0 != 1 )
tone = -1;
else
{
if ( PIND.4 == 1 )
tone += 1;
if ( PIND.3 == 1 )
tone += 2;
if ( PIND.2 == 1 )
tone += 4;
if ( PIND.1 == 1 )
tone += 8;
}
return tone;
}
/*
Function Signature: void send_tone( int tone, int duration )
Return Value: None
Parameters: int - numerical representation of a DTMF tone
int - time in milliseconds of the delay
Author(s): Chad and Randy
Description: This function sets port B according to
the input tone for the duration specified
by the second argument
0 - tone enable
1,2 - col output
3,4 - row output
*/
void send_tone( int tone, int duration )
{
switch ( tone )
{
case 1: PORTB.1 = 0;
PORTB.2 = 0;
PORTB.3 = 0;
PORTB.4 = 0;
break;
case 2: PORTB.1 = 1;
PORTB.2 = 0;
PORTB.3 = 0;
PORTB.4 = 0;
break;
case 3: PORTB.1 = 0;
PORTB.2 = 1;
PORTB.3 = 0;
PORTB.4 = 0;
break;
case 4: PORTB.1 = 0;
PORTB.2 = 0;
PORTB.3 = 1;
PORTB.4 = 0;
break;
case 5: PORTB.1 = 1;
PORTB.2 = 0;
PORTB.3 = 1;
PORTB.4 = 0;
break;
case 6: PORTB.1 = 0;
PORTB.2 = 1;
PORTB.3 = 1;
PORTB.4 = 0;
break;
case 7: PORTB.1 = 0;
PORTB.2 = 0;
PORTB.3 = 0;
PORTB.4 = 1;
break;
case 8: PORTB.1 = 1;
PORTB.2 = 0;
PORTB.3 = 0;
PORTB.4 = 1;
break;
case 9: PORTB.1 = 0;
PORTB.2 = 1;
PORTB.3 = 0;
PORTB.4 = 1;
break;
case 10: PORTB.1 = 1;
PORTB.2 = 0;
PORTB.3 = 1;
PORTB.4 = 1;
break;
case 11: PORTB.1 = 0;
PORTB.2 = 0;
PORTB.3 = 1;
PORTB.4 = 1;
break;
case 12: PORTB.1 = 0;
PORTB.2 = 1;
PORTB.3 = 1;
PORTB.4 = 1;
break;
case 13: PORTB.1 = 1;
PORTB.2 = 1;
PORTB.3 = 0;
PORTB.4 = 0;
break;
case 14: PORTB.1 = 1;
PORTB.2 = 1;
PORTB.3 = 1;
PORTB.4 = 0;
break;
case 15: PORTB.1 = 1;
PORTB.2 = 1;
PORTB.3 = 0;
PORTB.4 = 1;
break;
case 16: PORTB.1 = 1;
PORTB.2 = 1;
PORTB.3 = 1;
PORTB.4 = 1;
break;
}
PORTB.0 = 0;
//delay_ms(duration);
//PORTB.0 = 1;
}
/*
Function Signature: void Motor( void )
Return Value: None
Parameters: None
Author(s): Chad and Randy
Description: This function checks the value of the
global variable Direction and sets the
value of Port C in order to drive the
tank in that direction
*/
void Motor(void)
{
if ( PINA.0 == 1 && Direction == 6 && overrideMode == 0 ) Direction = 5; //front
else if ( PINA.1 == 1 && (Direction == 3 || Direction == 2 || Direction == 7) && overrideMode == 0 ) Direction = 5; //left
else if ( PINA.2 == 1 && (Direction == 4 || Direction == 1 || Direction == 7) && overrideMode == 0 ) Direction = 5; //back
else if ( PINA.3 == 1 && (Direction == 9 || Direction == 8 || Direction == 1) && overrideMode == 0 ) Direction = 5; //right
switch(Direction)
{ /*
case 1: PORTC.0 = 0;
PORTC.1 = 0;
PORTC.2 = 0;
PORTC.3 = 1;
break; */
case 2: PORTC.0 = 0;
PORTC.1 = 1;
PORTC.2 = 1;
PORTC.3 = 0;
break; /*
case 3: PORTC.0 = 0;
PORTC.1 = 0;
PORTC.2 = 1;
PORTC.3 = 0;
break; */
case 4: PORTC.0 = 0;
PORTC.1 = 1;
PORTC.2 = 0;
PORTC.3 = 1;
break;
case 5: PORTC.0 = 0;
PORTC.1 = 0;
PORTC.2 = 0;
PORTC.3 = 0;
break;
case 6: PORTC.0 = 1;
PORTC.1 = 0;
PORTC.2 = 1;
PORTC.3 = 0;
break; /*
case 7: PORTC.0 = 0;
PORTC.1 = 1;
PORTC.2 = 0;
PORTC.3 = 0;
break; */
case 8: PORTC.0 = 1;
PORTC.1 = 0;
PORTC.2 = 0;
PORTC.3 = 1;
break; /*
case 9: PORTC.0 = 1;
PORTC.1 = 0;
PORTC.2 = 0;
PORTC.3 = 0;
break; */
default: PORTC.0 = 0;
PORTC.1 = 0;
PORTC.2 = 0;
PORTC.3 = 0;
}
}
/*
Function Signature: void stepper( char )
Return Value: None
Parameters: None
Author(s): Chad and Randy
Description:
*/
void stepper( void )
{
if ( steps >= 250 && currAim == 'r' )
currAim = 's';
if ( steps 9 ) Direction-=3;
break;
case Y_CENTER:
if( Direction % 3 == 0 )
Direction--;
else if( Direction % 3 == 1 )
Direction++;
break;
case X_CENTER:
if( Direction > 6 )
Direction-=3;
else if( Direction < 4 )
Direction+=3;
break;
case TURRET_LEFT: if ( currAim == 'r' ) currAim = 's';
else if ( currAim == 's' ) currAim = 'l';
break;
case TURRET_RIGHT: if ( currAim == 'l' ) currAim = 's';
else if ( currAim == 's') currAim = 'r';
break;
case TURRET_CENTER: currAim = 's';
break;
case FIRE: PORTD.7 = 1;
delay_ms(100);
PORTD.7 = 0;
break;
case SEARCH_MODE: searchMode = 1;
break;
case OVERRIDE: overrideMode = overrideMode ^ 1;
break;
default: break;
}
Motor();
stepper();
return;
}
/*
Function Signature: void joyAction( int tone )
Return Value: None
Parameters: int - numerical representation of a DTMF tone
Author(s): Chad and Randy
Description: This function takes the input tone which is a
numerical representation of a DTMF tone and
performs an action based on that DTMF tone.
*/
void joyAction( int tone )
{
switch ( tone )
{
case UP: Direction = 6;
break;
case DOWN: Direction = 4;
break;
case LEFT: Direction = 8;
break;
case RIGHT: Direction = 2;
break;
case Y_CENTER:
if( Direction == 6 || Direction == 4 )
Direction = 5;
break;
case X_CENTER:
if( Direction == 2 || Direction == 8 )
Direction = 5;
break;
case TURRET_LEFT: if ( currAim == 'r' ) currAim = 's';
else if ( currAim == 's' ) currAim = 'l';
break;
case TURRET_RIGHT: if ( currAim == 'l' ) currAim = 's';
else if ( currAim == 's') currAim = 'r';
break;
case TURRET_CENTER: currAim = 's';
break;
case FIRE: PORTD.7 = 1;
delay_ms(100);
PORTD.7 = 0;
break;
case SEARCH_MODE: searchMode = 1;
break;
case OVERRIDE: overrideMode = overrideMode ^ 1;
break;
}
Motor();
stepper();
return;
}
/*
Function Signature: int Ultrasonic( int )
Return Value: int
Parameters: int
Author(s): Chad
Description: This takes the readings from the ultrasonic
and stores the distance.
*/
int Ultrasonic(int Readings)
{
unsigned int Counter, Counter2, Counter3, i;
unsigned int Total = 0 ;
Counter2 = 0;
Counter3 = 0;
for(i=0;i Readings * 2 * 100 )
{
i = 100;
}
if( Counter3 >= 5 )
{
i=100;
}
//delay_ms(10);
}
//PORTB = (Total / Counter2) | 0x80;
//PORTB = 0x01;
if( Counter2 == 0 )
{
return 0;
}
if( Counter3 > Counter2 )
{
return 0;
}
return (Total / Counter2);
}
/*
Function Signature: void Autonomous( void )
Return Value: None
Parameters: None
Author(s): Chad and Randy
Description: This function controls the autonomous
mode.
*/
void Autonomous(void)
{
int tempDistance = 0;
int Counter = 0;
if( steps > 0 )
{
currAim = 'l';
}
else
{
currAim = 'r';
}
while( steps != 0 )
{
stepper();
delay_ms(5);
}
currAim = 'r';
while( steps < 250 )
{
Counter++;
if( get_tone() == SEARCH_MODE )
{
searchMode = 0;
delay_ms(100);
return;
}
if( Distance[steps+250] != 0 )
{
if( Counter >= 10 )
{
tempDistance = Ultrasonic(20);
if( tempDistance != 0 )
{
Distance[steps+250] = ( Distance[steps+250] + tempDistance ) / 2;
}
else
{
Distance[steps+250] = ( Distance[steps+250] + 60 ) / 2;
}
Counter = 0;
}
else
{
delay_ms(5);
}
}
else
{
if( Counter >= 10 )
{
tempDistance = Ultrasonic(20);
if( tempDistance != 0 )
{
Distance[steps+250] = Ultrasonic(20);
}
else
{
Distance[steps+250] = 60;
}
Counter = 0;
}
else
{
delay_ms(5);
}
}
stepper();
//delay_ms(10);
}
currAim = 'l';
Counter = 0;
while( steps > -250 )
{
if( get_tone() == SEARCH_MODE )
{
searchMode = 0;
delay_ms(100);
return;
}
Counter++;
if( Distance[steps+250] != 0 )
{
if( Counter >= 10 )
{
tempDistance = Ultrasonic(20);
if( tempDistance != 0 )
{
Distance[steps+250] = ( Distance[steps+250] + tempDistance ) / 2;
}
else
{
Distance[steps+250] = ( Distance[steps+250] + 60 ) / 2;
}
Counter = 0;
}
else
{
delay_ms(5);
}
}
else
{
if( Counter >= 10 )
{
tempDistance = Ultrasonic(20);
if( tempDistance != 0 )
{
Distance[steps+250] = Ultrasonic(20);
}
else
{
Distance[steps+250] = 60;
}
Counter = 0;
}
else
{
delay_ms(5);
}
}
stepper();
//delay_ms(10);
}
currAim = 'r';
Counter = 0;
while( steps != 0 )
{
if( get_tone() == SEARCH_MODE )
{
searchMode = 0;
delay_ms(100);
return;
}
Counter++;
if( Distance[steps+250] != 0 )
{
if( Counter >= 10 )
{
tempDistance = Ultrasonic(20);
if( tempDistance != 0 )
{
Distance[steps+250] = ( Distance[steps+250] + tempDistance ) / 2;
}
else
{
Distance[steps+250] = ( Distance[steps+250] + 60 ) / 2;
}
Counter = 0;
}
else
{
delay_ms(5);
}
}
else
{
if( Counter >= 10 )
{
tempDistance = Ultrasonic(20);
if( tempDistance != 0 )
{
Distance[steps+250] = Ultrasonic(20);
}
else
{
Distance[steps+250] = 60;
}
Counter = 0;
}
else
{
delay_ms(5);
}
}
stepper();
//delay_ms(10);
}
Counter = 0;
do
{
Counter++;
if( steps >= 250 )
{
currAim = 'l';
}
else if( steps = 10 )
{
tempDistance = Ultrasonic(5);
if( tempDistance != 0 )
{
tempDistance = Distance[steps+250] - tempDistance;
/*
if( tempDistance < 0 )
{
tempDistance*= -1;
}
*/
if( tempDistance > 10 )
{
tempDistance = Distance[steps+250] - Ultrasonic(5);
if( tempDistance > 10 )
{
PORTD.7 = 1;
delay_ms(100);
PORTD.7 = 0;
}
}
}
Counter = 0;
}
else
{
delay_ms(5);
}
stepper();
}while( get_tone() != SEARCH_MODE );
searchMode = 0;
return;
}
/*
Function Signature: void joystick( void )
Return Value: None
Parameters: None
Author(s): Chad and Randy
Description: This function is an infinite while loop which
checks the value of the sensor inputs and sends
a tone to the Command Center based on the sensor
inputs. It also receives tones from the Command
Center and performs the appropriate action based
on the DTMF tone received.
*/
void joystick(void)
{
int tone, counter;
unsigned char leds, comparison;
leds = 0x00;
comparison = 0x00;
counter = 6;
//send_tone(ACKNOWLEDGE_TONE, 80);
while (1)
{
//This compares the current sensor inputs (PORTA)
//with what they were on the previous loop iteration.
//If any of the port pins are different than before,
//that bit is set high in 'comparison'. 'comparison'
//is then checked bit-by-bit and the appropriate tone
//is sent.
//comparison = leds ^ PINA;
counter++;
comparison = PINA;
comparison = comparison >> (counter-7) ;
//for(i=7;i> 1;
//}
if ( steps < -40 && steps > -63 && currAim != 's' ) //turret left
if ( currAim == 'r' )
send_tone(13, 80);
else
send_tone(11, 80);
else if ( steps > 40 && steps < 63 && currAim != 's' ) //turret right
if ( currAim == 'l' )
send_tone(13,80);
else
send_tone(12,80);
do //Loop until a tone is received
{
tone = get_tone();
Motor();
stepper();
} while( tone == -1 );
joyAction( tone );
if( searchMode )
{
Autonomous();
searchMode = 0;
}
delay_ms(10);
PORTB.0 = 1;
}
}
/*
Function Signature: void phone( void )
Return Value: None
Parameters: None
Author(s): Chad and Randy
Description: This function gets a tone input and
executes search mode if that is the
current mode or performs actions based
on incoming DTMF tones from a phone.
*/
void phone(void)
{
int tone;
searchMode = 0;
PORTB.0 = 1;
while(1)
{
do
{
tone = get_tone();
//tone = -1; // DELETE ME!!!!!!!!!!!!!!!!!
}while ( tone != -1 );
if( searchMode )
{
Autonomous();
}
else
{
do //Loop until a tone is received
{
tone = get_tone();
Motor();
stepper();
} while( tone == -1 );
//send_tone( ACKNOWLEDGE_TONE, 80 );
action( tone );
}
}
}
/*
Function Signature: void init( void )
Return Value: None
Parameters: None
Author(s): CodeVision
Description: This function sets all of our ports
data direciton registers and initial
values. It also sets some timer/counter
functionality which we do not use.
*/
void init( void )
{
// Input/Output Ports initialization
// Port A initialization
// Func0=In Func1=In Func2=In Func3=In Func4=In Func5=In Func6=In Func7=In
// State0=T State1=T State2=T State3=T State4=T State5=T State6=T State7=T
PORTA=0x00;
DDRA=0x00;
// Port B initialization
// Func0=Out Func1=Out Func2=Out Func3=Out Func4=Out Func5=Out Func6=Out Func7=Out
// State0=0 State1=0 State2=0 State3=0 State4=0 State5=0 State6=0 State7=0
PORTB=0x01;
DDRB=0xFF;
// Port C initialization
// Func0=Out Func1=Out Func2=Out Func3=Out Func4=Out Func5=Out Func6=Out Func7=Out
// State0=0 State1=0 State2=0 State3=0 State4=0 State5=0 State6=0 State7=0
PORTC=0x00;
DDRC=0xFF;
// Port D initialization
// Func0=In Func1=In Func2=In Func3=In Func4=In Func5=Out Func6=In Func7=Out
// State0=T State1=T State2=T State3=T State4=T State5=0 State6=T State7=0
PORTD=0x00;
DDRD=0xA0;
// Timer/Counter 0 initialization
// Clock source: System Clock
// Clock value: Timer 0 Stopped
// Mode: Normal top=FFh
// OC0 output: Disconnected
TCCR0=0x00;
TCNT0=0x00;
OCR0=0x00;
// Timer/Counter 1 initialization
// Clock source: System Clock
// Clock value: Timer 1 Stopped
// Mode: Normal top=FFFFh
// OC1A output: Discon.
// OC1B output: Discon.
// Noise Canceler: Off
// Input Capture on Falling Edge
TCCR1A=0x00;
TCCR1B=0x00;
TCNT1H=0x00;
TCNT1L=0x00;
OCR1AH=0x00;
OCR1AL=0x00;
OCR1BH=0x00;
OCR1BL=0x00;
// Timer/Counter 2 initialization
// Clock source: System Clock
// Clock value: Timer 2 Stopped
// Mode: Normal top=FFh
// OC2 output: Disconnected
ASSR=0x00;
TCCR2=0x00;
TCNT2=0x00;
OCR2=0x00;
// External Interrupt(s) initialization
// INT0: Off
// INT1: Off
// INT2: Off
MCUCR=0x00;
MCUCSR=0x00;
// Timer(s)/Counter(s) Interrupt(s) initialization
TIMSK=0x00;
// Analog Comparator initialization
// Analog Comparator: Off
// Analog Comparator Input Capture by Timer/Counter 1: Off
// Analog Comparator Output: Off
ACSR=0x80;
SFIOR=0x00;
SFIOR |= 0x04; //disables internal pull-up resistors
searchMode = 0;
Direction = 5;
currAim = 's';
steps = 0;
stepPos = 0x33;
return;
}
/*
Function Signature: void main( void )
Return Value: None
Parameters: None
Author(s): Chad and Randy
Description: This function calls the function init
and then recevies a tone which tells
the tank if it is going to be controlled
by a phone or the Command Center.
*/
void main(void)
{
// Declare your local variables here
int tone;
init();
PORTC = 0x00;
currAim = 's';
do
{
tone = get_tone();
} while( tone != IMA_JOYSTICK && tone != IMA_PHONE );
send_tone( ACKNOWLEDGE_TONE, 800 );
delay_ms(800);
if( tone == IMA_JOYSTICK )
{
joystick();
}
else /*IM_A_PHONE*/
{
phone();
}
}
Command Center:
/*********************************************
This program was produced by the
CodeWizardAVR V1.23.8d Standard
Automatic Program Generator
© Copyright 1998-2003 HP InfoTech s.r.l.
e-mail:office@hpinfotech.ro
Project : Command Center
Version : 1
Date : 3/22/2005
Author : ECE477 Group 11
Company : Top Guns
Comments:
No, boys. There's two O's in Goose
Chip type : ATmega16
Program type : Application
Clock frequency : 1.000000 MHz
Memory model : Small
External SRAM size : 0
Data Stack size : 256
*********************************************/
#include
#include
#define ADC_VREF_TYPE 0x20
// Read the 8 most significant bits
// of the AD conversion result
// Declare your global variables here
#define ACKNOWLEDGE_TONE 1
#define IMA_JOYSTICK 15
#define UP 2
#define DOWN 5
#define LEFT 4
#define RIGHT 6
#define X_CENTER 13
#define Y_CENTER 14
#define TURRET_LEFT 11
#define TURRET_RIGHT 12
#define TURRET_CENTER 3
#define FIRE 10
#define SEARCH_MODE 8
#define OVERRIDE 7
void set_led( int tone );
/*
Function Signature: unsigned char read_adc
(unsigned char adc_input)
Return Value: unsigned char - the value of the analog-
to-digital conversion
Parameters: unsigned char - the value of the port pin
to do the conversion
Author(s): CodeVision
Description: This function reads the port pin specified
by the first argument and returns the result
of the analog-to-digital conversion.
*/
unsigned char read_adc(unsigned char adc_input)
{
ADMUX=adc_input|ADC_VREF_TYPE;
// Start the AD conversion
ADCSRA|=0x40;
// Wait for the AD conversion to complete
while ((ADCSRA & 0x10)==0);
ADCSRA|=0x10;
return ADCH;
}
/*
Function Signature: int get_tone( int tone )
Return Value: int - numerical representation of a DTMF tone
Parameters: None
Author(s): Chad and Randy
Description: This function checks port D pins 0-4 and
returns the number encoded or -1 if pin 0
is low
*/
int get_tone()
{
int tone = 0;
if ( PIND.0 != 1 )
tone = -1;
else
{
if ( PIND.4 == 1 )
tone += 1;
if ( PIND.3 == 1 )
tone += 2;
if ( PIND.2 == 1 )
tone += 4;
if ( PIND.1 == 1 )
tone += 8;
}
return tone;
}
/*
Function Signature: void send_tone( int tone, int duration )
Return Value: None
Parameters: int - numerical representation of a DTMF tone
int - time in milliseconds of the delay
Author(s): Chad and Randy
Description: This function sets port B according to
the input tone for the duration specified
by the second argument
0 - tone enable
1,2 - col output
3,4 - row output
*/
void send_tone( int tone , int duration )
{
//int new_tone = -1;
switch ( tone )
{
case 1: PORTB.1 = 0;
PORTB.2 = 0;
PORTB.3 = 0;
PORTB.4 = 0;
break;
case 2: PORTB.1 = 1;
PORTB.2 = 0;
PORTB.3 = 0;
PORTB.4 = 0;
break;
case 3: PORTB.1 = 0;
PORTB.2 = 1;
PORTB.3 = 0;
PORTB.4 = 0;
break;
case 4: PORTB.1 = 0;
PORTB.2 = 0;
PORTB.3 = 1;
PORTB.4 = 0;
break;
case 5: PORTB.1 = 1;
PORTB.2 = 0;
PORTB.3 = 1;
PORTB.4 = 0;
break;
case 6: PORTB.1 = 0;
PORTB.2 = 1;
PORTB.3 = 1;
PORTB.4 = 0;
break;
case 7: PORTB.1 = 0;
PORTB.2 = 0;
PORTB.3 = 0;
PORTB.4 = 1;
break;
case 8: PORTB.1 = 1;
PORTB.2 = 0;
PORTB.3 = 0;
PORTB.4 = 1;
break;
case 9: PORTB.1 = 0;
PORTB.2 = 1;
PORTB.3 = 0;
PORTB.4 = 1;
break;
case 10: PORTB.1 = 1;
PORTB.2 = 0;
PORTB.3 = 1;
PORTB.4 = 1;
break;
case 11: PORTB.1 = 0;
PORTB.2 = 0;
PORTB.3 = 1;
PORTB.4 = 1;
break;
case 12: PORTB.1 = 0;
PORTB.2 = 1;
PORTB.3 = 1;
PORTB.4 = 1;
break;
case 13: PORTB.1 = 1;
PORTB.2 = 1;
PORTB.3 = 0;
PORTB.4 = 0;
break;
case 14: PORTB.1 = 1;
PORTB.2 = 1;
PORTB.3 = 1;
PORTB.4 = 0;
break;
case 15: PORTB.1 = 1;
PORTB.2 = 1;
PORTB.3 = 0;
PORTB.4 = 1;
break;
case 16: PORTB.1 = 1;
PORTB.2 = 1;
PORTB.3 = 1;
PORTB.4 = 1;
break;
}
PORTB.0 = 0;
delay_ms(duration);
PORTB.0 = 1;
return;
}
/*
Function Signature: void set_led( int tone )
Return Value: None
Parameters: int - numerical representation of a DTMF tone
Author(s): Chad and Randy
Description: This function sets LED's based on the
following tones: On/Off
Firing - 4
Search Mode - 5
Obstacle Override - 6
Obstacle Forward - 7
Obstacle Left - 8
Obstacle Behind - 9
Obstacle Right - 10
Motion Sensor Left - 11
Motion Sensor Forward - 12
Motion Sensor Right - 13
Connected - 14
*/
void set_led( int tone )
{
switch ( tone )
{
case 4: PORTD.6 = /*PORTD.6 ^*/ 0;
break;
case 5: PORTD.5 = /*PORTD.5 ^*/ 0;
break;
case 6: PORTC.7 = /*PORTC.7 ^*/ 0;
break;
case 7: PORTC.6 = /*PORTC.6 ^*/ 0;
break;
case 8: PORTC.5 = /*PORTC.5 ^*/ 0;
break;
case 9: PORTC.4 = /*PORTC.4 ^*/ 0;
break;
case 10: PORTC.3 = /*PORTC.3 ^*/ 0;
break;
case 11: PORTC.2 = /*PORTC.2 ^*/ 0; //LEFT (11)
PORTC.1 = 1;
PORTC.0 = 1;
break;
case 13: PORTC.1 = /*PORTC.1 ^*/ 0; //CENTER (13)
PORTC.0 = 1;
PORTC.2 = 1;
break;
case 12: PORTC.0 = /*PORTC.0 ^ 1*/ 0; //RIGHT (12)
PORTC.1 = 1;
PORTC.2 = 1;
break;
case 14: PORTD.7 = /*PORTD.7 ^ 1*/ 0;
break;
default: break;
}
return;
}
/*
Function Signature: void init( void )
Return Value: None
Parameters: None
Author(s): CodeVision
Description: This function sets all of our ports
data direciton registers and initial
values. It also sets some timer/counter
functionality which we do not use.
*/
void init( void )
{
// Input/Output Ports initialization
// Port A initialization
// Func0=In Func1=In Func2=In Func3=In Func4=In Func5=In Func6=In Func7=In
// State0=T State1=T State2=T State3=T State4=T State5=T State6=T State7=T
PORTA=0x00;
DDRA=0x00;
// Port B initialization
// Func0=Out Func1=Out Func2=Out Func3=Out Func4=Out Func5=In Func6=In Func7=In
// State0=0 State1=0 State2=0 State3=0 State4=0 State5=T State6=T State7=T
PORTB=0x00;
DDRB=0x1F;
// Port C initialization
// Func0=Out Func1=Out Func2=Out Func3=Out Func4=Out Func5=Out Func6=Out Func7=Out
// State0=0 State1=0 State2=0 State3=0 State4=0 State5=0 State6=0 State7=0
PORTC=0xFF;
DDRC=0xFF;
// Port D initialization
// Func0=In Func1=In Func2=In Func3=In Func4=In Func5=Out Func6=Out Func7=Out
// State0=T State1=T State2=T State3=T State4=T State5=0 State6=0 State7=0
PORTD=0xE0;
DDRD=0xE0;
// Timer/Counter 0 initialization
// Clock source: System Clock
// Clock value: Timer 0 Stopped
// Mode: Normal top=FFh
// OC0 output: Disconnected
TCCR0=0x00;
TCNT0=0x00;
OCR0=0x00;
// Timer/Counter 1 initialization
// Clock source: System Clock
// Clock value: Timer 1 Stopped
// Mode: Normal top=FFFFh
// OC1A output: Discon.
// OC1B output: Discon.
// Noise Canceler: Off
// Input Capture on Falling Edge
TCCR1A=0x00;
TCCR1B=0x00;
TCNT1H=0x00;
TCNT1L=0x00;
OCR1AH=0x00;
OCR1AL=0x00;
OCR1BH=0x00;
OCR1BL=0x00;
// Timer/Counter 2 initialization
// Clock source: System Clock
// Clock value: Timer 2 Stopped
// Mode: Normal top=FFh
// OC2 output: Disconnected
ASSR=0x00;
TCCR2=0x00;
TCNT2=0x00;
OCR2=0x00;
// External Interrupt(s) initialization
// INT0: Off
// INT1: Off
// INT2: Off
MCUCR=0x00;
MCUCSR=0x00;
// Timer(s)/Counter(s) Interrupt(s) initialization
TIMSK=0x00;
// Analog Comparator initialization
// Analog Comparator: Off
// Analog Comparator Input Capture by Timer/Counter 1: Off
// Analog Comparator Output: Off
ACSR=0x80;
SFIOR=0x00;
// ADC initialization
// ADC Clock frequency: 125.000 kHz
// ADC Voltage Reference: AREF pin
// ADC High Speed Mode: Off
// ADC Auto Trigger Source: None
// Only the 8 most significant bits of
// the AD conversion result are used
ADMUX=ADC_VREF_TYPE;
ADCSRA=0x83;
SFIOR&=0xEF;
SFIOR |= 0x04; //disables internal pull-up resistors
PORTC.1 = 0;
return;
}
/*
Function Signature: void main( void )
Return Value: None
Parameters: None
Author(s): Chad and Randy
Description: This function calls the function init
and then recevies a tone which tells
the Command Center that it is connected.
It then sets the conncted LED high and
enters an infinite while loop which decodes
the joystick input and sends an encoded DTMF
tone to reflect that position and checks the
incoming DTMF tones for status signals from the
tank to display them on the LED's.
*/
void main(void)
{
// Declare your local variables here
int tone;
int x_axis,y_axis,hat;
int i;
init();
/*test code*/
/*
while ( 1 )
{
send_tone( 1, 100 );
delay_ms(100);
send_tone( 2, 100 );
delay_ms(100);
send_tone( 3, 100 );
delay_ms(100);
send_tone( 4, 100 );
delay_ms(100);
send_tone( 5, 100 );
delay_ms(100);
}
*/
do
{
send_tone( IMA_JOYSTICK, 50 );
tone = get_tone();
} while( tone != ACKNOWLEDGE_TONE );
//send_tone(ACKNOWLEDGE_TONE, 780);
i = 0;
set_led( 14 ); //Connected
//delay_ms(1500);
while (1)
{
//if ( ++i == 5 )
//{
// i = 0;
//PORTC = 0xF8;
//PORTC.7 = 1;
PORTC.6 = 1;
PORTC.5 = 1;
PORTC.4 = 1;
PORTC.3 = 1;
//}
//Get Status Signal from Tank
//packet = get_status();
tone = get_tone();
//Light up proper LED
set_led( tone );
//Generate DTMF output for Joystick/Buttons
x_axis = read_adc(0);
if( x_axis > 180 ) //715
{
// PORTC.5 = 0;
send_tone(LEFT, 50);
}
else if( x_axis < 125 ) //473
{
// PORTC.3 = 0;
send_tone(RIGHT, 50);
}
else
{
send_tone(X_CENTER, 50);
//PORTC.7 = 0;
}
y_axis = read_adc(1);
if( y_axis > 141 ) //563
{
// PORTC.6 = 0;
send_tone(UP, 50);
}
else if( y_axis < 97 ) //389
{
// PORTC.4 = 0;
send_tone(DOWN, 50);
}
else
{
// PORTC.7 = 0;
send_tone(Y_CENTER, 50);
}
hat = read_adc(2);
if( hat > 65 && hat < 90 ) //500, 583 125 146
{
// PORTC.2 = 0;
send_tone(TURRET_LEFT, 50);
}
else if( hat > 125 && hat < 146 ) //716, 860 179 215
{
// PORTC.0 = 0;
send_tone(TURRET_RIGHT, 50);
}
else
{
// PORTC.1 = 0;
send_tone(TURRET_CENTER, 50);
}
if( PINA.4 == 0 )
{
// PORTD.6 = 0;
send_tone(FIRE, 50);
}
if( PINA.3 == 0 )
{
send_tone(SEARCH_MODE, 50);
PORTD.5 = PIND.5 ^ 1;
}
if( PINA.6 == 0 )
{
send_tone(OVERRIDE, 100);
PORTC.7 = PINC.7 ^ 1;
}
//delay_ms(1000);
// PORTD.6 = 1;
// PORTC = 0xFF;
}
}
Appendix G: User Manual
• 1.0 Product Description
Congratulations on your purchase of MAVerick, your personal mobile assault vehicle! MAVerick is a mobile tank with a paintball gun that can be controlled from anywhere that has cell phone service, practically anywhere in the world!
MAVerick’s mobility is unmatched, featuring high torque motors for climbing over cumbersome obstacles. In addition to more power, MAVerick’s treads offer the lucky user more turning options than simple wheeled vehicles. It is capable of the super-spin turn, spinning in place.
MAVerick also features a 300 degree rotating turret providing a wide target area.
In manual mode, the user can sit at his computer and view first person video. The user can see what MAVerick sees, all while controlling it from anywhere in the world with his cell phone! But that’s not all. MAVerick wouldn’t be complete without its wingman, Goose.
Goose is a joystick option that allows for arcade-like feel when controlling MAVerick, as opposed to pressing cell phone buttons. Goose’s easy and comfortable access to its buttons allows for a more enjoyable and realistic targeting experience.
MAVerick is like having two different vehicles in one, featuring two modes of operation. It isn’t just a manual vehicle that the user controls! It also has a mind of its own with its autonomous mode.
Autonomous mode puts MAVerick in a search for targets. It will sit and make sweeps with the turret until it detects motion, then it will fire at the moving target. It will continue firing until the target is out of range, which is not good news for your enemies!
Whether you want to easily infiltrate your enemies’ territory in a friendly game of paintball, defend your own territory in autonomous mode, enjoy a game of tank wars, or even see who’s the best shot in a game of target practice, the Top Guns are certain MAVerick is the vehicle for you.
• 2.0 Product Illustration
[pic]
[pic]
• 3.0 Product Setup Instructions
1. Open the box and verify the following contents: (1) rechargeable battery pack with charger, (4) AA batteries (for Goose Command Center), (1) paintball hopper, (1) pack of paintballs, (1) barrel plug, (1) barrel squeegee, (1) CO2 tank, (1) Goose Command Center, and (1) MAVerick.
2. The following contents must be supplied by the user: (2) cellular phones.
Goose Command Center Setup: (optional)
3. Open the bottom of the Goose Command Center and insert the 4 AA batteries as shown in Figure 3.1.
[pic]
Figure 3.1 Goose Command Center Batteries
4. Turn on the Command Center by flipping the switch and verify that the power LED turns on. If the LED does not turn on, see the troubleshooting section.
Tank Setup:
5. Insert the rechargeable battery pack in the bottom of the tank as shown in Figure 3.2.
[pic]
Figure 3.2 MAVerick Battery Pack
6. Insert the paintball hopper on the top of the tank as shown in Figure 3.3.
[pic]
Figure 3.3 Inserting paintball hopper
7. Insert the CO2 tank through the fastened loop as shown in Figure 3.4.
[pic]
Figure 3.4 Inserting the CO2 tank
8. Insert the paintballs into the paintball hopper as shown in Figure 3.5.
[pic]
Figure 3.5 Insert paintballs into the hopper
Connection Setup:
9. Attach one cell phone’s hands-free input to the Goose Command Center (optional).
10. Attach the other cell phone’s hands-free input to MAVerick.
[pic]
• 5.0 Troubleshooting
Tank doesn’t turn on: Check battery, Check the on/off switch.
Command Center doesn’t turn on: Check the polarity of the batteries. Check the on/off switch. Make sure you are using non-rechargeable batteries. Make sure the batteries have a full charge.
Tank will not connect: Make sure the tank is on. Make sure a strong cellular signal is present. Turn device off then on, dial the phone on the tank. If you are using the Goose command center, make sure it is properly plugged in to the hands-free socket on the dialing cell phone and that the command center is on. Within a few seconds, the connected LED should light up. If you are using the cell phone keypad, keep pressing the identify button (button 1) on the keypad until you receive a confirmation tone on your cell phone. You can verify that the tank is connected by pressing any of the keys that control the tank such as * or # to turn the turret.
Tank STILL will not connect: Unplug the cell phone on the tank and connect to it with the dialing cell phone. If you are using the Goose Command Center, make sure that the dialing cell phone is connected properly and that the Command Center is on. On the speaker of the tank cell phone, you should here a tone being broadcasted. If you cannot hear anything from the tank cell phone, verify that the command center is on and properly connected. If you are just using the dialing cell phones keypad to control the tank, press buttons on the keypad and verify that a tone is being generated from the tanks cell phone speaker. If not, verify the connection of the hands-free connection on the dialing cell phone.
NOTE: Not all cell phones output a tone when a key is pressed. Most likely, the phone will have a touch-tone or DTMF option that may need to be turned on.
Command Center does not control properly: Make sure the batteries have a strong charge. It may be possible for the Command Center to still turn on but not have enough power to operate correctly.
Turret will not turn: Make sure the tank battery has a full charge. Verify that there are no obstructions in the path of the turret. Verify that the cell phones are properly connected.
Turret rotates an uneven amount in opposite directions: When the tank is first turned on, the turret must be centered. Turn the tank off, center the turret and reconnect.
Tank will not move: Make sure the tank battery has a full charge. Verify that there are no obstructions in the path of the tank as the IR sensors can inhibit movement to avoid running into an obstacle. If the turret is able to move and not the tank, try using the override button to ignore the IR sensors, it is the lower thumb button on the Command Center or button 3 on the cell phone keypad. Verify that the cell phones are properly connected.
Tank will not fire: Make sure the tank battery has a full charge. Verify that the hopper has paintballs in it. It is possible that the gun has become uncocked, pull back on the brown wire on the back of the turret until you hear a click. A possible reason for the gun becoming uncocked is because the CO2 tank is running low. Another sign of running out of CO2 is when a rapid succession of shots occurs after shooting once. If either of these happens, you should refill or replace the CO2 tank.
Appendix H: FMECA Worksheet
|Failure No. |Failure Mode |Possible Causes |Failure Effects |Method of Detection |Criticality |Remarks |
|A1 |Voltage output = 0V |Shorted |No voltage gets to rest |Cannot detect |Low |MAVerick becomes useless|
| | |capacitors C7 or |of circuit |voltage drop | | |
| | |C8, or U4 is | |anywhere | | |
| | |damaged | | | | |
|A2 |Voltage output > 5.0V |U4 does not work |Too much voltage supplied|Observation |High |Possible damage to |
| | | |to rest of circuit | | |microcontroller and |
| | | | | | |other ICs, possible |
| | | | | | |safety issues |
|B1 |Failure of U9 or U10 |Oscillator |No output from DTMF |Observation |Low |MAVerick loses |
| | |damaged |encoder or decoder | | |communication ability, |
| | | | | | |if using cell phone then|
| | | | | | |MAVerick will get stuck |
| | | | | | |in current mode |
|B2 |Vdd = 0V |C9 or C10 shorted|No output from DTMF |Observation |Low |MAVerick loses |
| | | |encoder or decoder | | |communication ability, |
| | | | | | |if using cell phone then|
| | | | | | |MAVerick will get stuck |
| | | | | | |in current mode |
|C1 |Microprocessor has no |C14 shorted |Microprocessor constantly|Observation |Low |MAVerick becomes useless|
| |output | |resets | | | |
|C2 |Voltage drop in |Bypass capacitor |Too little voltage output|Observation |Low |Unpredictable effects, |
| |microprocessor |C15 shorted |from microprocessor | | |some components may not |
| | | | | | |work, possible collision|
|D1 |Current through status |R2 through R9, |Status LED will not work |Observation |Low |Won’t know the status of|
| |LEDs = 0A |R15, R16, or R32 | | | |your sensors or what |
| | |are shorted | | | |mode you’re in |
|E1 |No input from joystick |R1, R2, R3, or R4|Joystick buttons will not|Observation |Low |Command center will not |
| |buttons |are shorted |work | | |be able to control the |
| | | | | | |MAVerick |
|E2 |No input from directional|R5 shorted |Directional hat will not |Observation |Low |Command Center will not |
| |hat | |work | | |be able to move the |
| | | | | | |turret |
|F1 |Sensors constantly on |Q1, Q2, or Q3 |Sensors will waste power |Observation |Low |Unnecessary drain on the|
| | |damaged |by not turning off when | | |battery |
| | | |not in use | | | |
|F2 |Ultrasonic output = 0V |Q4 is damaged |Ultrasonic will not work |Observation |Low |Can’t determine when a |
| | | | | | |target is there to fire |
| | | | | | |at |
|G1 |Inverter chip output |Inverter chip is |Microcontroller can’t |Observation |High |Motors could potentially|
| |stuck in current logic |damaged |turn PMOS transistors off| | |become too hot, damaged,|
| |state | | | | |and a safety hazard |
|G2 |N-channel transistor |Q9, Q10, Q11, or |Either motor does not |Observation |High |Motors could get too |
| |shorted |Q12 is damaged |turn off or Vcc is | | |hot, and transistors |
| | | |shorted straight to | | |could get too hot |
| | | |ground | | | |
|G3 |P-channel transistor |Q13, Q14, Q15, or|Either motor does not |Observation |High |Motors could get too |
| |shorted |Q16 is damaged |turn off or Vcc is | | |hot, and transistors |
| | | |shorted straight to | | |could get too hot |
| | | |ground | | | |
|H1 |Diode is open |D12, D13, D14, or|Arc-suppression |Observation |High |Arc suppression could |
| | |D15 is shorted |protection is gone and | | |shock a human being |
| | | |could damage circuit | | | |
|H2 |Stepper motor does not |Q6, Q7, Q8, or |Stepper will get stuck in|Observation |Low |Turret cannot rotate |
| |work |Q17 is damaged |one state | | | |
|I1 |Trigger does not work |Q5 is shorted |Trigger will get stuck in|Observation |Low |Trigger will get stuck, |
| | | |pulled position | | |but the gun is not |
| | | | | | |automatic so only one |
| | | | | | |shot will be fired |
-----------------------
C-1
Comments:
Fig D.1 Command Center Top Copper
Fig D.4 Tank Bottom Copper
Figure C.1 Tank Schematic
Figure C.2 Command Center Schematic
D-1
Fig D.3 Tank Top Copper
Fig D.2 Command Center Bottom Copper
C-2
On/Off Switch
D-2
[pic]
Turret Hat
Autonomous Mode Toggle
Obstacle Override Button
Trigger
Autonomous Mode LED
Connected LED
Power LED
Power Switch
Obstacle Warnings
Turret Direction
Firing LED
Obstacle Override
Paintball Hopper
CO2 Tank
Ultrasonic Sensor
IR Obstacle Detectors
Hands-free Connector
Table 3.1 - Microcontroller comparison
[pic]
Table 3.2 – DTMF Encoder Comparison
[pic]
Table 3.3 – DTMF Decoder Comparison
[pic]
Table 3.4 – Ultrasonic Sensor Comparison
[pic]
Figure C.1 Tank Schematic
B-1
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- ee 477 final report purdue university
- critical incident response plan for first responders
- mmel cessna 525 cj cj1 cj1 m2
- wyoming yhec 2021 challenge rules and regulations
- template for developing sewer collection system preventive
- esl grade 3 5 historical perspectives model curriculum unit
- chief of naval air training
- ar2788 ar2788s fa1000 fa1234
- remote touchscreen controlled defense turret
- outcome measures tool kit va
Related searches
- final maturity of ee savings bonds
- final maturity date for ee bonds
- calculate ee bond final value
- ee savings bonds final maturity
- final cost report nysed
- purdue university plagiarism checker
- purdue university salaries
- project final report template
- project final summary report template
- final grant report sample
- project management final report example
- project management final report template