In this project, the team proposes to build a mobile Extra-Vehicular Activity Robotic Assistant equipped with a manipulator arm. The two main characteristics of the proposed robot are its ability to interpret and execute high level commands given by a human operator, and its ability to detect, isolate and recover from the different types of failures that might affect its hardware. The types of hardware failures that the team will consider to illustrate the fail-safe operation are: (i) failure to one of the electric motors actuating the manipulator arm, and (ii) failure to one of the navigation sensors of the robot.

The high level commands will be used to initiate a multitude of tasks that the robot has to carry out autonomously. The fail-safe operations will allow the robot to continue its mission even in the event of a hardware failure. This proposal describes the proposed design and the method of approach to implement and test the high-level command (HLC) and the fail-safe operations (FSP) of the robot.

2. Mentor / Research Group

The JSC mentor for this project is Mr. David Cheuvront. He is the Technology Integration Manager of the Advanced Technology Development Office at the Lyndon B. Johnson Space Center. The Technology Integration Division oversees current designs and technologies involved in space exploration and makes decisions whether or not there is a need for technological advancements that need to be made to increase productivity in space exploration. Mr. Cheuvront worked with the Canadian Space Agency in Ottawa, Japan’s Space Agency, and the European Space Agency.

3. Collaboration

In addition to collaborating with Mr. Dave Cheuvront, the team will be advised by Dr. Mounir Ben Ghalia and Dr. Hamid Zarnani. The team will consult with other engineering students who have worked on previous robotics projects, and with past UTPA graduate students.

4. Team ID / Member Profiles

The team members are currently enrolled in ELEE 4461, Senior Design Project I. The name chosen for the team is Space Autonomia. Originally, the team came up with the name Autonomy in Space. The name was chosen due to the autonomous function of the robot. Then, after some discussions among the team, a consensus was reached to select the name Space Autonomia. Autonomia is the Spanish word for autonomy. The team has named the robot to Autonomo.

The faculty advisor is Dr. Mounir Ben Ghalia. He is an Assistant Professor of Electrical Engineering Department who specializes in robotics and control systems theory. Dr. Ben Ghalia can be contacted via email at benghalia@panam.edu .

The team is lead by Ana Castillo, a Sr. Electrical Engineering student. The team also consists of Nelson Carrasquero, a Sr. Electrical Engineering student, Mario Contreras Jr., a Sr. Electrical Engineering student, and Gabriel Rodriguez, a Sr. Electrical Engineering student. Anna and Nelson will be working on the Fail-Safe operations of the robot. Gabriel and Mario will be working on the High Level Command system. All team members will contribute to the design and construction of the robot structure and the manipulator arm.

5. Team Patch Design

Figure 1:Team Patch

The colors (green and orange) reflect the University of Texas – Pan American’s (UTPA) colors. The top of the design shows the synergy of NASA and Texas Space Grant Consortium (TSGC). The team members’ names are shown on each side of UTPA’s logo (sun). The robots and rockets show the work of NASA’s past and present accomplishments. Finally, the team name is below the logo.

6. Background

The area of robotics plays an important role in space exploration. Different types of robotic Technologies have been developed. One of the technologies used in space exploration is tele-robotics. In this technology, a robot is controlled from a remote and safe location by a human operator.

Fail-Safe operations are increasingly important in autonomous or industrial robots which are subject to failures. In this project, a fail-safe system will be designed and built allowing the robot to detect, isolate, and recover from a hardware failure. The High-Level Command allows the robot to carryout a series of complex tasks upon receipt of a speech-command by a human operator. This operative feature removes the need for giving detailed instructions to the robot. Once a high level command is received, the robot starts carrying out its tasks in an autonomous fashion.

7. Design Objective

Team Space Autonomia will demonstrate the effectiveness of a HLC and fail-safe system. The design objects are:

Design a collision detection and avoidance system
Design a hardware failure detection module
Design a recovery module
Design a voice-recognition system

The HLC will allow the operator to command the robot. The robot will then process the HLC into a series of low level instructions to carry out its main task. The HLC consists of a word phrase that the robot will then process in order to identify the task it must perform. For instance, the operator will give the command “Task 1” and the robot will respond accordingly.

The fail-safe system will detect, isolate, and recover from any faults that may occur during the robot’s mission.

8. System Level Design

Given the specified design objectives, the following system level design was blocked together to determine the sub-levels of the design. The following figure shows a block diagram of the entire system level design that needs to be implemented in order to create Autonomo.

Figure 2: Block Diagram of System Level Design

