Final Report - Senior Design

Transcription

Restaurant Automation
Final Report
Project Code
May07-14
March 30, 2007
Client
Senior Design
Faculty Advisor
Dr. Manimaran Govindarasu
Technical Advisor
Dr. Randall L. Geiger
Team Members
Chris Ford
Sean McVeigh
Obioma Ohia
Nichole Taylor
Anthony VanSant
DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer
engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional
engineering design or a professional land surveying document. Although the information is intended to be accurate,
the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the
accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any
such use does not violate any laws with regard to professional licensing and certification requirements. This use
includes any work resulting from this student-prepared document that is required to be under the responsible charge
of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and
the associated faculty advisors. No part may be reproduced without the written permission of the senior design
course coordinator.
TABLE OF CONTENTS
Section
Description
Page
1
Executive Summary ........................................................................................... 1-1
2
Project Statement............................................................................................... 2-1
2.1 Project Purpose .............................................................................................. 2-1
2.2 Operating Environment.................................................................................. 2-1
2.3 Intended Use and Users.................................................................................. 2-1
2.4 Assumptions and Limitations......................................................................... 2-2
2.4.1 Assumptions .......................................................................................... 2-2
2.4.2 Limitations............................................................................................. 2-2
2.5 Expected Project Product and Other Deliverables......................................... 2-2
3
Approach and Results ........................................................................................ 3-1
3.1 End-Product Functional Requirements .......................................................... 3-1
3.2 Handheld Approach and Results.................................................................... 3-2
3.2.1 Resultant Design Constraints ................................................................ 3-2
3.2.2 Approaches Considered and One Used ................................................. 3-3
3.2.2.1 Platform .................................................................................... 3-3
3.2.2.2 Programming Language ........................................................... 3-4
3.2.2.3 Wireless Communications........................................................ 3-5
3.2.3 Detailed Design (hardware)................................................................... 3-5
3.2.3.1 ICOP Technology eBox-II........................................................ 3-5
3.2.3.2 Credit Card Reader ................................................................... 3-7
3.2.3.3 USB Wireless Network Card.................................................... 3-8
3.2.3.4 Bluetooth Converter ................................................................. 3-8
3.2.3.5 Printer ....................................................................................... 3-9
3.2.4 Detailed Design (software).................................................................... 3-9
3.2.4.1 Inputs ........................................................................................ 3-9
3.2.4.2 User Interfaces.......................................................................... 3-9
3.2.4.3 Modules .................................................................................. 3-10
3.2.4.3.1 Update/Startup function ............................................ 3-10
3.2.4.3.2 Sorting function......................................................... 3-10
3.2.4.3.3 Create an order function ............................................ 3-10
3.2.4.3.4 Edit order module...................................................... 3-11
3.2.4.3.5 Payment module ........................................................ 3-11
3.2.4.3.6 Item selection function .............................................. 3-17
3.2.4.4 Communications..................................................................... 3-17
3.2.4.4.1 Socket programming ................................................. 3-17
3.2.4.4.2 Communication between handheld and central computer
................................................................................... 3-18
3.2.5 Implementation Process Description................................................... 3-18
3.2.6 End Product Testing ............................................................................ 3-19
3.3 Kitchen Display Approach and Results ....................................................... 3-19
i
TABLE OF CONTENTS (Con’t)
Section
Description
Page
3.3.1 Resultant Design Constraints .............................................................. 3-19
3.3.2 Approaches Considered and One Used ............................................... 3-19
3.3.2.1 Programming Language ......................................................... 3-20
3.3.2.2 Wireless Communications...................................................... 3-20
3.3.3 Detailed Design (hardware)................................................................. 3-21
3.3.3.1 Dell GX270............................................................................. 3-21
3.3.4 Detailed Design (software).................................................................. 3-22
3.3.4.1 Inputs ...................................................................................... 3-22
3.3.4.1.1 User Input.................................................................. 3-22
3.3.4.1.2 Input via Wireless Communication........................... 3-22
3.3.4.2 User Interfaces........................................................................ 3-23
3.3.4.2.1 Application Flow....................................................... 3-23
3.3.6 End Product Testing ............................................................................ 3-25
3.4 Central Computer Approach and Results..................................................... 3-25
3.4.1 Resultant Design Constraints .............................................................. 3-25
3.4.2 Approaches Considered and One Used ............................................... 3-26
3.4.2.1 Programming Language ......................................................... 3-26
3.4.2.2 Wireless Communications...................................................... 3-26
3.4.3 Detailed Design (hardware)................................................................. 3-27
3.4.3.1 Dell GX270............................................................................. 3-27
3.4.3.2 Linksys BEFW11S4 Wireless-B Router ................................ 3-28
3.4.4 Detailed Design (software).................................................................. 3-29
3.4.4.1 Inputs ...................................................................................... 3-29
3.4.4.1.1 User Input.................................................................. 3-29
3.4.4.1.2 Input via Wireless Communication........................... 3-29
3.4.4.2 System Communication.......................................................... 3-29
3.4.4.3 User Interfaces........................................................................ 3-30
3.4.4.4 Application Flow .................................................................... 3-31
3.4.4.4.1 Central Computer Server........................................... 3-31
3.4.4.4.2 Manager Software ..................................................... 3-33
3.4.6 End Product Testing Description ........................................................ 3-34
3.5 Project End Results ...................................................................................... 3-35
4
Actual and Estimated Resources and Schedules.............................................. 4-1
4.1 Actual and Estimated Resource Requirements .............................................. 4-1
4.1.1 Actual Resource Requirements ............................................................. 4-1
4.1.2 Estimated Resource Requirements........................................................ 4-3
4.2 Actual and Estimated Schedule Requirements .............................................. 4-7
5
Project Evaluation .............................................................................................. 5-1
ii
Section
Description
Page
6
Commercialization ............................................................................................. 6-1
7
Recommendations for Additional Work.......................................................... 7-1
8
Lessons Learned ................................................................................................. 8-1
9
Risk and Risk Management .............................................................................. 9-1
10
Project Team Information ............................................................................... 10-1
11
Summary............................................................................................................ 11-1
12
References.......................................................................................................... 12-1
LIST OF FIGURES ................................................................................................ iv
LIST OF TABLES ................................................................................................... v
ACRONYMS AND ABBREVIATIONS ............................................................... vi
iii
LIST OF FIGURES
Figure
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12
Figure 13
Figure 14
Figure 15
Figure 16
Figure 17
Figure 18
Figure 19
Figure 20
Figure 21
Figure 22
Figure 23
Figure 24
Figure 25
Figure 26
Figure 27
Figure 28
Figure 29
Figure 30
Description
Page
Project’s product components ............................................................................. 2-3
ICOP Technology eBox-II .................................................................................. 3-6
Magtek Mini USB credit card reader .................................................................. 3-7
U.S. Robotics Wireless MAXg USB Adapter..................................................... 3-8
Ambicom Wireless Bluetooth Printer Kit ........................................................... 3-9
GUI for the handheld device ............................................................................. 3-10
Example of order arrays .................................................................................... 3-11
Hierarchal view of the payment module ........................................................... 3-12
Payment main menu .......................................................................................... 3-12
Cash submenu.................................................................................................... 3-13
Check submenu ................................................................................................. 3-14
Credit submenu ................................................................................................. 3-15
Debit submenu .................................................................................................. 3-16
Tip submenu...................................................................................................... 3-16
Socket diagram .................................................................................................. 3-18
Server and client communication ...................................................................... 3-22
Working prototype design of kitchen display GUI ........................................... 3-23
Application flow of kitchen display .................................................................. 3-24
Linksys BEFW11S4 broadband router ............................................................. 3-29
This GUI will allow a manager to create/edit menus........................................ 3-30
This GUI controls the server ............................................................................. 3-31
Flow diagram of how an incoming packet of data is handled........................... 3-32
Part of how the classes interact with each other in the central computer server
software ............................................................................................................. 3-32
The rest of how the classes interact with each other in the central computer server
software ............................................................................................................. 3-33
Actual Project Schedule ...................................................................................... 4-8
Revised Estimated Project Schedule ................................................................... 4-9
Original Estimated Project Schedule................................................................. 4-10
Actual Deliverables Schedule ........................................................................... 4-11
Revised Deliverables Schedule ......................................................................... 4-12
Original Deliverables Schedule......................................................................... 4-13
iv
LIST OF TABLES
Tables
Table 1
Table 2
Table 3
Table 4
Table 5
Table 6
Table 7
Table 8
Table 9
Description
Page
Actual Personnel Manhour Effort Requirements for Each.................................. 4-1
Actual Required Resources.................................................................................. 4-2
Actual Estimated Project Costs............................................................................ 4-3
Revised Estimated Personnel Manhour Effort Requirements for Each............... 4-3
Original Estimated Personnel Manhour Effort Requirements for Each .............. 4-4
Revised Required Resources ............................................................................... 4-5
Original Required Resources ............................................................................... 4-5
Revised Estimated Project Costs ......................................................................... 4-6
Original Estimated Project Costs......................................................................... 4-7
v
ACRONYMS AND ABBREVIATIONS
WHOS
Wireless Handheld Ordering System
HDK
hardware development kit
LCD
liquid crystal display
GUI
graphical user interface
PCMCIA
Personal Computer Memory Card International Association
VPN
Virtual Private Network
MSDN
Microsoft Developer Network
vi
1
Executive Summary
In many restaurants when a server takes an order from the customer they must write the order
down and then enter it into a computer at one central location. The order is then printed out in the
kitchen. When it is time to pay the server the server must go back to the central location and print
out a copy of the customer’s bill. If the customer wants to pay with a credit card the server then
has to take the customer’s credit card back to the computer at the central location to scan it in
and then print the receipt. The current system wastes a lot of time because the server keeps going
to and from the customer and the computer at the central location. It also wastes paper since the
order must be written down, printed out in the kitchen, and finally a paper receipt must be given
to the customer.
The purpose of this Project is to develop a handheld device that can be used take an order while
the server is standing at the table and send the order directly to a screen in the kitchen. When the
customer is done eating the server will be able to show the customer their bill on the handheld
device and, if the customer chooses to pay with a credit card, the device will be able to scan the
credit card and print out a receipt without having to leave the customer. This system will reduce
the time the sever takes to obtain and process an order and settle the bill with the customer. The
device will also eliminate some paper used because the only printout is the customer’s credit
card receipt.
This report contains the strategies and approach that the May 07-14 group used to complete the
Project on time. The report contains sections that address the following issues: operating
environment; intended users; assumption and limitations; the end product; detailed results of the
Project; costs; and schedule used for the completion of the project. The end product will be used
in the demonstration, modification/continuation recommendation for the Project.
Changes made to the project, since the Project Design are a revision in the cost estimate, time
estimates and schedule for the Project. The revisions are being made due to the project being
done and the actual numbers being known.
1-1
2
Project Statement
This section will outline the purpose of the Project and identify conditions that will need to be
satisfied as part of the development of a paperless restaurant system.
2.1 Project Purpose
The purpose of the Project is to develop a Wireless Handheld Ordering System (WHOS) to be
used in a restaurant. The system will accept order information and send it to the kitchen while the
server is standing at the customer’s table. The system needs the ability to notify the server when
the order is done. When the customer has finished their meal, the server will be able to display
their bill and print a final receipt that will be given to the customer. If the customer is paying by
credit card the server will be able to swipe the credit card information using the WHOS. The
system will be able to keep track of all orders taken each day.
The WHOS will consist of a handheld device (hereinafter called “product”) which will be able to
communicate wirelessly to output screens in the kitchen and to a central computer used to
record/document all orders. The device will be modeled by using an ICOP Technology eBox-II
provided by the Department of Electrical and Computer Engineering. All inputs into the WHOS
will be done using a mouse. Receipts given to customers will be printed from a printer connected
to the system using Bluetooth communications. Programming for the devices will be done using
Microsoft Visual C++ for the eBox-II and Java for the kitchen and central computer.
2.2 Operating Environment
The product will need to be used both indoors and outdoors, weather permitting. It will not be
required to work in the rain or any other extreme weather conditions. It will be stored at room
temperature in a dry place but must be able to perform at non-condensing ambient temperatures.
Other wireless devices are possible sources for interference.
2.3 Intended Use and Users
The product is intended to be used by servers in a restaurant environment. Customers will also
use the device to provide their electronic signature or debt card pin number. Orders will be
received in the kitchen where the cook will be able to view and arrange the orders.
The product will be designed so it can be easily used by an adult. All parts of the system will be
easy to learn with a minimal amount of training. The requirements for using the product are basic
reading and writing skills. The WHOS will require initially to be installed by technical personnel
but menu changes, data interrogation and record reporting will be able to be accomplished by
someone with limited computer skills.
2-1
2.4 Assumptions and Limitations
To limit the Project’s definition and scope to a manageable form, we have identified the
following assumptions and limitations.
2.4.1 Assumptions
1. Product will not be state of the art – Research shows that the resources are
unattainable to make a state of the art product.
2. Since the prototype will be developed using a HDK it will not be handheld. The
final commercial product can easily be developed from the prototype.
3. A maximum of 12 units will be used at once.
4. The maximum distance of transmission is within 10 meters (32 feet), about the
range of Bluetooth [1].
5. There will be a maximum of 5 simultaneous transmissions.
6. Handheld devices are able to be recharged throughout the day – The way in which
this will occur will be like a Pocket PC.
7. Central computer will be located to maximize coverage.
8. Model can be developed into a handheld device..
2.4.2 Limitations
1.
2.
3.
4.
5.
Wireless and Bluetooth distance – Approximately 10m for Bluetooth and much
larger depending on the structure of the building for Wireless.
Power supply – This means the size of the battery used will limit the amount of
time the device can be used before it needs to be recharged.
Size and type of monitor available in the kitchen.
The cost for items needed to complete the Project. May need to tone down the
demo.
The lack of programming skills due to the team being made of just electrical
engineers.
2.5 Expected Project Product and Other Deliverables
The expected Project product is a model of a WHOS that is ready for prototyping. The WHOS
model will use simplified restaurant management software for demonstration. The following
components will be available at the end of the Project:
1.
2.
3.
4.
5.
Handheld device – ICOP Technology eBox-II;
Computer monitor – displays the orders to the kitchen;
Wireless printer – prints receipts;
Central computer – keeps track of orders and makes updates to the system; and
Model – portrays final product.
2-2
A graphical representation of the Project’s product components and how they communicate with
each other is shown in Figure 1.
Figure 1: Project’s product components
2-3
3
Approach and Results
The following section will discuss in detail the approach used to develop the WHOS, the design
of the components and the system. The first device to be discussed will be the handheld device,
the central computer, and finally the kitchen display.
3.1 End-Product Functional Requirements
The following are the functional requirements for the end product with a brief description of how
each requirement is suppose to be met:
•
Send an order to the central computer for processing
This will be done by opening a socket between the handheld and the central computer
once an order has been placed. To verify that this has worked the kitchen display will
then display the new order and the database will be updated with the new order.
•
Reading and writing to the MySQL database
This will be done by the central computer software whereby it takes in information
from either the kitchen or the handheld. The information from the kitchen will be when
an order has been completed the database needs to be updated to change the state of an
order. The information from the handheld that will need access to the MySQL database
would be retrieving the menu, updating the menu after an order, adding new orders to
the database, and changing the state of an order in the database.
•
Send from kitchen that an order is done
The requirement requires that the kitchen tell the handheld that an order has been
completed and is ready for pickup and needs to update the database on the state of the
order.
•
Updating the menu on the handheld when the program first starts
This will be done by sending a message out to the central computer that it needs the
menu. The handheld will then receive from the central computer a compiled menu that
will then be used on the handheld when taking orders and compiling the check.
•
Read a credit card or debit card from a credit card reader
The way in which this requirement will be met by allowing the handheld to read a
credit card or debit card when a transaction is made. The way this will be verified is by
3-1
having a message box pop up with the information on the card after the card had been
swept.
•
Print to a printer using Bluetooth
This requirement will be met by printing the receipt after the transaction had been
completed.
•
Create a menu to be used by the handheld
A brief description of this requirement would be that the software would be able to
access the MySQL database and be able to access the tables in the database and be able
to add to the tables or be able to create new tables that the handheld would be able to
access as menus that patrons could order from.
•
Ability to rearrange the orders in the kitchen display
The main functionality of this would be able to allow cooks to move the orders around
so they could change the priority of the orders if they like.
•
For payment taking in a signature for a credit card or taking in a pin number for a
debit card and sending it to the central computer.
The way in which this requirement would work would be to take from the handheld the
signature from the patron or their pin number and then send it to the central computer
where it could be either stored or sent to the appropriate place that would need that
information so that the payment method could be verified.
•
Ability to resend and edit a current order if there is a mistake
This functionality would allow the patron to make a change to their order and then
allow the wait staff to resend the order to the kitchen where the cooks would get the
updated order on their screen.
3.2 Handheld Approach and Results
This section will go through the approach taken to complete the handheld subsystem and the
results that were obtained when the software was completed.
3.2.1 Resultant Design Constraints
The following section contains information regarding the design constraints for the handheld
device.
3-2
Bluetooth range
The maximum range that our blue tooth device can support is 300 feet.
Default menus
The software will contain default menus that each menu item must fall under.
These menus can be changed, but to do this changes in the code must be made.
Menu names and sizes
For this application each item name is limited to 100 characters, and each menu is
limited to 30 items. These numbers can be changed, but changes to the code must
be made.
GUI
Because of the limited programming knowledge of the group the GUI will not be
as visually pleasing as it could be.
Maximum number of orders
This must be limited in order for the handheld to be able to edit the orders.
3.2.2 Approaches Considered and One Used
The following technologies were considered for implementation in the final design:
3.2.2.1 Platform
A review of platforms on which to complete the Project were considered. The platforms
considered were using a Tablet PC to build a prototype, using a HDK, or using an
eBox-II kit.
Tablet PC
The Tablet PC had the distinct advantage of being a mobile device
compared to the other platforms. This would allow a prototype of the
handheld to be developed. However, developing the operating system for
the Tablet PC would be considerably more difficult than other platforms.
Also, integration of the many hardware components would be more
difficult because Tablet PC’s are not designed to maximize hardware
integration.
3-3
Hardware Development Kit (HDK)
The HDK is a platform specifically designed for development projects.
Toward this end, the kit allows easy integration of hardware components
and simplifies the development of the operator system. Disadvantages of
the HDK are the cost and the lack of mobility. However, designing the
handheld on a HDK would produce a workable prototype.
ICOP Technology eBox-II
The eBox-II is another development tool for design projects. The eBox-II
runs a compiled Windows CE operating system. The operating system
comes with many hardware drivers to ease integration. Also, these boxes
are readily available to the team. However, development on the eBox-II is
somewhat cumbersome, plagued with long compile times and a steep
learning curve.
Selected Approach
The platform chosen was the eBox-II because it would simplify the
development and the integration of the Project and is freely available from
the Department of Electrical and Computer Engineering.
3.2.2.2
Programming Language
The programming language to use for the handheld development was reviewed. The
languages considered were Visual C++ and Java.
Visual C++
Visual C++ language is based on C++ which is familiar to many members
of the WHOS team. Additional components assist in developing GUIs,
often without writing much additional code and is the native code that can
be used on the eBox-II.
Java
Java is another language that lends itself to development of GUIs. There
are a lot of libraries, scripts, and other example code available freely on
the internet.
Selected Approach
The language chosen for the handheld development was Visual C++. The
WHOS team is familiar with C++ and Java, but Visual C++ is native to
3-4
Windows CE and would require less development time on figuring out
how to get Java working in Windows CE.
3.2.2.3
Wireless Communications
The wireless communication method for the system was reviewed. The methods
considered were Bluetooth and WiFi.
Bluetooth
Bluetooth is a wireless communication method for low power, shortrange, secure communications. It allows quick and easy integration of
different devices. However, only a limited number of devices can
communicate simultaneously using Bluetooth.
WiFi
WiFi is a wireless communication method often employed for larger
networks. It allows farther ranges and can be more secure than Bluetooth,
but it consumes more power and is more difficult to integrate devices.
Selected Approach
The wireless communication method chosen was to use both WiFI and
Bluetooth. WiFi’s range and its ability to have simultaneous users
communicate at the same time will make communicating with the central
computer to be easier, while Bluetooth will allow easier integration of
multiple close range devices, such as a printer, and consumes less power.
3.2.3 Detailed Design (hardware)
The following sections contain detailed information regarding the features and design of the
handheld device used in the project.
3.2.3.1 ICOP Technology eBox-II
The ICOP eBox-II hardware development kit was chosen because of its capabilities to
run Microsoft Windows CE 5.0 and Microsoft Visual C++. The eBox-II combines an
x86 compatible processor, Ethernet networking capability, USB and other input/output
ports, and memory in to a compact case seen in the Figure 2.
3-5
Figure 2: ICOP Technology eBox-II[2]
The eBox-II has the following features and specifications:
•
Processor – 200 MHz Vortex86 system-on-chip (equivalent to the
SiS550);
•
Memory – 128 MB SDRAM;
•
Disk – EIDE interface;
•
Ethernet – 10/100 Mbps Realtek 8100B with PXE boot;
•
CRT/LCD video controller:
o
AGP Rev 2.0 Compliant
o
Shared system memory area up to 128 MB
o
Up to 1920 X 1440 resolution in “true color”
•
Other input/output ports:
o
USB X 3
o
PS/2 keyboard/mouse
o
Parallel
•
Real Time Clock with lithium battery backup;
•
BIOS – AMI BIOS;
•
Audio
o
AC97 V2.1 CODEC
o
Microphone, line in/out connections
3-6
•
Power Requirements – single voltage, +5Volts at 1.7 Amps, with ACPI
support;
•
Dimensions – 5.2 X 2.5 X 4.4 inches; and
•
Operating temperature – 20 to 60 degrees C[2].
The eBox were supplied free of charge by the Department of Electrical and Computer
Engineering at Iowa State University.
3.2.3.2 Credit Card Reader
A Magtek Mini USB credit card reader will be used for this Project. This particular
credit card reader was chosen because it has the following desired features and
specifications.
•
Powered by USB (No external power supply required);
•
Dual and three track capability;
•
Bi-directional read capability;
•
Reads encoded cards that meet ISO, ANSI and AAMVA standards;
•
Up to 1,000,000 passes with ISO-conforming cards;
•
Includes USB interface;
•
Card speed – 3 – 50 inches per second[3].
Figure 3: Magtek Mini USB credit card reader[3]
The credit card reader was purchase from theNerds.net at a cost of $53.70.
3-7
3.2.3.3 USB Wireless Network Card
A U.S. Robotics Wireless MAXg USB Adapter will be used in this project because it is
capable of connecting to the eBox-II via a USB port. The important specifications and
system requirements for this device are as follows:
•
System requirements
o
PC with Pentium processor or equivalent, 100 MHz or higher
o
USB 2.0 or USB 1.1 Port
o
Windows 2000 & XP
•
Specifications
o
Radio data rate – MAXg Technology for up to 125 Mbps
performance
o
Frequency – 2.400 ~ 2.462 GHz
o
Encryption – 802.11i (WPA2); Wi-Fi Protected Access (WPA),
TKIP; AES Encryption; 64/128-bit Wired Equivalent Privacy
(WEP) encryption; 802.1x authentication
o
Bus interface – USB 2.0[4]
Figure 4: U.S. Robotics Wireless MAXg USB Adapter[5]
3.2.3.4 Bluetooth Converter
A Bluetooth converter will be used in order to convert a standard printer into a wireless
printer. The Ambicom wireless Bluetooth printer kit (Model BT2-USB) was used for
out application because it has the following specifications:
•
Enables your computer and USB printer with Bluetooth wireless
technology and allows you to wirelessly send print jobs to a USB printer
•
Plug and play, easy to install
•
Range of up to 300 ft
The wireless printer kit was purchased from Ambicom Incorporated at a cost of $79.99.
A picture of the all of the components in the kit can be seen in the following figure. The
device with the USB port will plug in the handheld device, and will be responsible for
send all information to be printed. The other device will connect to the printer, and will
receive all information that needs to be printed.
3-8
Figure 5: Ambicom Wireless Bluetooth Printer Kit[6]
3.2.3.5 Printer
We will be using an hp deskjet960c printer for this application. This printer was chosen
because of its compatibility with the Bluetooth printer kit.
3.2.4 Detailed Design (software)
The following sections contain detailed information regarding the features and design of the
handheld device used in the project.
3.2.4.1 Inputs
The two types of inputs that the handheld device will use are inputs from the mouse and
inputs from the card reader.
Mouse clicks
The user will be able to select different menu options by clicking on them
with the mouse pointer.
Credit card reader
The credit card reader will be able to convert the information stored on the
magnetic strip of a credit card into data that the hand held device is
capable of understanding.
3.2.4.2 User Interfaces
The GUI for the handheld device will consist of two regions. The first region will
consist of the bottom half of the handheld’s display. This region is where all menu
options will be displayed. The final region is the display window across the top of the
handheld’s display. It will show all order information, the price of each item, and a
3-9
running tally of all items in the current order. The following figure shows GUI for the
handheld device
Figure 6: GUI for the handheld device
3.2.4.3 Modules
The handheld’s programming was broken down into smaller easier to handle functions.
The following is a break down of the functionality of each of these functions.
3.2.4.3.1
Update/Startup function
The purpose of this function is to send a message to the central server that the
handheld needs to be sent the menus. After receiving this is message the
central server will send the menus to the handheld were they will be stored in
one large character array.
3.2.4.3.2 Sorting function
The purpose of this function is to take the large array generated by the
update/start up function and sort it into the correct menus.
3.2.4.3.3 Create an order function
The purpose of this function is to create an order array that can be sent to the
kitchen. The first step in this process is to ask the user to enter an order
number. This number will be stored on the first line of the array. The next step
will as the user to enter the seat number for the order. After the seat number is
entered it will ask the user to select the top menu that the item is located in.
When a selection is made it will enter it into the order array, and then display
the form with the next set of selections. This processes will continue until all
selections for a single item have been made, at this point the program will
once again ask for a seat number. This process will continue until the send
3-10
option is selected, at which point the order will be sent to the central
computer, and the program will go to the item selection function. An example
of the order array can be seen in Figure 7.
[Handheld
55555\n
:Appetisers\nChicken Fingers\n
:Salad\nCeasar Salad\nBlue Cheese\n
:Bugers\nCheese\nFris\nRanch\n
:Entres\nShrimp\n
:Appetisers\nBreaded Mush\n
:Appetisers\nCheese Fris\n]
Figure 7: Example of an order array
3.2.4.3.4 Edit order module
The purpose of this function is to display a list of the current orders. The user
will then be able to select one the order to be edited. Once the order is selected
it will be loaded into the order array. After the order is entered into the array it
will be sent into the create order function.
3.2.4.3.5 Payment module
The purpose of the payment module is to provide point-of-sale support for the
handheld device. With the assistance of the magnetic stripe reader, the module
supports cash, check, credit, and debit card payments. The payment module
consists of a main menu and submenus for cash, check, credit and debit
payment methods. A menu to add a tip to the bill is a submenu of the credit
and debit menus.
3-11
Figure 8: Hierarchal view of the payment module.
Payment main menu
The payment main menu requires the total bill as input. Main menu
allows the user to access the different payment menus by clicking
on the appropriate button. To exit the payment module, the user
can click on the “Main Menu” button. In addition, this keeps a
running tally of the total payments and total tips entered in the
payment methods submenus.
Figure 9: Payment main menu
Cash submenu
3-12
The cash submenu requires the total bill as input. It allows the user
to enter in the amount of cash given using the onscreen numeric
keypad, and can calculate the change. Once finished, the user can
return to the payment main menu by pressing “done” if they are to
return the change or pressing “tip” if the change is to be converted
to a tip. The total payment and total tip is incremented
appropriately in the payment main menu. Pressing “cancel” will
return the user to the payment main menu without incrementing.
Figure 10: Cash submenu
Check submenu
The check submenu requires the total bill as input. It allows the
user to enter the value of a check given. Pressing “done” will
return to the payment main menu and increment the total payment
and the total tip appropriately. Pressing “cancel” will return the
user to the payment main menu without incrementing.
3-13
Figure 11: Check submenu
Credit submenu
The credit submenu requires the total bill as input. It allows the
user to enter a tip using the tip menu which will be discussed
below. Credit card information can be inputted by pressing the
credit box and then swiping the card using the magnetic stripe
reader. This information is then to be sent to the appropriate
resources to verify the credit card. If valid, this will be shown
using the indicator. The user can then use the mouse to sign their
name. Pressing “done” will return to the payment main menu and
increment the total payment and the total tip appropriately.
Pressing “cancel” will return the user to the payment main menu
without incrementing.
3-14
Figure 12: Credit submenu
Debit submenu
The debit submenu requires the total bill as input. It allows the user
to enter a tip using the tip menu which will be discussed below.
Debit card information can be inputted by pressing the debit box
and then swiping the card using the magnetic stripe reader. The
user’s pin is then entered using the onscreen numeric keypad. By
clicking the “enter” button, this information is sent to appropriate
resources to be verified. Pressing “done” will return to the payment
main menu and increment the total payment and the total tip
appropriately. Pressing “cancel” will return the user to the payment
main menu without incrementing.
3-15
Figure 13: Debit submenu
Tip submenu
The tip submenu allows the user to enter a tip using the onscreen
numeric keypad. The tip entered is returned to the previous menu.
Pressing “done” will return to the previous menu with the entered
tip. Pressing “cancel” will return the user to the payment main
menu without incrementing.
Figure 14: Tip submenu
3-16
3.2.4.3.6 Item selection function
The purpose of this function is to guide the user through the item selection
process. It will consist of a top form were the user will have the following
options:
•
Update Menu
•
Start New Order
•
Edit Order
•
Payment
If the update menu option is select the program will rerun the update/start up
and sorting functions, and then return back to the top form. If the start new
order option is selected the program will call the start new order function. It
will do the same things for the edit order and payment selections.
3.2.4.4 Communications
The handheld device and the central computer will communicate using a wireless
network. On the software level the two systems will communicate using sockets
3.2.4.4.1 Socket programming
Sockets are one of the easiest ways for two computers to communicate with
each other. When the handheld device (client) needs to communicate with the
central computer (server) it will create a socket. This socket will correspond to
a socket on the server with specific port identification. When the client socket
connects with server socket it creates a link between the two computers that
information can be passed along. After communications with the server are
finished the connection will be broken until the next time the client needs to
communicate with the server in which case the connection will be remade.
The sockets being used will be unidirectional, so if the central computer needs
to communicate with the handheld device the central computer will become
the client and the handheld will become the server. The same process will
occur just the roles will be reversed. The following figure shows a basic
diagram for how socket programming works.
3-17
Figure 15: Socket diagram[7]
3.2.4.4.2 Communication between handheld and central computer
The handheld device needs to have the capability to communicate with all of
the devices in the system. The most import of which is the central computer.
In order for the handheld to achieve its desired functionality the following
information must be sent/received to/from the correct location.
•
Send order information to the central computer
•
Send credit card verification to the central computer
•
Send order to kitchen display
•
Send bill to be printed to Bluetooth printer
•
Receive menu updates from the central computer
•
Receive credit card verification from central computer
•
Receive order status form kitchen
3.2.5 Implementation Process Description
Since this project 90 % programming it was implemented by building each small function
and then bringing them together to form the program. The functionality of the program was
split into 3 manageable functions the communication, the item selections, and making a
payment. Each function was developed by a different group member using Visual C++ .NET.
During each weekly meeting members of the group updated each other on the progress being
made, and helped each other with any problem. Once all of the functions were complete they
were combined to make the final program. The one problem in the implementation process
was that a non-GUI version was developed before the GUI version was developed. The nonGUI code could not really be converted into the GUI code so it would have been easier to
start with the GUI to begin with. The smaller hardware part of the project was primarily
given to one team member who tested it on the eBox-II. Once the program was finally
complete the program was transferred to the eBox-II.
3-18
3.2.6 End-Product Testing Description
Since this was mainly a software program most testing was done while building the program.
Every time a new form or button was added it was tested to make sure it functioned like it
was supposed to. The communications for the handheld was tested by stepping through the
program and making sure that the right information was being sent back and forth. When the
program was finished the group had people enter an order, and asked them to give us oral
feedback on what needed to be changed. Everyone that the system was tested on didn’t have
any trouble completing an order. The final test of the system was once the program was
ported onto the eBox-II. For the final test the group made a couple of sample orders and
verified that the correct changes were made to the database.
3.3 Kitchen Display Approach and Results
This section will go through the approach taken to complete the kitchen display subsystem and
the results that were obtained when the software was completed.
The project requirements for the kitchen display also include some design restraints, which
are described as the following:
Cost
The overall product budget is $150, but the goal is to keep the cost for the kitchen
display system as low as possible. That is why all the software being used is available
for free. An affordable desktop computer that is already available for testing will be
used, as well.
User interfaces
All user interfaces on the kitchen display must be presented in a simple, graphical
interface to allow for easy user navigation.
Minimal wireless communications
The kitchen display application must be designed to allow the overall system to work
with minimal communication between the two systems. The less the two systems
have to interact over the network, the lower the risk of communication errors. This
will also allow for more handheld systems to interact with the central computer
system at once.
3-19
3.3.2.1
The programming language to use for the WHOS development was reviewed. The
languages considered were Visual C++ and Java.
Visual C++
often without writing much additional code.
Java
the internet.
Selected Approach
The language chosen for the kitchen development was Java. The reason
for the choice was that the kitchen development team was very familiar
with Java.
3.3.2.2
Bluetooth
WiFi
3-20
Selected Approach
The wireless communication method chosen was to use was WiFI. WiFi’s
range and its ability to have simultaneous users communicate at the same
time will make communicating with the central computer to be easier.
The following is a detailed look at the design of the kitchen display system which will
process orders coming from the handheld device via the central server and display them on a
kitchen monitor.
3.3.3.1 Dell GX270
The Dell GX270 was chosen as the computer for the kitchen display system because it
is a multi-purpose desktop computer with the capabilities to run the applications that
will be created for it. It was also chosen because there are multiple of these machines
available to the team for testing purposes. In reality, the applications will be made to be
able to be installed on any modern desktop computer running on a Windows operation
system. A similar computer will be used for the kitchen display, though it will likely be
a laptop running an application on the Dell GX270 via a remote desktop connection.
The Dell GX270 has the following features and specifications that may apply to this
project:
•
Processor – Intel 865G chipset, Intel® Pentium® 4 processor with 800
MHz front side bus and Hyper-Threading support or 533 MHz front side
bus (depending on processor) and 512K L2 cache or Celeron® processor
with 400 MHz front side bus and 128K L2 cache
•
Memory – .4 DIMM slots (SF Chassis only has two); Non-ECC dual
channel shared2 DDR SDRAM system memory (333Mhz or 400Mhz)
up to 4GB on the SD and SMT chassis
•
Ethernet – One RJ45 Port
•
o
Eight USB 2.0
o
PS/2 keyboard/mouse
o
One Ethernet (RJ45)
•
Video Controller- Integrated Intel Extreme® Graphics 2
•
Power Supply – Small Form Factor 160W, Small Desktop 210W, Small
Mini-Tower 250W[8]
3-21
The following is an overview of the software design for the kitchen display application. The
application will be written in Java 5.0. A main application will be used to receive order
information and to call methods from two classes, one for processing and displaying orders
and one for sending messages to the central server.
3.3.4.1 Inputs
The application will use two types of input: User input via a keyboard and/or mouse
and information being directly received from the handheld via the central server.
3.3.4.1.1 User Input
If the user is at the kitchen-based computer, he/she will use a mouse and
keyboard to either prioritize orders that are on the screen or send a message to
the handheld confirming that the order has been completed.
3.3.4.1.2 Input via Wireless Communication
The kitchen application will receive and send information to and from the
central server. Using socket programming (Java 5.0 has classes designed for
networking, including the Socket() class) the application will be able to
receive and deliver information to/from the central server.
Networking in the Java Application
The application will serve as a client to the central server. The
kitchen will connect with the server and request order information.
This idea is shown in the following diagram:
Figure 16: Server and client communication[9]
The two will then be able to communicate by writing to or reading
from their sockets.
3-22
For the kitchen display, the GUI will consist of a simple series of boxes, each
containing an order. They will be displayed from left to right, top to bottom, in the
order they were received by the handheld. The image below is a screen shot from the
working GUI of the kitchen display. As you can see, each order is displayed, and a text
field at the bottom allows the user to enter them number of a completed order (1-6,
respective to the numbers above each order in the GUI). Upon pushing the “Order
Done” button, the order is removed, the update is displayed with a new order from the
queue, and a message is sent to the central computer confirming said order completion.
.
Figure 17: Working prototype design of kitchen display GUI
3.3.4.3 Application Flow
When the main kitchen display application starts up, it will establish connection with
the central server through the wireless router. It will request order information
continuously from the server and display these orders on the kitchen monitor. Upon
order completion, which is initiated by the user, a message will be sent to the server
notifying the completion of said order. This process will be going on continuously and
automatically as long as the application is running. The figure below shows in detail
these communications and exactly what functions the application will be performing.
3-23
Figure 18: Application flow of kitchen display
The approach to developing the kitchen-based system was designed to minimize the risk of
failure. With the success of the project in mind, the first and biggest priority for the kitchen
system was to achieve a very basic working version that incorporated all the most important
functions on the kitchen side. This included the ability for the software to appropriately
process and display orders in some fashion, as well as the functionality of user input to
confirm order completion and refresh the order queue.
Once this functionality was established in the software in a non-graphical version (text-based
display), the focus was moved to system integration. Communication with the central
computer server is essential since that is where all the orders come from in the first place.
Software being developed for communication purposes on the central computer side was
merely simplified and altered accordingly to the needs of the kitchen side of communications
and implemented into the text-based kitchen software.
Finally, with the system in basic functioning order, the final stage of the process, the
development of a user-friendly graphical interface, began. A very simple user interface was
created with ease-of-use in mind. Upon completion of the GUI, the kitchen-based system was
complete.
3-24
Because the kitchen-based system is entirely software based, testing was going on all
throughout the development process. As each required element of the system was added in,
every function and system component was carefully tested to insure that everything was still
working and that system integration was going as planned. Any problems encountered while
testing in the development stage were immediately looked into and fixed accordingly to
prevent the issue from becoming a bigger problem later on in the product development.
For testing with a user, the main thing that has to be tested is ease-of-use. Can a person new
to the kitchen system easily start the application and use it in a kitchen environment? Can
he/she understand the kitchen display itself? Can he/she understand how to confirm
completion of an order? These questions were to be answered and by answering yes to all of
these then it was known that the kitchen display worked properly.
3.4 Central Computer Approach and Results
The following addresses the design objectives, the functional requirements, and the design
restraints of the central computer system. It also looks at some technical and testing approach
considerations.
The Project requirements for the central computer system also include some design restraints,
which are described as the following:
Cost
The overall product budget is $150, but the goal is to keep the cost for the central
computer system as low as possible. That is why all the software being used is available
for free. An affordable desktop computer that is already available for testing will be
used, as well.
User interfaces
All user interfaces on the central computer system must be presented in a simple,
graphical interface to allow for easy user navigation.
Minimal wireless communications
The central system must be designed to allow the overall system to work with minimal
communication between the two systems. The less the two systems have to interact
over the network, the lower the risk of communication errors. This will also allow for
more handheld systems to interact with the central computer system at once.
3-25
3.4.2.1
The programming language to use for the central computer development was reviewed.
The languages considered were Visual C++ and Java.
Visual C++
often without writing much additional code.
Java
the internet.
Selected Approach
The language chosen for the creation of the central computer software was
Java because of its ease of use and the amount of documentation available
that can be used during the development of the software.
3.4.2.2
Bluetooth
WiFi
3-26
Selected Approach
The wireless communication method chosen was to use WiFI. WiFi’s
range and its ability to have simultaneous users communicate at the same
time will make communications easier due to the support for it in Java.
The following is a detailed look at the design of the central computer system which will
process packets coming from the handheld device and from the kitchen and take the packets
and update the restaurant’s item database and order history. The central computer system will
have software that will allow users to create, edit, and select menus and update information
on the wireless handheld device.
3.4.3.1 Dell GX270
The Dell GX270 was chosen as the computer for the central computer system because
it is a multi-purpose desktop computer with the capabilities to run the applications that
will be created for it. It was also chosen because there are multiple of these machines
available to the team for testing purposes. In reality, the applications will be made to be
able to be installed on any modern desktop computer running on a Windows operation
system. A similar computer will be used for the kitchen display, though it will likely be
a laptop running an application on the Dell GX270 via a remote desktop connection.
The Dell GX270 has the following features and specifications that may apply to this
project:
•
Processor – Intel 865G chipset, Intel® Pentium® 4 processor with 800
MHz front side bus and hyper-threading support or 533 MHz front side
bus (depending on processor) and 512K L2 cache or Celeron® processor
with 400 MHz front side bus and 128K L2 cache;
•
Memory – .4 DIMM slots (SF chassis only has two); non-ECC dual
channel shared2 DDR SDRAM system memory (333Mhz or 400Mhz)
up to 4GB on the SD and SMT chassis;
•
Ethernet – One RJ45 port;
•
o
Eight USB 2.0
o
PS/2 keyboard/mouse
o
One Ethernet (RJ45)
•
Video controller- Integrated Intel Extreme® Graphics 2;
3-27
•
Power supply – small form factor 160W, small desktop 210W, small
mini-tower 250W[8].
3.4.3.2 Linksys BEFW11S4 Wireless-B Broadband Router
The Linksys BEFW11S4 Wireless-B Broadband Router has been chosen as an
affordable and reliable router that will be able to handle the requirements of this
system. It has the following features and specifications that make it a choice wireless
router for this Project:
•
Standards: IEEE 802.3, IEEE 802.3u, IEEE 802.11b;
•
Protocol: CSMA/CD;
•
Channels: 11 channels (US, Canada), 13 channels (Europe) 14 channels
(Japan);
•
Ports:
o
Internet: one 10/1000 RJ-45 port for cable/DSL modem connection
o
LAN: four 10/100 RJ-45 switched ports
•
Speed: 10/100Mbps (half duplex) 20/200 (full duplex);
•
Cabling Type: UTP category 5 or better;
•
Dimensions: 7.31" x 6.16" x 1.88" (186 mm x 154 mm x 48 mm);
•
Unit weight: 16 oz. (0.45 kg);
•
Power: external, 5V DC, 2A;
•
Certifications: FCC, CE, WiFi, UPnP;
•
Operating temp: 0ºC to 40ºC (32ºF to 104ºF);
•
Storage temp: -20ºC to 70ºC (-4ºF to 158ºF);
•
Operating humidity: 10% to 85%, non-condensing; and
•
Storage humidity: 5% to 90%, non-condensing[10]
3-28
[10]
Figure 19: Linksys BEFW11S4 broadband router
The following is an overview of the software design for the applications running on the
central computer system. The applications will be written in Java 5.0, and MySQL will be
used for database support. One Java application will act like a server that will process
incoming data packets from the handheld or the kitchen display and the other will be used for
the creating/editing menus, view order history, and view/edit the inventory. MySQL
databases will store all inventory, order, menu, and pricing information. These databases will
be accessed from the Java application through MySQL client software for Java.
3.4.4.1 Inputs
The application on the central computer will use two types of input: user input via a
keyboard and/or mouse and information being directly received from the handheld via
wireless communication.
3.4.4.1.1 User Input
The user will have the capability to input information into the central
computer through some different applications. If the user is accessing the
database, he/she will be able to create/edit/choose menus, as well as
view/update the restaurant inventory and view/edit the order history.
3.4.4.1.2 Handheld Device Input via Wireless Communication
The application on the central system will receive and send information to and
from the handheld through a wireless router. Using socket programming (Java
5.0 has classes designed for networking, including the Socket() class) the
application will be able to receive and deliver information to/from the
handheld.
3.4.4.2 System Communication
MySQL is database software that is available free over the internet. It runs on
commands given by the user (much like a language such as Java or C++). The very
3-29
useful thing about MySQL for the purposes of the project is that there is client software
available that allows a program running in either Java or C++ to directly speak to the
databases and create, edit, and read from databases. This database system will work as
follows:
There will be a database for: the restaurant inventory; the order history; and each menu
created. Every time an order is placed by the handheld the central computer will
process the order and notify the kitchen that a new order has arrived. The central
computer can also take care of using the order information to update the inventory and
order history, which will minimize the number of communications between the
handheld and the central system over the network.
The application on the central computer system will have a few different uses, each
requiring its own graphical user interface.
For creating/editing menus, the GUI will consist of a series of options that the user can
select with a mouse or keyboard. These will allow the user to select from choosing a
menu, creating a menu, or editing a previously created menu as shown in Figure 20.
Figure 20: This GUI will allow a manager to create/edit menus
The next GUI that will be run on the central computer will be the server software that
will enable the user to start and stop the server whenever they want to. The way in
which the GUI looks is shown in Figure 21.
3-30
Figure 21: This GUI controls the server
3.4.4.4 Application Flow
The following section will go over the application flow of central computer server and
then the manager software.
3.4.4.4.1 Central Computer Server
When the central computer application starts up, it will start a simple server
that will wait for incoming data from the handheld or the kitchen. This is
basically waiting for an order to be placed. The program will then notify the
kitchen that a new order has been placed by forwarding the order to the
kitchen and then update the database with the order and then update the
counter in the menu that keeps track of the inventory of each item in the
restaurant. This process will be going on continuously and automatically as
long as the application is running.
A flow diagram of how incoming information into the server is processed is
shown in Figure 22. The class diagram interaction of what the algorithm for
the server is shown in Figure 23 and 24. This basically shows blueprint of
how the server was created to get it to do what it does.
3-31
Figure 22: Flow diagram of how an incoming packet of data is handled
Figure 23: Part of how the classes interact with each other in the central computer server software
3-32
Figure 24: The rest of how the classes interact with each other in the central computer server software
3.4.4.4.2 Manager Software
At the same time, the central computer will also be able to display the options
for the user, should they need to create/choose menus or view the database. If
the user chooses to create a menu, the program will display a form with
numerous blank entries, in which the user can type in main categories
(appetizers, salads, entrees, etc.). After pressing enter, the program will
display these categories. By clicking on one of these categories, another form
will be displayed, again showing blank entries into which the user can type in
sub-categories, and so on (for example, salad sub-categories would be various
different salads and the sub-categories of each of these may be possible salad
dressing options). After entering all desired items, the user can complete and
save the menu. This can be accessed from the “Choose Menu” section, which
will allow the user to edit the menu or select it to be sent to the handheld.
3-33
A description of the process to implement the central computer server software was to start
by first figuring out what were the functions that the server would need to do. After coming
up with a list of functions the classes were designed by coming up with the necessary
methods and attributes that each class would need to perform the necessary tasks that the
server would be required to do. Once this was completed then the next part was to develop a
simple multithreading server that once completed could have the functions added onto to it.
The first stage after getting a simple multithreading server running was to develop a GUI that
would interact with it to start and stop the server and to get information passed into it such as
the username, password, and IP addresses for the database; IP address for the kitchen; and
the number of handhelds that can simultaneously connect to the central server.
The next stage was to write the classes for receiving the data packets from the kitchen and
the handheld and sending them to the right places. Only then could it be possible to start
working on the design of the database. The reason for this was by waiting until now the
database could be matched to what needed to be sent and received from the handheld instead
of needing to meet a ridged requirement of the type of data to put into the database. Also, the
manipulation of the database is very easy and would require little effort to change to the
needs of the program. Once all of this was complete then the integration would begin
between the other subsystems of the Project.
As for any improvements to the process for developing the central computer and database
this method was a good process to follow for developing this subsystem of the Project.
Since this is mainly a proof of concept project the testing was done exclusively by the team.
The type of testing that the team did to this particular part of the Project was broken down
into to two parts. The first part was to test the subsystem on its own and make sure that it
could take in test packets and process them properly and the second part was with full
integration with the other subsystems of the Project.
The first part of the testing was done as a standalone program. The way in which it was
verified that the software worked properly was by using examples from Sun Microsystems of
two programs one of which was a server and another that was a client. These two programs
would help in verifying what type of data is sent out of the central computer software and
how it processes incoming data. To verify that the central computer software was processing
incoming data properly the program was stepped through to make sure that all of the data
was handled properly and the appropriate items in the database were updated properly or
queried properly to gain information from it. To make sure that the central computer software
sent the data out properly a complete example of making an order was tried, which used the
Sun Microsystems client program and sending an order to the central computer server and
then making sure that the Sun Microsystems server program was running and watching to see
3-34
what got sent from the central computer because the server program would show this. This
would be repeated for a “get menu” call from the handheld to the central computer and a
“done” command from the kitchen. After passing these tests then it was possible to begin the
next stage of testing which was for the full integration of all the subsystems together.
The testing of the full integration followed the same path as when the central computer was
tested as a standalone. This was done by going through and making sure that all of the
functions that were required for the whole Project worked properly. If there was an error the
offending software was stepped through to find the problem and then fixed. Once the
functionality was verified to work then it was determined that the whole system could work.
3.5 Project End Results
The end result of the handheld will be a working model centered around the eBox-II. The credit
card reader, Bluetooth printing kit, and wireless card will all be connected and will interacting
the handheld’s software running on the eBox-II. Due to the large cost of developing an actual
size product, the group was only able to model the system using item that were not of ideal sizes.
The result of the kitchen-based system is a system that meets all the basic requirements of the
project objectives that it is concerned with. A GUI-based program processes and displays the
orders on a monitor separate from the central computer. The program achieves basic
communication with the restaurant server. The system receives user input via the GUI to confirm
order completion. There are many areas in which this system could be improved if further
development were to take place, such as the appearance of the GUI and the overall efficiency of
the code, but nonetheless, the system has been developed up to the project’s standards.
As for the end results of the central computer the central computer will be able to redirect the
traffic from the handheld to the kitchen and vice-versa. As the data is being passed through the
central computer the database will be updated by updating the inventory, adding the orders and
updating the order status. Besides handling the data from the handheld and the kitchen the central
computer will also have software running on it that will be able to maintain the menus for the
restaurant by allowing a manager the ability to edit the menus.
3-35
4
Actual and Estimated Resources and Schedules
This section presents the estimated resources and schedules that will be used to estimated time
for each part of the phase of the Project and identify the cost of the Project. The first part will
present the estimated resources required for completing the Project. The second part will present
the schedule and how much time will be spent on each phase of the Project.
4.1 Actual and Estimated Resource Requirements
The actual and estimated resources requirements are broken down into three categories:
personnel and actual manhours for each task; equipment/material inventory list and associated
costs for each item; and the actual total cost of the Project.
4.1.1 Actual Resource Requirements
The actual personnel manhour effort for each of the tasks is shown below in Table 1. The
hours given in the table reflect the actual hours required to complete the project. The reason
for zero hours for Task 6 is that Task 6 is defined to be the amount of hours put into creating
end-user documentation. Since this project has no end-users and is a proof of concept project
there is no need to create end-user documentation.
Table 1: Actual Personnel Manhour Effort for Each Task
Personnel Name
Chris Ford
Sean McVeigh
Obioma Ohia
Nichole Taylor
Anthony VanSant
Total
Task 1
2.5
7.03
5.5
6.0
0.25
21.28
Task 2
4.0
2.43
16.0
15.0
1.25
38.68
Task 3
15.0
11.47
12.5
14.0
3.22
56.19
Task 4
80.0
88.52
40.5
41.0
52.63
302.65
Task 5
10.0
23.64
35.0
37.0
15.9
121.54
Task 6
0
0
0
0
0
0
Task 7
4.0
1.0
5.0
5.0
2.0
17.0
Task 8
50.0
49.03
32.5
44.0
13.13
188.66
Total
165.5
183.12
147.0
162.0
101.38
759.15
Task 1 – Problem Definition
Task 2 – Technology Considerations and Selections
Task 3 – End Product Design
Task 4 – End Product Prototype Implementation
Task 5 – End-Product Testing
Task 6 – End-Product Documentation
Task 7 – End-Product Demonstration
Task 8 – Project Reporting
The equipment/materials necessary to complete the Project and the associated costs are shown in
Table 2. The cost information has been gathered from the actual cost of the items purchased for
to complete the project. Most of the items located in the list are free because either the team
already owns the items or they can be easily obtained from the Department of Electrical and
4-1
Computer Engineering. The references of where the prices came from are all contained in
Section 7.
Table 2: Actual Required Resources
Item
Parts and Materials:
a. ICOP Technology eBox-II
b. Magtek Mini USB Credit Card Reader[11]
c. U.S. Robotics Wireless MAXg 802.11g USB 2.0
Adapter[12]
d. Bluetooth Printer Adapter[13]
e. Print Project Poster
f. Dell Dimension GX270
g. Linksys BEFW11S4 Wireless Router
Software:
a. Microsoft Windows CE .NET 5.0
b. Microsoft Visual Studio Pro 2005 w/MSDN Pro
Totals
Team Hours
Other Hours
Cost
0
0
0
0
0
0
Free
$53.70
$45.95
0
8
0
0
0
0
0
0
$79.99
$55.00
Free
Free
0
0
11
0
0
0
Free
Free
$234.64
The total cost of the Project includes both the cost for the equipment/materials and the labor.
Labor costs were calculated by assuming that the team personnel would receive $10.50 per
hour for working on the Project. The cost per hour was multiplied by the total hours each
person is estimated to work to get the total cost for one team member to work on the Project.
The $10.50 per hour comes from an estimate of what a recently graduated engineer (does not
include benefits markup) would make per hour and what an intern would make on an
internship. The actual cost for the Project is shown in Table 3.
4-2
Table 3: Actual Project Costs
Item
a. ICOP Technology eBox-II
b. Magtek Mini USB Credit Card Reader
c. U.S. Robotics Wireless MAXg 802.11g USB
2.0 Adapter
d. Bluetooth Printer Adapter
e. Print Project Poster
f. Dell Dimension GX270
g. Linksys BEFW11S4 Wireless Router
W/O Labor
With Labor
Free
$53.70
$45.95
Free
$53.70
$45.95
Subtotal
$79.99
$55.00
Free
Free
$234.64
$79.99
$55.00
Free
Free
$234.64
Subtotal
Free
Free
Free
Free
Free
Free
$234.64
$1,737.75
$1,922.76
$1,543.50
$1,701.00
$1,064.49
$7,969.50
$8,204.14
Software:
b. Microsoft Visual Studio Pro w/MSDN Pro
Labor at $10.50 per hour:
a. Ford, Chris
b. McVeigh, Sean
c. Ohia, Obioma
d. Taylor, Nichole
e. VanSant, Anthony
Subtotal
Total
4.1.2 Estimated Resource Requirement
The following section is provided to show the original and revised estimates for the project.
The first item to go over is Table 4 that shows the tasks required to complete the Project and
the corresponding estimated manhours to complete each task. The hours given for each team
member closely related to their expertise in programming and how much responsibility they
will assume for a given
Table 4: Revised Estimated Personnel Manhour Effort Requirements for Each Task
Personnel Name
Chris Ford
Sean McVeigh
Obioma Ohia
Nichole Taylor
Anthony VanSant
Total
Task 1
6.50
7.00
5.50
5.75
5.25
30.0
Task 2
14.0
19.0
13.0
11.5
12.5
70.0
Task 3
21.0
14.0
15.5
16.0
13.5
80.0
Task 4
40.0
49.0
48.0
43.0
45.0
225.0
4-3
Task 5
44.0
36.0
38.0
46.0
36.0
200.0
Task 6
11.5
14.0
9.5
12.0
13.0
60.0
Task 7
4.6
4.2
5.0
5.0
5.2
24.0
Task 8
42.0
56.0
35.0
45.0
38.0
216.0
Total
183.60
199.20
169.50
184.25
168.45
905.00
task. Table 4 does not show any change from the original manhours given in the Project Plan.
The reason for this is that it was still believed that these estimations were still the best
estimation of how the project will to be completed. The original manhours from the Project
Plan is shown below in Table 5.
Table 5: Original Estimated Personnel Manhour Effort Requirements for Each Task
Personnel Name
Chris Ford
Sean McVeigh
Obioma Ohia
Nichole Taylor
Anthony VanSant
Total
Task 1
6.50
7.00
5.50
5.75
5.25
30.0
Task 2
14.0
19.0
13.0
11.5
12.5
70.0
Task 3
21.0
14.0
15.5
16.0
13.5
80.0
Task 4
40.0
49.0
48.0
43.0
45.0
225.0
Task 5
44.0
36.0
38.0
46.0
36.0
200.0
Task 6
11.5
14.0
9.5
12.0
13.0
60.0
Task 7
4.6
4.2
5.0
5.0
5.2
24.0
Task 8
42.0
56.0
35.0
45.0
38.0
216.0
Total
183.60
199.20
169.50
184.25
168.45
905.00
The equipment/materials necessary to complete the Project and the associated costs are
shown in Table 6. The cost information for each item comes from going to supply companies
on the internet that provided these items. Most of the items located in the list are free because
either the team already owns the items or they can be easily obtained from the Department of
Electrical and Computer Engineering. In the instance of the HDK the cost is an estimate for
now. It was hoped that this item was to be donated by Intel in which case the cost would have
been nothing. Showing the cost provides a good cost estimate of how much something like
this costs and how it affects the budget. The references of where the prices came from are all
contained in Section 7.
4-4
Table 6: Revised Required Resources
Item
h. Hardware Development Kit Assembly[14]
i. ICOP Technology eBox-II
j. Magtek Mini USB Credit Card Reader[15]
k. NETGEAR 802.11B Wireless USB Adapter
l. Bluetooth Printer Adapter[16]
m. Miscellaneous Parts
n. Print Project Poster
o. Dell Dimension GX270
p. Linksys BEFW11S4 Wireless Router
Software:
c. Microsoft Windows CE .NET 5.0
d. Microsoft Visual Studio Pro 2005 w/MSDN Pro
Totals
Team Hours
Other Hours
Cost
3
0
0
0
0
0
8
0
0
0
0
0
0
0
0
0
0
0
~$1,399.00
Free
$67.20
Free
$54.00
$20.00
$50.00
Free
Free
0
0
11
0
0
0
Free
Free
$1,590.20
To better understand the origin of the items in Table 6 it is necessary to review the original
plan equipment/material list. The original plan equipment/material list is presented in Table 7
and shows the costs for each of the items that were needed for the Project. It was believed
initially that all of the items could be obtained through donations and that the estimated costs
were developed to give an idea of how much it would cost to get all of the items necessary to
complete the Project. Since the Project Plan was first presented, we have determined that the
ideal equipment/material to complete the Project will not be realized and we have revised the
required equipment/material resources in Table 6. It is necessary to present the original items
to show what it will take to complete the Project under ideal conditions.
Table 7: Original Required Resources
Item
a. Hardware Development Kit Assembly[14]
b. Card Swipe[15]
c. Wireless 802.11g PCMCIA Card[17]
d. Bluetooth Printer[18]
e. Bluetooth Adapter[19]
f. Miscellaneous Parts
g. Print Project Poster
h. Dell Dimension B110[20]
i. Linksys WRT54G Wireless Router[21]
Software:
a. Microsoft Windows CE .NET 4.2[22]
b. Microsoft Visual Studio Pro 2005 w/MSDN Pro[23]
Totals
Team Hours
Other Hours
Cost
3
0
0
0
0
0
8
0
0
0
0
0
0
0
0
0
0
0
$1,399
$75.80
$59.99
$725.00
$30.00
$20.00
$50.00
$569.00
$49.99
0
0
11
0
0
0
$995.00
$644.00
$4,617.78
The total cost of the Project includes both the cost for the equipment/materials and the labor.
Labor costs were calculated by assuming that the team personnel would receive $10.50 per
hour for working on the Project. The cost per hour was multiplied by the total hours each
person is estimated to work to get the total cost for one team member to work on the Project.
4-5
The $10.50 per hour comes from an estimate of what a recently graduated engineer (does not
include benefits markup) would make per hour and what an intern would make on an
internship. The cost estimate for the Project is shown in Table 8. This information is a
revised estimated project cost from the original plan. The change is due to the
equipment/materials needed to complete the Project has changed, thus the estimated project
costs were updated to reflect these changes and also the labor cost has decreased due to new
estimates in labor.
Table 8: Revised Estimated Project Costs
Item
h. Hardware Development Kit Assembly
i. ICOP Technology eBox-II
j. Magtek Mini USB Credit Card Reader
k. NETGEAR 802.11B Wireless USB Adapter
l. Bluetooth Printer Adapter
m. Miscellaneous Parts
n. Print Project Poster
o. Dell Dimension GX270
p. Linksys BEFW11S4 Wireless Router
W/O Labor
With Labor
Subtotal
~$1,399.00
Free
$67.20
Free
$54.00
$20.00
$50.00
Free
Free
$1,590.20
~$1,399.00
Free
$67.20
Free
$54.00
$20.00
$50.00
Free
Free
$1,590.20
Subtotal
Free
Free
Free
Free
Free
Free
$1,590.20
$1,927.80
$2,091.60
$1,779.75
$1,934.63
$1,768.73
$9,502.51
$11,092.71
Software:
c. Microsoft Windows CE .NET 5.0
d. Microsoft Visual Studio Pro w/MSDN Pro
f. Ford, Chris
g. McVeigh, Sean
h. Ohia, Obioma
i. Taylor, Nichole
j. VanSant, Anthony
Subtotal
Total
Table 9 is presented for purposes of showing the ideal case for completing the Project. It was
unrealistic to think that all the equipment/material could be obtained through donations and
that the least ideal case is the realistic way of completing the project.
4-6
Table 9: Original Estimated Project Costs
Item
a. Hardware Development Kit
b. Card Swipe
c. Wireless 802.11b PCMCIA Card
d. Bluetooth Printer
e. Bluetooth Adapter
f. Miscellaneous Parts
g. Project Poster
h. Dell Dimension B110
i. Linksys WRT54G Wireless Router
W/O Labor
With Labor
Subtotal
$1,399
$75.80
$59.99
$725.00
$30.00
$20.00
$50.00
$569.00
$49.99
$2,978.78
$1,399
$75.80
$59.99
$725.00
$30.00
$20.00
$50.00
$569.00
$49.99
$2,978.78
Subtotal
$995.00
$644.00
$1,639.00
$995.00
$644.00
$1,639.00
$4,617.78
$4,590.00
$4,980.00
$4,237.50
$4,606.25
$4,211.25
$22,625.00
$27,242.28
Software:
b. Microsoft Visual Studio Pro w/MSDN Pro
a. Ford, Chris
b. McVeigh, Sean
c. Ohia, Obioma
d. Taylor, Nichole
e. VanSant, Anthony
Subtotal
Total
4.2 Actual and Estimated Schedule Requirements
The estimated schedule has two components: task start and finish schedule; project deliverables
schedule. The actual schedule for when a task begins and ends in shown in Figure 16, which is
on the following page and the revised original schedule is shown in Figure 17 followed by the
original schedule Figure 18. The actual deliverables schedule is shown in Figure 19 followed by
the revised deliverables schedule in Figure 20 and the original deliverables schedule shown in
Figure 21.
4-7
4-8
Constraint Identification
4
Technology Research
Technology Selection
8
9
Test Development
Actual Testing
18
19
Client Demonstration
Industrial Review Panel Demonstration
23
24
Unbound Project Plan
Bound Project Plan
Unbound Design Report
Bound Design Report
Project Poster
Unbound Final Report
Bound Final Report
Weekly Email Reporting
26
27
28
29
30
31
32
33
Project Reporting
Faculty Advisor(s) Demonstration
22
25
Demonstration Planning
21
End-Product Demonstration
Test Planning
17
20
End-Product Testing
Implementation of Prototype
15
16
Identification of Limitations
14
Prototype Implem entation
Design Process
12
13
Identification of Requirements
11
End-Product Design
Identification of Criteria
7
10
Identification of Technologies
6
Technology Considerations
End User(s) and End Use(s)
5
Project Definition Completion
3
Project Definition
1
2
Task Name
ID
Fri 10/6/06
Sat 9/16/06
Mon 9/11/06
Tue 4/24/07
Wed 4/18/07
Wed 4/11/07
Wed 4/4/07
Wed 4/4/07
Mon 1/29/07
Tue 1/23/07
Tue 1/16/07
Tue 1/16/07
Fri 10/20/06
Fri 10/13/06
Fri 10/13/06
Fri 10/13/06
Fri 10/6/06
Fri 10/6/06
Fri 10/20/06
Mon 10/2/06
Mon 9/25/06
Fri 9/8/06
Fri 9/8/06
Wed 9/13/06
Fri 9/15/06
Tue 8/29/06
Tue 8/29/06
Start
169 days
14 days
12 days
11 days
8 days
Mon 9/11/06
Fri 4/13/07
Fri 3/16/07
Wed 2/14/07
Mon 12/4/06
23 days Wed 10/11/06
3 days
5 days
172 days
1 day
1 day
1 day
5 days
15 days
60 days
5 days
5 days
70 days
132 days
3 days
137 days
98 days
5 days
103 days
3 days
14 days
5 days
12 days
34 days
5 days
1 day
13 days
16 days
Duration
Oct 8, '06
W
T
F
Oct 29, '06
S
S
M
Nov 19, '06
T
W
Dec 10, '06
T
F
S
Figure 25: Actual Project Schedule
Aug 27, '06
Sep 17, '06
F
S
S
M
T
Dec 31, '06
S
M
T
Jan 21, '07
W
T
Feb 11, '07
Mar 4, '07
F
S
S
M
T
Mar 25, '07
W
T
F
A pr 15, '0 7
M
S
S
M
4-9
Technology Research
8
9
23
29
30
Bound Project Plan
Bound Design Report
Project Poster
Bound Final Report
32
33
34
35
36
37
38
39
Project Reporting
28
31
27
Maintence Documentation
Test Documentation
End-Product Documentation
22
Result Evaluation
21
26
Actual Testing
20
End-user Documentation
Test Development
19
25
Test Planning
18
24
End-Product Testing
17
14
Document Design
13
16
Design Process
12
15
11
End-Product Design
7
10
6
4
5
3
Project Definition
1
2
Task Name
ID
27
Sep '06
3
10
17
24
15
22
Nov '06
29
5
12
19
26
Dec '06
3
10
17
24
Jan '0 7
31
7
Figure 26: Revised Estimated Project Schedule
Oct '06
1
8
14
21
Feb '07
28
4
11
18
Mar '07
25
4
11
18
25
Apr '0 7
1
8
15
22
May
29
4-10
Technology Research
8
9
23
29
30
Bound Project Plan
Bound Design Report
Project Poster
Bound Final Report
32
33
34
35
36
37
38
39
Project Reporting
28
31
27
Maintence Documentation
Test Documentation
End-Product Documentation
22
Result Evaluation
21
26
Actual Testing
20
End-user Documentation
Test Development
19
25
Test Planning
18
24
End-Product Testing
17
14
Document Design
13
16
Design Process
12
15
11
End-Product Design
7
10
6
4
5
3
Project Definition
1
2
Task Name
ID
27
Sep '06
3
10
17
24
15
22
Nov '06
29
5
12
19
26
Dec '06
3
10
17
24
Jan '0 7
31
7
Figure 27: Original Estimated Project Schedule
Oct '06
1
8
14
21
Feb '07
28
4
11
18
Mar '07
25
4
11
18
25
Apr '0 7
1
8
15
22
May
29
4-11
Bound Design Report
Project Poster
Bound Final Report
Class Presentation
Industrial Review Presentation
5
6
7
8
9
10
11
Bound Project Plan
4
3
Project Reporting
1
2
Task Name
ID
27, '06
S
S
9/22
Sep 17, '06
M
T
10/10
Oct 8, '06
W
T
F
Nov 19, '06
T
W
11/10
M
12/13
Dec 10, '06
T
F
S
Dec 31, '06
S
M
Figure 28: Actual Deliverables Schedule
Oct 29, '06
S
S
T
Jan 21, '0 7
W
T
Feb 11, '07
F
S
S
2/27
Mar 4, '07
M
T
3/27
3/30
Mar 25, '07
W
T
F
4/24
Apr 15, '0 7
S
S
M
5/2
May 6, '0
T
4-12
Bound Project Plan
Bound Design Report
Project Poster
Bound Final Report
Class Presentation
3
4
5
6
7
8
9
10
11
Project Reporting
1
2
Task Name
ID
27
Sep '06
3
10
17
9/22
24
Oct '06
1
8
22
Nov '06
29
5
11/10
12
19
26
Dec '06
3
10
12/13
17
24
Jan '0 7
31
7
Figure 29: Revised Deliverables Schedule
10/10
15
14
21
Feb '07
28
4
11
18
2/27
Mar '07
25
4
11
18
25
3/30
A pr '0 7
1
8
4/10
15
22
4/25
5
May
29
4-13
Bound Project Plan
Bound Design Report
Project Poster
Bound Final Report
Class Presentation
3
4
5
6
7
8
9
10
11
Project Reporting
1
2
Task Name
ID
27
Sep '06
3
10
17
9/22
24
Oct '06
1
8
22
Nov '06
29
5
11/10
12
19
26
Dec '06
3
10
12/13
17
24
Jan '0 7
31
7
Figure 30: Original Deliverables Schedule
10/10
15
14
21
Feb '07
28
4
11
18
2/27
Mar '07
25
4
11
18
25
3/30
A pr '0 7
1
8
4/10
15
22
4/25
5
May
29
5
Project Evaluation
The current progress of the project is that it has been partially met. The reason for this is that at
the time of printing the project still lacked full integration of the three major subsystems which
are the handheld, central computer and kitchen. The reason that it can be considered partially met
is that the individual subsystems can stand on their own and are fully operational. For this project
to be met all three parts must be proven to work together and the handheld software needs to be
on the eBox-II, which is another thing that has not been met quite yet.
For the project to be fully met all of the subsystems must work together and this was to be
proven by checking all of the functionalities of the handheld and the kitchen. The functionalities
to be checked on the handheld would be the ability to get the menu from the database through the
central computer, send an order and complete a transaction. As for the kitchen the only thing to
test would be to make sure that an order sent from the handheld was correctly displayed on the
kitchen display and that when the order was ready for pickup the done button sent a message to
the handheld notifying it that the order was done and ready for pickup. By checking all of these
functionalities it would then be known that the project had been fully met.
5-1
6
Commercialization
Since the project is a proof of concept instead of a final product it will not be able to be marketed
directly. If a handheld device was produced that had the same functionality as the setup
involving the eBox-II there would be a very good market for this program. This product could be
marketed to any restaurant in the United States. As with most products the selling price would be
made up from two components, recurring cost (such as the cost to manufacture the handhelds)
and non-recurring cost (such as cost of developing the software). Assuming that this product
could be sold on a large scale (more than 10,000 total units) the non-recurring cost would be less
than $1.00 per device. Each handheld would more than likely be produced for at most $300. This
estimate is base on the cost of the top of the line palm pilot (including the supplier markup).
This makes a total cost of $301.00 per handheld. This product should sell for the range of $450 $600 corresponding to 50% – 100% mark up. At this price the system could be sold to an
average size restaurant (about 30 - 40 table) for a price of $3,600 - $4,800. This price would not
include the cost of the central computer, or the kitchen display since they do not have to be as
application specific as the handheld device.
6-1
7
Recommendations for Additional Work
The following is a list of recommendations for additional work that could be done on this
project.
Increased functionality
In order for the system to be more marketable a manager function that allows someone
complete control over all the orders must be implemented.
A prototype of the handheld
If a prototype of the handheld device was made this product would be to be marketed to
local business, and the revenue generated could fund other senior design projects.
7-1
8
Lessons Learned
This project taught us a lot about what is involved in bringing a project from a conceptual idea to
a final product. The group was very good at communicating with each other over the various
aspects of the project. Especially, when someone needed help to finish something on time, or
didn’t understand how to implement something. The thing that gave our group the most problem
was developing a GUI for our application. Most of the group members had very limited
programming knowledge and what they did know was primarily used in text based application.
The biggest problem is also what taught us the most; because we did not know that much about
developing GUIs the group was forced to learn it as we were developing the project. While
completing this project the group also increased some of its non-technical skill. The most
important of which was documenting information regarding the project. At the beginning of the
first semester not a lot records of references or research that was conducted was kept, which
made it very hard to write the reports since the group had to go back and find all of the material
again. By the end of the project this was no longer a problem, if any thing was even a little
important to the project it was recorded incase it needed to be used in the future. The only thing
that would have been changed if this project was to be done over again would be that the group
would have skipped developing a text based version and started out with the GUI version.
8-1
9
Risk and Risk Management
The possibility of losing team members is of notable concern, as illness, family emergencies, and
other causes can create conflicts. There is also a concern with a member of the team not
contributing sufficiently to the project. To best deal with said risks, there will be an emphasis on
communication. Regular meetings will be held to discuss individual progress. In regards to the
risk of failure caused by any technical issues that may arise, the members of the project team and
faculty have much of the background knowledge needed to complete the project. In order to
make the project as technically successful as possible, a list of priorities has been developed. The
first priority, for example, is to establish wireless communications between the eBox-II and the
kitchen-based system. This is followed by other priorities and sub-priorities. This approach will
insure that the most necessary functions will be developed successfully, with other more obscure
functions added on only after the higher priority items have been completed. If the selected
software would not be able to be used to complete the application a new version or different
software package must be used.
The only major problem the group faced was it lack of technical knowledge. This problem was
solved by communications with the faculty advisor, and by looking for possible solutions on the
internet. The only unanticipated problem was that it was not possible to implement the program
using the version of Microsoft Visual Studio on all of the campus computers. This problem was
solved by downloading the newest version from the Iowa State University website, and coding
everything on our person computers. This made it so a section regarding software use had to be
added to the risk management plan.
9-1
10
Project Team Information
The following information identifies who the client is for the Project and the contact information
for all of the team members, the faculty advisor and technical advisor that will be used in the
completion of the Project.
Client
Senior Design
Faculty Advisor
Dr. Manimaran Govindarasu
3219 Coover Hall
Ames, IA 50011-3060
Technical Advisor
Dr. Randall Geiger
351 Durham Hall
Ames, IA 50011-2252
Office Phone: (515) 294-9175
Fax: (515) 294-8432
Email: [email protected]
Office Phone: (515) 294-7745
Fax: (515) 294-1152
Project Team
Christopher Ford
Electrical Engineering
15411 Horton Avenue
Urbandale, IA
Home Phone: (515) 975-7088
Nichole Taylor
1400 Coconino Rd #213
Ames, IA 50014
Home Phone: (563) 505-4735
Sean McVeigh (Project Manager)
420 South 4th Street #11
Ames, IA 50010
Home Phone: (515) 233-3360
Anthony Vansant
123 Sheldon Ave #13
Ames, IA 50014
Home Phone: (515) 708-1291
Obioma Ohia
103 Stanton Ave #25
Ames, IA 50014
Home Phone: (515) 710-9177
10-1
11
Summary
Although this device will not be a marketable product, the concept of the product will be proven.
A restaurant waiter will have a wireless handheld device that will allow the waiter to place
orders, receive payments and print receipts all with one device. Specifically, the device will
incorporate a magnetic card swipe and a Bluetooth printer which will allow restaurants to
increase the efficiency of the restaurants order/billing and inventory system and reduce the
amount of paper used. Restaurants may find the idea of this device to be an attractive option,
therefore such a system has a potential for success in commercial applications.
11-1
12
References
[1]
"Bluetooth Frequently Asked Questions Components." MobileInfo.Com. MobileInfo. 18 Sept.
2006 <http://www.mobileinfo.com/Bluetooth/FAQ.htm>.
[2]
"Low-Cost Platform Supports Windows CE Contest." WindowsForDevices.com. 6 Nov. 2006
<http://www.windowsfordevices.com/news/NS2983372021.html>.
[3]
"Card Reading > Magstripe > Swipe > Mini." Magtek. 6 Nov. 2006
<http://www.magtek.com/products/card_reading/magstripe/swipe/mini/specs_usb.asp>.
[4]
"USRobotics Wireless: USR5421 USRobotics Wireless MAXg USB Adapter - Specs."
USRobotics. 28 Mar. 2007 <http://www.usr.com/products/networking/wirelessproduct.asp?type=specs&sku=USR5421>.
[5]
"USRobotics Product Images - USR5421 Wireless MAXg USB Adapter." USRobotics. 28
Mar. 2007 <http://www.usr.com/images/products/product.asp?prod=5421>.
[6]
"AmbiCom, Inc. - WBP-KIT Wireless Bluetooth Printer
<http://www.ambicom.com/products/air2net/wbpkit.html>.
[7]
"Socket
Programming."
Troubleshooters.Com.
<http://www.troubleshooters.com/codecorn/sockets/>.
Kit."
6
28
Nov.
Mar.
2007
2006
[8]
"gx270-Spec.Pdf." 6 Nov. 2006 <http://www.scs.fsu.edu/classroom/Dell/gx270-spec.pdf>.
[9]
"What is a Socket? (the Java Tutorials > Custom Networking > All About Sockets)." Sun
Microsystems.
6
Nov.
2006
<http://java.sun.com/docs/books/tutorial/networking/sockets/definition.html>.
[10]
"Linksys.com - Products/Wireless/Basic Networking/Broadband Routers/WirelessB/BEFW11S4."
Linksys.
6
Nov.
2006
<http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLa
yout&cid=1115416826220&packedargs=site%3DUS&pagename=Linksys%2FCommon
%2FVisitorWrapper>.
[11]
"MAGTEK - 21040102 - MINI USB SWIPE RDR MSR TRACK 1/2/3 HID COMPATIBLE
TheNerds.Net.
28
Mar.
2007
BLK/6FT
CABL."
<http://www.thenerds.net/index.php?page=productpage&pn=21040102>.
[12]
"Wireless MAXg 802.11g USB 2.0 Adapter At Academic Superstore." Academic Superstore.
28
Mar.
2007
<http://www.academicsuperstore.com/market/marketdisp.html?PartNo=737402>.
12-1
[13]
"Wireless
Bluetooth
Printer
Kit."
online.stores.yahoo.net/wiblprkit.html>.
28
Mar.
2007
<http://ambicom-
[14]
"PXA270 - PhyCORE-XScale/PXA270 Rapid Development Kit." 9 Oct. 2006
<http://www.phytec.com/products/rdk/ARM-XScale/phyCORE-XScale-PXA270.html>.
[15]
"Tracks 1, 2, & 3 Credit Card Reader." BarcodesInc. Barcodes Inc. 7 Sept. 2006
<http://barcodesinc.com/cats/credit-card-readers/1-2-3.htm>.
[16]
"Bluetooth Print Adapter Kit for USB Prints (IOGEAR-GBP201KIT)." PriceGrabber.Com. 7
Nov.
2006
<http://www.pricegrabber.com/p__IOGEAR_Bluetooth_Print_Adapter_Kit_for_USB_Pr
inters,__7411747>.
[17]
"NetGear WG511 54 Mbps WL PC Card (NetGeat - WG511)." PriceGrabber.Com. 9 Oct.
2006 <http://amdmb.pricegrabber.com/search_getprod.php/masterid=691890>.
[18]
"Auto ID Solutions by Integrated Labeling Systems, Inc." 11 Sept. 2006
<http://www.productcatalog.com/preview_item.cfm?line=Intermec%20PB20%20Direct%20Thermal%20Port
able%20Printer&page_name=vendor&manu=Intermec&item=&BAToken=ils>.
[19]
"Network Adapter Bluetooth USB Wireless Networking." PriceGrabber.Com. 9 Oct. 2006
<http://amdmb.pricegrabber.com/search_attrib.php/page_id=371/popup2%5B%5D=40:1
012/popup1%5B%5D=50:227/popup3%5B%5D=10:264>.
[20]
"Basic
Desktops."
Dell.
Dell
Inc.
20
Sept.
2006
<http://www.dell.com/content/products/features.aspx/featured_basdt?c=us&cs=19&l=en
&s=dhs>.
[21]
"Linksys WRT54G Wireless G-Router." Amazon.Com. Amazon. 20 Sept. 2006
<http://www.amazon.com/Linksys-WRT54G-Wireless-G-Router/dp/B00007KDVI>.
[22]
"BSQARE
Store."
BSQUARE.
BSQUARE
Corporation.
21
Sep
2006
<http://store.bsquare.com/catalog/index.cfm?fuseaction=product&theParentId=142&id=2
469>.
[23]
"Visual Studio 2005 Professional Edition w/MSDN Pro." Pricegrabber.com. Price Grabber.
21 Sep 2006 <http://amdmb.pricegrabber.com/search_getprod.php/masterid=13954436>.
12-2

Final Report - Senior Design

Transcription

Similar documents

July, 1993 - Stumpf Welding Supplies

wireless pre-compliance testing

The Brimi Cuisine Education Office is a joint effort

liberty wireless

WSB-NLU Accommodation

Multi-Sync BTH-300 to Radio and/or Mobile

Kitchens with the Puustelli group - Piri-Piri

hand held spray - Water Tight Canberra

Exquisite Cocina

Yadtel Security - local service areas