Our Team Introduction - ODU Computer Science

Our Team Introduction
Joe Michelli
Project Manager
Testing
Evaluation
Ian Gullett
Hardware
Documentation
Charles Morris
Webmaster
Finances
Joshua Robertson
Marketing
Software
Team Structure
Joan Smith
Josh
Robertson
Joe
Michelli
Ian
Gullett
Charles
Morris
Presentation Format
Presentation Format
Define/Explain Problem & Solution
Define and Analyze Market
What the Solution Will Do
What the Solution Won’t Do
Technical Issues
Presentation Format
Risk Issues
Resource Issues
Management Methods Issues
Conclusion
Handout
Feasibility Report
Glossary of Terms
Hard Copy of Presentation
The Problem
Problem Description
Military units conducting
amphibious landings¹
(vehicles, equipment,
personnel from sea to shore)
need an accurate system of
surveying the beach for
obstacles, hazards, sand
bars, and water depths.
This is crucial for vehicle
safety and personnel dropoff. Failure could result in
massive loss of life.
Pre-assault Hydrographic
Reconnaissance²
Beach Survey³
Decide on Location
Divide Into Grid
The Method (Lead Line & Slate)
Multiple Combat Swimmers covertly
measure depth of water (line attached to a
weight or handheld fathometer⁵), locates
obstacles and transcribes data onto a slate.
The data is either hand drawn as a chart
or entered one character at a time into a
program to create a chart.
Deploy Team
of Swimmers
Line Up In Water
Why This Doesn’t Work
Inaccurate
Guesstimate location & depth
Time Consuming
Spend hours in the water & inputting data
Juggling Act
Trying to swim straight, with a line, writing on a
slate, keeping correct distance, at night in an area
you shouldn’t be in.
Proposed Solution
Our Solution
Incorporating GPS⁶, Fathometer,
and mapping software
technology; create a system to
accurately and efficiently collect
and display depth and obstacles
at specific locations.
ABSS Data Flow Model
Fathometer
Record Depth/
Location
Controller
Data Sent over
Serial Connection
Embedded Data
Recording System
Data Sent in
NMEA Format
Solid State
Storage
Data Is Transfered To A PC
Mapping Software
GPS
Record Obstacle
Location
Controller
Data Is Imported
Chart Is Created
Market Definition
and Analysis
Joshua Robertson
Market Composition
The focus market for our product will be the US
Navy.
Later on we plan to branch out to other branches of
the US Armed Forces as well as foreign armed forces.
The product will be geared towards stealthy military
use.
First we will analyze the US Navy.
Market for the US Navy SEALs⁷
Navy
East Coast
West Coast
Seal Teams
Seal Teams
Platoons
Platoons
Units
Units
The Navy Will Need 512 Devices!
They will need 8 units in each platoon
There are 8 platoons in each Seal Team
There are 4 Seal Teams on each coast
And there are 2 coasts
This means that there is an instant market for 512 of our
devices just taking into account the US Navy.
Prototype Cost Analysis
GPS Receiver
$200
Fathometer
$150
Interface
$400
Misc. Hardware
$50
Mapping Software
$100
Case
$100
Total
$1,000
Prototype Labor Analysis
Function
Hours Employees Total Hours
Extract GPS Data
20
1
20
Extract Fath Data
60
1
60
Interface & Data
160
4
640
Storage
Mapping Software
40
1
40
Casing
40
1
40
Documentation
200
1
200
Total Projected Hours
1,000
Retail Cost Analysis
Cost of Production Device
(70% of Prototype)
$700
Selling Price of Production Device
(300% of Cost)
$2,100
Projected Warranty Expense
(20% of Selling Price)
$420
Profit Per Device
$980
Profit Based on Sales
of 512 Initial Units
$501,760
Competition
Competition
Display Display
Depth Location
Vexilar LPS-1
Store
Depth
Store
Location
x
Magellan
SporTrack
Less
Than
$3000
Small
Platform
x
x
x
Handheld
Create
Chart of
Data
x
x
x
x
x
x
x
Garmin
Fishfinder⁸ 80
x
x
x
x
NavNet Radar/
Chart Plotter
x
x
x
x
NOAA Bay
Hydrographer
x
x
x
x
x
OHMEX
x
x
x
x
x
ABSS
x
x
x
x
x
x
x
x
x
x
Objectives Evaluated
Ian Gullett
Pros
Improved Beach Surveys
Surveys will be much
more accurate than
current lead-line and
slate which assume
all swimmers are
parallel.
Saving Lives
Our product could
help save lives in
battle by having more
accurate maps of
landing areas, leading
to fewer drownings.
Decreased Time
• The current system
•
can take up to six
hours to complete.
ABSS will take
approximately 1/10
the time
Cons
Cost
• The current system
of lead-line and slate
costs almost
nothing.
• Our solution will
retail for around
$2000.
Potential for Failure
There is a possibility
that a hardware
component in our
solution could fail
whereas this
problem isn’t present
in the current
solution.
What Our Solution
Will Do
Charles Morris
It Will Take and Store Readings
The ABSS will take
periodic readings of
depth and location
and store them on a
solid state device.
It Will Provide Accurate Readings
The ABSS will
provide much more
accurate readings
than the current
method of lead-line
and slate.
It Will Record Obstacles
The ABSS will have a
push button to record
when an obstacle is
found including the
coordinates and the
depth.
You Can Swim With It
The user will be able
to use the ABSS like a
kick-board and swim
it around collecting
the GPS and depth
information.
It Will Map Information
The desktop
interface software for
the ABSS will allow
the information from
multiple devices to be
imported and
mapped out.
What Our Solution
Won’t Do
It Won’t Differentiate Obstacles
Obstacle data is
stored in a boolean
fashion, not in a
detailed data
structure. Thus the
map will only show
where an obstacle is,
not additional info
about it.
It Won’t Record Tide Information
• ABSS will not
•
incorporate tide
information.
This will have to be
calculated using GPS
timestamps and
knowledge of the area
surveyed.
It Won’t Display Data To User
There is no safe and
practical way to show
the user the data as it
is collected on the
device due to the fact
that the user must be
stealthy.
It Won’t Work Under
All Weather Conditions
The GPS signal can be
disrupted by medium
to heavy cloud cover.
Strong wave
conditions may also
impair the ability to
use the ABSS properly.
Major Technical Issues
Ian Gullett
Power Supply
The power supply is largely dictated by the final
components used.
If we use a handheld-style GPS and fathometer the
power supply can likely be AA batteries which
would be ideal.
If we use other options such as a dual GPS/
fathometer we will likely have to use 12v power
which could add a lot of weight and bulk to the
device.
Architecture
We will have to pick an architecture to use
for the embedded system.
The main choices consist of a PDA or a PIC
chip.
The PDA has the benefit of easier
programmability, however the PIC would be
more customizable and be more suited for
our use.
Extracting Fathometer Data
The current fathometer we are using does
not have a computer (serial) output.
Due to this we will have to find a way to
interface with this component, likely
reading line voltages into the embedded
system.
This could be very difficult.
Identifying Proper Device
Operation
The device must be stealthy and thus
cannot have lights on the outside.
We must find a way to relay to the
user that the device is indeed turned
on, working, and can acquire a proper
GPS signal.
Implementing
Power Button
We will be pairing many different devices in the
ABSS including GPS, fathometer, and an
embedded recording system.
The end user must be able to turn on the device
and start recording with a simple push of a
button.
Thus we will have to find a way to startup all of
the devices at once from one switch.
Making the System Waterproof
Due to the nature of the task the ABSS will
have to be built into a waterproof container.
We will still have to allow access to a button to
mark obstacles and the power switch from the
outside.
Also there will have to be a port to connect to a
host to unload data.
Major Risk Issues
Joshua Robertson
Government Specifications
The final product may have to be within
Government Specifications.
This could dictate the model of GPS and
fathometer that we can incorporate as well as
the casing for the product and the housing.
We will have to take steps to ensure that
governmental requirements are met so we can
sell to our target market, the Navy.
Solution Too Expensive
The solution will require a fathometer and GPS to
be tied into non-volatile storage.
This means that the parts for the device will cost
around $700 for production devices.
The final product will retail for around $2000
which is a lot more than the cost of the lead-line
and slate currently in use.
GPS Link
GPS receivers must have a clear view of the
sky in order to properly obtain a link.
Due to this the user must have the device
properly oriented in order for it to function.
This could become a reliability issue, so we
must make sure that users are properly
trained in how to use the device.
Hardware Failure
Our electronic device will be replacing an
analog device, and thus there is a newly
introduced chance of hardware failure.
This means that the hardware will have to
be tested thoroughly to make the chance
of a hardware failure in the field as
minimal as possible.
Solution Too Complicated
The interface of the device must be
simple enough to allow “non-computer
people” to use the device.
If the interface to the device is too
complicated then the issue of user error
would come into play.
Resources
Ian Gullett
Equipment Needed
Handheld GPS Receiver w/ Serial
Output
Handheld Fathometer
Multiple Computers and Software
Development Programs
Skills Needed
Domain Expertise
Extensive Software Development Knowledge
Win32, Unix, Perl, Asm (x86, SPARC, z80, MIPS)
Thorough Knowledge of Electronics
Knowledge of Embedded Systems
Workspace, Time,
and Money
A workbench and several computer stations
are needed.
The project can be worked on part time, we
estimate four people with 20 hour work weeks
will be able to accomplish it.
Approximately $1000 will be needed to
complete the prototype device.
Management Method Issues
Joe Michelli
Management Style
Communication
Free-for-all Exchange of Ideas
Meetings
Schedule, Task, Completion Dates
Our Busy Schedules
Ian, Charlie, and Josh work as ODU Computer
Science System Administrators.
Joe is active in the ODU ROTC unit.
Our schedules generally dictate that we have to
get together late at night.
Based on these issues we have projected the time
required for the project on a 20 hour work week.
Schedule
Task
Duration
Extract GPS Data
7 days
Extract Fath Data
21 days
Embedded System
60 days
Mapping Software
14 days
Casing
14 days
Documentation
continuous
Month 1
Month 2
Month 3
CS410 / CS411
Month 4
Conclusion
Conclusion
There is a market for the ABSS
We can make a profit
We have the technical ability to create it
The superior performance over the old
system outweighs the cost of the ABSS
Questions?