8.1 Controllers

In the diagram, there are three main modules that will allow Autonomo to be the autonomous robot specified above. The design is centered on the Laptop and the microcontrollers that were selected appropriately for this project. The laptop needs to have the following specifications:

Pentium II processor with at least 400MHz
128MB RAM
CD-ROM
Serial Ports Communication
Parallel Port Communication
USB (to be converted to Serial)

The laptop will be processing the higher level commands and will also be processing the HLC that will start the process of the main task. The laptop was select over the PC/104 board because the PC/104 board consumes more power than a laptop. The PC/104 board also needed an extension board to connect a monitor for debugging purposes. The laptop already provides a monitor for debugging purposes. The prices are almost identical for each and it seemed that the laptop was more ideal for this project.

The microcontroller that was previously selected during the middle of the semester was chosen with the assumption that the team was going to use 11 sensors for navigation and fail safe simulation purposes. After narrowing the number of sensors being used, the need for many I/O pins was not needed team needed a smaller microcontroller to process the low level commands without losing the effectiveness the PIC18F8680 would provide. After looking a several different microcontrollers, Microchip’s PIC16F877A microcontroller was selected.

The following figure shows the pin out of the PIC16F877A.

Figure 3: Pin out for PIC16F877A [1]

The specifications on this microcontroller are as follows:

14336 bytes
256 EEPROM Data Memory
368 RAM
33 I/O
8/10 bit ADC
2 Comparators
20MHz Max

After reading the specifications on the microcontroller, an oscillation mode must be selected to allow the microcontroller to operate. For this particular microcontroller, there are 3 different oscillator modes: LP, XT, and HS. The XT oscillator mode can use a 200 kHz, 1 MHz or 4MHz crystal. With the use of a 4 MHz crystal, Microchip recommends values for the capacitors that are shown on the following table:

Figure 4: Table of Capacitor Selection [1]

8.1.1 Communication Interface

To be able to communicate between the microcontrollers and the laptop, RS-232 technology will be used. To accomplish the communication, a RS-232 converter is needed to convert RS-232 signals (+/- 12V) to TTL/CMOS (+/- 5V) and vice versa. The most common chip is the MAX232 chip from Maxim. The MAX232 has a built in charge pump that creates +/- 12 V. The diagram below shows the interface that will be used to have communication from the PC to the microcontroller. The MAX232A which requires smaller capacitors than the MAX232 will be used. In the diagram the RC6/TX/CK pin of the microcontroller is connected to the T2in pin of the converter and the RC7/RX/DT pin is connected to R2out pin of the converter. The TX pin is used for transmission and the RX pin is used for receiving through means of built-in universal synchronous / asynchronous receiver transmitter (USART) hardware. Figure 5 shows communication between the microcontroller and laptop.

Figure 5: Diagram of RS-232 interface [2]

The diagram does not show clearly which pins of the SUB-D connector are being used. Pin 5 goes to ground of the PC and pin 2 is used to transmit data to the PC. Pin 3 is used to receive data from the PC.

In order to keep track of the lower level processing, a 14 pic LCD display will be used. The interfacing of the LCD display to the microcontroller is shown in the following diagram. The LCD display is interfaced with the microcontroller using 4 I/O ports of the microcontroller. Two additional pins are needed to transmit the clock and the R/S instruction / register select. Figure 6 shows the interface for the LCD display.

Figure 6: LCD interface

If we need to free up some I/O pins, there is an alternate method to interface the LCD display screen. This method uses only 2 wires to interface. The following figure shows how the two wire interface is done using a 74LS174 shift register and an AND circuit using a diode and resistor.

Figure 7: Diagram of Two Wire LCD interface [2]

Depending on the availability of I/O ports, the method that does not use the shift registers will be used. The interfaces for the navigation system and speech recognition module will be presented in the appropriate section of the report.

8.2 High Level Command

The HLC will consist of a voice command that a human agent will issue to the robot.

The main reasons for adopting speech-command as the form of HLC are:

1. Security purposes

2. High level command implementation

3. Voice command is suitable technique for communication

The first reason ensures that the robot will respond to only authorized operators. This feature guarantees system operation security. Although circumvention is possible, the effort needed to do so acts as a deterrent. Sending other types of data (e.g., text) across is just as well; however, it has its caveat (third reason). Single verbal HLC allows for complicated tasks to be carried out and so HLC is implemented. A caveat for using data for HLC arises in the particular use of the system (robot). Consider, for instance, the case where the robot has to carry out military tasks under heavy fire. The Commanding Officer (CO) would only “speak” to the robot to perform its task.

