Software Engineering Final Report - Blue Team

Department of Aerospace Engineering
1
Software Engineering Project Final Report
Blue Team
1

The Pennsylvania State University, University Park, PA 16802
This report serves as the culiminating experience for the software engineering project in
AERP 440 Introduction to Software Engineering for Aerospace Engineers. Information
about requirements, design, coding, testing and verification and validation are presented
and analyzed. Various reports or key data points are presented, such as UML sequence
diagrams and testing reports. The Blue Team found this project to be benefial to their
learning in the course.
I. Introduction
HIS semester in AERSP 440 Introduction to Software Engineering for Aerospace Engineers, the class has
experienced two parallel activities. The first of these activities are traditional instructional methods, namely
lectures, homework and examinations. The later of these activities consisted of a software engineering project;
contained here is the final report for that project. Specifically, we were directed by Dr. Long that:

The project for this course will be the development of a software/hardware system using a small three-
wheeled robot chassis and an onboard Arduino processor, sonar sensor, and wifi camera. Each team will
build a robot that will:

Controlled thru a user interface on a laptop
The person controlling the robot will not be in the same room as the competition
Each robot will have a webcam on it and the person controlling it will see the image from the
onboard camera
Try to find and shoot the other robot using infrared sensor
Try to evade the other robot
Which ever team shoots the other teams robot the most wins

In order to undertake this task, we needed a laptop and a C or C++compiler. Additionally, Dr. Long provided:

A robot platform
An Arduino processor
An Arduino WiFi board
An Arduino Motor control board
A wifi camera (Foscam FI8909W)
A Infrared transmitter and receivers
Batteries

The team noted early on that all of the above provided materials were to be returned at the end of the semester, or
that the team would have to reimburse Dr. Long for the cost of them. Our team elected Brad Sottile as its Chief
Executive Officer (CEO), Tom Gempp as its Chief Financial Officer and Brian Harrell as its Chief Information
Officer (CIO).

1
Brad Sottile, CEO, is currently a graduate student in aerospace engineering. The other members of the team are
undergraduate students in aerospace engineering or engineering science. Various members of the team are student
members of AIAA and/or IEEE.
T


2
II. Chiefs
A. Chief Executive Officer (CEO)
Brad Sottile is the Chief Executive Officer (CEO) for the Blue Team. The role of the CEO is to interact with the
other groups to maintain the projects costs and time time schedule. The CEO has also been the main point of
contact for the customer. Every week, Brad has tried to stay in touch with Dr. Long, the TA, and the other groups in
order to mentor the groups and help to troubleshoot problems. The CEO has also action as the Blue Teams
designated liaison to the CEO of the White Team, Tim Double. For the saking of space, a detailed Gannt chart
reflecting the Teams progress can be found attached to this report. All in all, some tasks where completed ahead of
schedule, some tasks ran late, and some tasks were completed right on time. The Blue Team found trying to work
ahead to be beneficial, since it enabled us to have a little more time to fall back on for when we did have schedule
slips. Overall, the CEO is pleased that this project was delivered on time and under budget, a rarity for many
software engineering projects.
B. Chief Financial Officer (CFO)
Tom Gempp is the Chief Financial Officer (CFO) for the Blue Team. The CFO is responsible for the financial
planning and record-keeping, as well as financial reporting to higher management. Typically, the CFO reports
directly to the CEO and assists the Chief Operating Officer on all strategic and tactical matters as they relate to
budget management, cost benefit analysis, forecasting needs and the securing of new funding. Throughout the
course of this development, the CFO reported directly to the CEO, and updated the teams and client regularly.
Overall, the project was planned to have cost $326,000.00; the final cost of the project is $206.150.00,
approximately 45% less than what was expected.

1. Constructive Cost Model (COCOMO)
The Constructive Cost Model (COCOMO), an empirical model based on project experience, is a well-
documented, publically available model which acts independently from a specific software vendor. There are three
distinct level of project complexity that this model is able to represent: simple, moderate, and embedded. This
project fell into the simple complexity category in which the following model can be used:

PH = 2.4(KSI)
1.05
H (1)

where PM is person months, KDSI is the thousands of delivered source instructions, and M is the product, project,
and team characteristics; all rated on a scale from 1 to 6. The variable M is defined as:
H = PERS RCPX RuSE PIF PREX FCII SCE (2)

where PERS is the personnel capability, RCPX is the product reliability and complexity, RUSE is the reuse
requirement, PDIF is the platform difficulty, PREX is the personnel experience, FCIL is the team support facilities,
and SCED is the required schedule. The following values were used for each:
PERS 3 PREX 2
RCPX 2 FCIL 1
RUSE 1 SCED 2
PDIF 2

With 1,000 lines of code written and using the COCOMO equation above, the expected time for this project was:
115.2 person months, which for a team of 35 people works out to be 3.29 months/person. This appears high
considering no one was able to work on this project more than part time, however, this overprojection may be a
function of our inexperience in software cost estimation.
2. Initial Cost Estimation
The methodology used in conducting the initial cost estimation was the bottom-up approach. This method starts
at the component level and estimates the effort required for each component; then these values are added to reach a
final estimate. Table 1 shows the breakdown each of the Chiefs and team leads submitted for estimation.


3
Table 1. Initial Blue Team Cost Re-Evaluation

Midway through the project, a voluntary reassessment was conducted so that the Chiefs and team leads could have a
better understanding of the amount of remaining work to complete our mission objective. The following table
shows the breakdown of the Chiefs and team leads estimation for the second half of the project.

Table 2. Midsemester Blue Team Cost Re-Evaluation

3. Operational Target (OPTAR)
Using the operational target (OPTAR) system used predominately at the United States Naval War College, the
budget was able to monitored more efficiently. This required team leads to submit weekly hours reports for their
groups, which were then complied into a series of interconnected documents. Once the data was loaded into the
system, the OPTAR was updated instantaneously. The complete Blue Team OPTAR is shown in Figure 1.

Figure 1. Blue Team OPTAR
Group Hours/Person TeamMembers TotalManHours(hrs) HourlyRate($/hr) TotalCost $/wk(15wks)
CEO 180 1 180 400.00 $ 72,000.00 $ 4,800.00 $
CFO 160 1 160 400.00 $ 64,000.00 $ 4,266.67 $
CIO 160 1 160 400.00 $ 64,000.00 $ 4,266.67 $
Requirements 10 6 60 200.00 $ 12,000.00 $ 800.00 $
Design 15 6 90 200.00 $ 18,000.00 $ 1,200.00 $
Coding 42 7 294 200.00 $ 58,800.00 $ 3,920.00 $
Testing 17 6 102 200.00 $ 20,400.00 $ 1,360.00 $
V&V 12 7 84 200.00 $ 16,800.00 $ 1,120.00 $
Total 596 35 1130 326,000.00 $ 21,733.33 $
Group Hours/Person TeamMembers TotalManHours(hrs) HourlyRate($/hr) TotalCost $/wk(7wks)
CEO 55 1 55 400.00 $ 22,000.00 $ 3,142.86 $
CFO 30 1 30 400.00 $ 12,000.00 $ 1,714.29 $
CIO 30 1 30 400.00 $ 12,000.00 $ 1,714.29 $
Requirements 5 6 27 200.00 $ 5,400.00 $ 771.43 $
Design 5 6 29.5 200.00 $ 5,900.00 $ 842.86 $
Coding 18 7 127.5 200.00 $ 25,500.00 $ 3,642.86 $
Testing 10 6 60 200.00 $ 12,000.00 $ 1,714.29 $
V&V 8 7 54.25 200.00 $ 10,850.00 $ 1,550.00 $
Total 160 35 413.25 105,650.00 $ 15,092.86 $


4
As can be seen in the preceeding figure, the overall project was significantly under budget. During the first five
weeks of the project, all of the teams were working simultaneously in order to get ahead, mainly by the
Requirements and Design groups. This surge leveled off from weeks five through eight, this can attributed to the
majority of the work being done by mainly the Coding group. There was a steady increase in workflow from week
nine through eleven. There was a significant surge in fund expenditures from week eleven through thirteen as
Testing and V&V began to have a significant increase in workflow; this trend continued up to the completing of the
project.

4. Blue Team Final Cost Breakdown
A complete analysis of the hours and fund expenditures by each of the groups was conducted. The breakdown of
each team is shown in Table 3.

Table 3. End of Semester Blue Team Cost Breakdown

As can be seen by Table 3, the overall project was significantly under budget. This can be attributed to using the
bottom-up method as described above. All of the groups overestimated their number of project hours because of the
unfamiliarity with the objective and tasks. The following table and figures show the distribution of the funds
expended throughout the course of the project.

Table 4. Cost Breakdown by Expense

Group TotalWorkHours HoursEstimated HoursRemaining FundsEst. FundsExp. FundsRemaining
CEO 52 180.0 128.00
72,000.00 $ 20,800.00 $ 51,200.00 $
CFO 46 160.0 114.00
64,000.00 $ 18,400.00 $ 45,600.00 $
CIO 38 160.0 122.00
64,000.00 $ 15,200.00 $ 48,800.00 $
Requi rements 58 60.0 2.00
12,000.00 $ 11,600.00 $ 400.00 $
Desi gn 94 90.0 -4.00
18,000.00 $ 18,800.00 $ (800.00) $
Codi ng 324 294.0 -30.00
58,800.00 $ 64,800.00 $ (6,000.00) $
Testi ng 108 102.0 -6.00
20,400.00 $ 21,600.00 $ (1,200.00) $
V&V 174.75 84.0 -90.75
16,800.00 $ 34,950.00 $ (18,150.00) $
Total 894.75 1130.0 235.25 326,000.00 $ 206,150.00 $ 119,850.00 $
Group TotalWorkHours HourlyRate FundsExp %Hours %Funds
CEO 52 400.00 $ 20,800.00 $ 5.81 10.09
CFO 46 400.00 $ 18,400.00 $ 5.14 8.93
CIO 38 400.00 $ 15,200.00 $ 4.25 7.37
Requirements 58 200.00 $ 11,600.00 $ 6.48 5.63
Design 94 200.00 $ 18,800.00 $ 10.51 9.12
Coding 324 200.00 $ 64,800.00 $ 36.21 31.43
Testing 108 200.00 $ 21,600.00 $ 12.07 10.48
V&V 174.75 200.00 $ 34,950.00 $ 19.53 16.95
Total 894.75 - 206,150.00 $ 100 100


5

Figure 2. Project Work Hours Distribution Figure 3. Project Fund Expenditure Breakdown

C. Chief Information Officer (CFO)
Brian Harrell is the Chief Information Officer for the Blue Team. The CIO had several responsibilities over the
duration of this project. His primary responsibilities involved setting up a secure website for the blue team, and
monitoring all files and file revisions. He began the semester by setting up a website for the blue team, which was
hosted by Google. The website contains a separate page for each step of the software engineering V-cycle
(Requirements, Design, Coding, Testing, Validation & Verification), as well as separate pages for the chiefs,
finances, Gannt chart and hours reports. Each page of the website contains all of the files and file revisions for each
separate V-cycle group. In addition, the chiefs page contains brief descriptions of each chiefs role and the Finances
page contains information and graphs related to our projected cost for this project as well as reports for each weeks
progress and expenses. Finally, the Gannt chart page contains the original Gannt chart as well as updates to the
chart as they have been provided by the CEO.
On top of maintain the website and monitoring access to the website, the CIO has also spent time backing up and
organizing all of our teams files on his own personal external hard drive. He also spent time discussing and
monitoring the progress of the project at several meetings with the chiefs and group leads. Overall, throughout the
course of this project, he was able to closely monitor access to, and the security of our website, as well as ensuring
that all groups had the necessary files and documents needed to complete the project in a timely manner.
III. Requirements
Ty Druce is the lead of the Requirements group. This portion of the report covers all the aspects leaned about
requirements engineering, including the overall process, CONOPS, requirements elicitation and documentation, and
useful charts. This document focuses on lessons learned for each of these aspects. Requirements engineering is a
crucial part of the systems engineering process and vital to the success of any program.
A. Reflection and Lessons Learned
1. Requirements Documentation
The first step in requirements engineering was requirements elicitation. This is the process of requirements
gathering and required collaboration between the customer, program management, the design team, V&V, and the
user. It was learned that the coding team also played an integral part in determining requirements, since this team
has direct knowledge on the capabilities of the software itself. In future programs, the coding team should be
consulted sooner in the process to save time and money.

In requirements documentation, semantics played a crucial role. Many requirements were rewritten several times
to obtain the most clear and concise language. It is important that requirements clearly convey what the system
should do without overbearing constraints. Finding this balance was difficult and it took a couple weeks of practice


6
before good requirements could be written easily. Unclear language can result in misunderstandings and deviate the
program from the proper path.

2. Requirements Schematics
Several types of schematics were used to visually represent the requirements and convey a high level picture of
the system. This team utilized system flow charts, UML diagrams, scenarios, and sequence diagrams to help visually
portray the system. Software engineering is uniquely difficult since it is not a tangible product; it is hard to visualize
and track progress. For this reason, it is imperative that visual aids are used to help team members understand the
scope of the system. These visuals also help program management track progress and help estimate hours and cost.
They are also helpful in making sure the customer and the designers are on the same page for the product.

3. Requirements Engineering
One of the leading reasons for software engineering failures is due to poor requirements. Requirements
engineering is the first step in the engineering cycle, but the most critical. Requirements are the cheapest item to fix
at the start of a program, but the most expensive to fix at the end of the program; therefore, it is critical to invest
time and skill into generate solid, clear, and practical requirements. This team learned the requirements process is
iterative in itself. To develop proper language, and to convey system and user capabilities, all take several iterations.
B. CONOPS and Requirements Document
A Concept of Operations (CONOPS) and formal requirements document was approved by the customer and
then utilized by the Architecture and Design team to design the system. This document was also used by the
Verification and Validation team to ensure the proper product was built and all the requirements were met. This
document has been submitted with this report.
C. Traceability Matrix
A traceability matrix was used to describe the relationships between requirements, their sources, and the system
design. It helps to link dependent and reliable requirements; therefore, making it easier to see how a requirements
change propagates to other requirements. Our traceability matrix may be found below in Figure 4.

