Download Final Report

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
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.