Using other types of HLCs requires for the CO to spend more time on sending data, either by keyboard, or using a stylus to select task from a PDA-like device. Another example is that of an astronaut commanding a robot to assist him/her carrying out a mission while the astronaut is performing his/her destiny.

8.2.1 Speech Recognition System

Figure 8 shows the block diagram of the HLC module.

Figure 8: Block design approach of HLC

The team proposes the use of a wireless microphone headset to transmit the voice signal to the robot. The receiver will be a walkie-talkie. The transmitter will be a redesigned walkie-talkie performing as a wireless microphone headset. This transmitter will have an important feature: Voice Operated Transmitter (VOX). The general circuit (Figure 9) below gives a general approach on how to design a VOX.

Figure 9: Design approach of a VOX circuit [3]

The speech recognition system will process the signal and store the command in a static RAM IC. Figure 10 shows the schematic of the speech recognition board.

Diode

Figure 10: Schematic of speech recognition board [4]

For a more detailed picture of the HM2007 CMOS chip, see Figure 11.

Figure 11: Pin layout of HM2007 chip [5]

Similarly, Figures 12 shows an improved detailed view of the SRAM IC.

Figure 12: SRAM layout [6]

The speech recognition circuit allows the operator to speak a word in less than 0.92 seconds. Using a speaker dependent and word isolation method, the speech recognition system has a maximum of 40 words stored in an 8Kx8 static RAM. In order to store these words in memory, the keypad is used [7]. For instance, pressing “0” then “1” programs the word as 01. This works similarly up until word 40.

From Figure 10, the LED acts as status indicators for the operator. If the circuit accepts the word, the LED flashes. However, if the LED does not flash, the word was not correctly programmed, and so must be programmed again. The 7-segment display shows the word programmed or word number currently being programmed [7].

For security purposes, the robot will acknowledge a high level command only if it is issued from one of the team members. Hence, each command word has to be recorded by each team member in his or her own voice. In addition, if the robot encounters problems interpreting high level commands, a backup system will be used to send individual low level commands to the robot (e.g. move forward, lift arm, etc).

A straightforward approach for a backup system for HLC requires for the astronaut to approach the robot and depress a designated button for each task.

8.2.2 Speech Recognition Interface

The Speech Recognition Module will be directly interfaced to the laptop using its parallel port. The 8 data lines that are the outputs of the D-Flip flops are then sent to the data ports of the parallel port of the PC. Figure 13 shows the connection between the Speech Recognition module and the laptop.

Figure 13: Speech Recognition Interface with PC [8]

8.3 Design of Manipulator Arm

8.3.1 Dimensions of manipulator arm

The concept of fail - safe system will be also applied to one of the actuators of the robot. One of the joint actuators of a mechanical arm will be used to simulate a failure that happens during its function. The approach that will be used to provide autonomy to the robot is to have a redundant system that replaces the system that will fail to function. Consequently, a mechanical arm with an additional joint actuator will be used to allow autonomo recover from an actuator failure independently.

Figure 14 exemplifies the concept of the type of arm configuration that will be necessary to illustrate the fail – safe system. Figure 14 shows a manipulator arm with a link between the base of the arm and joint 1. Link 2 corresponds to the segment between joint 1 and joint 2 (). Link 3 and link 4 are the segments between joint 2 and joint 3 () and between joint 3 and joint 4 () respectively. In general, the manipulator arm will have four joints and an end effector that will allow it to grasp and pick up samples of matter.

Figure 14: Example of Manipulator Arm

8.3.2 Kinematics of the arm

The arm configuration is composed of a base platform that acts as the base of the arm and connects the arm to the mobile platform. The base platform will have a servo motor that performs a yaw motion. This motion will allow the arm to reach an adequate position to store the sample in the containers placed in the back of the robot. Joint 1, 2, 3, and 4 will move in a pitch form to provide the desired degree of freedom needed to perform the task of sample collection. The actuator of joint 2 will illustrate the redundancy concept for the implementation of the fail – safe system. The actuator of joint 2 will act as a back up system in case the actuator of joint 3 fails. Therefore, the actuator of joint 2 will remain inactive if the actuator of joint 3 works properly.