Figure 4. Traceability Matrix
D. Viewpoint Charts
When developing a system, it is important to consider all actors with will be involved in using the system.
These actors may directly or indirectly act on the system, and they may be tangible or intangible actors. For


7
example, both the specific user and manager of a system play a separate and unique role in how they will interact
with it. Formal specifications, such as government guidelines, will also play a role in how the system is designed.
Figure 5 shows the viewpoint chart for this program.

Figure 5. Viewpoint Chart
E. Scenarios
Scenarios are used to describe real-life examples of how a system can be used. It makes it easier for people to
understand how the system would react in certain situation. Below is an example scenario created for the program.

1. Initial Assumption
The robot seeks the white teams robot and shoots it with an infrared laser more times than the white team can
hit the blue teams robot. Each teams operator has the control laptop in a separate room and can only view the
robots through a wifi camera.

2. Normal Operation
The blue teams operator maneuvers the robot and quickly finds the white teams robot. Once fount, it will begin
firing and infrared laser at it and hit it as many times as possible. If the white team locks onto the blue teams robot,
the blue robot will evade it immediately and continue to seek and destroy the white robot. The blue team will hit the
white teams robot with the laser more times than white team hits the blue robot.

3. What Can Go Wrong
The white team locates the blue robot first and begins firing upon it before the blue team can find the white robot
or the white teams robot starts shooting the blue robot more times than the blue team is hitting the white robot.
Further, the blue team must immediately perform evasive maneuvers and continue to seek and fire at the white
robot. Finally, if the blue robot hits an obstacle or gets stuck, the operator must immediately proceed around the
object, or reverse out of the situation.

4. Other Activities
The white team may be evading the blue teams lasers remarkably or the blue team keeps missing the white
robot.

5. System State on Conclusion
The blue team hits the white teams robot with the laser more times than the white team hits the blue robot and
the blue team receives three extra credit points. The robot and the control laptop are shut down.

F. Use Cases
Use cases were used to identify the actors in an interaction and describe the interaction itself in the Unified
Markup Language (UML). The following is an example of simple use case describing the task of our current
system. The 3 persons in the diagram are the customer who makes the demands, the user who programs the system


8
and controls the robot, and the robot itself which performs the action. The customer creates instructions for the user.
The user then edits the instructions for the robot in a language which the robot can understand. The robot then
transmits information back to the user so that the users instructions may be accurate to the current situation of the
robot. The robot also takes the instructions from the user and interprets the commands and performs the task. Our
use case may be found in Figure 6

Figure 6. Use Case
G. Sequence Diagram
A sequence diagram was used to add detail to use-cases by showing sequence of even processing in the system.
Sequence diagram helps understand the interaction between user and a system via series of events that take place for
a given condition. Figure 7 is a general representation of a task described in sequence of events.

Figure 7. Sequence Diagram
This sequence diagram below shows the interactions between the user, the motherboard, and the robot. It is
the responsibility of the team to ensure that the robot gives feedback to the user of whether or not a task can be
completed, when it was completed, and what the user can do to correct a possible error. Here it shows whether the
commands were accepted, whether the laser was fired, and whether the robot has taken damage from the other robot
in competition.


9
H. Structure Chart
The robotic system that the Blue Team will be using is made up of two main parts. The vehicle system will be in
the room of the competition while the controller or operator will be in another room. As the competition
commences, the camera mounted on the vehicle will continuously send a real time feed through an internet browser
on the operators laptop in the other room. From this separate room the operator will control the vehicle using a
series of commands that will be sent to the processor and board on the vehicle system. These commands will funnel
down from the processor to the IR gun and sensor as well as the vehicle motor. Figure 8 shows the robotic system
breakdown.

Figure 8. High Level Structure Chart
I. Requirements Conclusions
Requirements engineering begins the development process and is one of the most critical aspects of a program.
The difference between good and bad requirements could be the difference between a successful or unsuccessful
program, or a program with runaway costs at the end to fix poor requirements. Requirements elicitation should
utilize the several chart explained in this document to help engineers consider all actors involved in a system. It is
important requirement engineers understand the capabilities and limitations of the systems they are creating so
unfeasible requirements do not plague lower level design engineers. Understanding requirements is necessary for all
engineers.
IV. Design
Evan Masters is the lead of the Design group. The design team first began with the information provided from
the requirements engineering process. Requirements were reviewed, rated, and traced based on understanding and
clarity for the system. Preliminary and architectural designs were created in the form of sequence diagrams,
structure diagrams, state diagrams and data flow models. The key goal of the design team was to create a design
portfolio that could be easily understood and developed by the coding team, and then passed to testing and
validation and verification (V&V). It is of paramount importance that the design team worked quickly and
efficiently to produce a system design so that the coding team could get a quick start on code development. In
addition, the preliminary budget dictated that the coding team would expend the most hours on the project, so the
design team needed to work in an efficient manner to produce preliminary and architectural designs to the team
within the budget guidelines. Once each team progressed through the V-cycle, the design team used an iterative
approach to the architectural design to meet the overall team goals. As requirements were updated, the
corresponding design was tweaked and edited to meet these new requirements. During each iteration this
information was passed on to coding, testing and V&V to ensure that the overall team was making progress and
conforming to each updated design. It is the belief of the design team that a robust and efficient design was created
to give the team the greatest chance of success and therefore completing the objectives set forth in the competition,
thus placing the team in position to win the overall competition.


10
This passage reviews and reflects on the design engineering portion of the software engineering project. It
focuses on the lessons learned during this process.

1. Design Process
To prepare for the design process, the team familiarized itself with chapter 3 of the Software Engineering Book
of Knowledge (SWEBOK) and section 2.3 of a Gentle Introduction to Software Engineering (GISE). These
publications discussed the need for a robust design and ways in which this can be achieved. The next step in
developing an architectural design for the robot was to obtain the requirements document from the requirements
team. A preliminary design was critical in understanding the link between product specifications from requirements
and detailed interactions between the individual components. This architectural design is important in the
verification and validation of non-functional requirements of the system. For this project, the simplified V-cycle
does not allow for V&V to take place until some testing has begun. In a real software application, this V&V work
would take place at each step in the software development cycle, which contributes to V&V often consuming 50%
or more of the overall budget.

Detailed design of the system and its components revolved around creating diagrams that show the interaction
between system components for each of the functional requirements. These models were created in multiple ways
through sequence, state and data flow models to give the coding team different angles of the same processes to
create a more clear vision of the system they are to develop. A very important portion of software design lies with
giving the coding team enough information from which they can develop a system that not only completes the
intended goal, but also is created in a way that the testing and V&V teams can test and verify the system
requirements in a reasonable manner.

2. Design Models
The models created for the coding teams software development included sequence diagrams for both the
movement and infrared systems. A structural model of all components and their main interactions was created to
show the overall system, and a state transition model included all of these components for their various run case
situations. These systems were also modeled for redundancy in data flow models. The goal of creating many
diagrams for the coding team was to ensure that they were able to fully understand the system they were to create,
while showing the component interactions from different viewpoints. Because of the extensive costs related to
coding, a good design is critical in reducing costs associated with meetings and interactions between design and
coding team members to clarify models, when this time should be spent by the coding team writing code.

3. Design Engineering
A sound architectural and detailed design of a software system is critical in maintaining a schedule and meeting
budget requirements for an entire project. By designing a system that can be readily developed into useful code, the
V-cycle for software development can seamlessly transition from design to coding, testing and verification and
validation with fewer changes to be made. In the case of requirements changing, design models can be updated and
passed on to the coding team to make appropriate changes, while limiting the time required to implement these
modifications. As with other areas of the software lifecycle, the design method became an iterative process between
design, requirements and coding.
B. Requirements Ratings Table
The design team individually rated the requirements numerically on a scale from not well understood- a good
design cannot be developed (5) to the requirement is well understood and a good design can be developed from it
(1). The team then discussed as a group how well they understood the requirements, and comments were relayed to
the requirements team for revisions. This was an iterative process, after which all of the requirements were
understood by team members. The final ratings are shown in Figure 9, with averages taken and no ratings showing
that the individual believes that they could not create an acceptable design from the requirement.


11

Figure 9. Requirements Ratings Table
C. Traceability Matrix
Once the design team had determined that they fully understood these requirements, a traceability matrix was
constructed and is presented as Figure 10. It helps to link dependent and reliable requirements in a way such that it is
easier to see how a requirement can effect or change other requirements. Pertaining to design, this helped construct
the data flow and sequence models to guide the commands throughout the system from start to finish. Understanding
the related and dependent requirements also helped to construct the overall system structure diagram.

Figure 10. Traceability Matrix


12
D. Sequence Diagrams
Sequence diagrams were created for two distinct scenarios. One situation modeled the movement commands
from the user to the robot, while the other showed how the infrared system should interact with the enemy robot.
The following diagrams illustrate a use case for movement and the infrared gun, with other system constraints set in
to show pertinent non-functional requirements.Figure 11 is the sequence diagram the movement control system, and
Figure 12 is the sequence diagram for the IR system.

Figure 11. Sequence Diagram for Movement Control System

Figure 12. Sequence Diagram for IR System


13
E. State Transition Model
A state transition model shows the various states of components onboard the robot at any instant in time during
which the robot is active. This diagram below shows the movement flow for the required forward, backwards and
left / right rotations, as well as the infrared gun trigger and delay mechanism. The infrared sensor is continuously on
and sensing for hits from the enemy IR gun. This model helps the coding team understand the various functions of
the robot and how they are interconnected. This also shows some of the non-functional requirements such as the two
second delay on firing.

Figure 13. State Transition Model
F. Structural Model
A structural model displays all of the system components with arrows directing the ways in which information is
passed between them. This integrates both hardware and software to show the full system. This is useful for the
coding team to check where information is being passed to, and making sure that these are the correct destinations.

Figure 14. Structural Model


14
G. Data Flow Diagrams
A structural model is a model that represents the flow of information through a system, with particular emphasis
on its process aspects. A data flow diagram shows what kind of information will be input to and output from a
system, and its various subcomponents. Figure 15 illustrates the data flow model for the IR system, while Figure 13
illustrates the data flow model for movement.

Figure 15. Data Flow Model for IR System

Figure 16. Data Flow Model for Movement
H. Design Conclusions
To fully implement and confirm that the requirements have been met, a well understood design is necessary.
Using different diagrams is needed to explain and document the different component interactions in the robotic
system so that the coding team can develop a robust code that will execute the mission successfully. This was
accomplished through taking time to understand the functional and non-functional requirements set forth from the
customer needs, after which these requirements were examined for their relations and dependencies. From this,
preliminary structure and sequence diagrams were created, which were then revised after communicating with the
coding team to determine their capabilities of developing code. These final diagrams were then split into component
and system models to show how the movement and infrared systems should interact with the robotic vehicle in the


15
test arena. These detailed sequence diagrams provide the basis for movement and infrared shooting, with listed non-
functional requirements that constrain the overall system. By using both data flow and sequence models, the coding
team is given multiple angles of the final design to aid in their code development. There will be continued
communication between all of the teams included in this project, ultimately using an iterative V-cycle process to
develop a robust design capable of winning the final competition.
V. Coding
Kelvin Nguyen is the lead of the Coding group. Software constructions is related to the creation of working,
useful software. Desirable traits of this software include minimal complexity, anticipation of change, constructs for
testing and verification, and use standards.

Figure 17. Client Code Flow Diagram
A. Client Side Code Summary
A high level flowchart for the client side code is shown in Figure 17. The main function begins by creating an
instance of the Game class, which is where the connection is initialized. Should the initializations fail, the
program closes. Otherwise, the game object begins running and transitions into its main loop.
While the game is running, the code loops through many events. First, the event log and keyboard state are
updated. If the controller is attached, the code will take input from the controller and check for any desired events.
However, if the controller is not attached, the controller pointer is reset and input is taken from the keyboard. Once
the code checks the state of the keyboard or controller, it then fills a 5 element array with the appropriate values to
control the wheels and IR gun of the robot.


16
Finally it sends the array via the established Wi-Fi connection to the robot. If the IR gun has been fired during
the past two seconds, a reload flag will be set in place to prevent subsequent firings too early, and an appropriately
sized rectangle will be rendered on the GUI to act as a reload bar. Should the client code detect a disconnect from
the Arduino server, a Disconnected image will be rendered in place of the Connected image on the GUI.
B. Detailed Source Code Components
Shown in Figure 18 is a detailed UML sequence diagram of the client side code. The major components of the
code are then detailed.

Figure 18. UML Sequence Diagram
1. Key Variables
The UInt8 sendarray[] variable is a five element array that is sent to the Arduino Wi-fi board. The variable tells
the Arduino to do two different things; move and fire. The first and second elements control the left wheel, while
the third and fourth control the right wheel. The first and third elements control the speed of the wheels, with a
higher value corresponding to a faster speed. These values range from 0 to 255. The second and fourth elements
control the direction of the wheel. If the integer is 1 then the wheel will turn forward, if it is 0 it will turn in the
opposite direction. The last element determines if the IR gun fires if the value is 1, voltage is sent through the IR
gun. Each element is only one byte in size which allows for simple transmission from the client to the Arduino.
The integer time_now is updated at the start of each loop iteration, and is used to keep track of clock and ensures
that events do not happen too often. Futher, the integer time_fired receives updates by using function call to
SDL_GetTicks() when command to fire is sent. This variable is used to prevent firing more often than once every 2.0
seconds. Finally, the integer time_hit is updated by using function call to SDL_GetTicks() when robot detects a hit
event. This variable is used to prevent a single hit from being registered more than 1.5 seconds.


