05508 – EE PLASMON Multimedia Kiosk

Team:

Tracie Johnson

Chris Brazener

Sponsor/Mentor:

Dr. Robert Bowman

Coordinators:

Paul Garsin

Dr. Daniel Phillips

Introduction:

The PLASMON system (Project #05508) is a multi-media kiosk for the Electrical Engineering Department. The kiosk will serve as a center for up-to-date information as well as a form of entertainment. The intended target audience consists of both current and prospective students.

Needs Assessment:

The PLASMON Multimedia Kiosk resides outside of the department of Electrical Engineering in the Kate Gleason College of Engineering at RIT. Prior to its inception as a senior design project, the kiosk allowed the user to view a PowerPoint presentation, which was played repeatedly by a personal computer (PC). The subject matter of the slide show consisted of information relative to the department of Electrical Engineering, its staff, faculty, and students.

The existing kiosk is comprised of a widescreen flat-panel monitor, a Pentium III PC, an audio amplifier, a pair of loudspeakers, an interface board, and a capacitance-sensing touch plate.. The initial setup of the PLASMON was intended to facilitate additional hardware for interactivity. The department purchased a capacitive touch panel for use with the system, as well as interface circuitry and harnessing for connection of the panel to the parallel port of the computer.

The PLASMON project entailed the creation of design modifications in an effort to make the kiosk presentation more interactive and informative. Instead of repeatedly playing a slide show, the new kiosk facilitates interaction with the user, allowing the user to extract information efficiently. The PLASMON also provides a degree of entertainment while supplying information about the department.

The end realization of the PLASMON system is a completely interactive and informative kiosk that incorporates documents, calendars, photos, audio, and video streams that can be controlled by the user. Since the majority of the users of the kiosk will be people with an interest in the EE field or the department, the quality of the overall presentation will be of utmost importance. A strong presentation will allow the kiosk to attract users and encourage them to learn about the department.

Specifications:

The PLASMON multimedia presentation shall be able to provide the user with the following content:

·  Academic Flowcharts for each EE Degree Program

·  Event Calendars and Department Information

·  Photo Albums of Faculty/Staff /Students

·  Information about the PLASMON itself

·  A Virtual Tour of the Electrical Engineering Department

·  Provide an entertaining, interactive experience

The PLASMON System shall offer the following to the Operator/Administrator:

·  Simple and Efficient Updating of Presentation via common Microsoft Applications

The PLASMON hardware shall consist of the following:

·  A Pentium 4, PC-Compatible personal computer with the following requirements:

o  2GHz or better CPU

o  Minimum 1GB of free Hard drive space

o  128M video card or better

o  Minimum 256 MB of RAM

o  PS2-configurable Parallel Port

·  A Quantum Research E-160 six-button charge-transfer touch panel

·  A 50” High-resolution color plasma display

·  An audio amplifier and speaker system Part Number: 31-1982B

·  A presence-sensing device that will begin the presentation when a potential user approaches the kiosk within five feet

·  An Interface board to facilitate communications between the touch panel and the Software.

Deliverables

Below is the list of deliverables to meet customer satisfaction:

  1. Complete/functional Software application, which complies to all required specifications.
  2. A Functional interface board with all required harnessing
  3. One unpopulated Interface PCB board along with all required parts for assembly of one additional Interface PCB
  4. One Technical Manual Detailing Software and Hardware Installation and configuration
  5. One Users Manual Detailing Presentation Updating.
  6. CD containing all software, hardware schematics and layout files, pictures, videos, manuals, etc.

Concept Development:

The conceptualization for the PLASMON kiosk had been underway prior to becoming a senior design project. The kiosk booth had been constructed. The monitor, a Pentium III PC, a touch panel, an interface box, and complete set of harnesses were also acquired prior to the inception of the 05508 PLASMON senior design project. The concept development phase was therefore bounded by pre-existing hardware requirements. Issues addressed in the concept development phase included:

·  Type of executive programming language

·  Incorporation of photo albums and video streams

·  Polling I/O scheme versus interrupt-driven I/O

·  Hardware and software interaction in response to stimuli from the user

·  Design of both hardware and software for testability

·  File structure for easy maintainability

Perhaps the most important concept to be considered is the type of programming language to be used for the presentation. Prior to Senior Design involvement in the PLASMON project, the kiosk software was constructed entirely with the Flash MX web graphics/animation package available from Macromedia. Although this software facilitates high-quality graphics images and effects, it provides little control over I/O peripherals such as the parallel port. The files created by Macromedia are very large, and as a result require a significant amount of time to load before execution can take place. For these reasons, a brainstorming session was held to determine the best method for creating the structure of the kiosk software. One result of the session was the idea of implementing an executive program that could call much smaller files when prompted by the user. The executive program could run the hidden functions necessary for I/O handling and menu navigation, while the “slave” program would run the applications visible to the user, such as photos and video animation.

The executive program idea brought about other issues to be looked at further-- one being which software would be the best for this executive code. Visual Basic and C++ were both considered during brainstorming to serve as the executive programming language. The characteristics determined to be most important in choosing an executive language include:

·  Compiling time

·  Execution Speed

·  Graphics Capabilities

·  Easy import/ export of different file types to the presentation

Using these characteristics, a rating system was established. The rating system was implemented, and results were tabulated in the Feasibility Assessment section of this report.

A second consideration that required some analysis was the method of communication between the executive language and the parallel port. Recent Microsoft Windows operating systems (Windows ’98 and later) require the use of a Kernel-mode device driver in order to gain access to hardware peripherals. On-line research was conducted, and four drivers were weighed according to the following characteristics:

·  Compatibility with executive programming language and operating system

·  Possible conflicts with existing parallel port drivers

·  Ease of incorporation of parallel port driver with executive software

·  Simplicity of Syntax

·  Ability to read or write to port registers

·  Ability to respond to hardware interrupts

·  Price

The results of the rating procedure are documented in the Feasibility Assessment section of this report.

Visual basic has the ability to read the contents of a folder and point to files. Because the photo albums were required to be easily modifiable, the concept of file and folder access was examined closely. It was determined that a photo album folder could be created to hold all pictures. Within this folder, the administrator could add and remove files without having to modify code if pointers to files are used in the executive skeleton. The same is true of faculty interviews. This could allow the users to “page” through selections simply by moving a pointer.

Design for testability was considered in the early stages of the project. Only one set of hardware existed, which made testing and development challenging at times. Over the course of software design, provisions were made that would enable the software developer to test code on a laptop without requiring the use of the touch panel. Likewise, during the design of a new interface board, provisions were made that would enable a system test with only the interface box and a PC. Consideration of design for testability proved very useful and will benefit future developers of the system.

While the project was in the design stage certain concerns about the polling structure were expressed. This consideration of interrupt-driven I/O led to conceptualization of a hardware-software communication scheme that will provide an interface that is as error-free as possible. Hardware interrupts can be caused by a button press at the touch panel, or by detection of a user by the presence sensor. The interface PCB could provide hardware that can allow the software to disable certain events, or being able to monitor signals without causing an interrupt. This is discussed more in depth during the feasibility section.

Presence/motion sensors were researched concurrently to conceptualization of the Interface PCB. Both infrared and ultrasonic sensors were being considered. See the Feasibility section of this report for a synopsis of sensor selection.

Feasibility:

After assessing the needs and creating software concepts as stated above, the choices were summarized and then a brief analysis was preformed. Due to previous decisions determined by the first Engineering Team, the project already had a definitive direction, which in turn created less of a need for an elaborate feasibility assessment. One of the focal points in the beginning of the project centered on how the execution of the menu navigation was going to be preformed. Below, in Table 1, shows a summation of the decision process. . The two options considered were:

·  Create an executive skeleton that could call smaller portions of the presentation upon each input from the user.

·  Keep the presentation entirely within Macromedia and try to use Macromedia’s ‘Action Script’ for interfacing.

Executive Program /

Macromedia

Rank

/ Pro’s / Con’s / Pro’s / Con’s
4 / Apparent Parallel Port communication capability
(4) / No Apparent Parallel Port communication capability
(-4)
3 / Faster execution time. (3) / Approximately 2+ additional weeks of implementation time
(-3) / Approximately 2+ fewer weeks implementation time
(3) / Slower execution time
(-1)
2 / Past Experience with Software
(2) / Would require 30+ (small) graphics Swf files
(-2) / Ability to have one (large) graphics .exe file
(2) / No Prior Experience
(-2)
1 / Approximately a fourth of the File Size. (~112Mb)
(1) / Large files size and processor usage. (~ 400Mb)
(-1)
Total: / +5 / Total: / -3

Table 1: Concept Decision 1 - Executive Vs. Macromedia

The above table made it apparent that the Macromedia option wasn’t a feasible choice. This was confirmed with the shortcomings the previous Engineering team encountered using this approach. With this evaluation complete, another obstacle presented its self. The executive program could have been developed using various software packages. At the time of the concept development the two obvious choices were to use either C++ or Visual Basic 6.0 due to the software package capabilities. Refer to Table 2 below for the results.

Visual Basic was ultimately chosen as the executive language for the kiosk. Visual Basic (VB) has the ability to call other applications such as Macromedia Flash, Windows Media Player, or Microsoft Office applications within the GUI. This provides a degree of modularity with respect to modification and upkeep of the presentation. If a video or spreadsheet needs to be changed, the administrator can simply replace the source file. This modularity gives rise to the overall file and directory structure of the kiosk software.

C++ / Visual Basic 6.0

Rank

/ Pro’s / Con’s / Pro’s / Con’s
4 / Software created for data and register manipulations. Important for the Parallel Port
(4) / Software package not created for additional “plug and play” graphics
(-4) / Microsoft package allows easy compatibility with other Microsoft products using OLE containers (Word, excel etc.)
(4)
3 / Approximately 2 additional weeks added to implement time
(-3) / Software package designed specifically for GUI applications
(3) / Software package not used for in depth register manipulation needed for the PP
(-3)
2 / Compiled language
(2) / Current .swf integration available
(2) / Interpreted Language
(-2)
1 / Prior VB team experience, leading to approximately 2 fewer weeks for implementation time
(1)
Total: / -1 / Total: / +5

Table 2: Concept Decision 2 - C++ Vs Visual Basic

Using both of these assessments the project went underway using a Visual Basic executive program that utilizes different Macromedia .swf movie files depending on user input.

The project initially adopted a polling structure in order to detect a user key press. However there were a few concerns expressed pertaining to the CPU processing power being consumed consistently while the program was running. Although the presentation seemed to be operating within the real time specification, future additions may have an impact and create a time lag or a discontinuous appearance. At this time, a proposal to transfer to an interrupt driven structure was considered. Although this would involve a complete redesign of the current I/O scheme, the system would be a more robust and practical application. Below in Table 3, is the layout of the decision process.

Alter to an Interrupt Structure / Pursue Current Polling Structure

Rank

/ Pro’s / Con’s / Pro’s / Con’s
4 / Frees up to 10 times the CPU Processing time
(4) / Loose up to 3 weeks of project design
(-4) / Will have up to 3 additional weeks to create additions
(4) / May limit future additions, and usage of the kiosk
(-4)
3 / Creates a smoother real-time presentation
(3) / Design/build/purchase new Interface board capable of interrupts
(3)
2 / Would satisfy customer specifications to a greater extent
(2)
1 / Provides valuable team experience
(1)
Total: / +3 / Total: / 0
Table 3: Concept Decision 3 - Interrupt Vs. Polling

After evaluating the different aspects and possible consequences of this change during the design stage, the team came to the conclusion to peruse the hardware interrupt structure. In order to make the transition as smooth as possible, most of the existing code was utilized.

Using a similar process as the previous concept feasibility, the team created a rating system for the multiple drivers available to implement communication to the parallel port. Below is a table format of this decision method.