EE 477 Final Report - Purdue University
ECE 477 Final Report
Spring 2005
[pic]
Team Code Name: _DigiRover________________________________ Team ID: _8___
Team Members (#1 is Team Leader):
#1: _Cory Tenbarge______________ Signature: ____________________ Date: _________
#2: _Jim Weimer_________________ Signature: ____________________ Date: _________
#3: _Brian Ryall_________________ Signature: ____________________ Date: _________
#4: _Siou Lin____________________ 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 |3 |
| 3.0 Constraint Analysis and Component Selection |4 |
| 4.0 Patent Liability Analysis |9 |
| 5.0 Reliability and Safety Analysis |12 |
| 6.0 Ethical and Environmental Impact Analysis |17 |
| 7.0 Packaging Design Considerations |21 |
| 8.0 Schematic Design Considerations |25 |
| 9.0 PCB Layout Design Considerations |27 |
|10.0 Software Design Considerations |29 |
|11.0 Version 2 Changes |34 |
|12.0 Summary and Conclusions |35 |
|13.0 References |36 |
|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
This project is a wireless remote control car that transmits and receives signals over the internet. It is controlled through an internet interface, and can be driven anywhere a wireless signal is present. Streaming video feedback from the car will display on the internet interface to facilitate the operator in controlling the vehicle.
1. Project Overview and Block Diagram
The DigiRover is a remote control vehicle operable through a wireless internet control interface. A webcam attached to the DigiRover streams video back to the control interface, allowing the operator to see what the vehicle sees. The operator is able to pan and tilt the webcam from the control interface to broaden the “peripheral vision” of the DigiRover. The video feedback facilitates the operator in wirelessly driving the vehicle.
As a safety precaution, the DigiRover overrides manual control to autonomously prevent collision when an obstacle is detected in the front or at the rear of the vehicle. Additional sensory information, including temperature and cardinal direction, is wirelessly transmitted from the vehicle and dynamically updated on the control interface. After parking the vehicle, the operator is able to blast “Roll Out” by Ludacris from the DigiRover’s on-board speaker. The feature-laden DigiRover is replete with blinding headlights and “hyper-blue” ground effects.
[pic]
Figure 1-1: DigiRover Block Diagram
[pic]
Figure 1-2: DigiRover Side View
2. Team Success Criteria and Fulfillment
1) Ability to remotely control the vehicle through a web-based control interface
SUCCESS: An operator is able to remotely control the forward, reverse, left, and right movement of the vehicle from the web-based control interface. Additionally, the operator is able to control the speed of the vehicle, and turn the headlights on/off from the control interface.
2) Ability to transmit sensor and display information to the web-based control interface
SUCCESS: Temperature and direction sensors relay information back to the microcontroller. The microcontroller decodes these signals and dynamically updates the temperature and direction readings on the webpage every 0.1s.
3) Ability to detect and prevent vehicle collisions through autonomous braking
SUCCESS: IR sensors attached to the front and rear of the vehicle are used to detect obstacles in the vehicle’s path. The vehicle autonomously starts to brake when an obstacle is detected and successfully stops before a collision occurs.
4) Ability to pan and tilt the camera from the web-based control interface
SUCCESS: The pan and tilt functionality is implemented by two servo motors. The user is successfully able to pan the viewing area 180° and tilt the viewing area 90° from the web-based control interface.
5) Ability to control the play of pre-recorded audio from the web-based control interface
SUCCESS: The DigiRover blasts “Roll Out” by Ludacris from its on-board speaker as controllable by the user through the web-based control interface.
Constraint Analysis and Component Selection
Analysis of “Real World” Design Constraints
Computation Requirements
This project requires a considerable amount of computational capacity. The processor will perform the following tasks:
• Serve the webpage
• Perform actions based on controls sent by the webpage
• Communicate asynchronously with the temperature sensor [3]
• Watch the Hall Effect digital compass [4] in order to update direction
• Watch the IR distance sensor [5] through the ATD converter in order to slow or stop the car to prevent a collision
• Perform audio processing
Based on these computation requirements, the project requires a processor with enough processing power to produce audio while still being able to communicate over the web and monitor sensors.
The time the microcontroller takes to react to user commands and process signal information is critical to the performance of the car and the overall ability of the user to perform the intended tasks. Since information which needs to be quickly processed will be sent between the user and microcontroller while other computations are taking place (i.e. obstacle detection), the microcontroller needs a fast clock rate.
Interface Requirements
This project utilizes several external components. In order to access the web, the microcontroller must interface to an Ethernet Connector. This requires several pins. Fortunately, since microcontrollers which support Ethernet include Ethernet-specific pins, the number of general purpose pins does not affect the Ethernet Connector. Table 2-1 summarizes the requirements for the remaining components.
|Component |Required Interface |
|Thermometer [3] |SCI (1) |
|Infrared Sensors [5] |ATD (2) |
|Hall Effect Sensor [4] |General Purpose IO (4) |
|Motor |PWM (1) and IO pins (2) |
|Steering Servo |PWM (1) and IO pins (2) |
|Pan/Tilt Servos |PWM (1) |
|Headlight |General Purpose IO (1) |
|Speaker |PWM (1) |
Table 2-1: Interface Requirements
Power Supply Constraints
The car will run completely on battery power. Therefore power consumption is a major concern. The biggest consumers of power will be the webcam, motor, servos and the wireless bridge. The motor and digital compass will each run on 12V. The webcam, wireless bridge, thermometer sensor and IR distance sensors will each require 5V. The chosen microcontroller requires 3.3V.
|Component |Part Number |Quantity |V (V) |I (A) |
|Microcontroller |MC9S12NE64 |1 |3.3 |0.285 |
|Wireless Internet Camera |DCS-900W |1 |5.0 |0.9 |
|Temperature Sensor |DS18B20 |1 |5.0 |0.001 |
|IR Distance Sensor |GP2Y0A02YK |2 |5.0 |0.033 |
|Wireless Bridge |DWL-810+ |1 |5.0 |~0.5 |
|Servo |Parallax, 900-00005 |2 |5.0 |~0.5 |
|Digital Compass |1490 |1 |8 to 13 |0.12 |
|Motor | |1 |~12 |1 |
| |3.339 |
Table 2-2: Power Requirements
The vehicle will require three supply voltages. The 3.3V source for the microcontroller will only have to supply enough current to run the microcontroller. In contrast, the 5V and 12V sources must each supply a significant amount of current. The 12V source will need to supply about one amp to run the motor. The 5V source will need to supply almost two amps to power the camera, wireless bridge and a servo.
Because of the large amount of power needed to run the components, and the possibility of a significant amount of current being drawn, either a large battery or several medium size batteries will be required. Knowing that we cannot really expect to get more than about an hour of operation time out of a reasonably priced battery, the chosen battery also needs to be rechargeable.
Packaging Constraints
Several packaging constraints must be taken into consideration. First, because everything must be mounted on or fit inside the car, the size and weight of the components must be taken into account. Two of the largest components, the camera and wireless bridge, will be attached to the outside of the vehicle’s shell. Second, because the motor must still be able to move the car when it is loaded with all of the components, the car must be large enough to hold all of the components and powerful enough to turn the motor and steer.
Cost Constraints
The primary cost constraint concern is to keep the costs as low as possible without sacrificing functionality. With the intended audience for this product being users of a remote, mobile surveillance/rescue system, it will not be mass produced. This application has a small user base with specific needs so functionality will take precedence over cost. We estimate prototyping costs to be around $500.
Rationale for Component Selection
Microcontroller
In order for this project to succeed, we know that the choice of microcontroller is imperative. The microcontroller needs to be able to handle a decent amount of processing and provide the peripherals required, most importantly, the Ethernet interface.
Due to the fact that we need an Ethernet interface, the search for a microcontroller was quickly narrowed down to two choices. Rabbit and Freescale both provide microcontrollers with all of the peripherals required for this project. The Rabbit RCM 3200 series processor provides the Ethernet interface and other peripherals needed, along with an abundance of extra flash memory. Rabbit Semiconductor sells several processors with an Ethernet interface, but I will focus the comparisons with the Rabbit RCM 3200 since most features are similar to the other Rabbit chips. The Freescale MC9S12NE64 [1] provides the same features but contains significantly less Flash and SRAM memory.
Both microcontrollers provide plenty of IO pins for driving the car and connecting the Hall Effect sensor (9 pins required). Moreover, the microcontroller must perform a considerable amount of processing. The 44.2 Mhz Rabbit compared to the 25 Mhz Freescale is not a straight forward comparison though. Freescale’s microcontroller performs instructions within a couple clock cycles, but the Rabbit microcontroller can take several more clock cycles in order to execute an instruction. In addition, the project requires four Pulse Width Modulators, which both processors provide. Finally, the Freescale chip has only one extra Serial Communication Interface (SCI), while the Rabbit has several extra SCI.
Both microcontrollers provide all of the features needed. The only major difference between the processors is the amount of SRAM and Flash. The Rabbit provides significantly more memory, which would allow us to play higher quality sound for a longer amount of time. Nevertheless, since we are only planning on playing short alert messages, the 64k of flash on the Freescale chip should be sufficient.
Since we could accomplish the project with either processor, price and reputation were the ultimate motivating factors in our final decision of microcontroller. Freescale’s reputation for reliability and ease-of-use appeared to be more respectable than Rabbit’s. Freescale’s reputation, combined with the fact that the Freescale processor is significantly cheaper, prompted us to choose the MC9S12NE64.
Vehicle
We had several different options in choosing the vehicle for this project. First, we could have built the chassis entirely by hand, installing the wheels, servos, and motor ourselves. This approach would give us more control over how the car looked and drove. Conversely, we could buy an RC car, strip it down to the base, wheels, motor and servo, then attach our components onto the car. This method would allow us to focus on the more Computer Engineering aspects of the design instead of the mechanics of designing the car from scratch.
While trying to decide whether to build or buy a car we found an RC car that looked like an Escalade at Wal-Mart for only $45. In order to build the car we expected to spend around $100. The reduced cost and ability to spend more time on the Computer Engineering aspects of the design process persuaded us to buy the Escalade and strip it down. Plus the Escalade looks cool!
Battery
The proper choice of battery is very important to the success of this project. Everything on the car relies on battery power. The battery must be able to supply enough current at the correct voltage in order to power all of the components for a reasonable amount of time. Operation time is the limiting factor in choosing the battery. A longer-running battery will be larger and heavier than a shorter-running battery. If the battery weighs down the car too much, the motor won’t move it. Therefore the battery must provide a good balance between battery life and weight.
We estimated that the 3.0 amp hour Power-Sonic battery [6] would last about an hour on the vehicle. The NiMH battery would last even longer. However, the NiMH battery is heavier and costs considerably more. Once we decided that one hour was a reasonable amount of time for the car to run, we chose the Power-Sonic battery. The reduced weight also increases the battery life by reducing the physical load on the motors.
List of Major Components
|Component |Vender |Part Number |Unit Cost |Quantity |Total Cost |
|Microcontroller |Freescale |MC9S12NE64 [1] |$17.24 |1 |$17.24 |
|RC Car |Newbright |Escalade |$45.00 |1 |$45.00 |
|Wireless Internet Camera |D-Link |DCS-900W [2] |$109.86 |1 |$109.86 |
|Temperature Sensor |Dallas Semiconductor |DS1822 [3] |$1.97 |1 |$1.97 |
|Digital Compass |Images SI Inc |1490 [4] |$15.95 |1 |$15.95 |
|IR Distance Sensor |Sharp |GP2Y0A02YK [5] |$15.63 |2 |$31.26 |
|Battery |Power-Sonic |PS-1230 [6] |$14.91 |1 |$14.91 |
|Servo |Parallax |900-00005 [7] |$16.00 |2 |$32.00 |
Table 2-3: List of Major Components
3. Patent Liability Analysis
Results of Patent Search
A thorough search was performed using the United States Patent and Trademark Office’s database to avoid any possible patent infringements. An internet search using the keywords of “Robot”, "Internet”, and “Control" and “802.11” was performed at the United States Patent and Trademark Office (). The following is a list of existing patents that our vehicle could possibly be infringing upon:
Patent: 6,845,297: Method and system for remote control of mobile robot (1/9/03)
Relevant Summarized Description
The objective of the invention is to provide a method for the intuitive tele-operation and user interface for remotely controlling a robot. The method of control of the robot is particularly suited for systems with asynchronous communication. Furthermore, the invention provides additional information to the user in the form of a graphical overlay to improve navigation of a remotely controlled robot. An intuitive user interface provides a means for remotely changing the active waypoint towards which a remotely-controlled robot is moving.
Patent: 6,658,325: Mobile robotic with web server and digital radio links (1/14/02)
Relevant Summarized Description
The robot’s communication mechanism is a short-range wireless digital connection using the 2.4 GHz band and digital protocols following either the IEEE 802.11, 802.15, or other digital communications protocol. The robotic system uses three different general method of control: local robotic control, remote automated control, and remote human control. Local robotic control would typically handle routine, simple, or fast response-time tasks that are best done by executing previously stored instructions using the robot's onboard computing facilities. It is anticipated that the robot would receive its most general (highest level) commands from a remote Internet link. However, there may often be situations where it is advantageous to enable the robot to interpret and modify these top-level commands in a quick, real-time manner, depending upon the state of the robot's sensors and local conditions. In other situations, the robot may be used to perform repetitious tasks that fit within the capability of the robot's onboard computer processor.
Patent: 6,868,314: Unmanned aerial vehicle apparatus, system and method for retrieving data (6/27/02)
Relevant Summarized Description
This system, in its simplest form, consists of a flying radio-controlled aircraft weighing less than 40 kg, an onboard digital memory unit with processor, and a wireless interface operating under a protocol such as IEEE 802.11, Home RF, Bluetooth or perhaps some other proprietary protocol. Enhancements to the system could include, but are not limited to, a global positioning system (GPS) receiver for directing the unmanned aerial vehicle to a ground based sensor location and an on board autonomous flight control system such as flight computer, waypoint memory, wing leveler, rate gyro, altimeter (radar or barometric), airspeed indicator, additional flight control uplink, automatic landing para foil or parachute, etc. …
Analysis of Patent Liability
Literal Infringement
The DigiRover literally infringes patent 6,658,325: Mobile robotic with web server and digital radio link. A remote operator uses an 802.11 wireless internet connection to communicate with the DigiRover. All complex computations (i.e. steaming video) are computed and performed by a separate computing device. In the event that a hazard is present the DigiRover will override any human commands to act quickly and prevent harm to itself or other objects. Additionally, data is transmitted about the DigiRover’s current location to the remote user via the wireless 802.11 connection. All these functions are directly stated in the aforementioned patent, thus constituting a literal infringement.
Infringement under Doctrine of Equivalents
Patent 6,845,297: Method and system for remote control of mobile robot, uses an internet based control to communicate with the mobile robot for direct and absolute control. The DigiRover is directly controlled via the internet, but also has the ability to override the remote operator’s directions. Although the patent does perform a similar function, the semi-autonomous nature of the Digi-rover should constitute a substantial difference in operation.
Patent 6,868,314: Unmanned aerial vehicle apparatus, system and method for retrieving data, deals with the feedback of information to the remote operator. The DigiRover is designed to be able to feed back data from on-board sensors to the remote user. However, the DigiRover also interprets the data in order to make logical decisions. Its ability to avoid obstacles is the primary example. While sensory data is being relayed back to the remote operator, the DigiRover uses the data to ensure its own safety and the safety of its immediate surroundings. Since the patent deals only with the direct relay of sensory data, this should constitute a substantial difference in operation. Additionally, this patent deals with an aerial vehicle implementation, while the DigiRover is a surface vehicle.
Action Recommended
There is a literal infringement with our current design. If the DigiRover is to be produced commercially, a new method of communicating with the remote operator needs to be implemented, or royalties paid to the patent holder. A new method of communicating with the remote operator defeats the purpose of the project which was to implement an internet based remote control vehicle.
Therefore, it would be recommended to investigate the cost of royalties to the patent holder or to buy the patent, before the DigiRover can be commercially produced. The other possible patent infringements are resolved by the semi-autonomous nature of the DigiRover, which must remain in the design.
4. Reliability and Safety Analysis
Reliability Analysis
The reliability analysis below focuses on the key parts that are high risk for failing in our design. These components include the microcontroller, the linear regulator, power MOSFET, Tip32C, and the switching regulator. The equations came from the Military Handbook of Reliability Prediction of Electronic Equipment [12] to determine the mean time to failure for evaluating the reliability of components in a design. Some of the values could not be found in the data sheets of the components under consideration so estimation was used to complete the equation.
Motorola MC9S12NE64 Microcontroller [13]
λ_p = (C1*П_T + C2*П_E) × П_Q × П_L Failures/106 Hours
Parameters
C1 = 0.28 ([12] section 5.1)
• Our microcontroller is a 16 bit microcontroller [13].
Π_T = 0.84 ([12] section 5.8)
• The microcontroller will have an operating range of -40 °C to 105 °C [13]. I assumed that our design should not exceed 80 °C during operation.
C2 = 0.0457 ([12] section 5.9)
• C2 was found from an equation since a 112 pin microcontroller was not listed in the table.
• C2 = (2.8 x 10^ (-4) * (number of pins) ^ (1.08)
Π_E = 2.0 ([12] section 5.10)
• 2.0 was chosen for this parameter because it was assumed that the design is operating in a “ground fixed” mode of operation.
Π_Q = 10 ([12] section 5.10)
• This parameter was selected due to the component being commercially made.
Π_L = 1.0([12] section 5.10)
• 1.0 was chosen since I assumed the part has been in production for greater than 2 years.
Result
From the above formula it was determined that the microcontroller has a[pic]of 3.266 per 10^6 hours. The mean time to failure is 306184 hours. The mean time to failure of the microcontroller will be around 34.95 years.
LM Linear Regulator - LM2576/TO [3]
λ_P = (C1*П_T + C2*П_E)*П_Q*П_L Failures/106 Hours
Parameters
C1 = .01 ([12] section 5.1)
• I assumed the part has under 100 transistors.
Π_T = 1.5([12] section 5.8)
• Based on the maximum temperature component will have. The LM2576 has an operating range of -40 °C to 125 °C [14]. I assumed that our design should not exceed 100 °C.
C2 = .00092 ([12] section 5.9)
• C2 was found in the table with this part having three pins.
Π_E = 2.0 ([12] section 5.10)
• 2.0 was chosen for this parameter because it was assumed that design is operating in a “ground fixed” mode of operation.
Π_Q = 10 ([12] section 5.10)
• This parameter was selected due to the component being commercially made.
Π_L = 1.0([12] section 5.10)
• 1.0 was chosen since I assumed the part has been in production for greater than 2 years.
Result
From the above formula it was determined that the linear regulator has a[pic]of 0.1684 failures per 10^6 hours. The mean time to failure is 5938242 hours. The mean time to failure of the linear regulator will be around 677.8 years.
Power Mosfet – IRL530N/TO [4]
λ_p = λ_B*Π_T*Π_A*Π_Q*Π_E
Parameters
λ_B= .012 ([12] section 6.4)
• This part is a MOSFET.
Π_T = 3.7 ([12] section 6.4)
• I assumed that this part should not exceed 100 °C.
Π_A = 8.0 ([12] section 6.4)
• This part has a rated output power of 79 W, so 8 was chosen.
Π_Q = 4 ([12] section 6.4)
• The quality factor could not be determined in the datasheet so I assumed a quality factor in the middle of the range of values.
Π_E = 1.0([12] section 6.4)
• 1.0 was chosen since this part is ground fixed.
Result
From the above formula it was determined that the power MOSFET has a[pic]of 1.4208 per 10^6 hours. The mean time to failure is 703828 hours. The mean time to failure of the power MOSFET will be around 80.3 years.
TIP 31C and TIP32C [5]
λ_p = λ_B*Π_T*Π_A*Π_Q*Π_E
Parameters
λ_B = 0.012 ([12] section 6.4)
• This part is a MOSFET.
Π_T = 3.7 ([12] section 6.4)
• I assumed that this part should not exceed 100 °C.
Π_A = 4.0 ([12] section 6.4)
• This part has a rated output power of 40 W, so 8 was chosen.
Π_Q = 4 ([12] section 6.4)
• The quality factor could not be determined in the datasheet so a quality factor in the middle of the range of values.
Π_E = 1.0([12] section 6.4)
• 1.0 was chosen since this part is ground fixed.
Result
From the above formula it was determined that the transistor has a[pic]of 0.7104 per 10^6 hours. The mean time to failure is 1407657 hours. This means the mean time to failure of the transistor will be around 160.7 years.
LM Switching Regulator - LM317/TO220 [17]
λ_P = (C1*П_T + C2*П_E) * П_Q*П_L
Parameters
C1 = .01 ([12] section 5.1)
• This part I assume has less than 100 transistors
Π_T = 1.5 ([12] section 5.8)
• The parts operating temperature is from 0 °C to 150 °C. An operating temperature of 100 °C was assumed.
C2 = .00092 ([12] section 5.9)
• This part has three pins and was found in the table.
Π_E = 2.0 ([12] section 5.10)
• 2.0 was chosen for this parameter because it was assumed that design is operating in a “ground fixed” mode of operation.
Π_Q = 10 ([12] section 5.10)
• This parameter was selected due to the component being commercially made
Π_L = 1.0([12] section 5.10)
• 1.0 was chosen since I assume the part has been in production for greater than 2 years.
Result
From the above formula it was determined that the switching regulator has a[pic]of 0.1684 per 10^6 hours. The mean time to failure is 5938242 hours. The mean time to failure of the switching regulator will be around 677.8 years.
Conclusion
From the reliability and safety analysis, it can be determined that the component with the shortest mean time to failure is the microcontroller (34.95 years). The values chosen for the finding the mean time to failure of the microcontroller were higher than the expected values for normal operation. One to improve the mean time to failure is to add a heat sink to the microcontroller to make sure it stays at a reasonable operating temperature. Additionally, introducing a sleep mode while the microcontroller is idle may help reduce power consumption.
The other components inspected in this section are from the motor control circuit and power supply. To improve the mean time to failure for these sections, an adjustment may be made to the schematic to make sure the devices operate within the normal operating temperatures.
5. Ethical and Environmental Impact Analysis
Ethical Impact Analysis
IEEE states: “Successful businesses benefit from standards both by actively participating in the standardization process and by using standards as strategic market instruments” [19]. In order to bring our product in compliance with IEEE’s standards, several ethical issues must be addressed and resolved before bringing our design to market.
I. Electrical Reliability
One potential cause of electrical malfunction is unexpected circuit behavior resulting from low battery levels. To resolve this issue, a battery monitor is included in the circuit that monitors the output voltage of the battery. When the voltage falls below a critical level, the vehicle will automatically shut down. In additional to implementing electrical monitoring safeguards, the product must be tested under a variety of operating conditions in order to ensure that it will operate safely and correctly.
Proper enclosure of our electrical components is instrumental to product safety and reliability. Enclosing electronic components will prevent both user injury and protect the circuit from external factors that could possibly damage it, such as water or dust. Because our vehicle operates on a 12 V battery, it is unlikely that electrical shock will result in any serious injury. Nevertheless, a warning label ought to be placed near the PCB that states: WARNING! Electric components may cause shock [26].
Although most of our electrical components reside within the plastic body of the car, there are loose wires and electrical contact points inside the vehicle. Furthermore, our electrical components are not completely enclosed by the plastic vehicle shell. Thus, water has the opportunity to get inside the car and damage the internal circuitry through the roof of the car. Before we manufacture our vehicle, we must first secure the loose wires within the vehicle, both for safety and aesthetic reasons. Second, we must cover the opening on the roof of the car. Finally, we must specify in the user’s manual not to operate the vehicle under conditions where it may come in contact with water.
II. Mechanical Reliability
Mechanical reliability is a direct function of both product usability, durability and failure safeguards. Before we manufacture our product, we must implement several design changes to enhance the usability of our product. For instance, the vehicle’s power switch is located on the PCB, which will be encased by the body of the vehicle. The user will have no means of accessing the power switch from the exterior of the vehicle. Thus the power switch must be moved to a location easily accessible to the user.
Another example of where we would have to improve usability is the mounting of our rechargeable battery. Currently, the battery is mounted by means of duct tape to the bottom of the car. This proves to be a problem because the battery is not easily removable for recharge as the anode and cathode of the battery is encased within the shell of the car. A user would have to remove the shell in order to recharge the battery. A mass-manufactured version of our car should contain a compartment for storing the battery such that it can easily be removed for recharge.
Concerning the issue of physical durability of our product, we must thoroughly test the vehicle under a variety of operating conditions to make sure that mechanical parts do not fail. As previously mentioned, we should warn against the operation of our vehicle on rough terrain in the user manual. One area of possible concern is that the servos used to pan and tilt our camera are not enclosed. Therefore, they are at greater risk of getting damaged. In order to protect the servos, we ought to enclose them.
Finally, further failure safeguards must be implemented. Although our design implements front and rear obstacle detection and collision prevention, we have not considered the case of sudden drops in surface level. For instance, if the user is operating the vehicle at the top of the stairway, there is no safeguard preventing the vehicle from falling down the stairway. This hazard is a major concern because our application is intended for remote operation and the only visual feedback to the operator of the vehicle’s surroundings is a real-time streaming video with a slight propagation delay. Under our current functional implementation, the webcam is affixed at a level, forward position while the vehicle is in motion. Thus, the user can only pan and tilt the camera when the vehicle is at rest. In order to effectively detect drops in ground level, the user must be able to tilt the camera towards the ground. Moreover, the delay in streaming video exasperates the problem since it reduces the time a user has to react to detected level drops.
Several methods may be employed to aid this problem. First, we could allow the camera to pan and tilt at while the vehicle is in motion. Second, restrict the maximum speed of the vehicle so that the user has enough time to react to detected drops in surface level. Third, we could attach additional distance sensors under the car and angle them to detect the ground level directly in front of and directly behind the vehicle. The vehicle would immediately stop in response to detecting a sudden drop in surface level in the direction in which it is traveling. Finally, we could include a section in the user manual that warns against operating the vehicle in unfamiliar territory or where drops may be present.
III. Software Reliability
Perhaps equally as important electrical and mechanical reliability is software reliability. Software must be carefully coded to account for as many error conditions as possible. For instance, if the computer loses its connection with the router attached to the vehicle, then a failure mode detection and recovery algorithm must be employed to ensure the safety of the vehicle. In addition to accounting for as many potential error conditions as possible, the software must also be thoroughly tested to make sure it does not contain any bugs.
IV. User Education
Finally it is our responsibility to inform the user about the ethical use of our product. Because our product contains a streaming webcam which may be used to broadcast illicit material, we ought to include a section in our user manual detailing both the intended use of our product, and warning against the illegal or unethical application of our product. For instance, we are under ethical obligation to warn the user against using our device in such places as movie theaters or public bathrooms.
Environmental Impact Analysis
There are several environmental issues that must be considered in all stages of our product’s life cycle. From its initial fabrication to its final disposal, our product poses several threats to the environment. This section outlines the potential threats our product places on the environment and possible means to ameliorate these harms.
I. Manufacture
Several potential environmental risks arise from the fabrication of the parts used in our project. Most notably, the fabrication of our PCB poses the most severe threat to the environment. Many of the processes used in etching PCBs use strong acids, which cause many health risks and pose a great threat when released in the environment [20]. First, a face shield, chemically resistant gloves, and a lab coat must be used in order to protect the handler against potential spills when handling these strong acids [20]. Moreover, proper methods of disposal must be enforced in the manufacturing process. For instance, the acids could be neutralized before flushing into the sewer system [20]. The Environmental Protection Agency suggests safer alternatives means of fabricating PCBs, such as dry plasma metal deposition to replace the permanganate process [18, 21]. We ought to weigh the costs of employing “greener” alternative methods of manufacture before beginning production.
The soldering of electrical components to the board also poses a severe environmental and health threat. The main hazard of soldering comes from the fluxes that are used to prepare the metal for soldering [22]. Also detrimental to health is the effect of the fumes given off while soldering [22]. The hazard of airborne contaminants can be reduced by means of general dilution and local exhaust ventilation [22].
II. Normal Use
We foresee little environmental hazards within the useable lifespan of our product. However, because both our PCB and battery contain lead, coming in contact with the lead in these components may pose as a potential health risk. Because the user should not have direct access to the PCB, the lead that it contains is not an immediate problem. However, leakage from our lead-acid battery could pose a potential threat to both user health and the environment. Thus we should take appropriate measures to ensure that our battery is properly sealed.
III. Disposal/Recycling
The disposal of our lead-acid rechargeable battery and PCB poses a large threat to the environment. As lead has been know to cause several health risks such as kidney damage, brain damage, and disruption of nervous system, we must ensure that the components of our car that contain lead are properly disposed [23]. For instance, the battery can be taken to a rechargeable battery recycling corporation. A consumer could find the nearest location with respect to where they live by going to and entering the city and state, or zip code in which they live [24]. In conclusion, we should take precautions to ensure that our product is as environmentally friendly as possible. We must work to reduce the environmental and health hazards of our product during fabrication as well as inform our consumers of the proper disposal of our product.
6. Packaging Design Considerations
Analysis of Commercial Products
PatrolBot™
PatrolBot [27] is a mobile surveillance robot which can be controlled from an application on a separate computer. This robot is available from ActivMedia Robotics [28]. PatrolBot’s size is 24 inches long by 19 inches wide by 16 inches tall. An optional dome to protect the camera and wireless antennae is an additional 12 inches higher.
PatrolBot is constructed of an aluminum case in order to protect the electrical components. Two foam-filled nylon drive wheels along with two balancing casters provide its means of motion. The foam in the wheels would allow the robot to continue moving even after a wheel has a hole. The wheels are almost completely covered by the aluminum shell in order to provide additional protection. This very durable design weighs 45 kg and is capable of carrying 12 kg of additional weight.
All of the protective packaging does come at a cost though. The weight of the robot, 45 kg, makes moving it very difficult. Maintenance would require extra time in order to get to the damaged component because of the extra packaging.
[pic]
Figure 7-2: PatrolBot
We plan to protect most of the electrical components inside of a light plastic vehicle shell. Collisions will be almost completely avoided by the ability of our robot to detect obstacles and change the speed in order to prevent a collision. The DigiRover will not be as well armored and subsequently not as heavy as the PatrolBot. As our aim is a little different being only a surveillance robot, we felt a lighter, stealthier approach was more appropriate. A lighter robot means a less armored robot considering our budget.
Danduct Clean Inspection Robot
Danduct Clean [31] provides a robot which can be used to inspect air ducts for ventilation problems called the Inspection Robot [30]. This product provides video on a TV which can be controlled by the user with a control box. All data is sent over a 33 meter cable. The control box has a joystick to control the movement along with other switches to control other features such as the lights.
The Inspection Robot looks like a small RC car with a camera and light mounted on the chassis. The communication cable connects to the rear of the car. This robot is not meant to be battered around like the PatrolBot [27]. The camera, light and wheels do not have any protective cover. The robot is 215 mm long by 190 mm wide by 110 mm high and it weighs 3 kg.
The size and construction provide for a small and very light car. This would allow the robot to maneuver through small areas such as air ducts without having trouble getting stuck. Another nice feature of the Inspection Robot is that the camera has a lens in the front and rear of the car. The user can see in both directions without turning the car.
[pic]
Figure 7-3: Inspection Robot
A disadvantage of this car though is that it is wired. The user must be within 33 meters of the car at all times. Also the camera is fixed to the car without a way to pan or tilt it. Because of the cars small size, it would be nice to at least be able to tilt the camera vertically.
We would like the DigiRover to be light in order to allow it to move around easier. A lighter car would also allow us to use a smaller motor to turn the wheels and this would use less power. Using less power is very important for the DigiRover since it is completely battery powered.
Our vehicle will allow the user to move the camera unlike the Inspection Robot’s fixed camera. We feel a movable camera would be very useful for such a short robot. The packaging for the DigiRover will be stronger and a little heavier than the Inspection Robot. The PatrolBot and the Inspection Robot are good examples of the extremes of protective packaging. We will aim for a nice median between the two.
Specifications for the DigiRover
The DigiRover will have the outer appearance of an Escalade RC car with a few additions. Figure 7-4 shows the component layout of the DigiRover.
[pic]
Figure 7-4: DigiRover Component Layout
Figure 7-5 shows the pan-tilt design as found on the Superdroid Robotics website [37].
[pic]
Figure 7-5: Camera Platform Assembly
The battery will be able to sit on the chassis behind the rear wheels. It will be in a nice position to allow the user to attach the charger to the battery without going through the trouble of removing it. The construction of the DigiRover will not have many tooling requirements. Only basic tools will be required. We estimate that the following tools will be used:
• Screw drivers
• Soldering and de-soldering equipment
• Wire strippers
• Cutting tools (for plastic)
Table 7-1 shows the weight and cost requirements for all of the components used in the DigiRover. The car will be relatively light (about 10 pounds). The light weight will allow us to conserve power while moving the vehicle.
|Component |Quantity |Weight (lbs) |Total Weight (lbs) |Unit Cost |Total Cost |
|MC9S12NE64 Microcontroller and PCB |1 |~1 |~1 | $ 17.24 | $ 17.24 |
|Escalade RC Car |1 |~5 |~5 | $ 45.00 | $ 45.00 |
|Wireless Internet Camera |1 |0.6 |0.6 | $ 109.86 | $ 109.86 |
|Temperature Sensor |1 |~0 |~0 | $ 3.87 | $ 3.87 |
|Digital Compass |1 |~0 |~0 | $ 15.95 | $ 15.95 |
|IR Distance Sensor |2 |~0 |~0 | $ 15.63 | $ 31.26 |
|Power-Sonic Battery |1 |2.6 |2.6 | $ 14.91 | $ 14.91 |
|Wireless Bridge |1 |0.34 |0.34 | $ 64.99 | $ 64.99 |
|Servo |2 |~0.1 |~0.2 | $ 16.00 | $ 32.00 |
| | | |9.74 | | $ 335.08 |
Table 7-1: Weight and Unit Cost
7. Schematic Design Considerations
Microcontroller
The MC9S12NE64 – CPV micro controller is the brain of our onboard system. We clock the controller at 25 MHz to operate the internal web server and audio reproduction software. An onboard web-server and audio reproduction are the main processing pieces of the controller. A special RJ-45-connector with built in transformers is needed to connect to the wireless router and internet. Based on what the operator’s choices, the controller asserts signals to perform the desired operation. Various signals are fed back to the controller for processing and possibly perform an output operation. A 3.3 volts power supply is needed for operation at a maximum of 250 mA.
Power Supply
The ultimate power source of the vehicle is a 12 volt, 3.4 amp hour rechargeable lead acid battery. This specific battery was chosen for its loading characteristics and cost. The needed output voltages are: 12 volt unregulated (battery), 5.0 volt regulated, 3.3 volt regulated. The 5.0 volts must be able to source a maximum of 2.0 amps. A LM2576/TO switching regulator was chosen for its efficiency (84% at 5 volts), simplicity of surrounding circuitry, and available current (3 amps). The 3.3 volts must be able to source a maximum of 0.5 amps. A LM317/TO220 linear regulator was chosen for its ability to source current (1.5 amps) and dissipate power (15 Watts). A battery meter circuit returns a scaled down battery voltage to the controller for monitoring. All the grounds for the power circuit will connect at a single point.
Motor Drive Circuit
An H-bridge circuit was built to drive the motor in forward and reverse. IRF 9630 and IRF 630 MOSFETs where chosen for current rating (9A) and cost. The control signals are optically isolated from the H-bridge Circuitry. A 2.5 Amp inline fuse is placed between the H-bridge and 12 volts unregulated power to prevent damage to the transistors and motor. A braking signal is optically connected to a 12 volt, 5 amp relay. The relay shorts the motor terminals together when the brake signal is low (which is its state out of reset).
Steering Drive Circuit
An H-bridge circuit was built to drive a DC actuator either left or right. The circuit was built from 2N3702 (PNP) and 2N3704 (NPN) transistors. A 27 ohm resistor connects the H-bridge to ground to help slow down the DC actuator’s turning speed (less power) and to protect the circuit. The circuit runs off the 12 volt unregulated battery.
Sensors
Each sensor (temperature, distance, and direction) communicates directly with the controller. All sensor circuits are connected to power through either a switch or jumper. Protective circuitry is attached between the controller and direction and distance sensors since they operate at 5 volts. The Temperature sensor uses an analog voltage to communicate with the controller.
Pan/Tilt Platform Control
Two parallax 5.0 volt standard servos are used to control the pan and tilt of the webcam platform. These servos were chosen for their low power consumption and sufficient torque. Two optically isolated pulse signals from the controller each drive one servo to the desired position as specified by the operator through the web interfa1ce.
Audio Control and Memory Expansion
Audio data is stored as a 4 bit .WAV format on an external nonvolatile 512k SRAM (which has an internal battery and is rated to retain its contents for 10 years). The controller will output a reset and clock signals to two PLACE26V12 PLDs, which in turn will serve as the program counter, outputting a 19-bit address to the SRAM. The SRAM will transmit a 4-bit digital encoded audio signal back to the controller though a parallel interface. The conversion of the 4-bit data into an analog signal will be performed by the controller. The PWM signal from the controller will interface with an external active filter and pre-amplifier constructed of 4 LM324 op-amps. The final amplifier consists of a TIP 31C Power BJT which will act as a class D amplifier.
8. PCB Layout Design Considerations
The layout of our printed circuit board must satisfy several specifications. First the RC car shell in which we are placing the board constrains the board size. Additionally, two section of our design required large amount of power. Thus, large parts had to be placed at specific areas of the board. Each of these major considerations will be discussed in detail below.
We decided to place the board underneath the plastic seating and on top of the plastic base of the car. Since the board was going underneath the seating, there was a height restriction on certain areas of the board. We had to keep all the taller parts to one side so they could fit into the area under the seating. The area of our board had to be around 5 inches by 7.5 inches.
On our PCB board, placement of the components was a key issue. The motor control circuit required heat sinks on all the transistors which took up a large amount of space. The heat sinks needed to be placed near the top of the board so there was enough clearance under the plastic seating of the RC car. The power supply circuit contained many radial capacitors and a relay which also had to be placed in the upper portion of the board so there is enough clearance under the plastic seating. The motor control and power supply need to be separated since they are analog. Also, this portion of the design needed to be separated as much as possible since those parts generate a lot of heat. These parts of our design contained most of our tall parts and had to be placed on the upper portion of the board since we had more height clearance there. The digital components and sensors were placed on the other side of the board.
[pic]
Figure 8-1: General Placement of Component Sections
The power supply and motor control circuits required large trace widths so they could handle the current going through that portion of the design. From a PCB trace width calculator [39] we found that we needed at least 80 mils width to have a temp gain of only a couple of degrees and to allow the current we need through that part of the circuit.
Sensor placement was also a consideration we needed to make. The temperature sensor needed to be placed far enough away from the power supply and motor control so that the temperature reading will be as accurate as possible. We placed the sensor on the outward extension of the board to accommodate this requirement. We also put our digital compass to one edge of the board so it would not experience interference from the other components, especially the inductor. The rest of our sensors are off the board so their headers were placed to the edges of the board to prevent EMI [38].
The microcontroller was placed near the center of the board so we could keep the traces coming from the microcontroller as small as possible. Also, the decoupling capacitors and all other resistors and capacitors that connected directly to the micro were placed on the second layer so they could be close as possible to the microcontroller. To suppress the noise on the board the oscillator was based near the center of the board and near the microcontroller. All the traces used 45° angles for the traces [38]. Finally, the Ethernet controller needed to be placed as close as possible to the microcontroller and also include a ground plane underneath it [40].
In conclusion, our printed circuit board design required much consideration and many placement strategies. We had to take into account the space and heat requirement s for different sections of the schematic and make sure that these sections do not interfere with other section of the circuit. Finally we needed to make sure the board will fit into the predetermined space in the RC car.
9. Software Design Considerations
Software Introduction
The Freescale MC9S12NE64 microprocessor with embedded web server functionality serves as the core “brain” of the DigiRover. Because this is a real-time system, the main objective is to minimize service latencies of time-critical event triggers. The interrupt-driven service mechanism of the DigiRover will be refined to incorporate a priority-based servicing policy. Interrupts will periodically be generated by the microcontroller in order to transmit operator commands to the DigiRover and update sensor readings on the webpage. The primary software considerations are vehicle movement controls, peripheral communication, audio interface, and autonomous collision prevention.
Software Considerations
I. Memory Models
The NE64 microprocessor was chosen for its built-in Ethernet capability, an essential component to our project. One minor drawback of using the NE64 is that it contains only 64KB of Flash EEPROM and 8KB of SRAM. The complete web server is estimated to use approximately 20KB of Flash storage space. Because the storage of audio data requires a large amount of memory, an external 4MB non-volatile SRAM will be used for the storage of audio files. We are dealing with a flat memory model since the NE64 does not support virtual on-demand paging; the entire program must be loaded in the physical memory of a stand-alone embedded system. Taking the additional external memory into consideration, storage space will not be a foremost concern in our design. Regardless, we do not use any recursive constructs, complex data structures, or any routines that require the incorporation of a large library in our code.
II. Memory Sections/Mappings
Two main types of memory are used. The following is an explanation of each:
➢ Flash: Flash is non-volatile memory with a limited write life. It is used to hold permanent program code and any static constant data. Our web server is located in this section of memory. No temporary data will be stored in Flash.
➢ SRAM: SRAM is typically volatile memory that will support a virtually unlimited number of writes. It has faster read and write access times than Flash. All temporary variables will be stored in the on-board SRAM. Additionally, an external non-volatile SRAM will be used to store audio data.
The following figure displays how memory is mapped in the NE64 [1].
[pic]
Figure 10-6: MC9S12NE64 Memory Map
We are using OpenTCP, an open source TCP/IP stack software that is compatible with the CodeWarrior IDE, to develop our web server. One major advantage in using CodeWarrior is that it compiles C code into NE64-native object code, handling all memory mapping and layout details during compilation.
III. Startup Code
On system startup or reset, the application initialization code generated by CodeWarrior takes care of the memory mapping, initializing the system stack and BSS. Upon completion of this task, our main routine is called, which performs these additional initializations:
➢ Initialize clock speed
➢ Initialize value registers for all I/O pins used
➢ Initialize data direction registers for all I/O pins used
➢ Initialize mode registers for TIM, ATD, SCI, etc.
After all initializations take place, application-specific routines are called.
IV. Organization of Embedded Application Code
OpenTCP translates .htm files into .h and .c files and outputs a hash value based on the file name. In turn, CodeWarrior compiles these files, maps each to a unique address space, and is able to access them by looking up their hash values from a lookup table. In accordance to the OpenTCP framework, our application code is organized as follows:
➢ mainwebserver.c: Initializes all startup values, and then enters an infinite loop waiting for service interrupts.
➢ Vectors.c: Interrupt vector table linking each software trap to its respective interrupt.
➢ ne64driver.c: Interrupt service routines.
➢ FileSys.c: Hash table which lays out where each web server file is stored in memory.
➢ https_callbacks.c: Intercepts control interface requests and executes the appropriate instructions in response to those requests.
➢ main.htm: Defines the layout of the user control interface.
➢ [action].htm: Signals a specific service action. For instance, clicking on the 50% Duty Cycle button will prompt the pwm4_50.htm file to be loaded, which in turn signals https_callbacks.c to set the TIM4 channel to a 50% duty cycle.
Software Design Narrative
I. Vehicle Movement Control
➢ Motor: A timer channel is used to simulate a PWM signal that drives the motor. From the control interface, the user can change the duty cycle along with the forward and reverse direction of the motor.
➢ Steering: The steering uses two general output signals to drive a DC actuator. From the control interface, the user can change the left/right movement of the DigiRover.
➢ Obstacle Detection and Avoidance: Two IR sensors mounted at the front and the rear of the vehicle will each send a respective analog signal to two ATD channels. An autonomous obstacle detection and avoidance algorithm will compute the distance to the nearest obstacle and stop in order to avoid collision.
➢ Pan-tilt: Two timer channels will be used to control the servos that pan and tilt the camera. The user will be able to pan and tilt the camera from the control interface.
II. Audio Interface
➢ Memory Write: A timer channel is used to generate periodic data, address clock, and write enable signals use to write audio data to the external SRAM. The memory write function will be hidden from user access.
➢ Memory Read: Three address select signals will be used on address reset to set the external SRAM to a specified address. A timer channel will serve as an address clock, allowing for the sequential access of data from the external SRAM. The user can request to play audio files from the control interface as long as the vehicle is not in motion.
➢ Audio Digital to Analog Conversion: Audio is stored in 8-bit 11.024 kHz mono WAV format. The individual bytes in the file are signed values ranging from -128 to 127, corresponding to 0% and 100% duty cycles, respectively. A timer channel is used to output an audio signal of varying duty cycle.
III. Peripheral Devices/Sensors
➢ Headlights/Ground Effects: The headlights and ground effects can be turned on and off from the control interface.
➢ Temperature Sensor: The temperature sensor uses ATD channels to request and receive temperature readings. The analog readings are converted to the temperature in Fahrenheit through use of table look up. The temperature reading will be updated every 0.1s on the control interface.
➢ Digital Compass: The digital compass uses four bits to output eight possible directions. The direction reading will periodically be updated on the control interface.
IV. Web Control Interface
The web interface will be coded in HTML and will serve as a GUI to the embedded functionality. Along with allowing access to vehicle movement control, audio interface, and peripheral communication, the control interface will also display streaming video from a standalone webcam unit.
Software Documentation
I. Algorithms
➢ Audio
1. Set the pc_rst signal high to reset to the starting point
2. Set the respective timer output compare register to interrupt within a specified period of time: TC4 = TCNT + Constant.
3. Inside the ISR:
a) If reset is low, set high
b) Toggle the timer channel output.
c) Reset output compare register: TC4 = TCNT + Constant.
d) Set flag if the end of file has been reached.
➢ Temperature
1. Receive analog temperature every 0.1 s.
2. Look up the temperature value using the look-up table.
3. Repeat from Step 1.
➢ Cardinal Direction
1. Read and decode the direction reading.
2. Display result on the control interface.
3. Repeat from Step 1.
➢ Obstacle Avoidance
1. Compute distance to nearest obstacle from the IR senor reading.
2. Determine if vehicle is moving toward or away from the obstacle
3. Start slowing down if an obstacle is detected and vehicle is moving toward the obstacle.
4. Stop if nearest obstacle is within 0.5 ft of the DigiRover.
5. Repeat from Step 1.
II. Listing
See Appendix F.
10. Version 2 Changes
• Enhance front obstacle detection ability by placing two additional IR sensors at the front corners of the vehicle.
• Enhance rear obstacle detection ability by placing two additional IR sensors at the rear corners of the vehicle.
• Make battery compartment more aesthetically pleasing by constructing it out of materials other than wires and duct tape.
• Make battery more accessible for recharging by making it more easily removable.
• Make power switch more accessible by moving it from the PCB to the shell of the car.
• Facilitate vehicle controls by using JavaScript to allow the use of directional pads to steer vehicle.
• Add level detection by adding IR sensors to the bottom of the vehicle to prevent the vehicle from falling at sudden drops in ground level.
• Clean up tangle of wires inside the shell of the vehicle.
• Incorporate a larger flash memory for audio.
• Amplify the speakers.
Summary and Conclusions
This project was a success on account of all the hard work and dedication our team put forth throughout the semester to accomplish our goal. We made sure to order our parts early and utilize lab consultation hours. It involved several overlapping phases that included: forming a project idea, researching parts, designing the schematic, mapping the PCB layout, and coding the software.
Because our project consisted of integrating together several major components, we were able to effectively utilize division of labor to ensure individual accountability. Although we divided several tasks, a large portion of this project consisted of integrating our individual contributions. Thus, we effectively worked as a team to put together, test, and fine-tune the final product. Essentially, teamwork is what made this project a success.
Throughout the semester, our lab notebooks played a crucial role in documenting the important design choices we made. We tried to keep our notebooks as up-to-date as possible in order to account for the time we put forth on the project, and to inform other members of the team of what was accomplished through our efforts. This semester certainly reinforced the fact that communication is essential to good teamwork. Team members frequently communicated via email to schedule team meetings and to discuss project considerations. Effective communication helped us avoid the pitfalls of redoing tasks that another team member had already accomplished.
Overall, the project was a definite success. It satisfied all five of its success criteria. More importantly, we learned invaluable lessons in designing, testing, debugging, and teamwork. We will certainly apply the lessons we learned with us to future projects.
References
[1] Freescale, MC9S12NE64 Microcontroller Datasheet
[2] D-Link, DCS-900W Wireless Internet Camera
[3] Dallas Semiconductor, DS1822 Temperature Sensor
[4] Dinsmore Sensing Systems, 1490 Hall Effect Sensor
[5] Sharp, GP2Y0A2YK Analog IR Distance Sensor
[6] Power-Sonic, PS-1230 Rechargeable 12V 3.0 AH Battery
[7] Parallax, 900-00005 Standard Servo
[8] United States Patent and Trademark Office.
[9] Patent Number: 6,845,297 Title: Method and system for remote control of mobile robot.
[10] Patent Number: 6,658,325 Title: Mobile robotic with web server and digital radio links.
[11] 6,868,314: Title: Unmanned aerial vehicle apparatus, system and method for retrieving data.
[12] MIL-HDBK-217F – Military Handbook of Reliability Prediction of Electronic Equipment
[13] Parallax, 900-00005 Standard Servo
[14] Datasheet for LM2576/TO
[15] Datasheet for IRL530N/TO
[16] Datasheet for TIP31C
[17] Datasheet for LM317/TO220
[18] Environmental Protection Agency
[19] IEEE Code of Ethics
[20] PCB Fabrication
[21] PCB Fabrication Hazards and Alternatives
[22] Soldering Safety and Hazards
[23] Dangers of Lead Exposure
[24] Battery Recycling
[25] Environmental Education Reform
[26] Warning Labels
[27] ActivMedia, PatrolBot™
[28] ActivMedia Robotics
[29] Danduct Clean, Inspection Robot
[30] Danduct Clean
[31] D-Link, DWL-810+ Ethernet Wireless Bridge
[32] D-Link, DCS-900W Wireless Internet Camera
[33] Dallas Semiconductor, DS1822 Temperature Sensor
[34] Dinsmore Sensing Systems, 1490 Hall Effect Sensor
[35] Sharp, GP2Y0A2YK Analog IR Distance Sensor
[36] Power-Sonic, PS-1230 Rechargeable 12V 3.0 AH Battery
[37] Superdroid Robotics, Camera Pan and Tilt Assembly
[38] Motorola AN1259
[39] PCB Trace Width Calculator
[40] MotorolaAN2759
Appendix A: Individual Contributions
A.1 Contributions of Cory Tenbarge:
I was the team leader for this project. This role consisted of organizing and planning meetings. I tried to keep the other members up to date on the progress being made. I also made it a point to push members to work on their individual work in order to meet deadlines.
During the first two weeks of the project, in addition to planning the DigiRover, I also wrote the PHP scripts necessary to allow online submission of notebook entries. The webpage allowed us to easily update our notebooks anywhere without logging into the server to edit files. I believe this saved a lot of time and guaranteed uniformity among the four online notebooks. I also hosted the team’s webpage on my own personal Linux server because of the need for PHP support.
I was the main person in charge of software during the length of the project. I worked with OpenTCP, the open source web server ported to our microprocessor, at the beginning of the project to insure that we would be able to accomplish all of our success criteria which relied on the web server. This was not a trivial task though due to the non-existence of any online documentation or tutorials for the use of OpenTCP. I had to rely on reading through the code and comments in order to see how to manipulate the software for our own use. I was able to get the web server to perform actions by clicking on links. I found that I could intercept the request for a web page, execute my own code, and then serve the page as normal. I was also able to create dynamic content by intercepting the request for certain web pages and performing the action of filling the buffer to be sent to the client myself. Once I was able to control the car through the web browser and also create dynamic content, I knew it was possible to pass all of the success criteria.
I completely wrote and debugged the code which moved the pan and tilt servos, controlled the motor speed and direction, moved the steering actuator, toggled the lights and camera power, decoded the digital compass data, interpreted the distance sensor data and changed the motor speed accordingly, and decoded the temperature sensor data. Jim assisted in the debugging process by making any changes necessary to the hardware while I worked with the software. I accomplished the pan and tilt of the camera platform and the motor speed control by using Pulse Width Modulator (PWM) signals. I had to use the Analog to Digital (ATD) module in order to get the data from the IR distance sensors and the temperature sensor. I also wrote the initialization code which is executed upon reset, and I also wrote the extra code to insure that all of the mutually exclusive tasks were performed as such.
I spent quite a bit of time working on the audio. I was eventually not successful, but Jim took over and got the audio working. I wrote timer Interrupt Sub Routines (ISRs) which changed the duty cycle of a PWM signal based on the value of a byte from a WAV file. I believe the problem I ultimately had was due to my ISR taking longer to execute than the amount of time between interrupts. Jim was able to correct this by writing the ISR in assembly.
In total, I had 269.5 hours logged in my online notebook. Most of this time consisted of software development. Jim and I spent a considerable amount of time working in tandem in order to debug the hardware and software simultaneously.
A.2 Contributions of Jim Weimer:
I was the only aspiring electrical engineer on our team, and therefore I assumed most of the hardware-related work. I designed, using datasheets provided by Freescale, the circuitry surrounding the microcontroller, including circuitry for a power-up reset, in-circuit programming, an external oscillator, and an RJ-45 Ethernet connector. I designed a three level power supply consisting of a 12-volt lead acid battery, 5-volt switching regulator, and 3.3-volt linear regulator. I designed and prototyped an optically isolated 30 Watt motor controller consisting of a discrete component Metal Oxide Semiconductor Field Effect Transistor (MOSFET) arc suppressed H-bridge circuit and a Double Push Double Throw (DPDT) relay to remove the motor from the circuit for safety and short terminal leads for dynamic braking. I designed and prototyped an optically isolated steering controller consisting of a discrete component Bipolar Junction Transistor (BJT) arc suppressed H-bridge. Additionally, I designed and prototyped a sixth order low pass filter with 20 dB of attenuation at 10 kHz, a pre-amplifier and discrete component 15-Watt Class D power amplifier. I designed other smaller circuits to perform various operations such powering Light Emitting Diodes (LEDs), interfacing sensors, and interfacing servos for their use in a pan/tilt arrangement. Since I had designed most of the circuits, I also created the entire schematic.
Although I was not supposed to create the printed circuit board (PCB) layout, the team member in charge of this portion was struggling. I repositioned almost all the components, and proceeded to route the board. A great effort on my part ensured that the PCB would be compact and fit into our space-limited packaging design. The shape of the PCB, placement of tall components, required maximum trace lengths, necessary minimum trace widths, and location of heat dissipating components, all where driving forces in the final placement and routing configuration. Ultimately, I routed over 95% of the PCB using a mere 8 vias. The team member in charge of the homework finished the last few routes.
Once receiving the PCB, I was in charge of populating and testing the board. I populated the entire board, with the exception of a few by-pass capacitors near the microcontroller. I tested (without using the microcontroller) the populated PCB as each sub-circuit was completed. I helped Cory debug the hardware/software interface issues associated with the port pins on the microcontroller as he finished software segments. I performed all the needed fly-wirings and any post-PCB production redesigns.
I performed all the necessary mechanical alterations to the vehicle in order to mount the PCB, LEDs, and the pan/tilt servos. I also designed and manufactured the actual pan/tilt platform.
After the hardware portion was completed, I began helping with the software. I coded the audio driver in assembly to cut down on the bus cycles needed to complete the timer-interrupt service routine and speed up the rate at which it could interrupt. I also wrote a function in Matlab (‘bitkiller.m’), whose input was an 8-bit .WAV file, and output was only the upper 4 bits of each byte saved into a series of 10 kB files.
In total, I spent over 340 on the project, and designed, built and tested almost everything associated with hardware. Towards the end, I even created some software since time was running low.
A.3 Contributions of Siou Lin:
I contributed to this project in several ways. In the beginning of the semester, I was in charge of designing the team webpage layout. During the initial phases of the project, I helped research parts that would be needed in our design. I selected the switching power supply and helped search for webcams we could use on our vehicle. Additionally, I built the test circuit for the digital compass and tested that component to ensure its functionality.
My largest contribution to the hardware aspect of our project was designing the memory interface. Because we had a limited number of pins available to implement the memory interface, I had to find a way to make the memory interface utilize as few pins as possible. The two options I researched were:
1. Conducting the audio signal processing externally such the audio data would not have to be fed back into the microcontroller.
2. Using an external program counter to sequentially access the audio files stored in memory.
Due to time constraints in completing the schematic, I was unable to figure out how to use an external DtoA converter to output an analog audio signal. Furthermore, the second option of incorporating an external program counter would save more pins.
Thus, I designed the memory circuit to use a 512KB non-volatile SRAM with a19-bit program counter. I designed the program counter using two 22-pin PLDs that could be programmed to be reset to several locations that denoted the start of an audio clip. My original design used 5.0V PLDs that interfaced to the microcontroller through level converters. After some searching, I was able to find 3.3V PLDs that could be programmed using the universal programmer we have in lab. Thus I was able to simplify the circuit by removing the level translation.
In addition to designing the hardware memory interface, I also coded the algorithm to write to and read from memory. This included writing the ABEL code for the program counters and writing the OpenTCP code to interface the program counters and SRAM. In the final stages of the project, I burned our selected audio file to memory. This was a time-consuming process because 52 file fragments had to be individually burned to the memory for a single audio clip. Additionally, it took several tries to successfully burn a file to memory. After burning the files, I helped interface the memory with the audio.
I also played a major role in documenting the project. I did the majority of the work in putting together our Midterm and Final PowerPoint presentations. Additionally, I wrote the majority of the User’s Manual and put together the Final Report.
A.4 Contributions of Brian Ryall:
In the first month of the semester, i worked on generating project ideas since we came into the class without any to work with. Also during this time i spent looking for components and datasheets to use in our design. Also helped a lot with the project webpage, with the layout and creating the different pages for the webpage.
During the design and prototyping portion of the semester, i spent lots of time doing the printed circuit board and working with the webserver software to accept commands. I also help design the networking part of the project since i have had experience with networks. Then I helped write some code and did a lot of helping debugged the other teammates software they were writing. I also worked a lot with the temperature sensor. I has lots of trouble getting the communication correct for the original sensor we bought, so i did some research and found another that was based on ATD and made the software much easier.
I was also in charge of two homeworks. My first homework was the printed circuit board homework where i wrote about the issues in placement and size of the parts on the board. I spent a great deal of time with the placement of the different parts and getting them to fit in the RC car we purchased. Then Jim did most of the routing while I did help a lot at the end of routing.
The second homework was on the safety and reliability analysis homework. I had to look over the entire design looking for three to five key parts that have a short mean time to failure. And then have to break our design into functional blocks and analyze all the ways the block could fail and if it is a low or high criticality.
I am pleased to work with a great group of people on my team. They were all really dedicated and got the job done. We had most of the project success criteria done partway though the semester and had time to add some extra features. I have put a lot of time in this course, more than any of my other classes this semester and i am very proud of the finished product. I feel that i deserve a B in this course.
Appendix B: Packaging
[pic]
Figure B-1: DigiRover Component Layout
[pic]
Figure B-2: DigiRover Side View
[pic]
Figure 7: DigiRover Front View
[pic]
Figure 8: DigiRover Top View
Appendix C: Schematic
[pic]
Figure C-1: Microcontroller Circuit
[pic]
Figure C-2: Audio Circuit
[pic]
Figure C-3: LED Circuit
[pic]
Figure C-4: Memory Circuit
[pic]
Figure C-5: Motor Circuit
[pic]
Figure C-6: Pan/Tilt Circuit
[pic]
Figure C-7: Power Supply Circuit
[pic]
Figure C-8: Sensor Circuits
[pic]
Figure C-9: Steering Circuit
Appendix D: PCB Layout Top and Bottom Copper
[pic]
Figure D-1: DigiRover Top PCB Layer
[pic]
Figure D-2: DigiRover Bottom PCB Layer
Appendix E: Parts List Spreadsheet
Table E-1: DigiRover Major Parts
|Component |Vender |Part Number |Unit Cost |Quantity |Total Cost |
|Microcontroller |Freescale Semiconductor|MC9S12NE64 |$17.24 |1 |$17.24 |
| | | | | | |
|Development Board |Freescale Semiconductor|DEMO9S12NE64 |$80.00 |1 |$80.00 |
|RC Car |New Bright |Escalade |$45.00 |1 |$45.00 |
|Wireless 2.4GHz Internet |D-Link |DCS-900W |$109.86 |1 |$109.86 |
|Camera | | | | | |
|Temperature Sensor |Dallas Semiconductor |DS1721S |$3.87 |1 |$3.87 |
|Digital Compass |Dinsmore Sensing |1490 |$15.95 |1 |$15.95 |
| |Systems | | | | |
|Distance Sensor |Sharp |GP2Y0A02YK |$15.63 |2 |$31.26 |
|Battery |Power-Sonic |PS-1230 |$14.91 |1 |$14.91 |
| Memory |Dallas Semiconductor |DS1250W | $85.00 |1 | $85.00 |
Appendix F: Software Listing
/**************************************************************************
*
* Copyright (C) 2003 Freescale Semiconductor, Inc.
* and 2000-2002 Viola Systems Ltd.
* All Rights Reserved
*
* File Name : mainwebserver.c
*
* Version : 1.0
*
***************************************************************************/
#include "debug.h"
#include "datatypes.h"
#include "timers.h"
#include "system.h"
#include "ethernet.h"
#include "arp.h"
#include "ip.h"
#include "tcp_ip.h"
#include "http_server.h"
#include "smtp_client.h"
#include "ne64driver.h"
#include "ne64api.h"
#include "mBuf.h"
#include "ne64config.h"
#include "address.h"
#include "MC9S12NE64.h"
/* Including used modules for compiling procedure */
/* Network Interface definition. Must be somewhere so why not here? :-)*/
struct netif localmachine;
extern void RTI_Enable (void);
extern void porth_isr_handler (void);
extern int first_add_motor;
extern int second_add_motor;
extern int bat_level;
extern int audio;
extern tU08 gotlink;
#if USE_SWLED
tU16 LEDcounter=0;
#endif
//============================================================
tU08 OldSwitchValue=255;
tU16 Pot=0;
tU16 OldPot=1050;
tU08 OldB1=255;
tU08 OldB2=255;
tU08 OldB3=255;
tU08 OldB4=255;
//============================================================
#pragma CODE_SEG NON_BANKED
interrupt void PortHInterrupt (void)
{
porth_isr_handler();
}
#pragma CODE_SEG DEFAULT
//============================================================
//Initialize ATD
//============================================================
void ATD_init(void)
{
ATDCTL2 = ATDCTL2_ADPU_MASK | ATDCTL2_AFFC_MASK;
ATDCTL3_S1C = 8; // 8 ch seq.
ATDCTL3_FIFO = 0; // no FIFO
ATDCTL3_FRZ = 3; // Freeze immediately in BDM
ATDCTL4 = ATDCTL4_PRS2_MASK |ATDCTL4_PRS1_MASK | ATDCTL4_PRS0_MASK;
ATDCTL4 = ATDCTL4 & ~ATDCTL4_SRES8_MASK; //10 bit
ATDCTL5 = ATDCTL5_SCAN_MASK;
}
//============================================================
// Initialize Port for LEDs, Switch, and Buttons
//============================================================
void demoinit(void)
{
DDRAB = 0xFFFF; // AB is used for motor control and others
PORTAB = 0x0000;
PORTA = PORTA | 0x10; // apply brake
PORTA = PORTA | 0x03; // motor speed off
DDRJ_DDRJ7 = 1; //PTJ7 is used for tri state buffer
PTJ_PTJ7 = 1;
DDRG_DDRG0 = 1; //1:output
DDRG_DDRG1 = 1; //1:output
DDRG_DDRG2 = 1; //1:output
DDRG_DDRG3 = 1; //1:output
DDRG_DDRG4 = 1; //1:output
DDRG_DDRG5 = 1; //1:output
DDRG_DDRG6 = 1; //1:output
DDRG_DDRG7 = 1; //1:output
PTG_PTG0 = 0; //turn off
PTG_PTG1 = 0; //turn off
PTG_PTG2 = 0; //turn off
PTG_PTG3 = 1; //turn on camera
PTG_PTG4 = 0; //turn off
PTG_PTG5 = 1; // motor speed forward
PTG_PTG6 = 1; // motor speed reverse
PTG_PTG7 = 0; //turn off
DDRT_DDRT4 = 1;
DDRT_DDRT5 = 1;
DDRT_DDRT6 = 1;
DDRT_DDRT7 = 1;
PTT_PTT4 = 0;
PTT_PTT5 = 0;
PTT_PTT6 = 0;
PTT_PTT7 = 0;
// PWM 5 TILT 90 degrees
TSCR2 = TSCR2 | 0x04;
TIOS = TIOS | 0x20;
TSCR1 = TSCR1 | 0x80;
TC5 = TCNT + 0x7A12;
TIE = TIE | 0x20;
// PWM 6 PAN 90 degrees
TSCR2 = TSCR2 | 0x04;
TIOS = TIOS | 0x40;
TSCR1 = TSCR1 | 0x80;
TC6 = TCNT + 0x7A12;
TIE = TIE | 0x40;
bat_level = 2;
ATDDIEN1_IEN3 = 1; // digital input for atd 3 to 6
ATDDIEN1_IEN4 = 1;
ATDDIEN1_IEN5 = 1;
ATDDIEN1_IEN6 = 1;
// Siou's memory read initializations
DDRB = 0x00; // Set PB7..PB0 as input
DDRG |= 0x01; // Set PG0 as output
DDRJ |= 0x8c; // Set PJ7, PJ3, PJ2 as output
DDRK |= 0xF0; // Set PK7, PK6, PK5, PK4 as output
PTG_PTG0 = 1; // nWE = 1 (set to read mode)
PTJ_PTJ3 = 0; // nOE = 0 (enable output)
PTJ_PTJ2 = 0; // nCE = 0 (enable the chip)
// Jim's audio stuff
audio = 0;
}
//============================================================
/* main */
//============================================================
void main(void)
{
INT16 len;
/* System clock initialization */
CLKSEL=0;
CLKSEL_PLLSEL = 0; // Select clock source from XTAL
PLLCTL_PLLON = 0; // Disable the PLL
SYNR = 0; // Set the multiplier register
REFDV = 0; // Set the divider register
PLLCTL = 192;
PLLCTL_PLLON = 1; // Enable the PLL
while(!CRGFLG_LOCK); // Wait
CLKSEL_PLLSEL = 1; // Select clock source from PLL
INTCR_IRQEN = 0; // Disable the IRQ interrupt. IRQ interrupt is enabled after CPU reset by default
init();
demoinit();
localmachine.localip = *((UINT32 *)ip_address); // IP address
localmachine.defgw = *((UINT32 *)ip_gateway); // Default gateway
mask = *((UINT32 *)ip_netmask); // Subnet mask
/* Ethernet (MAC) address */
localmachine.localHW[0] = hard_addr[0];
localmachine.localHW[1] = hard_addr[1];
localmachine.localHW[2] = hard_addr[2];
localmachine.localHW[3] = hard_addr[3];
localmachine.localHW[4] = hard_addr[4];
localmachine.localHW[5] = hard_addr[5];
/* Init system services */
timer_pool_init();
/* Initialize all buffer descriptors */
mBufInit ();
/*interrupts can be enabled AFTER timer pool has been initialized */
/* Initialize all network layers */
EtherInit();
/* Initialize required network protocols */
arp_init();
(void)udp_init();
udp_demo_init();
(void)tcp_init();
(void)https_init ();
/* Enable RTI */
RTI_Enable ();
/* main loop */
DEBUGOUT(">>>>>>>>>Entering to MAIN LOOP>>>>>>>>>\n\r");
for (;;)
{
#if USE_SWLED
UseSWLedRun();
#endif
if (gotlink) {
/* take care of watchdog stuff */
/* Try to receive Ethernet Frame */
if( NETWORK_CHECK_IF_RECEIVED() == TRUE ) {
switch( received_frame.protocol) {
case PROTOCOL_ARP:
process_arp (&received_frame);
break;
case PROTOCOL_IP:
len = process_ip_in(&received_frame);
if(len < 0)
break;
switch (received_ip_packet.protocol) {
case IP_ICMP:
process_icmp_in (&received_ip_packet, len);
break;
case IP_UDP:
process_udp_in (&received_ip_packet,len); break;
case IP_TCP:
process_tcp_in (&received_ip_packet, len);
break;
default:
break;
}
break;
default:
break;
}
/* discard received frame */
NETWORK_RECEIVE_END();
}
arp_manage();
/* Application main loops */
/* TCP/IP stack Periodic tasks here... */
udp_demo_run();
tcp_poll();
https_run ();
}
}
}
/******************************************************************************
*
* (c) Freescale Inc. 2004 All rights reserved
*
* File Name :Vectors.c
*
* Version : 1.0
* Date : Jun/22/2004
*
******************************************************************************/
extern void near _Startup(void); /* Startup routine */
extern void near RealTimeInterrupt(void);
extern void near emac_ec_isr(void);
extern void near emac_lc_isr(void);
extern void near emac_b_rx_error_isr(void);
extern void near emac_rx_b_b_o_isr(void);
extern void near emac_rx_b_a_o_isr(void);
extern void near emac_rx_error_isr(void);
extern void near emac_mii_mtc_isr(void);
extern void near emac_rx_fc_isr(void);
extern void near emac_f_tx_c_isr(void);
extern void near emac_rx_b_b_c_isr(void);
extern void near emac_rx_b_a_c_isr(void);
extern void near ephy_isr(void);
extern void near PortHInterrupt(void);
extern void near pwm4_isr(void);
extern void near pwm_5_isr_cam_tilt(void);
extern void near pwm_6_isr_cam_pan(void);
extern void near pwm_7_audio(void);
//************************************************************************
// SOFTWARE TRAP FUNCTION
// DESCRIPTION:
// Function that traps all unexpected interrupts. Used for debugging
// software to find runaway code.
//************************************************************************
#pragma CODE_SEG __NEAR_SEG NON_BANKED /* Interrupt section for this module. Placement will be in NON_BANKED area. */
__interrupt void software_trap(void){ for(;;); }
#pragma CODE_SEG DEFAULT /* Change code section to DEFAULT. */
//************************************************************************
typedef void (*near tIsrFunc)(void);
const tIsrFunc _vect[] @0xFF80 = { /* Interrupt table */
software_trap, /* 0 Default (unused) interrupt FF80*/
software_trap, /* 1 Default (unused) interrupt FF82*/
software_trap, /* 2 Default (unused) interrupt FF84*/
software_trap, /* 3 Default (unused) interrupt FF86*/
software_trap, /* 4 Default (unused) interrupt FF88*/
software_trap, /* 5 Default (unused) interrupt FF8A*/
software_trap, /* 6 Default (unused) interrupt FF8C*/
software_trap, /* 7 Default (unused) interrupt FF8E*/
software_trap, /* 8 Default (unused) interrupt FF90*/
software_trap, /* 9 Default (unused) interrupt FF92*/
software_trap, /* 10 Default (unused) interrupt FF94*/
software_trap, /* 11 Default (unused) interrupt FF96*/
software_trap, /* 12 Default (unused) interrupt FF98*/
software_trap, /* 13 Default (unused) interrupt FF9A*/
software_trap, /* 14 Default (unused) interrupt FF9C*/
software_trap, /* 15 Default (unused) interrupt FF9E*/
emac_ec_isr, /*FFA0*/
emac_lc_isr, /*FFA2*/
emac_b_rx_error_isr, /*FFA4*/
emac_rx_b_b_o_isr, /*FFA6*/
emac_rx_b_a_o_isr, /*FFA8*/
emac_rx_error_isr, /*FFAA*/
emac_mii_mtc_isr, /*FFAC*/
emac_rx_fc_isr, /*FFAE*/
emac_f_tx_c_isr, /*FFB0*/
emac_rx_b_b_c_isr, /*FFB2*/
emac_rx_b_a_c_isr, /*FFB4*/
ephy_isr, /*FFB6*/
software_trap, /* 28 Default (unused) interrupt FFB8*/
software_trap, /* 29 Default (unused) interrupt FFBA*/
software_trap, /* 30 Default (unused) interrupt FFBC*/
software_trap, /* 31 Default (unused) interrupt FFBE*/
software_trap, /* 32 Default (unused) interrupt FFC0*/
software_trap, /* 33 Default (unused) interrupt FFC2*/
software_trap, /* 34 Default (unused) interrupt FFC4*/
software_trap, /* 35 Default (unused) interrupt FFC6*/
software_trap, /* 36 Default (unused) interrupt FFC8*/
software_trap, /* 37 Default (unused) interrupt FFCA*/
PortHInterrupt, /* 38 Default (unused) interrupt FFCC*/
software_trap, /* 39 Default (unused) interrupt FFCE*/
software_trap, /* 40 Default (unused) interrupt FFD0*/
software_trap, /* 41 Default (unused) interrupt FFD2*/
software_trap, /* 42 Default (unused) interrupt FFD4*/
software_trap, /* 43 Default (unused) interrupt FFD6*/
software_trap, /* 44 Default (unused) interrupt FFD8*/
software_trap, /* 45 Default (unused) interrupt FFDA*/
software_trap, /* 46 Default (unused) interrupt FFDC*/
software_trap, /* 47 Default (unused) interrupt FFDE*/
pwm_7_audio, /* 48 Default (unused) interrupt FFE0*/
pwm_6_isr_cam_pan, /* 49 Default (unused) interrupt FFE2*/
pwm_5_isr_cam_tilt, /* 50 Default (unused) interrupt FFE4*/
pwm4_isr, /* 51 Default (unused) interrupt FFE6*/
software_trap, /* 52 Default (unused) interrupt */
software_trap, /* 53 Default (unused) interrupt */
software_trap, /* 54 Default (unused) interrupt */
software_trap, /* 55 Default (unused) interrupt */
RealTimeInterrupt, /* 56 Default (unused) interrupt */
software_trap, /* 57 Default (unused) interrupt */
software_trap, /* 58 Default (unused) interrupt */
software_trap, /* 59 Default (unused) interrupt */
software_trap, /* 60 Default (unused) interrupt */
software_trap, /* 61 Default (unused) interrupt */
software_trap, /* 62 Default (unused) interrupt */
_Startup /* Reset vector */
}
#include"datatypes.h"
#include"debug.h"
#include"globalvariables.h"
#include"system.h"
#include"http_server.h"
#include"MC9S12NE64.h"
#include "FileSys.h"
int first_add_motor = 0x030D;
int second_add_motor = 0x030D;
int first_add_cam_pan = 0x0928;
int second_add_cam_pan = 0x70EA;
int first_add_cam_tilt = 0x0520;
int second_add_cam_tilt = 0x70EA;
int forward = 0; // 0 = no direction
// 1 = forward
// 2 = reverse
int audio = 0;
int bat_level = 2;
unsigned char * song_start_address;
extern char temperature;
extern char temp_array[279];
/* brief File not found message
*
* Message that will be displayed if a file with appropriate name (hash
* value) was not found.
*/
const char https_not_found_page[] = "HTTP/1.0 200 OK\r\nLast-modified: Mon, 17 May 2004 15:02:45 GMT\r\nServer: ESERV-10/1.0\nContent-type: text/html\r\nContent-length: 400\r\n\r\nViola Systems Embedded WEB ServerHTTP 1.0 404 Error. File Not FoundThe requested URL was not found on this server.Viola Systems Embedded WEB Server 2.01, 2004Did you wish 192.168.2.3/index.htm? - Embedding The Internet";
const char cardinal_dir_page[] = " ................
................
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
- lauren hoover professional portfolio home
- emily s site
- aspireassist non surgical weight loss procedure
- the official web site for the state of new jersey
- welcome to adult basic skills professional development
- sci 1101 labs measurement
- common core state standards ccss for mathematics k 12
- counting calories spatially optimizing cross us running
- ee 477 final report purdue university
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