17
2. Functions
The first function is OnInit(). This section of the code handles initialization of the SDL and Winsock
components. In this function a connection is made between the users computer and the robot. If the connection
succeeds then it continues on with the program. If a connection cannot be established then it will keep attempting to
establish a connection until the user terminates the program. However before a connection is established the function
will begin initializing SDL and create a window on the upper left corner of the computer screen which the client will
use to visually communicate with the user later in the program.
After passing through the OnInit() function the client runs through one of two functions: GetControllerInput()
and GetKeyboardInput(). In this section of the code the system takes the user inputs through whatever medium the
user is using and turns them into values. During each cycle of the main loop the client checks for a controller input
through either the GetControllerInput() or GetKeyBoardInput() functions. If the client detects a controller the client
uses the GetControllerInput() function where it reads in the state of all the buttons and joysticks and turns them into
usable values which is stored in the UInt8 sendarray[] variable. When filling the first slot of the variable the
function adds a bias value to fix a hardware problem present in the robots left wheel. Should a controller not be
connected, then the GetKeyBoardInput() function will be called to fill up the UInt8 sendarray[] variable. Like the
controller input function, this function also maps the state of the keyboard into usable values and adds an additional
bias to the first value in the array.
After the GetControllerInput() and GetKeyBoardInput() functions are called within the main loop the client goes
through the functions OnLoop() and OnRender().In this section of the client code are the functions that contain the
transmission of data to the robot and the rending of the visual the user will use to determine wether or not they will
be able to fire the IR emitter at the given time. Here the function OnLoop() packages the array generated by the
GetControllerInput() and GetKeyBoardInput() functions as well as determines if the IR gun is allowed to be fired. If
the IR gun is allowed to fire the function sends off the array to the robot as is. At the start of the OnLoop() function,
the time_now variable is set by using the SDL_GetTicks() function, which returns the number of milliseconds since
epoch, or when the program started. When a packet is sent, or the IR gun is fired, more function calls to GetTicks are
used to set the values of time_fired and time_sent. Conditional if statements are then used to allow packets to be
sent to the Arduino every 40 ms, as to not overload the server. Another if statement is used to control firing of the
IR gun. If the gun should not be fired, then it changes the value pertaining to the IR gun in the code so it will not fire
(the fifth element of the sendarray[] variable is set to 0). After this, the loop runs through the OnRender() function
which handles rendering of the reload bar and GUI images to the window. Here the function uses the time_now,
time_fire and time_hit to generate SDL visuals that correspond to the robots IR gun and sensor. OnRender() uses
the time_now and time_fire variables to generate a red box which the user will use to determine wether or not they
are allowed to fire the IR gun.

3. Third Party Libraries
The code utilizes two third party libraries for many of its primary functions. The first, SDL, or Simple
DirectMedia Layer, allows for fluid, low-level input from various devices, as well as low-level graphical output.
SDL is a cross-platform library written in C that is used in video playback software, emulators, and even in popular
games from various developers, including Valve. The library has a lot of capabilities, but is used in this code mostly
for keyboard and controller input, and for creating some simple graphical outputs. Because SDL is designed for use
in video games, it was an attractive choice in terms of the desired capabilities of our software; one of the key goals
was to make the control scheme as simple and sensible as possible, and casting it as a game seemed like the best
way to do that.
SDL's primary capability revolves around the use of events. Any time an event is triggered, it is added to the
event log, and the functions can be used to poll for any desired events, while ignoring any others, and resolve
anything that the code should do upon those specific events. Things like key presses, controller button presses,
mouse clicks, and many others are all distinct events that the library can recognize. Another useful capability of
SDL is its ability to retrieve a keyboard or controller state, as opposed to polling for distinct key press or joystick
motion events. That is, the library has functions that return whether or not a key is pressed, or how far a joystick is
moved on either axis, so that input can be obtained based on the state of the device, to allow for a constant stream of
the desired user command. The last capability of SDL our code utilizes is the graphical output. SDL's simplest
graphical capabilities involve rendering simple shapes and image files to a generated window. The code utilizes
these capabilities to display messages, saved as bitmap files, as well as the reloading bar, a simple animation that is
just a series of rendered rectangles increasing in size.
The second third party library, WinSock, is a Windows platform-dependent networking library. There are two
standards for networking in C/C++: for Windows platforms, it is WinSock, while Unix platforms have their own


18
standard networking libraries. The decision to use WinSock was made for a couple reasons. First, because almost
the entire coding group is running Windows platforms, and getting the UNIX libraries installed and linked properly
on a Windows platform would have been an undesirable amount of trouble. Second, because the tutorials we found
for WinSock were easier to follow, especially considering none of us have experience in networking. The WinSock
library is used for all the networking functionality of the client code. The connect(), send(), and recv() functions
form the basic networking capabilities required for the software. Winsock is used to create and bind a socket,
change the settings so that communication works the way it needs to, and send and receive packets on that socket.
C. Arduino Side Code
It is now possible to review the coding for the Arduino side code.

1. Key Global Variables
The char ssid[] is the Wifi network name. Additionally, the char pass[] contains the Wifi Password. The byte
in[] is a 5 byte array to receive and store incoming packets. The first four bytes control direction and speed of each
motor, while the 5th byte controls the state of the IR gun. Finally, the variables Time_now, time_fired, and time_sent
ar used to keep track of current time and time send and firing occurred; all of these variables were initialized to 0.

2. setup()
During the setup() loop, the interrupts for the IR receiver are declared. This section of code was provided by
Vidullan, our Graduate Teaching Aide (TAide), to ensure fair and symmetric hit detection between both robots. The
middle part of the setup() loop declares the motor pin and IR pin as outputs to control the motor and IR gun. The
remainder of the setup function contains a while statement, which attempts to connect to the declared Wifi network
using the defined password. Once a connection is established, the setup() function is complete.

3. loop()
At the start of each loop, the millis() function is called to set the value of time_now to be the time, in
milliseconds, since epoch. Like on the client code, this allows the Arduino to control when the board checks for
new data, and when to allow the IR gun to fire. Whenever a new packet is received, or the IR gun is fired, calls to
millis() are used to store the time the event occurred. Every 50 milliseconds the Arduino Wifi-shield checks for a
packet from the client code. Once a packet is detected, calls to client.read() are used to read and store control
information into the in[] array. Once the array is filled, the MotorControl() function is called to command the
wheels to move at the specified speed and direction. Each loop iteration, a hit flag is used to determine whether or
not the robot is being hit by the opposing IR gun. The criteria for this hitflag returning true is built into the code
provided by Vidullan. A conditional if statement is used to trigger an event, such as lighting an LED or freezing the
robot, to acknowledge the hit.

Figure 19. Arduino Wiring Diagram


19
D. Wiring Diagram
Figure 19 details the various wiring connections on the robot. The Arduino UNO and Wifi Shield are connected
directly on every pin. A few pins had to be rewired between the Wifi Shield and Motor Shield, via the blue and
green wires, because both shields are designed to use them by default. The Arduino code is written for all these
specific pin connections, so any changes made in the hardware must be mirrored in the software for the system to
work properly.
E. Coding Conclusions
In the end, the client code is shown to be effective at commanding the Arduino robot through a TCP Wi-Fi
connection. At a high level, operation of the robot is very simple, as there are only five degrees of freedom
associated with the robot the direction of each wheel, the speed of each wheel, and the state of the IR gun.
Commands (the 5 valued array) are simply sent to the robot at continuous, set intervals, and based off the values in
the array, the controllable components of the robot the two wheels and IR gun are commanded. The infrared
sensor drives an interrupt, which flips a flag when triggered to perform the penalty action turning on the LED and
freezing the robot momentarily.
VI. Testing
Steve Stanek is the lead of the Testing group. The primary goal of testing should not only be to identify and
correct errors but also to identify the root causes of errors and modify the software development process so that
current error trends do not continue. It should be noted that testing can only show the presence of errors, it cannot
show the absence of errors. It is possible for the developed software to have minimal errors, yet still not fulfill the
users needs. Organizations should also keep in mind that cutting the amount of time allowed for testing not only
increases the number of remaining errors but also eliminates the chance fix those errors.
A. Reflections and Lessons Learned
There are eight distinct sections of testing. These sections include, component, static, dynamic, unit, integration,
system, defect, and release testing. Though testing cannot show the absence of errors, through these different testing
procedures, the end product should perform as best as possible.

1. Component Testing
Component tests are designed to ensure that the individual components of the system are functioning properly in
isolation from the rest of the system. During the process, the system is broken down in to smaller components.
These components should be the smallest testable parts of an application. Components may be individual functions,
object classes or composite components. The individual units are then tested to expose defects. An example of how
component testing was utilized in this project includes the testing of the motor and the unequal spin rates of the two
wheels. To fix this, a gain was added to ensure the wheels spun at equal rates.

2. Static Testing
Static testing is testing the object when it is not in use. Static testing is mainly performed by visually scanning
the code or using software that helps debug the code. During static testing, hardware and integration aspects are
ignored and the code is examined for errors. During the addition of several bits of code, multiple sets were utilized
to ensure the code that was inputting was correct. This could include any time constraint, such as the two second
delay between firing the IR gun.

3. Dynamic Testing
Dynamic testing is a crucially vital process in successfully delivering a product to the consumer. Dynamic
testing is executed while a program is in operation. Typically it will look at system memory, functional behavior,
response time, and overall performance of the system. The main goal of the tests is to execute a program with the
sole intent to find where errors occur. The way in which this is carried out is by running a certain case with a known
outcome. This known outcome then is compared to the outcome from the system. If the two outcomes are different,
then there is an error in the system. When planning out dynamic testing, it is important to design a test in which
errors are systematically discovered.

An example of a dynamic test includes the testing of the IR gun and the reload bar found in the command
window. The requirements states that the IR gun cannot fire more than once every two seconds. Because of this, the


20
IR gun and the reload bar should recharge at the same time. This was tested in two ways. First, each test was tested
individually. They were both looked at visually and the reload time or the flash of the IR gun, seen using a digital
camera, was measured via a stop watch. Once that test was completed, they were tested dynamically, together. To
test this, the flash and recharged reload bar were put side by side and examined. Multiple shots were fired
consecutively and shown that they were indeed both on the same two second recharge.

4. Unit Testing
The purpose of unit testing is to divide the software up into separately testable units and verify their functionality
in isolation from one-another. If possible, unit testing should not be done by the developers. They may be not feel
inclined to honestly identify errors in the software. There are two different types of unit testing known as white-box
testing and black-box testing. During white-box testing, the unit testers have access to the unit's code. This helps the
testers plan their test cases and also allows them to verify that the unit is doing what it was designed to do. Black-
box testing involves testing how the unit works when confronted by typical input. Due to the large number of
possible inputs, complete black-box testing is impossible. It is also important to note that black-box testing also
requires the testing of invalid inputs. In this case, with the program running, multiple key strokes that should have
no binding were utilized to test to see if they affected the system in any way.

5. Integration Testing
The purpose of integration testing is to verify that the individual units of the software are working in
conjunction with each in the way they were designed. Integration testing focuses on the interfaces
between various units of the software since these tend to be a problem area in development. Things such
as parameters and global variables as well as all possible interactions between units must be examined
and tested. When testing large and complex software, it is usually a bad idea to test the system by putting
all the components together at once. In these cases is makes more sense to integrate the components
incrementally. In relation to this project, first the motion was tested, followed by the Wi-Fi camera feed,
incrementally up to the IR gun and sensor.

6. System Testing
The purpose of system testing is to verify that the system is working as a whole. It is also useful for determining
if the system meets its non-functional requirements. At this point in testing, the majority of errors should have
already been identified and dealt with in previous stages. For our case, once assembled and fully integrated, the
robot was tested as a whole to ensure the individual tests held up.

7. Defect Testing
The definition of defect testing inherently means that it is never truly finished. The absence of errors does not
mean that they do not exist, only that they have not yet been discovered. While testing the robot, expected error
messages were displayed on GUI with specified actions, but no unforeseen errors occurred. The testing process for
this class of defects will continue until the product is released, and is the responsibility of all team members to track.
Proper communication between the different groups is vital in order to ensure that proper defect testing is
administered.

8. Release Testing
Before a software product is released for public use, release testing is performed on the software to ensure that it
is error free, safe for use, and has met the customers needs. Before the product is released to the customer, the
robots functionality will be tested and the prior tests evaluated to ensure they have all been completed properly.
B. Testing Highlights
This section highlights each components description, purpose, characteritics, testing procedure and the testing
results.

1. The vehicle must be able to execute all commands given from the controller

Purpose of the Part
- The controller is what the user will use to control the robot and enable proper command input to enable
victory in the final competition.


21
- Single inputs should be able to make the robot rotate left/right, move forward/backward, and fire an IR
gun.

Characteristics of the Part
- Utilizing the keyboard on a laptop there are designated keys for left, right, forward, and backward motion
of the robot. The Xbox 360 controller utilizes the left joystick for forwards and backwards motion with the right
joystick utilized for rotation.
- The spacebar and right trigger are utilized to fire a single IR gun shot.
- The up and down arrow keys, as well as the right and left bumper, are utilized to change the speed of the
robot increasingly or decreasingly, respectively.

Procedure
1. Start up the robot following the normal start up procedures.
2. Run the robot through a series of commands: Left/Right rotations, forward/backward movement, and fire
the IR gun.
3. Make note of any discrepancies or malfunctions between the robots action and the command window.

Results
1. Initially the forward motion of the robot was impeded due to each wheel rotating at different rates.
a. Adjustments were made and the wheels were given different gains and now rotate at the same rate.
i. The robot is now able to move forwards or backward in a straight line.
2. On occasion the robot would become stuck in a rotating state
a. Adjustments were made in the code before secondary testing of the rotation.
i. The robot now only gets stuck in a rotation if it becomes disconnected from the controller.
3. The IR gun fires once for each suppression of the spacebar.

2. Command Window

Purpose of the Part
- The command window will be used by the controller to send signals to the robot that will enable it to
move, fire the IR gun, and transmit video.
- The user command window should utilize single keys for movement and fire commands.
- The command window will output necessary messages.

Characteristics of the part
- The command window should appear in an aesthetically pleasing manner to the user on the operating
laptop.
- The command window should show the timing it takes to fire the IR gun so that the user can see when
they are able to fire.

Procedure
2. Run the robot through a series of commands: Left/Right rotations, forward/backward movement, and
fire the IR gun.

Results
1. There were no discrepancies between the input commands from the window and the robots actions.
2. When the robot is online the window will read connected. If the robot disconnects the connected
message will be replaced by disconnected. Furthermore, the command window displays a hit message
when we are hit.