Figure 15 shows that the displacement of joint 1 will be represented by θ₁ as shown. Joint 1 will have a displacement range of 160 degrees. Joint 2 will be used as a back up system. The joint 2 displacement will be represented by θ₂, and it will have a range of 180 degrees. The joint 3 displacement will be represented by θ₃. Since joint 3 will be used to simulate the failure case, its displacement range is limited to the degree of freedom that the arm needs to have to complete the task by enabling the back up system (actuator of joint 2). The displacement range of joint 3 will be 90 degrees. The joint 4 displacement will be represented by θ₄, and it will have a range of 180 degrees.

Figure 15: Illustration of Arm Working Properly

In the absence of failure, only joints 1, 3, and 4 will be active to perform the task. Figure 14 illustrates the points that the end effector will have to reach in order to collect the sample of matter from the surface. These points form a straight line path that will be reached by actuating joint 1, 3, and 4. By parallel projection on the X and Y axes, the coordinates of the points shown in the figure above can be determined using the following equations [9]:

Equation 1

Equation 2

Since the coordinates of these points will be known, the joints displacement θ₁, θ₃, and θ₄ needed to place the end effector to the desired positions will be determined by applying inverse kinematics.

8.3.3 Failure Simulation of Manipulator Arm

An object (see Figure 16) will be placed manually between link 2 and link 3. This will hinder the joint 3 motion. In the scenario previously mentioned, when an object is placed between the two links connected by joint 3, the motor will require more power to produce a greater torque; therefore, the magnitude of the current drawn by the motor will increase. When the current drawn by the motor increases abnormally, this situation, will be flagged as an effector failure. In order to detect the failure, a system will be used to measure and monitor the current drawn by the electrical motor of joint 3. This system will consist of an in-line (shunt) resistor circuit that will measure the current drawn by the motor, and the interface of the current meter circuit with the microcontroller to monitor the behavior of the current drawn by the motor.

Figure 16: Illustration of Arm with Disabled Joint and Kinematics

Figure 17 illustrates the circuit that will be used to measure the current drawn by the motor. It can be noticed from the figure that a resistor is placed between the power supply and one of the motor terminals. The current drawn by the motor will cause a voltage drop across the resistor. This signal will be amplified using a LM324 op-amp with non-inverting configuration as illustrated in the figure. The microcontroller will receive the resulting output signal and compare it to the ideal current ranges that the motor should draw under normal operation. If the actual output magnitude differs from the ideal output magnitude by a large percentage, then the microcontroller will determine that the actuator is not working properly.

Figure 17: In-line (Shunt) Resistor and Meter [10]

Figure 18 illustrates the diagram of the fail - safe system algorithm where the processes of failure detection, failure isolation, and system reconfiguration have effect. The first process of the system monitors the current measurements obtained. As it was previously mentioned, the in-line shunt resistor plus an amplifier will be used to determine the current drawn by motors, and the signal will be monitored by the microcontroller. The microcontroller will also compare these values to determine if the motor is working under normal conditions. In case the joint actuator performs a normal function, the process will continue. However, if the joint actuator performs an abnormal function, the process will stop. Subsequently another process will come into action to test other configurations of the joints of the arm and ensure if the source of the previous abnormal performance continues occurring. After that process, if the conditions of the actuators go back to normal, then the system will reconfigure and continue the process. Conversely, if the conditions of the joint actuator continue being abnormal, another process will take place to isolate the faulty joint actuator from the system. Subsequent to isolation of the failure, the process of redundant joint activation will have effect. This process will be followed by the reconfiguration of the system and continuation of the main task.

Target Diagram

Figure 18: Diagram of Fail - Safe System

8.4 Sensor Design

8.4.1 Brief Description of Robot Sensors / Collision Avoidance

Autonomo uses two types of sensors to achieve its goals in regards to obstacle detection and collision avoidance. To provide a backup system for the sonar sensors, infrared sensors are placed on the front of the robot to detect an object. The sonar sensors will face forward and detect objects.

8.4.2 Fail Safe System

There are many conditions, which may lead sensors to produce incorrect readings. The sensors may become damage with time as their internal circuitry is overused. Other causes of sensor failures may incur to external noise, or a power source problem. In this design, a sensor fail -safe system was developed because of these sensor failure problems.

8.4.3 Fail-Safe System Applied to Sensors

Figure 19 shows the backup system for fail-safe operations. As it can be seen, only the sonar sensors will be making readings. If one of the sonar sensors becomes faulty, an infrared sensor is activated.

Figure 19: Sensor Reconfiguration

8.4.4 Sensor Fail-Safe Operation / Fault Detection / Isolation / Recovery

Now, the final algorithm design for the fail-safe operation of the sensors is shown in Figure 20.

