Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Remote Controlled Tank Wirelessly controlled tank using Android phone and Microsoft Kinect. Gordon Werner – [email protected] Ben Johnstone – [email protected] Ramazan Cav – [email protected] Tuesday October 30th, 2012 1 Table of Contents Overview .......................................................................................................................................................................................... 1 Needs Statement ......................................................................................................................................................................... 1 Objective Statement .................................................................................................................................................................... 1 Description ................................................................................................................................................................................... 1 Requirements Specification ............................................................................................................................................................. 2 Marketing Requirements ............................................................................................................................................................. 2 Engineering Specifications ........................................................................................................................................................... 2 Analysis ........................................................................................................................................................................................ 2 Concept Selection............................................................................................................................................................................. 4 Existing Systems ........................................................................................................................................................................... 4 Navigation Control Systems ......................................................................................................................................................... 6 Turret Control Systems ................................................................................................................................................................ 7 Power Source ............................................................................................................................................................................... 8 Microcontroller ............................................................................................................................................................................ 9 Design ............................................................................................................................................................................................. 10 Overall System Level 0 Design.................................................................................................................................................... 10 Subsystems ................................................................................................................................................................................ 10 User Interface and Controls ....................................................................................................................................................... 12 Extensibility ................................................................................................................................................................................ 12 Background Specifics.................................................................................................................................................................. 12 Manufacturability ...................................................................................................................................................................... 12 Background Specifics.................................................................................................................................................................. 13 Multidisciplinary Aspects ........................................................................................................................................................... 13 Outside Contributors ................................................................................................................................................................. 13 Considerations ............................................................................................................................................................................... 14 Health and Safety ....................................................................................................................................................................... 14 Sustainability .............................................................................................................................................................................. 14 Cost Estimates ................................................................................................................................................................................ 15 Testing Strategy.............................................................................................................................................................................. 16 Risks ................................................................................................................................................................................................ 17 Kinect ......................................................................................................................................................................................... 17 Microcontroller Selection .......................................................................................................................................................... 18 Power ......................................................................................................................................................................................... 18 Schedule ......................................................................................................................................................................................... 19 Perspective ..................................................................................................................................................................................... 19 I. Overview 1. Needs Statement Today, American soldiers are deployed all over the world. Many are in places where combat is extremely likely, and there is a real threat on their lives. To prevent loss of life, the military attempts to gain as much information as possible about an area before sending troops in. Many recon devices, such as the reaper drone are restricted to the air. While this is an effective recon method, dense jungles, caves, and buildings are all immune to aerial surveillance. A new recon device is needed that can easily move through such areas without putting soldiers in harm’s way. 2. Objective Statement The objective of this project is to design a portable and remote controlled tank system that can be used for recon, assault and defense in the field while also reducing the risk of friendly casualties. The tank will be controlled remotely by two users, one for directing the tank’s movement, and another to control the tank’s gun. The driver of the tank will control it with a portable device, such as a smart phone, while the gun operator will control the aiming using a Microsoft Kinect. The driver will be able to accelerate forward and backward, and rotate the tank both clockwise and counterclockwise. 3. Description Using cameras attached to the tank and the gun, operators are able to see the field relevant to their control system. For driving, the mobile device’s internal accelerometer is used to control movement: tilting forward to drive forward, back for reverse, and left and right to turn. Using Kinect controls, the gunman can position the turret with his hand and control firing with his voice. Figure 1: High-level Diagram 1 II. Requirements Specification 1. Marketing Requirements Table 1: Marketing Requirements Marketing Requirements 1. The system should have portable controls. 2. The system controls should be easy to learn. 3. The system should move accurately. 4. The system should be controlled without line of sight to the user. 5. The system should be able to run long enough to complete a mission. 2. Engineering Specifications Table 2: Engineering Requirements Engineering Specifications Engineering Requirements 1,2,3,4 A new user must be able to run the obstacle course in 3 minutes with no previous familiarity of the system controls, no knowledge of the course, and no live visual of the course. 2,3 Turning and mobility should be accurate to 10 degrees. 3 Tank should respond to command within 300 ms. 5 Tank should be able to run for 2 hours before batteries need to be recharged. Justification Any soldier should be able to control the recon tank in the field with minimal training and without line of sight to the tank. The tank needs to control as expected; if one wants to drive towards an objective one must know that the tank is going on the correct path. If tank does not respond as quickly as if it were manned, it serves no effective purpose tactically. If the tank’s batteries run out, it cannot be used. 3. Analysis The purpose of the remote controlled tank is to move the operators from within the tank to a safer and remote location. One operator may actually be in the field but at a safe distance from the tank and out of harm’s way. The engineering specifications describe how the new tank should operate. The new tank should function similarly with the operators at a remote location versus the operators controlling the tank from 2 within. The control systems should be able to provide the same functionality that normal tanks provide and incorporate newer functionality as well. The first engineering specification is that a new user must be able to run a training course using the new controls within a set amount of time. The user can not have any previous knowledge or familiarity with the system. The purpose of this is so that the control systems to navigate the tank and control the turret aiming and shooting are easy to learn and understand. It is a guide for the developers to follow when designing the user interfaces as well as the backend systems for implementing the controls. With this specification in mind, a user friendly interface will be created. The next two specifications relate to the accuracy of the tank and turret movement when responding to commands from the operators. The purpose of these specifications is to allow for accurate control of the systems or else the tank would be useless. If the turret operator is unable to acquire a target quickly, then the target might escape. If the navigation operator is not able to drive in a safe manner or the tank does not drive in the direction that is intended, then the tank might be unsafe for soldiers to be around, and it might drive through hazardous conditions instead of a safe path set by the navigator. The new tank controls need to “feel” like the old controls inside the tank. 3 III. Concept Selection 1. Existing Systems Predator drones perform surveillance, but in the air and a counterpart vehicle is needed for ground support. There are high performance cameras that transmit video back to the operator who may use a joystick to control flight and shooting. These control systems will also be used for the tank. A ground based vehicle was chosen because there is a need to support soldiers on the ground and to have a vehicle go into hostile environments before any soldiers do. This would provide greater knowledge of the area as well as keep soldiers out of harm’s way. Figure 2: Predator Drone There are many similar projects that exist, and the best and easiest solution for the tank would be to use modular designs based on such projects and incorporate them into the tank’s design. Modular designs mean that no component of the tank relies on any other component to work correctly. The components themselves can be removed without affecting the rest of the tank. With a modular approach, the solution can be broken into smaller and simpler pieces. The tank may feature many modular components, such as the camera systems transmitting video back to their respective control systems. The cameras themselves should not rely on anything to work other than a power source. The control systems should not rely on any specific camera but should be able to work with any compatible camera chosen. The project pictured in Figure 3 may have designs that can be used such as how a webcam is used for video. 4 Figure 3: Autonomous Tank Another tank project such as the one pictured in Figure 4 might be used as a guide for how to transmit the wireless signals from the controlling device to the tank so it can be driven. This tank features its own custom made controller with two thumb sticks and a directional pad accompanied by buttons. The point of this one is not the design of the controller but how the controller sends its wireless signals and how the tank receives those signals and interprets them. Figure 4: Wireless RC Tank 5 2. Navigation Control Systems iPhone Platform Table 3: Portable Platform Decision Android Platform Windows Platform http://coolspotters.com/cellphones/apple-iphone http://www.mobilebond.com/asusrecomfirms-its-android-phone/ http://www.amazon.com/Samsung-FocusWindows-Phone-AT/dp/B0047T74VS PROS: - Tons of apps and samples available - Lots of tutorials - Easy to use Pros: - Pros: - - Cons: - - - - No group members have an iPhone or iPod touch No group members have any experience coding for iPhone Apple development uses objective C, a propriety language available only on Apple computers No group member has an Apple computer Cons: - Tons of apps and samples available Lots of tutorials Applications can be created using Java Android phone available for use Easy to use No group member has experience developing android apps - Cons: - - Best Solution Tons of apps and samples available Lots of tutorials One team member has experience developing apps for it Not as easy to use as known platforms Apps coded in C# or VB, which only one team member has experience with C# Windows phone is not as widespread as the android and iPhone platforms 6 Analysis - The android platform was chosen because it is the easiest of the three to create apps for since all team members know the main programming language used, Java. Although no one has developed for android devices, there are plenty of sources to get help and code samples and tutorials, and the only setback is that it will take some time to get everything setup for mobile devices. The iPhone platform is just as popular as android if not more popular, but because it requires an Apple product to develop on, as well as an Apple product for testing the app, it was an unfeasible decision. This path would require an immense amount of money that would be out of budget. As for the Windows phone platform, this platform is not as used and widespread. There are a lot of apps out there for it, but nowhere near as many as the other two platforms. Another con for the Windows phone platform is that applications can be written in the programming languages of C# or Visual Basic. The problem with this is that only one member has experience with C# and it would take too much time for the others to catch up. Android is the chosen platform to go with. 3. Turret Control System Table 4: Gun Movement Control System Microsoft Kinect Portable Device Pros: Pros: - Speech recognition - Already implementing using a portable - Movement gestures recognized device - Team member already has access to - Easy to program using a language all a Kinect sensor team members know Cons: - Team members unfamiliar with Kinect development Cons: - Not much diversity among project component Requires another android device (if using android platform again) which team only has one Best Solution Analysis: The Microsoft Kinect sensor was chosen. Although the team will have to face a new development platform and is unfamiliar with the Kinect, the Kinect is a new way to implement the gun controls for the tank project. Another portable device would have been more practical and would have fit time restraints better, but using a second android device would be very similar to the tank’s movement controls which provide less design opportunities. 4. Power Source A microcontroller and two cameras will be mounted on the tank. In order to power these components, a portable power source is required. The tank itself has its own power source, so it 7 was not necessary to take the tank’s power consumption into account. Three possible solutions were considered for the component power source: a lithium-ion battery pack, a NiMH D size battery and a lithium ion flat top battery. All three meet the operation time goal, and are rechargeable. The three solutions are compared in the tables below. Table 5: Power Source Comparison Li-ion Battery Pack NiMH D Battery Li-ion Battery http://www.tenergy.com/31006_2 http://www.tenergy.com/10105?ext=F http://www.tenergy.com/30005?ext=F PROS: - Rechargeable - Good capacity (5200 mAh) - Small - Built-in connectors Cons: - Expensive ($3045) Pros: - Pros: - Small Inexpensive ($12) Cons: - Low Capacity (2700 mAh) Cons: - Very high capacity (10000 mAh) Expensive ($30) Requires 5 batteries Takes up a lot of space Best Solution Analysis: Ultimately, the Li-ion battery pack is the best choice. It has a capacity of 5200 mAh, meaning it can power the components for at least 4 hours. In addition, it takes up very little space. Although the D batteries have almost double the capacity of the battery pack, it would require 5 of them connected in series to get a voltage greater than 5 V. The Li-ion batteries are small and inexpensive, but their comparatively low 2600 mAh capacity eliminated them from contention. Although the battery pack uses 7.4V, the voltage can be scaled down using a voltage regulator. The cost of the pack varies depending on where it is purchased, but its highest cost is $43, just $13 more than the cost of the 5 D size batteries that would be needed. 8 5. Microcontroller Gumstix Raspberry Pi Windows Platform http://www.skybotix.com/support/ wiki/images/8/8f/Gumstix_overo_w ifi.jpg http://2.bp.blogspot.com/aBZlcm5wA48/Tw1969sT6jI/AAAAAAAA HVY/WJHDSkceUCc/s1600/RaspberryPi-computer.jpg http://markus.jabs.name/wpcontent/uploads/2009/08/Arduino.jpg PROS: - Runs full Linux - On board Wi-Fi and USB - Easy to use - On board DSP - 512 MB Ram Cons: - Expensive ($250) Pros: - Pros: - Easy to use Inexpensive ($30-$40) Programmed with C++ Cons: - No operating system No wireless Best Solution Cons: - Runs full Linux USB on board On board Ethernet Inexpensive ($35) Minimal documentation for chips - No wireless - Sold as-is, cannot add or remove parts **Implemented Device Analysis: The Gumstix board was determined to be the best choice, due to its many positive features. The only bad thing that can be said about the Gumstix is that it is expensive, costing $250. However, given its capabilities, such as on board Wi-Fi, USB, and full Linux support, the Gumstix board was chosen for the project. Its capabilities make it worth the higher price. Although the Gumstix was the best choice in terms of hardware, the high price point forced the use of a different micro-controller. The Raspberry Pi was chosen for the project as it was affordable and could still perform the required functions without adding too much complexity to the project. 9 IV. Design 1. Overall System Level 0 Design Android Movement Controls Video of Environment (x2) Kinect Weapon Controls Power Source Airsoft Tank Tank Movement Gun Controls Figure 5: Level 0 System Diagram The tank is controlled by two operators. The gun operator will control the turret movement and firing via an Xbox Kinect. The Kinect detects body movement and can also perform voice recognition. The operator will use gestures to move the turret while firing will be controlled by voice commands. The driver will control the tank's movement via a smart phone. The accelerometer in the smart phone detects when the phone is tilted, which will allow the driver to control the tank by tilting the phone. 2. Subsystems Figure 6: Kinect Control System Diagram 10 The figure above is a level 1 block diagram of how the Microsoft Kinect will be integrated into the project. The inputs to the system are voice and gesture commands, which will be processed and sent wirelessly to the tank over a Wi-Fi network to control the tank’s turret. Raspberry Pi Video Feed Streamed Video Motion Android Commands Tank Movement Bash Scripts Kinect Commands Tank Movement Code Turret Operation Code Turret Movement Figure 7: Tank Control System Diagram The figure above is a level 1 block diagram of the Raspberry Pi (R-Pi). There will be three inputs to the system consisting of a video feed from the camera, the Android wireless commands and the Kinect wireless commands. The video feed is processed by a program called Motion which creates a web server that displays the video stream. The Android device connects to this server and displays the provided stream. The wireless commands from the Android device and the Kinect are processed by independent bash scripts on the RPi. Once the command has been decoded the R-Pi powers the tank’s motors appropriately. Power System 7.4 V Battery Pack Camera 1 Power 5V Regulator R-Pi Power Figure 8: Power System Block Diagram The figure above is a level 1 block diagram of the power system used to power the components which will be mounted on the tank. A 7.4 V Li-ion battery pack will power both 11 cameras and the R-Pi. A voltage regulator will be used in order to lower the output voltage to 5V, which is the required voltage for all three components. 3. User Interface and Controls T h e f i g u r e a Figure 8: Kinect User Interface Above is a preliminary screenshot of the user interface for the Kinect. The user interface will consist of three moving images, and multiple stationary images to implement the controls. The moving images are two hands and a circle image for the head. These will move based on the operator’s physical movement once they are in the Kinect’s camera view. The blue arrows are stationary images which the operator will have to move his/her hand over to control the turret’s movement. The operator can then use voice commands such as “fire” to further control the turret. 4. Extensibility The tank design for this project is a small-scale proof of concept. With some modifications, the system can be scaled up in size for actual military use; however that is out of the scope of the project. Considerations such as tank sizing, weight, armor, and cost are not a part of this project’s goal. 5. Manufacturability The system is composed of commercial off the shelf (COTS) components, giving it a high degree of manufacturability. There will be no custom hardware in the tank; instead it is only necessary to integrate the microcontroller and cameras into the tank platform. In addition, the software components can be reused for later projects. 12 6. Reliability The reliability of the system will depend greatly on the communication between the tank and its controllers, as well as the connections between the microcontroller and the tank's motors. There must be a reliable Wi-Fi infrastructure in place to ensure that the Kinect and Android control systems can send and receive messages from the tank. Using an inferior wireless network may result in an inability to communicate with the tank. In order for the tank to perform any actions, the microcontroller must be connected to the motors in the tank. These connections must be secure enough that they will not be severed during normal operation. Poor connections between the microcontroller and the motors may cause parts of the system to be inoperable. 7. Background Specifics The tank control system design will require the use of a microprocessor. This will require C code, or low level bash scripting, two languages the group is familiar with thanks to prior classes and co-op experience. The android control app will be written in Java, a language that was taught in all three parts of the computer science track, as well as software engineering. 8. Multidisciplinary Aspects Designing the power system for the tank required some knowledge of electrical engineering. It involved determining the power consumption of the components and comparing power sources based on their capacity and voltage levels. In addition, a small regulator circuit will need to be used in order to provide the right voltage. There are several software components in this project. These include the programs for the Kinect and Android control systems. All three group members will be responsible for programming. Managing the development and testing of the software for this project will require some of the techniques learned in the software engineering curriculum. 9. Outside Contributors Emilio Del Plato helped with the selection and setup of the tank’s micro-controller and motor drivers. He also helped set up the R-Pi on the RIT network. Rick Tolleson helped with the ordering of equipment as well as providing supplies and suggestions with the project. Dr. Mondragon helped set up a meeting with another project group which resulted in the use of the Motion software for this project. 13 V. Considerations 1. Health and Safety Considering that the primary purpose of the system is military use, there are many different facets to be considered. Although the tank’s main purpose is reconnaissance, the system is outfitted with munitions that can provide lethal force. This outfitting could prove detrimental to the health and safety of enemy forces; however in battlefield situations that is an unavoidable cost of operation. By providing a system that does not require live men in the vicinity of operation reduces such dangers to friendly forces. In the context of the project, the tank shoots air soft pellets which can be dangerous to bystanders. It is imperative that children do not play with a system such as this to avoid harm. 2. Sustainability The tank uses rechargeable batteries to power the cameras and microcontroller outfitted on the tank. The only cost will be the electricity used to power the Microsoft Kinect and computer it is attached to, and to charge the Android phone as well as the rechargeable batteries. 14 VI. Cost Table 7: Cost Estimates for Project 15 VII. Testing strategy The main test will employ two operators with little hands-on experience who must navigate the tank through a course. The operators will also have no familiarity with the course and must engage enemy targets while maneuvering through the course. The initial testing completed were the independent software tests. These tests consisted of both the Kinect and Android running their respective apps and ensuring that they produced the correct output. The Kinect and Android programs were first tested with simple output strings to determine correct functionality without the need for functional hardware on the tank. As hardware development progressed, the tests were expanded to include communication over a network. To test communication over the network, a listening port was opened on the R-Pi using Netcat. The Kinect and Android code was expanded so that the string outputs were sent out to the listening port rather than to standard output. The listening port on the R-Pi simply printed all received data. When the data printed matched the output of the Kinect and Android apps, the tests were considered successful. The testing of the Kinect and Android communication over the network was then expanded to full integration testing. Bash Scripts were written on the R-Pi that interpreted the incoming network traffic and responded accordingly. The Kinect and Android were able to successfully receive input from the user and transmit the correct command over the network to the R-Pi; the R-Pi was able to receive those commands and display them to the terminal. The first hardware test that was conducted consisted of powering the tank’s motors using the motor drivers and the R-Pi GPIO pins. Initially the hardware was tested using predefined input. The next step was to ensure that the correct voltages were sent from the correct GPIO pins into the correct motor driver pins. After successfully wiring the R-Pi to the motor drivers and the motors themselves, the GPIO control code was integrated into the existing Bash scripts allowing for full system testing. The Bash scripts were expanded to control the tank based on the commands received from the Kinect and Android over the network. The tank responded correctly to inputs from both systems and thus the project integration was complete. 16 VIII. Risks The major hurdles that must be overcome in project development are the team’s unfamiliarity with the development environments for both the Kinect system and the android operating system. In addition to this, implementing the Gumstix board onto the Tank itself is something the team again has little familiarity with, as it will require deconstruction of the tank’s circuitry and the addition of the team’s power supply and microcontroller. Another risk is the capability of the R-Pi board to provide the required features to fully implement the control system. Space is another consideration as the team will be adding microcontroller circuitry, a custom power supply and multiple cameras. 1. Kinect The risks associated with the Microsoft Kinect consist of the integration of the speech recognition and gesture tracking functions, as well as hardware failures. The speech recognition sample program that was included with the Kinect’s development kit runs similarly to a normal program except that the program loops indefinitely. This loop does all the speech capturing and processing and stops only when the user closes the program. The gesture tracking sample that was found online works using GUI events. The program displays a GUI, and the program performs its functions only when events happen to the GUI. With the Kinect, the basic event is that a skeleton of a person is captured, which is when someone steps in front of the Kinect in full view of it. Once a person is captured by the Kinect, then the rest of the program processes the gestures in an indefinite loop. The big risk here is that both programs have unidentifiable looping structures that span across multiple functions in the programs, and trying to integrate both into one program will make things very complicated. To solve this problem the Kinect documentation and many online resources need to be consulted. The other risk with the Kinect is due to hardware failure. One of the main reasons why the Kinect was chosen is because it features speech recognition and gesture tracking that can be used to control the tank. The Kinect provides these powerful features for use. The problem with this is that if any one component within the Kinect fails, it may propagate through the rest of the Kinect and into our project. There are many internal sensors and complex circuitry that are susceptible to damage. The worst case hardware failure scenario is that the entire Kinect no longer works because it is broken. This would mean that the turret cannot be controlled and the team will fail the final demonstration. As a safeguard, a second control system will be implemented using a joystick to control the turret. Another possible scenario is that something in the Kinect goes wrong to the extent that it still works but the Kinect sends the wrong commands to the tank. This is a very difficult problem to troubleshoot and would again result in total system failure. To solve this problem, a backup 17 system will also be implemented using either a joystick or a mouse (either of which can be wireless). 2. Microcontroller Selection A major risk associated with the project is if the microcontroller chosen can provide the full functionality required. The board needs to be capable of streaming out two separate video streams, while also reading commands sent from the Android and Kinect and issuing them to the tank’s servos. The tank and turret are controlled using PWM signals, requiring the microcontroller to have a separate output pin for each servo on the tank. Outputting signals through the board’s 6 PWM out pins can be accomplished through a simple command line argument. In addition, the Gumstix has on board DSP, allowing for easy video encoding and streaming through a network. When researching streaming multiple video streams through the Gumstix, little information was found, however the board should be capable of streaming both feeds. If team experimentation shows the board is incapable of multiple video feeds, the team’s secondary plan is to use a wireless webcam for one connection that will stream directly to the controller screen, removing the need for on board encoding on the Gumstix. This design will still allow for the design of the video encoding and streaming system, while also allowing the project to be completed to specifications. 3. Power Another risk is that the components mounted on the tank cannot be powered with a portable power supply. Without an onboard means of powering the mounted devices, the usefulness of the tank is greatly diminished. The tank has its own power supply, so it was only necessary to look into the microcontroller and the cameras. An analysis of the Gumstix board and a USB-powered webcam showed that a current draw of 875-1275 mA can be expected when the tank is in use. The Li-ion battery pack chosen as the power source has a 5200 mAh capacity, so it can power the components for at least 4 hours. Further testing is required to ensure that the power system works properly. 18 IX. Schedule Table 8: Schedule Task/Milestone Original Due Date Team Member Choose microcontroller 9-4-12 Gordon Modified Completion Date Completed Develop Android Functionality Map out tank’s current control system Kinect Video interaction 9-10-12 Ben Completed 9-10-12 Group Completed 9-8-12 Ramazan Completed (See comments) Android video interaction 9-20-12 Ben & Gordon Completed Complete Android application 9-20-12 Ben Completed Set up motion program on Raspberry pi Figure out how the PWM controller works 9-22-12 Gordon Completed 9-29-12 Gordon Completed Figure out how the motor controller works 9-29-12 Gordon Completed Figure out how the PWM controller works 9-29-12 Gordon Completed Comments Gumstix too expensive, searching for alternatives Schedule conflicts over the summer New tank acquired Video can’t be integrated directly into program, use separate window for video. Integrate video stream into Android app Video stream integrated into app, need networking and commands Setup the program on the microcontroller Setup sample program to control PWM pins Setup sample program to control a servo motor Setup sample program to control PWM pins 19 Develop backup control system program 9-29-12 Ramazan Completed Complete independent software systems Complete independent software system tests Begin hardware integration 9-10-12 Ramazan Completed 9-24-12 Gordon Completed 10-5-12 Ben Completed Complete Hardware Integration Complete Integration Testing 10-12-12 Ramazan Completed 10-12-12 Gordon Completed Complete Acceptance Testing 10-19-12 Ben Completed Final Demonstration 10-30-12 Group Completed Backup system will use the Xbox 360 controller and windows program Schedule conflicts arose over the summer Testing has been carried out using the R-PI Begin assembling hardware Finish hardware integration Test hardware after everything is put together Complete project, make sure all requirements are met Demo project 9/7/12 9/9/12 9/4/12 9/20/12 9/20/12 10/1/12 10/28/12 Video streaming Netw ork Commands Microcontroller Command Decoding Motor Controlling Video streaming System Integration [Name] 2.3 2.4 3 3.1 3.2 3.3 4 9/6/12 10/1/12 10/18/12 10/1/12 10/26/12 10/12/12 10/27/12 10/27/12 10/28/12 Integrate all sy stems Integration Testing Acceptance Testing 4.2 4.3 4.4 10/1/12 10/1/12 Sy stems 9/4/12 10/1/12 9/29/12 9/29/12 9/15/12 9/15/12 4.1 Complete Independent 9/6/12 Button functionality 2.2 Gordon 9/5/12 10/1/12 Tilt detection 10/1/12 2.1 9/4/12 Android Program 9/22/12 9/15/12 Sy stem Ben 9/9/12 9/14/12 2 Backup Control Netw ork Commands 9/7/12 9/8/12 9/7/12 10/1/12 End 1.4 1.3 & Gestures Combine Speech 9/6/12 Gesture Tracking 1.2 1.2.1 9/5/12 9/4/12 Speech Recognition Start 1.1 Task Lead Ramazan Tasks Kinect Program WBS 1 Duration (Days) 2 15 25 17 28 6 6 6 28 5 5 5 5 26 5 5 5 5 5 28 % Complete 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% Working Days 0 11 20 14 20 8 8 3 20 15 16 7 8 20 6 5 6 2 3 20 Days Complete 2 15 25 17 28 6 6 6 28 5 5 5 5 26 5 5 5 5 5 28 Days Remaining 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 20 Gantt Chart: 05 - Nov - 12 29 - Oct - 12 22 - Oct - 12 15 - Oct - 12 08 - Oct - 12 01 - Oct - 12 24 - Sep - 12 17 - Sep - 12 10 - Sep - 12 03 - Sep - 12 21 X. Perspective During the course of the project many obstacles emerged which had to be overcome for project completion. These obstacles included the rejection of the Gumstix board as a viable platform as well as how to power the DC motors of the tank. The Gumstix board was too expensive for the department to purchase and an alternative was required. Eventually with some help from an outside contributor (Emilio), the R-Pi was chosen as the platform that was used for the project. The R-Pi proved difficult to use as it did not have full support for most pieces of hardware and the hardware that it claimed to support did not always function as expected. For example, at one point a powered USB hub was used to interface with the webcams, the wireless adapter and a PWM controller. However, the R-Pi would continually freeze and lose connection to the network when using this setup. This required a total change in approach to both the video streaming and the motor control system. This motivated the use of the R-Pi’s GPIO pins in place of the PWM controller as well as the streaming of only one video feed through the R-Pi. Another difficulty that was faced was the integration of video streams into the Kinect application as well as the backup control system. It was extremely difficult to find any resources where people had implemented this design and the existing solutions were not compatible as they were built upon old frameworks of Microsoft’s Visual Studio. The solution to this was to open a web browser that would display the video feed from the camera attached to the tank’s turret. The motor drivers had a higher than expected learning curve as it took a considerable amount of time to correctly configure. This was due to inexperience with this type of hardware. There was also a lack of documentation for the hardware being used. Additionally, the motor drivers may have been defective or misrepresented by the vendor as supplying a PWM signal to the PWM input pin did not produce a correct output. The Android program had a bit of a learning curve, but was completed successfully as there was experience with Java programming. It was frustrating as well because the program was correctly written but the program was not correctly communicating with the other hardware. This was later determined to be caused by the XML structure in the project’s file system. After some research into the problem a variable in one of the XML files of the project had to be changed. This variable was related to how the project was setup with the Android SDK. If this project was to be repeated, a higher emphasis on research, preparation and planning would be recommended. The largest pitfalls to the project came from a lack of understanding of the parts required and their relation to each other. Most progress came from experimenting with and learning the different pieces of hardware used. This was exacerbated by the delay in picking and ordering hardware, as there was less time to learn the hardware or order different parts. A little bit more precise planning into the assembly of the system would have been better. Some last ditch efforts were made and they ultimately made the tank look less professional.