22
3. Wi-Fi Camera and the video feed that is provided to the user; video speed/lag and a basic level of clarity are the
main focus of the testing

Purpose of the Part
- The primary purpose of the part is to provide a reliable source of visual data to the user so that proper
commands can be given in order to complete a specified mission objective

- The camera provides a basic video feed via the Wi-Fi board to the user oriented computer
- The frame rate and video quality can be varied, and inherently affect the performance of the robot
- Required power vs. video quality is a major focus due to the limit of available amperage and voltage

Procedure
1. The robot will be powered up and set to normal operating parameters to initialize the testing process
2. Video feed will be started with the robot in a stationary form.
3. Physical objects will be introduced into the field of view of the camera and quickly removed. Upon
moving them, time will be kept to determine the lag time of the video feed.
4. In addition to the feed timing, any issues such as black-outs or feed drop will be noted.
5. The entire process will be repeated with the robot in motion to ensure that it can continue proper
functions while in a dynamic state.
6. A frame rate count is determined using the computing functions of the robot, not from a direct test.

Results
1. The camera functioned properly and provided a basic visual feed that the user could use to direct the
robot.
2. One issue that arose was a considerably video lag. An overall lag of 5.2 seconds occurred. It was
determined that this was attributed to the high frame-rate provided to the user. This was corrected by
lowering the frame rate to 10 FPS.
3. Required power for the video unit was not a problem. The battery unit supplied enough power that the
robot could continue dynamic functions and still provide the required video feed.

4. The vehicle should have a manual on/off switch for the batteries and the camera

Purpose of the Part
- The manual on/off switch will enable the robot to be disconnected and powered down separately from
the controller.
- Having a backup option to power down the camera and robot will allow for a failsafe in case there are
any issues with the controller during runtime.

- There is a manual toggle switch located on the robot that allows for power to be turned on and off.

Procedure
2. Test the on/off switch by changing from the on position to the off position.
3. Make note of any discrepancies or malfunctions between the robot and the command window.

Results
1. The on/off switch properly controls the robots power as well as the cameras power.

5. The vehicle must be able to operate on linoleum floors

Purpose of the Part
- The tires and power supplied to them must be enough so that the vehicle can navigate in a controlled
and efficient manner on a linoleum floor.


23
- The tires are made up of a standard rubber material with standard all-purpose treading.

Procedure
2. Run the robot through a series of commands: Left/Right rotations, forward/backward movement all on a
linoleum floor.

Results
1. The robot was able to execute all commands efficiently and in a controlled manner on the linoleum
floor.

6. IR gun

Purpose of the Part
- The Infrared gun will be utilized to hit the opposing target that is equipped with IR sensors. The IR gun
is not allowed to fire more than once every 2 seconds.

- An IR beam cannot be focused to pinpoint accuracy. Due to this, the part will be tested to show the
range and cone of the IR shot. By measuring this, the user will be given proper knowledge to
successfully hit their target.
- The beams often can often become unaligned. Due to this, the IR beam will be continually tested in
regular intervals to monitor this.
- Like hockey, the wall has potential to be your friend. In hockey, players use the wall as a way to deflect
pucks around other players or to create a passing lane. An IR beam can act the same way. It will be
tested to see the reliability of bouncing the IR beam off a wall to the opponent.

Procedure
1. To ensure the functionality of the IR gun, our own receiver will be used to detect hits or not.
2. To give us the upper hand, the characteristics of the part will be tested and monitored without utilizing
the other team. In the room that will host the competition, the IR gun will be used as various location to
bounce off the walls. This test will either confirm or debunk the utilization of walls.
3. Twice per week the IR gun will be tested to ensure the alignment is correct. A more in depth description
of the procedure to this will become available at a later date.

Results
1. Prior to the update of the firmware, it was determined that the IR gun is functional.
a. After the firmware update, the IR gun remains functional.
2. It was determined that the utilization of walls is not favorable.

7. IR receiver; the IR receiver is composed of three sensors, located at the front, left, and right side of the robot
Purpose of the Part

- The IR receiver will be utilized to register hits from the opposing teams robot. Furthermore, each hit
that is registered should display in the command window with a tally.

- IR sensors are very common and most notably, found on your television. The IR sensors can detect
invisible light but not visible light.
- IR sensors have a demodulator inside them. Because the demodulator will only register specific
frequencies, the IR gun and sensor must be tested in unison.


24

Procedure
1. To ensure the functionality of the IR receiver, our own IR gun will be used to confirm whether or not
hits can be registered on each of the three sensors.
2. The command window will be used to determine if there was a hit by displaying a message

Results
1. Prior to the update of the firmware, it was determined that the IR gun is functional.
a. After the firmware update, the IR gun remains functional.
2. The command window outputs a hit message. It does not however keep a running tally

8. The vehicles battery should power the motor, camera, and all other electronics for at least 45 minutes

Purpose of the Part
- The battery will provide the power to the robot

- The battery pack is connected to the circuit boards via a connection link that is easily accessible. This
makes swapping the battery pack out a simple task.

Procedure
2. When the robot is moving a full speed, the robot will be disconnected. By disconnecting the robot, the
robots last received command runs on an infinite loop. This means the robot will have the motors
running at full speed and the camera feed will also be available.
3. The robots battery life will be measured via a stop watch and recorded

Results
1. The robots battery life is well over 1.25 hours.

9. Structural Integrity at High Speeds
The part being tested is the structural integrity (main supporting component) of the robot. The main analysis is of
any cracking, distortion, or stress fractures of the main structural unit when impact an object at full speed.

Purpose of the Part
- The main purpose of this part is providing a base structure for the required components of the robot.
- It must be able to properly contain and protect the secondary components of the robot so that they may
fulfill their intended purpose.

- The main structural body is a very straightforward and simplistic setup consisting of screws, a main
board, and connecting components.
- All secondary components are properly attached to the main body.

Procedure
1. The robot will be powered up and set to normal operating parameters to initialize the testing process.
2. Three obstacles will be used to determine if the robot can withstand harsh physical impact. One that fits
below the main board and impact the wheel base, one that is the same height as the main board, and one
that is taller than the entire unit.
3. With the robot engaged at full speed, direct impact is observed with each of the obstacles.
4. After each impact, the robot is visually inspected for any of the aforementioned flaws.
5. The robot is tested at full speed impact for both the front and rear portions of the system.

Results
1. The unit was able to withstand all forms of impact against a solid obstacle at maximum speed from both
a front and rear approach.


25
2. No structural flaws were found via the testing procedure.
VII. Verification and Validation (V&V)
Mike Matas is the lead of the Verification and Validation group. The V&V group operated based on the
information and findings from both the Requirements and Testing Teams, with a majority of the effort examining
and verifying the requirements documents. Tests were designed and performed in order to verify if each
requirement had been met. The project website was also examined and an internal verification process took place to
make sure each team knew of and completed the deliverables they were responsible for. The Validation process
involved taking our findings and current status of the robot software (and hardware in some cases) and making sure
it was suitable for the customer.
This passage reviews and reflects on the verification and validation portion of the software engineering project.
It focuses on the lessons learned during this process.

1. V&V Process
To prepare for the V&V process, the team read through the material in Software Engineering Book of
Knowledge (SWEBOK) and Gentle Introduction to Software Engineering (GISE) related to requirements
engineering and testing so that we could be prepared for interactions with those groups. We then familiarized
ourselved with the V&V process and the steps we would need to take to complete it for this project. For this project,
we divided into subgroups to distribute the work load. These groups included Wedsite Verification (1 member),
Requirements Verification (4 members), and Validation (2 members).

2. Website Verification
One member of the V&V team needed to be tasked with going through the website and making sure that every
group (Requirements, Design, Testing, Coding, and V&V) and the Chiefs (CEO, CFO, CIO) had all completed what
was asked of them. This process involved breaking the website into necessary deliverables, communicating with the
other groups, and keeping a checklist of what was actually being delivered via the final reports.

3. Requirements Verification
Requirements verification ensures that the product is built right. For each requirement, a test procedure is defined
and the necessary resources are identified. These procedures are followed, and the results are recorded in order to
determine whether or not each requirement has been met. In the Requirements Verification section of this report, the
results of the verification of functional and nonfunctional requirements are discussed with the format [requirement
number]: requirement description followed by the tests conducted and results.

4. Validation
Requirements validation ensures that the right product is built, i.e. the system functions to meet the needs of the
customer. The validation team was responsible for first meeting with the customer to acquire an overview of how
the system will be used and how it should function. The team then observed the verification process to make sure the
product will operate the way the customer intends it to.
B. Website Verification
This is a listing of the website verification conducted by the V&V group.

1. Requirements Deliverables
a. All members read chapter 2 of SWEBOK and Section 2.1 of GISE confirmed by team lead on 4/8
b. CONOPS attached as separated document.
c. Use cases page 6 of Requirements report.
d. Viewpoint charts page 4 of Requirements report.
e. Scenarios page 5 of Requirements report.
f. Sequence diagrams page 7 of Requirements report.
g. Use the provided template for the Requirements Document completed.
h. Final report uploaded in AIAA Format completed.


26
2. Design Deliverables
b. Requirements rating table page 3 of Design report.
c. Traceability Matrix page 4 of Design report.
d. Sequence model page 5 of Design report.
e. State transition model page 6 of Design report.
f. Structural model page 7 of Design report.
g. Data flow models page 8 of Design report.

3. Coding Deliverables
b. Flowcharts page 2 of Coding report.
c. User manual attached as separated document.
d. Documentation of each unit or component of code page 3-6 of Coding report.
e. Source code attached as separated document.
f. Guidance to testing group confirmed by both team leads on 11/11
g. UML diagrams page 3 of Coding report.

4. Testing Deliverables
b. Description of all tests done pages 5-13 of Testing report.
c. Results of all tests pages 5-13 of Testing report.
d. List of errors found and corrections pages 5-13 of Testing report.
e. Result of static testing page 3 of Testing report.
f. Show how you did a dynamic analysis page 3 of Testing report.
g. Unit testing results page 3 of Testing report.
h. Integration test results page 3 of Testing report.
i. Final report uploaded in AIAA Format completed.

5. V&V Deliverables
a. All members read chapters in SWEBOK and GISE related to V&V confirmed by team lead on 4/2
b. Designate one person to be responsible for reading the website and make sure the team addresses
every done.
c. Show (prove) which requirements have been met pages 6-10 of V&V report.
d. Show which requirements have NOT been met page 10-11 of V&V report.
e. Keep a record of all tests page 6-10 of V&V report.
f. Are all functional and non-functional requirements met page 6-10 of V&V report.
g. Suggest fixes required to requirements, coding, and testing groups confirmed by team leads on 4/11

6. CEO Deliverables
a. Final Gantt chart completed
b. Integration of final reports completed

7. CFO Deliverables
a. COCOMO model completed
b. Teams financial projections versus current financial status completed

8. CIO Deliverables
a. Working website that is secure to the Blue Team confirmed by CIO on 4/11


27
C. Requirements Verification
1. Functional Requirements
The functional requirements, or capabilities, provide an outline for the functions that the software must be able to
execute and how the system should react to different inputs. Upon verification of all functional requirements, it
shall be confirmed that the product is capable of performing all basic operations.

a. [2.1.1]: The vehicle must be entirely remote controlled.
Once turned on, verify that no direct user interaction is necessary to operate all vehicle functions. After the
power was switched on, the user was able to move the robot forward, backward, left, and right, fire the IR gun,
view the camera feed through the GUI, and detect hits without any direct interaction of a team member with the
robot.
b. [2.1.1.1]: The vehicle controller system must consist of only a laptop, wi-fi receiver, controller devices, and a
single user.
Examine the system hardware during operation to verify the vehicle is controlled by using only a
laptop, wi-fi receiver, any controller device and one user. Full control of the vehicle was achieved using only
these materials and no external assistance.
c. [2.1.]2: The vehicle must transmit as close to real time video feed as possible via a wi-fi camera to the
controller.
Determine if the video feed viewed by the user has a small enough delay such that it does not interfere with
effective operation of the vehicle. The server push mode was able to be used, and the video feed was very close
to real time (delay was on the order of milliseconds), which provides acceptable competition performance.
d. [2.1.3]: The vehicle must be able to execute all commands given from the controller.
Test that all commands can be transmitted from controller to vehicle and verify that they are performed.
Forward, backward, left, and right movement, all combinations of directional motion, and shooting were all
executed when commanded by the user.

e. [2.1.3.1]: Vehicle must be able to move forwards, backwards, rotate right, and rotate left.
Input each command or series of commands to confirm that each maneuver can be executed. While the Xbox
controller is being used, the left joystick commands forward and backward motion and the right joystick
commands left and right motion. When the keyboard is connected, the W, A, S, and D keys command forward,
left, backward, and right motion respectively.
f. [2.1.3.2]: Vehicle must have a designated button to fire the IR gun
Verify that there is a designated command on the controller that fires the IR gun. For the Xbox controller, the
right trigger fires the IR gun, and the space bar will fire the IR gun for the keyboard controller.
g. [2.1.3.3]: Vehicle must execute commands given wirelessly from the controller utilizing an Arduino wi-fi
board and Arduino processor
The Arduino processor and wi-fi board allow the controller to wirelessly send commands that are executed
by the robot.
h. [2.1.4]: Vehicle must have an IR gun and sensor
Examine the fully equipped vehicle and verify the presence of an IR gun and sensor. Visual inspection
showed that there are both an IR gun and sensor on the vehicle.


28
i. [2.1.4.1]: The IR gun must be able to fire every 2 seconds, as specified by the customer as the minimum
interval
Fire the IR gun multiple times within two seconds to verify that the shots only register at the two second
intervals. The IR gun was viewed through the camera while it was rapidly fired, which allowed the shot to be
seen, and it was confirmed that shots fired in succession after the initial fire did not register until two seconds
passed.
j. [2.1.4.2]: The IR sensor must be continuously on
The IR gun was fired continuously at each of the sensors located on the vehicle. All hits were registered
appropriately.
k. [2.1.5]: The vehicle must withstand ramming full speed into a rigid object with no critical structural damage
Drive the vehicle into rigid objects while at full speed and then examine the vehicle to determine the absence
or existence of structural damage. The vehicle was driven into a wooden table leg and a classroom wall at full
speed with no structural damage. The front metal bumper protected the vehicle and all accessories from
impairment.
2. Nonfunctional Requirements
The nonfunctional requirements, or constraints, are used to determine the quality and level of performance
desired by the user. Many of these are necessary to allow for a fair competition, but others are simply specifications
preferred by the customer. Although they may not be essential to the overall functionality of the system, it is
imperative that the nonfunctional requirements are met to ensure the best chance of success and eliminate the
possibility of disqualification.