Figure 20: Flowchart of Sensor Fail-Safe System

The low-level tasks that the microcontroller will process include:

Send the INIT signals to the sonar sensors
Read the ECHO signals from the sonar sensors
Provide the ECHO signal output value to the microcontroller
Read the value of the D/A converter output
Provide the input to the Infrared Sensors
Read the Infrared Sensor outputs

The microcontroller triggers all the sensors at one time. Both sonar sensors are triggered with an initial input to activate them. The two sonar sensors provide data to the microcontroller to measure the distance measurements. If one sonar sensor is providing incorrect readings, it still sends data to the microcontroller. The micro-controller determines that when the ECHO signal and INIT signal are high at the same time, the readings are due to a faulty sensor. Theoretically, each sonar sensor produces an ECHO output value, and the time between INIT going high and ECHO going high, is proportional to the distance between the transmitter and the object being encountered.

Since time is negligibly small, the micro-controller will be programmed to accept this reading as a faulty sensor after a certain time period. This failure will be isolated by shutting the power off to sonar one, and then activating the infrared on top of it, as a back up sensor. Figure 21 shows the circuit that will be connected to one of the I/O pins of the micro-controller.

Figure 21: Power Isolation Circuit

8.4.5 Sensor interfacing with microcontroller

The sensors used for the navigation system and simulation of the fail-safe system will be interfaced with PIC1 shown in Figure 22. All inputs and outputs to the sensors are digital which allows them to be directly interfaced to the microcontroller without any additional external circuitry. The Figure below shows the interfacing for the sensors to the microcontroller.

Figure 22: Sensor Interface

9. Illustrations of Robot Structure

Figures 23 and 24 show the front view of the robot and the back view of the robot respectively.

Figure 23: Front View of Robot Figure 24: Back View of Robot

10. Reviewer Section

10.1 In Defense of Speech Recognition

Trying to defend Team Space Autonomia reasoning for speech recognition system in this project against NASA’s reviewers is quite a daunting task. Nonetheless, the following text is in defense of such a system. Being almost an EVA project, the inclusion of speech recognition system does add value. It is not some fiat proposed by the team. NASA currently employs such a system in its ERA [11]. Also, as the authors of Providing Robotic Assistance during Extra-Vehicular Activity state, “The ERA team is specifically interested in the issues of how to produce a robot that can assist someone in a spacesuit. Some of these issues include astronaut/robot communication, such as voice . . . “[12].

Security inherently designed in the speech recognition system also adds value. From hackers trying to deny service [13], to defacing the NASA main site [14], and to shutting down servers hours after Columbia tragedy [15], security was remotely compromised. Obviously without security, a higher degree of harm would have resulted. Likewise, without security for Autonomo, the robot is at the disposal of any one operator, malicious intent or not. Having a security feature, the robot will not perform inadvertent tasks.

Astronauts are highly competent and trained professionals. They are trained to remain calm in undesirable situations, and to think reasonably under given situations. Confidence and familiarity arises from training. Therefore, having the astronaut press a button or utter a command is no of difference; it is merely another feature of an automated machine.

10.2 Programmable Logic Controller

The specifications of the controllers used have already been described in the proposal above. The microcontrollers for the motor control, sensors, and manipulator arm have been selected and are in the process of being interfaced with each individual component.

11. Customer needs as quantifiable requirements and constraints

For this project, NASA requires several objectives. One of them is the fail-safe ability to detect and respond appropriately to faulty sensors. The needs are being satisfied because the Extra-Vehicular Activity Robotic Assistant (EVARA) that the team will be building will be responding appropriately to faulty sensor and a failed joint. Also, the EVARA has HLC which is another customer need,

12. Profiling Several Concepts

12.1 Speech Recognition

In brainstorming for the speech recognition system, some contrived suggestions included:

Speaker independent
Letting laptop process speech (requires a fast processor)
Voice activated
Unintelligible detection (LED-feedback)
Using a pair of walkie-talkie
Using a headset microphone to transmit, with walkie-talkie as receiver

12.2 Sonar: Design Concept Development

The development of this project design has its bases on some ideas of the ERA Robotic Assistant that NASA developed in the past. However, there are some differences in the ways the team will be constructing the EVA. One of them is the way the robot will tracking for obstacles. For example, Boudreaux, the EVA Robotic Assistant, uses sensors for tracking humans. This robot uses the LMS-200 laser and a stereo vision using Firewire cameras. In comparison to the team’s tracking system, Autonomo’s had sensors to check for obstacles and be able to make a decision on time.