a. [2.2.1]: Software must be written using C or C++
The files were examined to determine what language was used to develop the code. There are 16 .cpp files, 3
header files, and 1 Arduino sketch.
b. [2.2.2]: Data link between the controller and vehicle must be wireless
Verify that data is transferred between the vehicle and controller wirelessly. All data was transferred without
any hardware connecting the vehicle and controller.
c. [2.2.2.1]: Software must utilize and integrate an Arduino processor, Arduino wi-fi board, Arduino motor
control board, a laptop, IR gun, and IR sensor
System components were analyzed to ensure that they carry out their functions once integrated together. The
Arduino processor, Arduino wi-fi board, Arduino motor control board, laptop, IR gun, and IR sensor all
performed appropriately.
d. [3.1.1]: All control commands should be executed using an Xbox controller (primary) or using the ASDW keys
on the keyboard (secondary).
The vehicle was operated under two separate tests in which the robot was controlled using either the Xbox
controller or keyboard individually.
e. [3.1.1.1]: The control commands should be mapped to the Xbox controller as follows: left joystick for
forward/backwards, right joystick for left/right, right trigger to shoot
While using the Xbox controller to operate the vehicle, all joysticks and triggers were used to determine their
functionality. Moving the left joystick up and down resulted in forward and backward motion, moving the right
joystick left and right resulted in the respective rotation or turning, and the right trigger resulted in the firing of
the IR gun.


29
f. [3.1.1.2]: The control commands should be mapped to the keyboard as follows: W-key for forward, S-key for
backwards, A-key for left, D-key for right, space bar to shoot
While using the keyboard to operate the vehicle, the relevant keys were used to determine their functionality.
The W-key resulted in forward motion, the S-key resulted in backward motion, the A-key resulted in
counterclockwise rotation or left turning, the D-key resulted in clockwise rotation or right turning, and the space
bar resulted in the firing of the IR gun.
g. [3.1.2]: The system should utilize a separate window for video feed
Verify that the video feed is displayed in its own window. A separate internet explorer window is used to
view the video feed.
h. [3.1.3]: Software should communicate applicable system errors to user
Verify that relevant errors are displayed to the user via the interface. There was one error found, and this was
a wi-fi disconnection. When the system is disconnected, the system alerts the user via the GUI.
i. [3.1.4]: A reload bar should notify the user when reload time is done
The IR gun was fired to verify that there is a reload bar on the command window that displays when the IR
laser is able to fire. Reload bar starts full, and when the gun is fired is goes to zero and then grows back over a
time period of 2 seconds.
j. [3.1.5]: User should be notified when vehicle is tagged
The IR gun was fired at the sensor, and the GUI was observed to determine if the user will be notified when
the vehicle is hit. A message is displayed and an alert noise sounds when the vehicle is tagged to visually and
audibly notify the user.
k. [3.2.1]: The robotic system should be placed on a small, two-wheeled chassis
Upon observation of the vehicle, the robotic system was confirmed to be controlled via a two-wheeled
chassis and an omnidirectional roller support.
l. [3.4.1]: The system should be user friendly to the point where a non-team member could be taught all aspects
of how to operate the vehicle in 15 minutes or less with less than 5 operational errors
Introduce a non-team member to the system and show them how to fully operate the vehicle. The teaching
session should be timed and stopped at 15 minutes, when the user will be asked to operate the vehicle and carry
out all functions with less than 5 operational errors. This 15 minute teaching session was carried out and the user
successfully operated all tasks without exceeding 5 errors.
m. [4.1.1]: System should process as fast as hardware allows with no unnecessary time delays
Verify that there is no significant time delay in overall functioning of the system. The system operates close
to real time, and the code was examined to make sure there was no unnecessary interrupts or delays.
n. [4.2.1]: The system should have a manual on/off for the batteries and camera
Verify that there are manual power switches for the batteries and camera. There is a single main power
switch on the robot chassis that controls the power to the batteries, boards, and camera


30
o. [4.3.1]: Operator should be able to visually detect an obstacle 3 feet in front of the vehicle through the wi-fi
camera
Place an object unknown to a team member in the view of the wi-fi camera and have the member detect the
object through the video feed. A monster energy drink was placed 3 ft in front of the vehicle. A user with no
knowledge of the item was able to identify the object and determine the approximate size.
p. [4.4.1]: System must be able to operate on a linoleum floor
Operate the vehicle on a linoleum floor and verify full functionality. The vehicle was operated on a linoleum
floor and the system operated appropriately and consistently.
q. [4.4.2]: Battery life should exceed 50 minutes at full performance
Power on the vehicle and operate at full speed to determine the battery life. The robot was fully functional for
more than 60 minutes without losing power.
r. [4.4.3]: Controller and camera range should be more than 50 feet
Test that the vehicle can operate remotely when placed 50 ft from the controller. The vehicle was driven
across the length of the room (past 50 ft from the controller) and remained fully operational with slight video lag
as the distance increased.
s. [5.2.2]: Command software should interface with the Arduino processor and board
The command software interfaces the user input with the Arduino hardware wirelessly, allowing the
robot to operate.
t. [5.2.3]: Arduino processor and board should interface with wheel motors
After the user commands are sent to the Arduino processor, the board interfaces with the wheel motors
and allows for movement.
u. [5.2.4]: Arduino processor and board should interface with IR gun and sensor
The user commands are sent to the Arduino processor, the board interfaces with the IR gun and allows
for firing. The processor also interfaces with the IR sensor and keeps track of any tags.
v. [5.2.5]: Battery will interface with motors and hardware
The hardware was examined, and the batteries are directly connected. Upon activating the switch, the
batteries power the motor and the Arduino boards used for operation.
w. [5.3.1]: System should be able to execute multiple commands at once
While operating the vehicle, various combinations of multiple, simultaneous inputs were tested. The user was
able to move forward or backward while also turning left or right, and the IR gun was fully functional while the
vehicle was in motion.
x. [5.4.1]: The vehicle should weigh less than 15 pounds
Verify that the vehicle weighs less than 15 lbs on a scale or other measuring device. The vehicle with all
accessories attached was weighed and are a combined 2.3 lbs.
y. [5.4.2]: The vehicle dimensions should be less than 2 ft x 2 ft x 2 ft
A tape measure was used to determine the length, width, and height of the vehicle to ensure it does not
exceed the required dimensions.


31
z. [6.1.1]: All information must be proprietary to team
All locations that host information regarding the project will be checked to ensure proper steps are taken to
prevent access of anyone non-team member. It was confirmed that the CIO is the only person who has access to
who can view all official documents uploaded to the team website.
aa. [7.1.1]: All instruments must be returned to the customer at the end of the semester
The customer will be contacted upon completion of the semester and asked if all the instruments have been
returned to them.
bb. [7.1.2]: Customer must be reimbursed for any broken instruments
The customer will be contacted upon completion of the project and asked if any instruments have been
broken. In the event that there are any broken instruments, the customer will be asked if they have been
reimbursed.
cc. [9.1.1]: All electronic devices and structural components should be off the shelf products
All of the electronic devices and structural components were recorded and research was conducted to
determine that all items were able to be purchased off the shelf. However, this requirement was not fully met
since the IR gun contains custom circuitry.
dd. [10.1.1]: Vehicle performance is limited by the specific instrumentation given by the customer
All of the instruments used on the vehicle was compiled and then compared to the list of all the
instrumentation given by the customer to confirm the vehicle performance does not depend devices not approved
by the customer.
ee. [10.3.1]: No outside equipment or instrumentation may be used
A list of all the instrumentation used in the vehicle was compiled and then compared to the list of all the
instruments given by the customer to confirm the vehicle performance does not depend on devices that were not
approved by the customer.
ff. [11.1]: Customer reserves the rights to reasonably change requirements based on evolving needs
3. Verification Failures
Throughout the process of requirements verification, many problems occurred which caused some setbacks. The
inability to verify certain requirements is a major issue, but it is a problem that must be solved. In some cases it is
best to either alter the requirement to make it more achievable or even remove it entirely due to the level of
reasonability or difficulty required. When neither of these options are available, an alternate solution must be found.

a. [3.1.6]: Controller software should keep count of opposing tags
Unfortunately this requirement was not able to be met. The software is capable of alerting the user that their
vehicle has been tagged, but it cannot keep count of how many hits have occurred over a given period of time.
However, the tags will be able to be counted manually by observing the visual and audible signals produced
while being hit.
b. [3.2.2]: Vehicle should not contain any other instrumentation that the given processor, wi-fi board, wi-fi
camera, IR sensor/receiver, and battery
The vehicle and all accessories were examined to verify the possession of necessary instrumentation. It was
confirmed that the vehicle contained the given Arduino processor, wi-fi board, wi-fi camera, IR sensor, and
battery. Also, an LED light was used in addition to this given instrumentation. The LED light will light up when
the IR sensor has been hit to serve as supplemental notification that the vehicle has been tagged. Although excess


32
materials were used and the requirement was not fully verified, the LED light does not alter the functionality of
the vehicle or allow for any advantage in the competition
D. Requirements Validation
1. Preliminary Customer Validation
This preliminary list was compiled after meeting with the customer to see what the ultimate goals were for the
project. These are the guidelines that were used for the validation process while testing the robot as well as for the
final customer validation. Any subsequent specification changes were accounted for appropriately.

a. The system should consist of a small three-wheeled robot chassis and an onboard Arduino processor, IR
gun and sensors, and wi-fi camera.
b. The robot should be controlled though a user interface on a laptop
c. The person controlling the robot will not be in the same room as the competition, and should be a trained
team member from a subgroup other than coding
d. The system should also be reliable especially the day of the competition, i.e. no IP address issues or
Wi-Fi connection errors.
e. The vehicle will have a wi-fi camera attached to it, and the user will see the video feed on the GUI
f. The vehicle should be able to shoot the other robot using infrared gun
g. The vehicle should be able to evade the other robot
h. There must be a two second reload time between shots
i. The vehicle should be able to move through a series of obstacles to get to the other robot and shoot it
j. Victory is achieved by tagging the opponents vehicle more times than they tag you
k. Above all, the ultimate goal is to win the competition

2. Internal Validation of Project Documentation
During the verification phase of the project, the above specifications were checked to see if they would
meet the customers satisfaction. Along with the tests conducted by the verification team, the validation team used
the same tests to see if the requirements were validated for the customer.

a. The robot chassis consisted of two rubber wheels with one roller ball as the third wheel support. This
chassis also held the Arduino processor, IR gun and sensors, and the Wi-Fi camera.
b. The robot can be controlled through the keyboard or an Xbox controller. It is important to note that the
controller takes higher priority than the keyboard option. But in the event that the controller is not able to
be used, the keyboard will suffice. The user interface properly displays the camera feed and the two
second reload bar.
c. The person controlling the robot is able to be within 50 ft of the robot with minimal lag. This was tested
by placing the user and the laptop outside of the classroom where the competition will be held. This
system works only when the router is in the same room as the robot.
d. Throughout the initial testing, the robot experienced random brownout errors but it would be able to
display to the user that it had disconnected from the system. In these cases, the robot would have to be
rebooted or reconnected. After a few fixes, this type of issue only happened while the robot was used at
maximum speed which would generate noise from the wheels that would interfere with the signal. The
brownout issue is the only aspect raising concern in the reliability aspect of the robot.
e. The Wi-Fi camera is able to display its image on the webpage that is accessed through the cameras IP
address. This showed no errors unless there is a brownout issue which freezes the image display.
f. In the display that is shown to the user, there is a reload bar that will refill for two seconds therefore not
allowing the user to fire while loading.
g. The usability of the IR gun has been confirmed as well as the detection of being hit by the IR sensors. At
this moment, the sensors are not working but will be fixed come the day of the competition.
h. The feedback from the camera is close to real time and is therefore a good source for navigation of the
robot to evade the enemy.
i. The robot is able to maneuver through obstacles rapidly and is therefore able to evade the robot.
j. The way the system is programmed right now, it is not able to count the number of hits. But with the
LEDs, that were provided by the customer, which will light up when hit, a reliable team member is able
to count the number of hits. With the proper functioning of the IR gun and sensors, LEDs and the proper
counting, it will be possible to detect which robot had the most hits.


33
k. The ultimate validation will come at the day of the competition, but if all components of the system
work together with no brownout errors, the robot should be able to win the competition.
VIII. Conclusion
In summary, this team has undertaken traditional course activities this semester as well as participated in this
software design process. Through the course of this project, many of the team members have remarked how
benefitial it was to truly experience the software engineering process. The process was, at times, messy, however
this is the kind of real-world experience many members of the team believe that we as students need to be
successful.
Appendix
A few images from the day of the competition are provided below in Figure 20 and Figure 21

Figure 20. Close-up of the Blue Team's Robot

Figure 21. The Robots Compete in the Competition
Acknowledgments
The Blue Team would like to thank Dr. Lyle N. Long, Distinguished Professor of Aerospace Engineering and
Mathematics, for his mentorship through this undertaking. The Blue Team would like to recognize the technical
support efforts of Vidullan Surendran as we undertook this project. Finally, the Blue Team would like to recognize
the White Team for being a cooperative partner in mutual testing endeavors, particularly as it related to sensor and
receiver testing; they have been a very worthy adversary.

ID Task
Mode
TaskName Deadline Duration Start Finish
1 Teamandgroupchoices Wed1/15/14 3days Fri 1/17/14 Tue1/21/14
2 Teamformationsannounced Wed1/22/14 1day Fri 1/17/14 Fri 1/17/14
3 CEO, CIOand CFOof eachteam
selected byteams
Wed1/22/14 1day Fri 1/17/14 Fri 1/17/14
4 Teamdocumentation websitein
place
Mon1/27/14 4days Mon1/20/14 Thu1/23/14
5 CEOEstablishGanntChart Fri 1/31/14 5days Mon1/27/14 Fri 1/31/14
6 Cost Estimate Mon1/27/14 10days Mon1/20/14 Fri 1/31/14
7 Receive estimates fromgroup
leads
Mon1/27/14 7days Wed 1/22/14 Thu1/30/14
8 Completedcost estimate Fri1/31/14 8days Wed 1/22/14 Fri1/31/14
9 Establishandmaintainhours
records
Thu1/23/14 3days Mon1/20/14 Wed 1/22/14
10 RequirementsPresentation Mon2/3/14 1day Wed1/15/14 Wed 1/15/14
11 CONOPS NA 14days Mon1/20/14 Thu2/6/14
12 ContactDr.Longfor any
additionalrequirements
NA 14days Mon1/20/14 Thu2/6/14
13 Tracability Matrix, relevance &
dependancyto eachother
14 Finalize requirements
documentation
15 Create req.presentation Sun2/2/14 14days Mon1/20/14 Thu2/6/14
16 DesignPresentation Mon2/17/14 1day Wed1/15/14 Wed 1/15/14
17 Requirementsratings and
traceabilitymatrixbreakdown
Mon2/17/14 1day Mon2/3/14 Mon2/3/14
18 Preliminary highlevelsequence,
structuralanddata flow
diagrams
Mon2/17/14 1day Mon2/3/14 Mon2/3/14
19 Detailedhighlevelsequence,
statetransitionanddata flow
diagrams
Mon2/17/14 1day Mon2/3/14 Mon2/3/14
20 Finaldetailedlow level
sequence,structural,state
transitionanddata flow
diagrams
Mon2/17/14 1day Wed 2/12/14 Wed 2/12/14
21 Coding Demonstration Mon2/24/14 1day Wed1/15/14 Wed 1/15/14
22 Get WiFi toArduino
communicationoperational
Mon2/24/14 11days Fri 1/24/14 Fri2/7/14
23 Commandrobotwirelesslyby
sendingsimple commandline
inputs
Mon2/24/14 6days Fri 1/24/14 Fri1/31/14
24 Coding Presentation Wed3/19/14 46days Wed1/15/14 Wed 3/19/14
25 Interfacing gamepadcontroller
inputs
Wed 3/19/14 17days Sat2/15/14 Sat3/8/14
26 Integration ofWiFiandRobot
wheels/motors
Wed 3/19/14 21days Sat2/8/14 Fri3/7/14
27 Functioning Camera Mon3/31/14 6days Fri 1/24/14 Fri 1/31/14
28 Power tocamera Fri3/28/14 22days Sat2/15/14 Sat3/15/14
29 IRGunfiring Mon3/31/14 8days Fri 3/7/14 Tue3/18/14
30 IRReceiverfunctioning Mon3/31/14 Fri 3/7/14
31 TestingPresentation Mon4/7/14 1day Mon4/7/14 Mon 4/7/14
32 Assemble Hardware Mon2/10/14 7days Sat1/25/14 Sat2/1/14
33 Create testingoutline Fri2/14/14 11days Mon1/27/14 Mon2/10/14
34 Assigntestingsubgroups Wed 2/19/14 6days Mon2/10/14 Mon2/17/14
35 Developsubgrouptesting plans Mon3/3/14 8days Wed 2/19/14 Fri2/28/14
36 ComponentTesting Mon3/31/14 22days Fri 2/28/14 Mon 3/31/14
37 MovingCapability Mon3/31/14 22days Fri 2/28/14 Mon3/31/14
38 CameraFeed Mon3/31/14 22days Fri 2/28/14 Mon3/31/14
39 Miscellaneous,includingIR
gunand collisiontesting
Mon3/31/14 22days Fri 2/28/14 Mon3/31/14
40 IntegrationTesting Mon3/31/14 22days Fri 2/28/14 Mon 3/31/14
41 MovementControl Mon3/31/14 22days Fri 2/28/14 Mon3/31/14
42 IRGunFunctionality Mon3/31/14 22days Fri 2/28/14 Mon3/31/14
43 Miscellaneous,including
speedvariability
Mon3/31/14 22days Fri 2/28/14 Mon3/31/14
44 DefectTesting Mon4/7/14 26days Fri 2/28/14 Fri 4/4/14
45 Useall features together
simultaneously
Mon4/7/14 26days Fri 2/28/14 Fri4/4/14
46 Checkingthat"errors"
properly occur
Mon4/7/14 26days Fri 2/28/14 Fri4/4/14
47 Stress andRelease Testing Mon4/7/14 37days Fri 2/28/14 Mon 4/21/14
48 WiFirange andcontrols Mon4/7/14 37days Fri 2/28/14 Mon4/21/14
49 Buttonmashing Mon4/7/14 37days Fri 2/28/14 Mon4/21/14
50 Verifying testresults Mon4/7/14 37days Fri 2/28/14 Mon4/21/14
51 Testing DryRun Wed 4/23/14 1day Wed 4/23/14 Wed 4/23/14
52 V&VPresentation Mon4/14/14 56days Mon1/27/14 Mon 4/14/14
53 Create V&VProjectOutline Mon2/3/14 6days Mon1/27/14 Mon2/3/14
54 DevelopsubgroupV&Vplans Mon2/10/14 6days Mon2/3/14 Mon2/10/14
55 WebsiteVerification Mon4/14/14 21days Mon3/17/14 Mon 4/14/14
56 Breakwebsite into
deliverables bysubgroup
Mon3/24/14 6days Mon3/17/14 Mon3/24/14
57 Contactsubgroupsw/their
requireddeliverablesand
deadlines
Mon3/31/14 6days Mon3/24/14 Mon3/31/14
58 Assemble list ofcompleted
deliverables
Mon4/7/14 6days Mon3/31/14 Mon4/7/14
59 RequirementsVerification Mon4/14/14 21days Mon3/17/14 Mon 4/14/14
60 Assemblytasklist (formal
wording)
Mon4/7/14 16days Mon3/17/14 Mon4/7/14
61 Performed tests Mon4/14/14 6days Mon4/7/14 Mon4/14/14
62 Validation Mon4/28/14 0days Tue3/11/14 Tue3/11/14
63 MeetwithCustomer Mon3/17/14 1day Mon3/17/14 Mon3/17/14
64 Compilechecklistof
validations
Mon3/24/14 5days Tue 3/18/14 Mon3/24/14
65 Finalproduct validation Mon4/28/14 18days Mon4/7/14 Wed 4/30/14
66 FinalDemonstration Wed 4/30/14 1day Wed 4/30/14 Wed 4/30/14
67 Finalized Final Report Fri 5/2/14 0days Mon4/21/14 Mon 4/21/14
68 Executive Summary Thu5/1/14 2days Mon4/21/14 Tue4/22/14
69 FinancialReport Mon4/28/14 2days Mon4/21/14 Tue4/22/14
70 InformationSection Mon4/28/14 2days Mon4/21/14 Tue4/22/14
71 RequirementsReport Mon4/28/14 6days Mon4/21/14 Mon4/28/14
72 DesignReport Mon4/28/14 6days Mon4/21/14 Mon4/28/14
73 Coding Report Wed 4/30/14 7days Mon4/21/14 Tue4/29/14
74 Testing Report Wed 4/30/14 8days Mon4/21/14 Wed 4/30/14
75 V&VReport Wed 4/30/14 8days Mon4/21/14 Wed 4/30/14
76 Editing/Review Fri5/2/14 2days Thu5/1/14 Fri5/2/14
77 Printing Fri5/2/14 1day Fri 5/2/14 Fri5/2/14
78 Binding Fri5/2/14 1day Fri 5/2/14 Fri5/2/14
AERSP 440
Dr.Long
Blue Team
CIO
CEO
CFO
CFO
CFO
Requirements
Ty Druce
Requirements
Requirements
Requirements
Design
Design
Design
Design
Coding
Coding
Coding
Coding
Coding
Coding
Coding
Testing
Testing
Testing
Testing
Testing
Testing
Testing
Testing
Testing
Testing
Testing
Testing
Testing
Testing
Testing
Testing
V&V
V&V
V&V
V&V
V&V
V&V
V&V
3/11
V&V
V&V
Blue Team
Blue Team
4/21
CEO
CFO
CIO
Requirements
Design
Coding
Testing
V&V
CEO andV&VLead
CEO
CEO
S W S T M F T S W S T M F T S W S T M F T S W S T M F T S W S T M F T
Jan19, '14 Feb2,'14 Feb 16,'14 Mar2, '14 Mar 16,'14 Mar 30,'14 Apr 13,'14 Apr27, '14 May 11,'14 May 25, '14
Task
Split
Milestone
Summary
Project Summary
ExternalTasks
External Milestone
Inactive Task
Inactive Milestone
InactiveSummary
Manual Task
Durationonly
Manual SummaryRollup
Manual Summary
Startonly
Finishonly
Deadline
Progress
Page 1
Project:BlueTeamGanntChart w
Date: Fri 5/2/14
Blue Team Concept of Operations & Requirements
Rev. G Page 1 of 8

Penn State Department of Aerospace Engineering

Aerospace 440 Spring 2014

Blue Team

Concept of Operations & Requirements

for

Controlled Robotic Vehicle

Revision G

Submitted:
05/02/2014

Rev. G Page 2 of 8

Signatures

Submitted by:
Tyler Druce, Requirements Manager
Date: xx/xx/xxx

Submitted by:
Brad Sottile, Chief Executive Officer
Date: xx/xx/xxx

Submitted to: Dr. Lyle N. Long

Review Notes

During verification process, a couple requirements were deemed either
untestable and unnecessary or not codeable. These have been removed but
document by a strikethrough in this report.
Rev. G Page 3 of 8
Table of Contents
1 SYSTEM CONTEXT & SCOPE
1.1 SCOPE OF THE SYSTEM
1.2 WORKFLOW PARTITIONING
1.3 PRODUCT BOUNDARY
1.4 USE CASE LIST
2 FUNCTIONAL AND DATA REQUIREMENTS
2.1 FUNCTIONAL REQUIREMENTS.
2.2 DATA REQUIREMENTS.
3 LOOK, FEEL AND USE REQUIREMENTS
3.1 USER INTERFACE REQUIREMENTS
3.2 STYLE OF THE PRODUCT REQUIREMENTS
3.3 EASE OF USE REQUIREMENTS
3.4 EASE OF LEARNING REQUIREMENTS
4 PERFORMANCE REQUIREMENTS
4.1 SPEED REQUIREMENTS
4.2 SAFETY CRITICAL REQUIREMENTS
4.3 PRECISION REQUIREMENTS
4.4 RELIABILITY AND AVAILABILITY REQUIREMENTS
4.5 CAPACITY AND SCALABILITY REQUIREMENTS
5 OPERATIONAL REQUIREMENTS
5.1 EXPECTED TECHNOLOGICAL ENVIRONMENT REQUIREMENTS
5.2 PARTNER APPLICATIONS & INTERFACES REQUIREMENTS
5.3 SUPPORTABILITY REQUIREMENTS
5.4 MAINTAINABILITY AND PORTABILITY REQUIREMENTS
6 SECURITY REQUIREMENTS
6.1 SYSTEM CONFIDENTIALITY REQUIREMENTS
6.2 DATA INTEGRITY REQUIREMENTS
6.3 AUDIT REQUIREMENTS
7 LEGAL REQUIREMENTS
8 STANDARDS REQUIREMENTS
9 OFF-THE-SHELF SOLUTIONS REQUIREMENTS
9.1 COTS SYSTEM SOLUTIONS REQUIREMENTS
9.2 READY-MADE COMPONENTS REQUIREMENTS
10 CONSTRAINTS AND ASSUMPTIONS
10.1 SOLUTION CONSTRAINTS
10.2 EXTERNAL FACTORS
10.3 ASSUMPTIONS
11 FUTURE REQUIREMENTS

Rev. G Page 4 of 8
1 SYSTEM CONTEXT & SCOPE
SCOPE OF THE SYSTEM
The system to be developed is a robotic vehicle that can execute given
commands from a user at a separate location through a wi-fi connection. It will
be driven through a laptop or game controller and use a wi-fi camera to
provide visual data to the user. The vehicle must be able to avoid obstacles in
order to tag the opposing vehicle with an IR sensor; as well as receive tags
from the opposing vehicle. The vehicle will have a designated reload time as
provided by the customer. The goal of the user is tag the opposing vehicle as
many times as possible while avoiding tags from the opposing vehicle.
WORKFLOW PARTITIONING
The workflow should follow the below diagram. A V cycle should be
utilized. The coding team has blocks of code tested and verified in increments in
order to keep progress flowing and allowing time to address issues and changing
customer needs.

Figure 1. Workflow Diagram

PRODUCT BOUNDARY
The team should assemble the vehicle using given off-the-shelf products
and create the software necessary for its control. The vehicle must meet all the
requirements designated by the customer and should meet all following
requirements as determined by requirements engineering. Testing must approve
the vehicle is fully operational and meets design criteria before V&V may verify
and validate all requirements are met. A user should be trained to control the
vehicle to compete on the competition.