13. Feasibility and Down-selection

Not all of the suggestions were implemented for using speech recognition for HLC. For example, making the system speaker independent would result in lax security. The HLC selected is voice activated and has a rudimentary unintelligible detection technique.

Originally, the transmitter and receiver was only a pair of walkie-talkies. This invalidates one of the reasons (ability to work in parallel fashion) for using speech as a HLC, requiring the operator to use his hands to communicate with the robot. To circumvent this, a headset microphone with a voice activated feature came about. Also, using hardware to implement speech recognition will increase performance of the laptop’s processor and so freeing more processing power for other tasks.

14. Visual Elements to Communicate Concepts

14.1 High Level Command

Of the reasons listed above for the HLC being based on speech recognition, the ability to do parallel tasks is paramount. For this reason, one of the walkie-talkies will be disassembled and revamped to have a voice activated circuit. The Voice Operated Transmitter (VOX) will allow for the operator to merely speak and transmission will occur, without the need for the operator to momentarily stop his task. Shown below is a basic VOX circuit having a pair of walkie-talkies incorporated with it (Figure 25).

Figure 25: Walkie-talkies interfaced with VOX circuit

The second walkie-talkie acts as a receiver. This allows for the frequency to be matched, and an easy straight-from-the-box implementation. Figure 26 shows the modified speech recognition system (Figure 10) using a walkie-talkie as receiver (and input to system), rather than a microphone as an input to the HM2007.

Figure 26: Walkie-Talkie acting as input to circuit

15. Team’s effort to conduct a field investigation to supplement textbook learning

The team will highly benefit from the field trip to NASA Johnson Space Center. This trip will enhance the team with ideas in implementing the current project as well as future projects. Also, this opportunity will give the team a chance to get a better understanding of the EVA technologies.

16. Conclusion

Today, autonomously operated machines play a very important role in space exploration missions. With autonomous robots, tasks can be carried out efficiently by astronauts. The proposed design will isolate a conceptual robotic system. The proposed design will illustrate a conceptual autonomous robotic system. The integrated HLC and fail - safe operation will make future space robotics more robust and also meet requirements of NASA/TSGC Challenge.

References

[1] http://www.microchip.com/download/lit/pline/picmicro/families/16f87x/39582b.pdf

[2] http://www.mikroelektronika.co.yu/english/product/books/picbasicbook/05.htm

[3] VOX circuit: http://www.rason.org/Projects/basicvox/basicvox.htm

[4] Speech Recognition layout:

http://www.imagesco.com/articles/hm2007/SpeechRecognitionTutorial02.html

[5] HM2007 chip: http://www.the4cs.com/~corin/cse477/toaster/datasheet.pdf

[6] SRAM IC: http://bszx.iinf.polsl.gliwice.pl/mikroiso/element/6264.html

[7] Iovine, John. (1998). Robots, Androids, and Animatrons: 12 Incredible Projects You

Can Build. New York. McGraw-Hill.

[8] http://www.doc.ic.ac.uk/~ih/doc/par/

[9] Duffy, Joseph. (1996). Statics and Kinematics with Applications to Robotics. New York. Cambridge University Press.

[10] Clark, Dennis. Owings, Michael. (2003). Building Robot Drive Trains. New York. McGraw-Hill

[11] NASA using Voice-Command: http://vesuvius.jsc.nasa.gov/er_er/html/era/era.html

[12] Burridge, Robert. Graham, Jeffrey. “Providing robotic assistance during extra-

vehicular activity” SPIE November 2001,

[http://vesuvius.jsc.nasa.gov/er_er/html/era/Information/spie_v9.pdf]

[13] Festa, Paul. “Hackers attack NASA, Navy”. CNET. 4 Mar. 1998

<http://news.com.com/2100-1001-208692.html?legacy=cnet>

[14] Friel, Brian. “NASA Web Site Hacked” Zeitfenster. 7 Mar. 1997.

<http://www.zeitfenster.de/firewalls/nasa-hacked.html>

[15] Roberts, Paul. “NASA Servers Hacked” PCWORD. 3 Feb. 2003.

<http://www.pcworld.com/news/article/0,aid,109174,00.asp>

Appendix A: Budget

ITEM NAME				COST
Sensors				$700.00
Heavy Torque Electric Motors				$500.00
Laptop				$400.00
Chassis and Wheels				$400.00
PIC (microcontrollers)				$20.00
PIC Pro Starter Kit				$200.00
Motors				$157.00
Supplies				$100.00
Total				$2,477.00