Rev. G Page 5 of 8
USE CASE LIST
2 FUNCTIONAL AND DATA REQUIREMENTS
2.1 FUNCTIONAL REQUIREMENTS.
2.1.1 The vehicle must be entirely remote controlled
2.1.1.1 The vehicle controller system must consist of only a laptop,
wi-fi receiver, any controller devices, and a single user
2.1.2 The vehicle must transmit as close to real time video feed as
possible via a given wi-fi camera to the controller
2.1.3 The vehicle must be able to execute all commands given from the
controller
2.1.3.1 Vehicle must be able to move forwards, backwards, rotate
right, and rotate left
2.1.3.2 Vehicle must have a designated button to fire the IR gun
2.1.3.3 Vehicle must execute commands given wirelessly from the
controller utilizing an Arduino wi-fi board and an Arduino processor
2.1.4 Vehicle must have an IR gun and sensor
2.1.4.1 The IR gun must be able to fire every 2 seconds, as
specified by the customer as the minimum interval
2.1.4.2 The IR sensor must be continuously on
2.1.5 The vehicle must withstand ramming full speed into a rigid object
with no critical structural damage
DATA REQUIREMENTS.
2.2.1 Software must be written using C or C++
2.2.2 Data link between the controller and vehicle must be wireless
2.2.2.1 Software must utilize and integrate an Arduino processor,
Arduino wi-fi board, Arduino motor control board, a laptop, IR gun, and IR
sensor
3 LOOK, FEEL AND USE REQUIREMENTS
3.1 USER INTERFACE REQUIREMENTS
3.1.1 All control commands should be executed using an Xbox controller
(primary) or using the ASDW keys on the keyboard (secondary).
3.1.1.1 The control commands should be mapped to the Xbox
controller as follows: left joystick for forward/backwards, right
joystick for left/right, right trigger to shoot
3.1.1.2 The control commands should be mapped to the keyboard
as follows: W-key for forward, S-key for backwards, A-Key for left,
D-Key for right, space bar to shoot
3.1.2 The system should utilize a separate window for video feed
3.1.3 Software should communicate applicable system errors to user
Rev. G Page 6 of 8
3.1.4 A reload bar should notify the user when reload time is done
3.1.5 User should be notified when vehicle is tagged
3.1.6 Controller software should keep count of opposing tags
3.2 STYLE OF THE PRODUCT REQUIREMENTS
3.2.1 The robotic system should be placed on a small, two-wheeled
chassis.
3.2.2 Vehicle should not contain any other instrumentation than the given
processor, wi-fi board, wi-fi camera, IR sensor/receiver, and battery
3.3 EASE OF USE REQUIREMENTS
N/A
3.4 EASE OF LEARNING REQUIREMENTS
3.4.1 The system should be user friendly to the point where a non-team
member could be taught all aspects of how to operate the vehicle in 15
minutes or less with less than 5 operational errors
4 PERFORMANCE REQUIREMENTS
4.1 SPEED REQUIREMENTS
4.1.1 System should process as fast as hardware allows with no
unnecessary time delays
4.2 SAFETY CRITICAL REQUIREMENTS
4.2.1 The system should have a manual on/off for the batteries and
camera
4.2.2 The system should have a remote kill switch initiated by the user on
the laptop
4.3 PRECISION REQUIREMENTS
4.3.1 Operator should be able to visually detect an obstacle 3 feet in front
of the vehicle through the wi-fi camera
4.3.2 Camera feed should include a dot, circle, or crosshair as an aiming
device
4.4 RELIABILITY AND AVAILABILITY REQUIREMENTS
4.4.1 System must be able to operate on a linoleum floor
4.4.2 Battery life should exceed 50 minutes at full performance
4.4.3 Controller and camera range should be more than 50 feet
4.5 CAPACITY AND SCALABILITY REQUIREMENTS
5 OPERATIONAL REQUIREMENTS
5.1 EXPECTED TECHNOLOGICAL ENVIRONMENT REQUIREMENTS
5.2 PARTNER APPLICATIONS & INTERFACES REQUIREMENTS
5.2.1 Wi-fi camera must interface with command software
Rev. G Page 7 of 8
5.2.2 Command software should interface with the Arduino processor and
board
5.2.3 Arduino processor & board should interface with wheel motors
5.2.4 Arduino processor and board should interface with IR gun & sensor
5.2.5 Battery will interface with motors and hardware
5.3 SUPPORTABILITY REQUIREMENTS
5.3.1 System should be able to execute multiple commands at once
5.4 MAINTAINABILITY AND PORTABILITY REQUIREMENTS
5.4.1 The vehicle should weigh less than 15 pounds
5.4.2 The vehicle dimensions should be less than 2x2x2 feet
6 SECURITY REQUIREMENTS
6.1 SYSTEM CONFIDENTIALITY REQUIREMENTS
6.1.1 All information must be proprietary to team
6.2 DATA INTEGRITY REQUIREMENTS
6.3 AUDIT REQUIREMENTS
N/A

7 Legal Requirements
7.1.1 All instruments must be returned to the customer at the end of the
semester
7.1.2 Customer must be reimbursed for any broken instruments
8 STANDARDS REQUIREMENTS
N/A
9 OFF-THE-SHELF SOLUTIONS REQUIREMENTS
9.1 COTS SYSTEM SOLUTIONS REQUIREMENTS
9.1.1 All electronic devices and structural components should be off the
shelf products
9.2 READY-MADE COMPONENTS REQUIREMENTS
N/A
10 CONSTRAINTS AND ASSUMPTIONS
10.1 SOLUTION CONSTRAINTS
10.1.1 Vehicle performance is limited by the specific instrumentation given
by the customer
10.2 EXTERNAL FACTORS
N/A
10.3 ASSUMPTIONS
10.3.1 No outside equipment or instrumentation may be used
Rev. G Page 8 of 8

11 FUTURE REQUIREMENTS
. 11.1 Customer reserves the rights to reasonably change requirements
based on evolving needs

AERSP 440: Robot User Manual
(BLUE TEAM)
I. Robot Set-up
a. Connect laptop to router-
Username: Cisco14266
Password: abcd1234
b. Make sure the battery is charged before use
c. Make sure the battery is plugged into the Arduino board
d. Turn on the robot with the silver switch on the top (light should turn on)
e. Use USB printer cable to connect Arduino to computer
f. Run Arduino IDE serial monitor to obtain IP for robot
g. Open folder with executable inside and run the executable
h. Window should pop-up and prompt for IP address of the robot
i. Enter the robot IP address and hit enter
j. Window should display reload bar for IR gun; the IR gun can be fired again once
the bar has been filled (2 seconds)
k. (optional) Connect USB controller to use controller scheme, otherwise default is
keyboard controls
Notes: *Make sure the window for the executable is active in Windows platform

II. Camera Set-up
a. Run camera software IPCamera to obtain camera IP address
b. Open Chrome and type in the IP address found
c. Input camera information-
Username: blue
Password: kelvinisrad
d. Click on Server Push Mode to access camera feed
Notes: *May need to wait a few seconds for camera IP to become available
*If camera cannot connect to router, see camera user manual for setup
III. Controls
a. Xbox Controller
a.i. Left J oystick Forward and Backward Motion
a.ii. Right J oystick Left and Right Turning Motion
a.iii. Left Bumper Speed Down
a.iv. Right Bumper Speed Up
a.v. Right Trigger Fire IR Gun

Figure 1: Xbox controller layout
Notes: *Both joysticks can be used for 8-way compass control

b. Keyboard
W Forward Motion
S Backward Motion
A Turn Left
D Turn Right
Up Arrow Speed Up
Down Arrow Speed Down
Space Bar Fire IR Gun

Figure 2: Keyboard controller layout
Notes: *Keyboard can only be used when Xbox controller is not plugged in

IV. Trouble Shooting
Arduino cant connect
Wrong username and password for router
Client cant connect
Wrong IP address for robot
Camera cant connect
Check camera user manual to reconnect camera to router
Run IPCamera application to verify IP address of camera
Keyboard control wont work
Make sure executable window is active (click in it)
Is the controller plugged in? If so, it takes priority over keyboard
If robot disconnects and doesnt auto reconnect
Restart executable first, then robot.

SourceCodeTableofContents:
Headers:
WifiConnection.h
Game.h
header.h
C++Files:
Game.cpp
GameCleanup.cpp
GameGetControllerInput.cpp
GameGetKEyboardInput.cpp
GameLogSDLError.cpp
GameOnInit.cpp
GameOnLoop.cpp
GameOnRender.cpp
Main.cpp
WifiConnection.cpp
WifiConnectionConnect.cpp
WifiConnectionInitialize.cpp
WifiConnectionLogWSAError.cpp
WifiConnectionQuit.cpp
WifiConnectionSendData.cpp

/**WifiConnectionHeaderFile
ContainstheinformationabouttheWifiConnectionclass
*/
#ifndefWIFICONNECTION_H_INCLUDED
#defineWIFICONNECTION_H_INCLUDED
#include"header.h"
classWifiConnection
{
private:
friendclassgame;//allowsthegameclasstoaccessallprivatedataoftheWifiConnectionclass
u_shortPORT;//portnumber
constchar*IP_ADDRESS;//characterarraythatholdsIPaddress
WSADATAwsa;//neededforWinSockinitialization
SOCKETs;//socket
structsockaddr_inserver;//serverstructthatholdsIPandportinformation
Uint8sendarray[5];//controldataarray
Uint8arraysent[5];//storesdatajustsent
char*ptr_sendarray;//pointertocontroldata
boolconnected;
charrecvarray;
char*ptr_recvarray;
public:
WifiConnection();
voidlogWSAError(ostream&os,conststring&msg);
boolInitialize();
boolConnect();
boolSendData();
voidQuit();
boolReceiveHit();
};
#endif

/**GameHeaderFile
Containstheinformationaboutthegameclass,andalsofunnelsalltheheaderlibrariesintoone
place
AlsocontainsaWifiConnectionobjectthathandlesallthenetworkingcapabilities
*/
#ifndefGAME_H_INCLUDED
#defineGAME_H_INCLUDED
#include"header.h"
#include"WifiConnection.h"
constintSCREEN_WIDTH=400;//widthofthegamewindow
constintSCREEN_HEIGHT=100;//heightofthegamewindow
constSDL_RectCONRECT={10,50,97,24};
constSDL_RectDISRECT={10,50,121,24};
constSDL_RectHITRECT={10,10,44,24};
classgame
{
private:
boolRunning;//definesifthegameisrunning
SDL_Window*window;//pointerforthegamewindow
SDL_Renderer*renderer;//pointerforthewindowrenderer
SDL_Surface*loadSurface;
SDL_Texture*TextConnect;
SDL_Texture*TextDisconnect;
SDL_Texture*TextHit;
SDL_EventEvent;//variabletoholdeventdata
SDL_GameController*controller;//pointerforthegamecontroller
constUint8*keystate;//pointer(usedasanarray)forthekeystateinformation
Uint8speed,max_speed;//initialspeed
Uint8left_bias,right_bias;
Sint16AxisState_Left,AxisState_Right,AxisState_Trigger;//stateofcontrolleraxes
inttime_fire,time_now,time_sent,time_hit;//timeoflastfiringandcurrenttime
WifiConnectionConnection;//WifiConnectionobject
intdeadzone;//Deadzoneforgamepads
boolfiring;
boolreloading;
boolhit;
inttime_nowms,time_firems;
public:
game();
voidlogSDLError(ostream&os,conststring&msg);
intOnExecute();
boolOnInit();
boolLoadContent();
voidGetKeyboardInput();
voidGetControllerInput();
voidOnEvent(SDL_Event*Event);
voidOnLoop();
voidOnRender();
voidCleanup();
};
#endif//GAME_H_INCLUDED
/**HeaderFile
Containsallthelibraries(andperhapslater,functionprototypes,butweshouldtrytokeepthosein
arelevantclassstructure)
thattheprogramneedstorun.Inordertocompileandrunthisprogram,SDL2.0andWinsock2are
alsorequired,andtheirrespective
librariesmustbelinkedinyourIDE.SDLalsohasa.dllfilethatmustbeintheprojectfolderforthe
executabletorun.
*/
#ifndefHEADER_H_INCLUDED
#defineHEADER_H_INCLUDED
#include<iostream>
#include<SDL.h>
#include<winsock2.h>
#include<stdint.h>
#include<ctime>
usingnamespacestd;
#endif//HEADER_H_INCLUDED

/**GameConstructorandExecutionLoop
Containsboththeconstructorforgame,whichinitializestherequiredvariables,
andthesimpleloopthatcontrolstheorderinwhichthingsoccurandupdateduringthegame.
UPDATE:Eliminateddelay.Shouldbebalancedbythefactthatthecodeonlysendsanewarray
whenitchanges,butwe'llhavetokeepaneyeonthis.
*/
#include"Game.h"
game::game()//gameconstructor
{
window=NULL;
renderer=NULL;
loadSurface=NULL;
TextConnect=NULL;
TextDisconnect=NULL;
TextHit=NULL;
controller=NULL;
keystate=SDL_GetKeyboardState(NULL);//initializesakeyboardstatethatcanbeupdatedlater
speed=100;
max_speed=150;//initialspeedforkeyboardinput
left_bias=right_bias=0;
Running=true;//thegameisnowrunning
firing=false;
reloading=false;
hit=false;
time_fire=0;
time_sent=0;
time_hit=0;
deadzone=6000;
intgame::OnExecute()
{
if(OnInit()==false)//initializeseverythingneededtorunthegame
{
return1;//ifinitializationfailed,closetheprogram
}
while(Running)//loopsaslongasgameisrunning
{
SDL_PumpEvents();
if(SDL_GameControllerGetAttached(controller)==SDL_TRUE)//getcontrollerinputifcontroller
isattached
{
GetControllerInput();
}
else
{
controller=NULL;//otherwise,resetcontrollerpointer(incaseit'sbeendisconnected)
GetKeyboardInput();//andgetkeyboardinput
}
while(SDL_PollEvent(&Event))//checktheeventlogforanydesiredevents
{
OnEvent(&Event);
}
OnLoop();//sendsdata
OnRender();
}
Cleanup();//oncegamestopsrunning,cleanupeverything
return0;
}
/**GameCleanup
Beforethegamequits,thisfunctioncleansallthedataandprocessesthatwereinitializedatthe
start,includingthenetworkingroutines
*/
#include"Game.h"
voidgame::Cleanup()
{
Connection.Quit();//quitthenetworkingroutines
SDL_GameControllerClose(controller);//closethegamecontroller
SDL_DestroyRenderer(renderer);//closetherenderer
SDL_DestroyWindow(window);//closethegamewindow
SDL_Quit();//quitSDL
}

/**GameControllerInput
Checksthestateofalldesiredcontrolleraxesandsetsdatavaluesthatcorrespondtocurrentstate
Inthefuture,controllerbuttonscanalsobemappedforcertainpurposes
*/
#include"Game.h"
voidgame::GetControllerInput()
{
Connection.sendarray[0]=0;
AxisState_Right=SDL_GameControllerGetAxis(controller,SDL_CONTROLLER_AXIS_RIGHTX);
AxisState_Left=SDL_GameControllerGetAxis(controller,SDL_CONTROLLER_AXIS_LEFTY);
if((AxisState_Right>Sint16(deadzone)))
{
Connection.sendarray[0]=speed+(30/130.0)*speed;
Connection.sendarray[1]=Uint8(0);
Connection.sendarray[2]=speed;
}
elseif((AxisState_Right<Sint16(deadzone)))
{
}
//theleftjoystickyaxisispositivedown,negativeup
if((AxisState_Left>Sint16(deadzone)))//itcontrolstheleftmotor
{
}
elseif((AxisState_Left<Sint16(deadzone)))
{
}
if(AxisState_Left<Sint16(deadzone)&&AxisState_Right>Sint16(deadzone))
{
Connection.sendarray[2]=(6.5/10.0)*speed;
}
elseif(AxisState_Left<Sint16(deadzone)&&AxisState_Right<Sint16(deadzone))
{
Connection.sendarray[0]=(6.5/10.0)*(speed+(30/130.0)*speed);
}
if(AxisState_Left>Sint16(deadzone)&&AxisState_Right>Sint16(deadzone))
{
Connection.sendarray[2]=(6.5/10.0)*speed;
}
elseif(AxisState_Left>Sint16(deadzone)&&AxisState_Right<Sint16(deadzone))
{
Connection.sendarray[0]=(6.5/10.0)*(speed+(30/130.0)*speed);
}
AxisState_Trigger=SDL_GameControllerGetAxis(controller,SDL_CONTROLLER_AXIS_TRIGGERRIGHT);
//therighttriggercontrolsthefiringmechanism
if((AxisState_Trigger>Sint16(deadzone)))
{
}
else
{
}
for(inti=0;i<5;i++)//printsoutcontroldatafordebugging
{
cout<<int(Connection.sendarray[i])<<endl;
}
}
/**GameKeyboardInput
Checksthestateofalldesiredkeysandsetsdatavaluesthatcorrespondtokeyspressed
*/
#include"Game.h"
voidgame::GetKeyboardInput()
{
if(keystate[SDL_SCANCODE_UP])//pressingtheuparrowkeyincreasesthespeed,uptoamaxof
130
{
if(speed<Uint8(max_speed))
{
speed++;
}
}
elseif(keystate[SDL_SCANCODE_DOWN])//pressingthedownarrowkeydecreasesthespeed,
downtoaminof0
{
if(speed>Uint8(0))
{
speed;
}
}
else{}
//oftheWASDkeys,whenmorethanoneispressed,onlyonewilldeterminethecontroldata
//itmaybehelpfulinthefuturetodefinescenariosinwhichmultiplekeysarepressed
if(keystate[SDL_SCANCODE_W])//Wmovesforwardandhashighestpriority
{
Connection.sendarray[0]=speed+left_bias;
Connection.sendarray[2]=speed+right_bias;
}
elseif(keystate[SDL_SCANCODE_S])//Smovesbackwardandhassecondpriority
{
}
elseif(keystate[SDL_SCANCODE_A])//Aturnsleftandhasthirdpriority
{
}
elseif(keystate[SDL_SCANCODE_D])//Dturnsrightandhasfourthpriority
{
}
else//ifnonearepressed,zerovaluemovementcommandsaresent
{
}
if(keystate[SDL_SCANCODE_SPACE])//thespacebarfirestheIRgun
{
}
else//ifnotpressed,gunwillnotfire
{
}
for(inti=0;i<5;i++)//printsoutcontroldatafordebugging
{
cout<<int(Connection.sendarray[i])<<endl;
}
}
/**GameLogSDLError
LoganSDLerrorwithsomeerrormessagetotheoutputstreamofourchoice
@paramosTheoutputstreamtowritethemessageto
@parammsgTheerrormessagetowrite,formatwillbe"<msg>error:<SDL_GetError()>"
*/
#include"Game.h"
voidgame::logSDLError(ostream&os,conststring&msg)
{
os<<msg<<"error:"<<SDL_GetError()<<endl;
}

/**GameEvent
Thisfunctionreceivesaneventoffthetopoftheeventlogandchecksifitisonethatweare
interestedin
ItalsohandlestheconnectionofaUSBgamecontroller
*/
#include"Game.h"
voidgame::OnEvent(SDL_Event*Event)
{
if(Event>type==SDL_QUIT)//ifthegamewindowisclosed,thegamewillstoprunning
{
Running=false;
}
if(Event>type==SDL_CONTROLLERDEVICEADDED)//ifacontrollerisconnected,itwillbe
mappedandusedinlateriterations
{
cout<<"Controllerconnected.\n";
for(inti=0;i<SDL_NumJoysticks();i++)
{
if(SDL_IsGameController(i))
{
controller=SDL_GameControllerOpen(i);
if(controller)
{
cout<<"ControllerName:"<<SDL_GameControllerName(controller)<<endl;
break;
}
else
{
logSDLError(cout,"SDL_GameControllerOpen");
}
}
}
}
if(Event>type==SDL_CONTROLLERBUTTONDOWN)
{
if(Event>cbutton.button==SDL_CONTROLLER_BUTTON_LEFTSHOULDER)
{
if(max_speed>=5)
{
max_speed=max_speed5;
if(speed>max_speed)
{
speed=max_speed;
}
}
cout<<"LEFTSHOULDER\n";
}
if(Event>cbutton.button==SDL_CONTROLLER_BUTTON_RIGHTSHOULDER)
{
max_speed=max_speed+5;
speed=max_speed;//changethislater
cout<<"RIGHTSHOULDER\n";
}
}
}
/**GameInitialization
Initializesalltherequiredprocessestorunthegame,includingcreatingawindowandrenderer,
andestablishinganetworkconnection
*/
#include"Game.h"
boolgame::OnInit()
{
if(SDL_Init(SDL_INIT_EVERYTHING)<0)//initializeSDL
{
logSDLError(cout,"SDL_Init");
returnfalse;
}
if((window=SDL_CreateWindow("SDLRenderClear",100,100,SCREEN_WIDTH,SCREEN_HEIGHT,
SDL_WINDOW_SHOWN))==NULL)//createawindownearthetopleftofthescreen
{
logSDLError(cout,"SDL_CreateWindow");
returnfalse;
}
renderer=SDL_CreateRenderer(window,0,SDL_RENDERER_ACCELERATED|
SDL_RENDERER_PRESENTVSYNC);//createarendererforthatwindowsothatimagescanbe
displayedlater
if(renderer==NULL)
{
logSDLError(cout,"SDL_CreateRenderer");
returnfalse;
}
if(Connection.Initialize()==false)//initializenetworkingfunctions
{
returnfalse;
}
if(Connection.Connect()==false)//connecttonetwork
{
returnfalse;
}
for(inti=0;i<SDL_NumJoysticks();i++)
{
if(SDL_IsGameController(i))
{
controller=SDL_GameControllerOpen(i);
if(controller)
{
cout<<"ControllerName:"<<SDL_GameControllerName(controller)<<endl;
break;
}
else
{
logSDLError(cout,"SDL_GameControllerOpen");
}
}
}
loadSurface=SDL_LoadBMP("Connected.bmp");
if(loadSurface==NULL){
logSDLError(cout,"SDL_LoadBMP_Connect");
returnfalse;
}
TextConnect=SDL_CreateTextureFromSurface(renderer,loadSurface);
if(TextConnect==NULL){
logSDLError(cout,"SDL_CreateTextureFromSurface_Connect");
returnfalse;
}
SDL_FreeSurface(loadSurface);
loadSurface=NULL;
loadSurface=SDL_LoadBMP("Disconnected.bmp");
logSDLError(cout,"SDL_LoadBMP_Disconnect");
returnfalse;
}
TextDisconnect=SDL_CreateTextureFromSurface(renderer,loadSurface);
logSDLError(cout,"SDL_CreateTextureFromSurface_Disconnect");
returnfalse;
}
loadSurface=NULL;
loadSurface=SDL_LoadBMP("Hit.bmp");
logSDLError(cout,"SDL_LoadBMP_Hit");
returnfalse;
}
TextHit=SDL_CreateTextureFromSurface(renderer,loadSurface);
logSDLError(cout,"SDL_CreateTextureFromSurface_Hit");
returnfalse;
}
loadSurface=NULL;
returntrue;
}
/**GameLoop
Thisfunctioncontainsanyprocessesthatneedtobeupdatedeachiteration,includingcheckingthe
timesincelastfire,
andsendingthecontroldata
*/
#include"Game.h"
voidgame::OnLoop()
{
time_now=SDL_GetTicks();//takesthecurrenttimeinms
if(Connection.sendarray[4]==1&&!reloading)//ifmorethantwosecondshavepassedsincelast
firing,
{
cout<<"FIRING"<<endl;
firing=true;
reloading=true;
time_fire=SDL_GetTicks();
}
if(time_nowtime_fire>500){
firing=false;
}
reloading=false;
}
if(firing){
}
if(!firing)
{
}
if((time_nowtime_sent)>100){
if(Connection.SendData()==false)//sendscontroldata
{
Connection.connected=false;
cout<<'\a';
closesocket(Connection.s);
Connection.s=socket(AF_INET,SOCK_STREAM,0);
Connection.Connect();
}
time_sent=SDL_GetTicks();
}
if(Connection.ReceiveHit()){
if((time_nowtime_hit)>1000){
hit=true;
time_hit=SDL_GetTicks();
cout<<'\a';
}
}
if((time_nowtime_hit)>1000){
hit=false;
}
}
/**GameRender
Thisfunctioncontrolswhat,ifanything,isrenderedinthegamewindow
Itisusedtoinformtheuserofbeinghit,aswellasdisplayingthereloadtime
*/
#include"Game.h"
voidgame::OnRender()
{
if(reloading){
//Drawsandredrawsagrowingrectanglebetween0and2000msoffiring.
SDL_Rectr;
SDL_SetRenderDrawColor(renderer,0,0,0,255);
SDL_RenderClear(renderer);
r.x=75;
r.y=10;
r.w=(time_nowtime_fire)/10.0;
r.h=25;
SDL_RenderDrawRect(renderer,&r);
}
if(!reloading){
if(Connection.connected){
SDL_RenderCopy(renderer,TextConnect,NULL,&CONRECT);
}
if(!Connection.connected){
SDL_RenderCopy(renderer,TextDisconnect,NULL,&DISRECT);
}
if(hit){
SDL_RenderCopy(renderer,TextHit,NULL,&HITRECT);
}
SDL_RenderPresent(renderer);
}
/**MainRoutine
CreatesagameobjectcalledtheGame,whichalsorunsitsconstructor,andthenstartsthegame.
*/
#include"Game.h"
intmain(intargc,char*argv[])//SDLRequiresmain()totaketheseparameters
{
gametheGame;
returntheGame.OnExecute();
}
/**WifiConnectionConstructor
InitializesnecessarydatafortheWifiConnectionobject
*/
#include"Game.h"
#include<string.h>
WifiConnection::WifiConnection()
{
stringip_addr;
cout<<"InputIPaddress:";
cin>>ip_addr;
PORT=5001;
IP_ADDRESS=ip_addr.c_str();
ptr_sendarray=(char*)(&sendarray);
ptr_recvarray=(char*)(&recvarray);
arraysent[0]=0;
arraysent[1]=0;
arraysent[2]=0;
arraysent[3]=0;
arraysent[4]=0;
connected=false;
server.sin_addr.s_addr=inet_addr(IP_ADDRESS);
server.sin_family=AF_INET;
server.sin_port=htons(PORT);
}
/**WifiConnectionConnect
ConnectstothenetworkIPandportdefinedintheconstructor
*/
#include"Game.h"
boolWifiConnection::Connect()
{
if(connect(s,(structsockaddr*)&server,sizeof(server))<0)
{
logWSAError(cout,"connect");
returnfalse;
}
u_longiMode=1;
ioctlsocket(s,FIONBIO,&iMode);//Setssockettononblockingmode
setsockopt(s,IPPROTO_TCP,TCP_NODELAY,ptr_sendarray,1);//DeactivatesNaglealgorithm
cout<<"Connected\n";
connected=true;
returntrue;
}
/**WifiConnectionInitialize
InitializesalltheWinSockfunctionsandprocessesnecessaryfornetworking,andcreatesasocket
*/
#include"Game.h"
boolWifiConnection::Initialize()
{
cout<<"InitializingWinsock_Version2...";
if(WSAStartup(MAKEWORD(2,2),&wsa)!=0)
{
logWSAError(cout,"WSAStartup");
returnfalse;
}
cout<<"Initialized.\n";
if((s=socket(AF_INET,SOCK_STREAM,0))==INVALID_SOCKET)
{
logWSAError(cout,"socket");
returnfalse;
}
cout<<"Socketcreated.\n";
returntrue;
}

/**WifiConnectionLogWSAError
LogaWSAerrorwithsomeerrormessagetotheoutputstreamofourchoice
@paramosTheoutputstreamtowritethemessageto
@parammsgTheerrormessagetowrite,formatwillbe"<msg>error:<WSAGetLastError()>"
*/
#include"Game.h"
voidWifiConnection::logWSAError(ostream&os,conststring&msg)
{
os<<msg<<"error:"<<WSAGetLastError()<<endl;
}
/**WifiConnectionQuit
Endstheconnection,closesthesocket,andquitsalltheWinsockprocesses
*/
#include"Game.h"
voidWifiConnection::Quit()
{
ptr_sendarray=NULL;
closesocket(s);
WSACleanup();
}
/**WifiConnectionSendData
Sendsthecontroldataoverthecreatednetworkconnection
/
#include"Game.h"
boolWifiConnection::SendData()
{
if(send(s,ptr_sendarray,5,0)<0)
{
logWSAError(cout,"send");
returnfalse;
}
arraysent[0]=sendarray[0];
returntrue;
}

Software Engineering Final Report - Blue Team

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering Final Report - Blue Team

Uploaded by

Copyright:

Available Formats

Department of Aerospace Engineering

Purpose of the Part

You might also like