* outline * - carnegie mellon school of computer …asim/rpcs06/voyager99_final_report.doc ·...

VIRTUAL VOYAGER(a field trip without leaving the classroom)

FINAL REPORT

RAPID PROTOTYPING, SPRING 1999CARNEGIE MELLON UNIVERSITY

7 MAY 1999

Contents

Figures and Tables Index...............................................................................................................4Introduction..................................................................................................................................... 5User Manual................................................................................................................................... 6Manual Introduction........................................................................................................................ 6Setup, Wiring, and Startup..............................................................................................................8

Screen..................................................................................................................................... 8Computers and Cabling...........................................................................................................9Starting the System Components..........................................................................................11

Curriculum Configuration..............................................................................................................15Administration Terminal device..............................................................................................15

Pilot Station................................................................................................................................... 17Screen................................................................................................................................... 17Throttles................................................................................................................................. 18Wheel.................................................................................................................................... 18Gauges.................................................................................................................................. 19

Navigation Station.........................................................................................................................20Porthole................................................................................................................................. 20Paper Map............................................................................................................................. 21E-Map.................................................................................................................................... 21Altimeter................................................................................................................................ 24

Conceptualization......................................................................................................................... 25Conceptualization Introduction......................................................................................................25The Client..................................................................................................................................... 25The Charge................................................................................................................................... 25Baseline........................................................................................................................................ 26

Baseline Introduction.............................................................................................................26Field Research......................................................................................................................26Scenario................................................................................................................................ 26

Enabling Technologies..................................................................................................................31Enabling Technologies Introduction.......................................................................................31Boat Simulation...................................................................................................................... 31Communication (With Real Voyager).....................................................................................32Computer-Simulated Conversation........................................................................................32Database Software................................................................................................................33Digital Video Cameras...........................................................................................................34Distance Learning Sites.........................................................................................................35Force-Feedback Input Devices..............................................................................................36Handheld Computing Devices...............................................................................................37Instrument Panels..................................................................................................................38Microcontrollers..................................................................................................................... 38Motion Tracking.....................................................................................................................39

Virtual Voyager Final Report — 2

Screen—Frame.....................................................................................................................40Screen—Lighting Bar.............................................................................................................40Screen—Parabolic Mirror......................................................................................................40Screen—Projector................................................................................................................. 40Screen—Material...................................................................................................................40Server Hardware.................................................................................................................... 41Smart/Interactive Rooms.......................................................................................................41Software Communications.....................................................................................................42Streaming Internet Video.......................................................................................................43“Virtual Map” Platforms..........................................................................................................44“Virtual Porthole” Platforms....................................................................................................44Virtual Reality........................................................................................................................ 45Virtual Reality Headgear........................................................................................................47

Visionary Solution.........................................................................................................................49Visionary Solution Introduction..............................................................................................49Participant Definition..............................................................................................................50Design Principles...................................................................................................................50State Curriculum Requirements.............................................................................................51Scenario................................................................................................................................ 52

Device Realization........................................................................................................................ 60Device Realization Introduction....................................................................................................60Supporting Technologies..............................................................................................................60

Virtual Voyager Computers....................................................................................................60Headsets............................................................................................................................... 62Administration Terminal.........................................................................................................63Alice World............................................................................................................................ 64Sound.................................................................................................................................... 66Global State Server...............................................................................................................68Boat Simulator.......................................................................................................................71

Piloting Station Overview..............................................................................................................72Screen and Projection...........................................................................................................73Wheel and Throttles...............................................................................................................76Gauges.................................................................................................................................. 77

Navigation Station Overview.........................................................................................................82Paper Map............................................................................................................................. 83E-Map.................................................................................................................................... 86Porthole................................................................................................................................. 90Altimeter................................................................................................................................ 99

Credits........................................................................................................................................ 101


Figures and Tables

Figures 1a, 1b – Screen Setup.......................................................................................................8Figure 2 – Cabling Diagram..........................................................................................................10Table 1 – Cabling List..............................................................................................................10-11Various device photos and screenshots..................................................................................15-24Table 2 – Boat Simulation Software..............................................................................................31Table 3 – CDPD Modems.............................................................................................................32Table 4 – CDPD Providers............................................................................................................32Table 5 – Computer Simulated Conversation Technology............................................................33Table 6 – Database Software.......................................................................................................33Table 7 – Digital Video Cameras..................................................................................................34Table 8 – Existing Distance Learning (DL) Programs..............................................................35-36Table 9 – General Force-Feedback Input Devices.......................................................................36Table 10 – Throttle-Style Force-Feedback Input Devices.............................................................37Table 11 – Handheld Computing Devices.....................................................................................37Table 12 – General Input Devices................................................................................................38Table 13 – Microcontroller Devices...............................................................................................39Table 14 – Motion Tracking Systems............................................................................................39Table 15 – LCD Projectors............................................................................................................40Table 16 – Server Hardware.........................................................................................................41Table 17 – Software Communication Technologies......................................................................43Table 18 – Streaming Internet Video Technologies......................................................................43Table 19 – Commercial Mapping Software...................................................................................44Table 20 – Virtual Porthole Platforms...........................................................................................45Table 21 – Virtual Reality Software...............................................................................................46Table 22 – Virtual Reality Headgear........................................................................................47-49Table 23 – Pennsylvania State Science Curriculum Requirements..............................................52Figure 3 – Listing of sound_infile.txt.............................................................................................68Figure 4 – Listing of sound_wavfile.txt..........................................................................................68Figure 5 – Sound System Setup...................................................................................................68Table 24 – GSS Source Files.......................................................................................................71Figure 6 – Sample Gauge.............................................................................................................77Figure 7 – Gague Architecture......................................................................................................78Figure 8 - KC-161 Microcontroller Board......................................................................................79Table 25 – Sample Microcontroller Messages..............................................................................81Table 26 – Sample Server Messages...........................................................................................81Figure 9 – Possible Configurations for Fully Digital E-Map Solution.............................................83Table 27 – Advantages/Disadvantages of Fully-Digital E-Map Configuration 1............................83Table 28 – Advantages/Disadvantages of Fully-Digital E-Map Configuration 2............................84Table 29 – General Advantages/Disadvantages of Fully-Digital E-Map........................................84Table 30 – Advantages/Disadvantages of Hybrid E-Map........................................................84-85Table 31 – Advantages/Disadvantages of Paper/E-Map Combination.........................................85Table 32 – Comparison of Three E-Map Options.........................................................................86Figure 10 – E-Map Layered Architecture......................................................................................88Figure 11 – Altimeter Circuit Diagram...........................................................................................99


Virtual VoyagerFinal Report

IntroductionWelcome to the comprehensive report for Virtual Voyager, the Carnegie Mellon University Rapid Prototyping course project for Spring 1999.

This report is divided into three main sections.

The User Manual is a reference which explains the setup and operation of the Virtual Voyager prototype developed by the class.

The Conceptualization section details the first six weeks of the class, during which the Voyager program was studied and a new Virtual Voyager system proposed. It is bracketed by two narrative scenarios which illustrate the current Voyager system and a visionary new system. Between these scenarios are more than twenty enabling technology studies which were undertaken by the class to explore available technologies.

The Device Realization section details the final eight weeks of the class, in which functional teams worked to design and build the more than ten devices and major software programs which comprise Virtual Voyager.

The Rapid Prototyping class has been offered at Carnegie Mellon for years. Its intention is to allow senior- and graduate-level students from different engineering disciplines—software engineering, electrical engineering (“hardware”) and mechanical engineering—to work together on a real-world problem, with specialized wearable computing devices often resulting. With the creation of the Human-Computer Interaction Institute in 1995, HCI engineering (user-centered design and evaluation techniques) became a fourth explicit disciplinary set.

Students from these four disciplines worked on smaller, sub-disciplinary teams during the Conceptualization segment (phase I) to study the client and the problem, prepare baseline and visionary scenarios, and identify and study possibly useful enabling technologies. For Device Realization (phase II, design, and phase III, implementation), the students regrouped into functional teams. Work was still done along disciplinary lines, with the most obvious being the software team’s efforts to create and maintain the backbone of the system which allowed all of the devices to interoperate.

The three phases ended with presentations and demonstrations for Voyager (the client) and the general public. A paper was also prepared and distributed. This final phase report encompasses the first two and reorganizes the information from a phase-centric approach to a device-centric one.

This report begins with a new section that treats the final prototype as if it were a consumer product—the User Manual.


User Manual

Manual Introduction

The User Manual section is designed to make the setup and use of the Virtual Voyager prototype as easy as possible.

The next page depicts a stylized view of all the components and their configuration. The introductory graphics for each User Manual chapter continue this motif to show exactly what devices comprise each station. Within the manual itself, device photographs and program screen shots illustrate each device or program.

The first part of the User Manual discusses the physical setup, cabling, and power-up of all the components in Virtual Voyager. Note that this information is based on the computers and devices demonstrated in the final prototype presentation; a subset of these components may be used as well.

The rest of the User Manual is a section-by-section and device-by-device discussion of each of the components. Each device has step-by-step instructions for use as well as a list of troubleshooting suggestions to solve potential problems.


Setup, Wiring, and Startup

Screen

Start by setting up the large front screen as follows:

Lay out the two pipes with a T-section parallel to each other, about 10' apart: The T should be facing up. (See figure 1a for a top view.)

Take the two, straight, 5' pipes and join them together (if they aren't already joined). Use this 10' pipe to join the two parallel T pipes (see figure 1b.)

Take the two 8' pipes and make sure they each have one wood piece in the end. Place the chromoly in the wood pieces. Make sure the screen is already tied to the chromoly.


Figures 1a, 1b – Screen Setup

Insert the free ends of the 8’ pipes into the T's of the base, and stand up the 8' pipes with the chromoly. Hook the tensile wire into the eye-loops on the upright 8' pipes. Tighten the tensile wires. The screen is set up.

Computers and Cabling

The Virtual Voyager system uses four computers. The cabling diagram in figure 2 shows the connections between these computers and the other devices in the system, as follows.

Pilot house computer - Used to show the front view of virtual world on the large projection screen. Pentium II - 300 Mhz, Windows 95, 128 MB RAM, Ethernet, Sound Blaster compatible built-in sound card, Diamond Voodoo2 3D Graphics Accelerator & built-in graphics card.

Porthole computer - Used to display the virtual world as seen through the porthole. Pentium II - 300 Mhz, Windows 95, 128 MB RAM, Ethernet, Diamond Voodoo2 3D Graphics Accelerator & built-in graphics card

Navigation computer - Used to display the electronic map and all the hot spots therein. Dual Pentium II - 450 Mhz, Windows NT, 512 MB RAM, Ethernet, Intense 3D Pro Graphics Accelerator

Network server computer - Used to run GSS and other simulation components. Pentium II - 300 Mhz, Windows 95, 256 MB RAM, Ethernet, Graphics Accelerator

All computers used have a monitor, keyboard and mouse and are connected to the network via 10-Base-T hub.


Figure 2 – Cabling Diagram

The following table describes what each of the wires are, and what each one connects to. Please refer to the above wiring diagram for each wire number.

Cable Connects

1 D-sub cable connecting Projection and Pilot house computer (A) - Diamond Graphic Accelerator output

2 Speaker cable connecting Audio Mixer/Amplifier and Pilot house computer (A) - Sound Out

3 Keyboard cable (for A)

4 Mouse cable (for A)

5 Game port cable connecting Porthole buttons (fixed) and Porthole Computer (B) gameport

6 D-sub cable connecting Porthole LCD screen and Porthole Computer (B) - Diamond Graphic Accelerator output

7 Serial cable connecting Porthole Tilt sensor (fixed) and Porthole Computer (B) - COM1 serial port

8 Keyboard cable (for B)

9 Mouse cable (for B)

10 D-sub cable connecting Navigation monitor and Navigation Computer (C) - video/monitor output

11 Serial Cable connecting Altimeter (fixed) and Navigation Computer (C) - COM1 serial port

12 Keyboard cable (for C)

13 Mouse cable (for C)

14 Speaker cable connecting Audio Mixer/Amplifier and Server Computer (D) - Sound Out

15 D-sub cable connecting Server monitor and Server Computer (D) - video/monitor output

16 Serial cable connecting Gauge box and Server Computer (D) - COM1 serial port


Cable Connects

17 Gameport cable connecting Throttle (fixed) and Server Computer (D) - Gameport; Wheel is daisy chained to throttle

18 Keyboard cable (for D)

19 Mouse cable (for D)

20 10-Base-T Ethernet cable connecting Pilot house computer (A) and Ethernet hub

21 10-Base-T Ethernet cable connecting Port hole computer (B) and Ethernet hub

22 10-Base-T Ethernet cable connecting Navigation computer (C) and Ethernet hub

23 10-Base-T Ethernet cable connecting Server computer (D) and Ethernet hub

24 10-Base-T cable connecting Ethernet hub and Campus/External network

25 D-sub cable connecting Pilot house monitor and Pilot house Computer (A) - built-in video/monitor output

26 D-sub cable connecting Porthole monitor and Porthole Computer (B) - built-in video/monitor output

Table 1 – Cabling List

The following contains the details for setting everything up, in reference to the cabling diagram (figure 2):

Projector - Connected to Pilot house computer (A) via standard D-sub monitor cable.

Porthole - LCD screen with tilt sensor and joystick buttons, connected to Porthole computer (B) via D-sub monitor cable (LCD screen), gameport (buttons) and serial port (COM1 - tilt sensor).

Gauge Box - Connected to Network Server computer (D) via serial port (COM1)

Wheel & Throttle - Connected to Network Server computer (D) via game port with wheel daisy chained to throttle.

Altimeter - Connected to Navigation computer (C) via serial port (COM1).

Amplifier & Audio Mixer - Connected to Pilot house computer (A) and Network Server (D) via Audio/Sound out.

Starting the System Components

Administration Terminal

To run the administration terminal, you must first make the following two settings:

Guarantee that the path can point to the global init file

CLASSPATH points to the classes directory

Next, you will run admin.bat -- this takes care of starting up the java AdminTerminal program. After about 5 seconds, the main window will open. There will be a list of components and their working status (alive, or dead).

To the bottom, there will be buttons for start, stop, pause, and quit. These buttons control the entire simulation, allowing the teacher to have full control over the running of Virtual Voyager.


To the right will be buttons for viewing the hierarchy of variables. Pressing these buttons will open up a new window with variables and their values, and buttons to the right for opening a sub-tree of variables. Variables that can be controlled by the administrator will have sliders below the variable name in these sub windows.

Global State Server (GSS)

To run the Global State Server, follow these steps:

Go into the directory that has the file startup_variables.txt. This file is needed to initialize the list of available states.

Type rmiregistry

Type java GlobalStateServer

To run a client of the Global State Server, follow these steps:

If the client requires any files defined relatively in its code, go into a directory that has those files.

Type java <client name> <Global State Server host name>

For example, if the client is named MyClient and the Global State Server is running on unix10.andrew.cmu.edu, you would type:java MyClient unix10.andrew.cmu.edu

Virtual World Software (Alice)

Copy the network directory onto the machine running Alice.

Load it up in Alice.

Type javac AliceDemo.java in the directory with the java code.

Type java AliceDemo in the directory with the java code. You can specify host address of GSS and port for Alice as command line arguments if you wish. If not, it uses default values that can be found in the first constructor.

In Alice, go to the script (the tab at the top) and modify the "HOST" variable to be the IP that AliceDemo is running on.

In Alice, click "Perform Script"

Back in the Java window, you can type in Alice commands and the Alice world will reflect the changes and perform the commands.

The return values (values read back in after Java sends the command to Alice) indicate if the command executed properly. See the print statements for clarifications.

Once the demo is finished, type exit in the java window. This stops the Alice world.


Sound

To get sound running for the full virtual voyager experience, follow these steps:

Unzip the file sound.zip

Place the sound files (these will all end in .wav) in your C:\ directory.

Run the boatsound.exe -- this file is automatically configured to play the sounds at the appropriate times.

Running any of the remaining components

To run a particular component/device, type:java <name of the class file w/out .class extension>

In cases when the application requires some initialization file that has been coded using relative paths (e.g. current version of the Electronic Map), you need to be in the directory that contains those files before running the application in the above manner. Ideally, such initialization files should be placed in the corresponding source directory so that the application can be run from its corresponding source directory.

For example, to run the Electronic Map, you should go into the$(PROTODIR)/java/src/emap

directory where all the map images and other initialization files reside, then type:java EMap

Gauges

The gauge box is connected to the system via the serial port (as per 16 in the wiring diagram figure). A special device driver has been written exclusively for these gauges.

To run the device drivers, execute the batch file ‘driver.bat’ on the server computer. This batch file will automatically set the necessary class paths and run the device driver in the background. Without this device driver running, the gauges will not display proper values.

To start up the system, plug the 7.5V power supply into the microcontroller board, which will immediately give the board power as shown by the lit LED. Press the reset button on the microcontroller board to start the gauges program, as indicated by the flashing LED. Next connect the 12V power supply to the microcontroller board at its respective socket. This will immediately turn on the power for the primary gauge panel. The secondary gauge panel is enabled by connecting the serial cable between the primary and secondary gauge panels.

Projector

The projector also relies on the AliceLink discussed earlier this section. To run the projector’s Alice script, be sure that the AliceLink is already running.


Only one copy of AliceLink is required for both the Porthole and the projector. Load up Alice with the correct script and press ‘Perform Script and Connect’.

E-Map

Follow the general application running as noted in the remaining components section above to run the e-map.

Altimeter

Follow the general application running as noted in the remaining components section above to run the E-Map.

The altimeter should be connected to the Navigator (C) computer via the serial port.


Curriculum Configuration

Administration Terminal device

The Administration Terminal is currently used for two purposes.

The more important use is to start, stop, and pause Virtual Voyager. The start and stop are used to begin the simulation and end it as appropriate. The pause button could come in handy if a general announcement to the class needs to be made by the teacher or a Voyager staff member about something the kids found or did while in the simulation.

It is also used simply as a display showing all numerical data about Virtual Voyager. This can be used to monitor where the boat is, how fast it is going, all the engine parameters, and so forth.

Instructions

Start / Stop / Pause buttons

Once Virtual Voyager is set up, the teacher will push the "Start" button on the screen.


Any time during the excursion, the teacher may press the "Pause" button if he/she feels something needs to be discussed surrounding the Virtual Voyager.

Once the students have arrived at their destination, the teacher may press the "Stop" button which will end the trip.

All the displays

There is no interaction with these displays. They are simply there as read outs meant to provide an overview to the teacher of everything that the students are controlling on the Voyager.

These displays are simply numerical. They are organized in related groups, showing general environment values, values for the boat, and values for each engine.

Troubleshooting

If the Start button does not function, please check the setup of the rest of the Voyager computers.

If the displays do not display (do not show anything), please check the Global State Server.

If a display does not change, please check the corresponding device.


Pilot Station

Screen

The screen is meant as an immersive view into the virtual world. It is only a view from the bow (front) of the boat.

The picture is displayed from behind the screen to prevent kids from walking in the way of the display.

Instructions

The projector should be set up behind the screen for rear-projection. If there is

enough throw space (around twenty-five feet), the projector should be able to throw an image which fills the screen (roughly 10’ x 7’). Set the projector to throw a reversed image in this case.

With less space behind the screen (roughly fifteen feet), position the mirror at fifteen feet. Place the projector to be about five feet behind the screen and


pointed back at the mirror. Set the projector to throw a non-reversed image, and adjust the positions of the mirror and projector to throw the full-size image on the screen.

Throttles

There are two throttles, one of which controls the left engine, the other of which controls the right engine. These simply control the speed of the boat; however, by applying separate acceleration on each throttle, the student will be able to turn the boat.

Instructions

In the off position, the throttle will be closest to the student. As the student pushes the throttle away himself or herself, the engines will pick up speed. The further the throttle is moved away from the student, the faster the boat will go.

The student will ideally need to move both throttles equally to maintain a straight heading. Most likely, the student will learn how much control each engine has on the boat by watching the boat turn.

Troubleshooting

If the throttle doesn't seem to be affecting the speed of the boat, please check the wire connection into the computer.

The throttles also rely on the engines working. If the boat has not been started, the throttles cannot function.

Wheel

This device is ideally what should be used for navigating through the river. This is how the student turns the boat to port (left) or starboard (right).

Instructions

It will be used as any wheel (such as a car wheel). Moving the wheel left will slowly move the boat to the left, and moving the wheel right will slowly move the boat to the right.

Troubleshooting

As with the throttle, if the wheel seems to have no effect on the boat's movement, please check the wire connection into the computer.

It will also not be usable if the boat's engines are not started.


Gauges

The last visual devices are the engine status gauges. These gauges provide feedback on how the engines are operating and their current status/ conditions.

There are two gauge boxes, one for each engine read out. They each have their own red button for on/off control for the engines.

Instructions

In order to start the engines, the student must press the red button on each of the gauge boxes. Think of the red button as turning the ignition key in a car. The needles will start to move to indicate that the engines have been turned on.

These are meant as a read out for how the engine is operating. The students will read the gauges to gather information such as speed of the boat and fuel level. This tool is important for students to learn how to read off of an analog gauge by watching where the needle is pointing.

This information is especially useful to the students for determining how far they can go on a given gas level and speed using the fuel chart, described later in the Navigation Station.

When the students are done with the Virtual Voyager, a student will press both red buttons to shut both engines off.

Troubleshooting

If turning the engines on does not work, please check the wiring to make sure it is plugged in properly to the computer.

If the gauges do not change, please check both the wiring to the computers as well as the Global State Server.


Navigation Station

Porthole

The virtual porthole is used as a surround-view into the virtual world. This frees students from the limitations of only seeing out the front of the boat. They can use this device to see the sky, the landscape around the boat, the

water, or anything surrounding the Virtual Voyager.

In this manner, the students can search around the boat for any interesting objects, ranging from animal life to water debris or anything else the student may wish to see.

The virtual porthole may also be used to determine the depth of the water currently below the Virtual Voyager.


Instructions

A student will hold the screen (about the size of a laptop computer screen) and can move it around the pole, up and down, and tilt the screen to any angle they wish to view.

In order to view certain items better, there are handy zoom in and zoom out buttons located at the left of the device. This allows the student to get the effect of binoculars on the surrounding area.

If the student wishes to get a depth reading, he or she will place the virtual porthole horizontally (as if looking straight down into the water), push a button, and the water depth will appear.

Troubleshooting

If the screen fails to show anything or move, please check the wire connection to the computer.

Paper Map

The paper map is used to provide a hands-on approach to manually plotting the course as the boat moves. It is needed to compare pre-plotted and actual course to figure out how far off course the current boat is and what the course

correction (if any) should be.

Instructions

Before the students visit the Virtual Voyager setup, they will decide upon a course which the boat is to take. They will use a paper map to pre-plot their course in black pencil and the cross-hairs to plot each point.

Once the students are using the Virtual Voyager, the actual course will be plotted using a red pencil and the cross-hairs to plot each point.

When the student (or teacher) decides the Virtual Voyager is too far off course, the student will use a protractor to find the angle difference between where the boat currently is and where it ideally should be. This angle difference, along with Port or Starboard is then relayed to the Executive Officer to make the appropriate course change.

Troubleshooting

If the pencils break during use, a pencil sharpener will be provided.

If the map should rip during use, another one may be printed out from the electronic map.

E-Map

A computer display which is used for multiple purposes. These include:


Electronic version of the paper map. This will show the actual boat movement as it happens.

Plotting a course. It is possible to input the entire pre-plotted course so it is possible to let the computer decide on course corrections if necessary. This course will the route that the students wish the boat to take, serving as a guide for the Navigation team.

Gathering information. The students can click on "hot spots" of the map to find out more specific information. Such information includes details about the Pittsburgh bridges, any important buildings, and any other sort of information the teacher finds useful. Such information may be relayed to the student as text, pictures, movies, or any other media format.

Bridge height calculations. By using the altimeter (described shortly), the student will see information about the height of a selected bridge, the boat height, and the water depth. This is to be used to determine if the boat can safely pass under the boat by doing subtractions of the given information.

Instructions

Course Plotting

Course plotting is generally only done at the setup of the Virtual Voyager. This involves the student typing in the pre-plotted course from the paper map. Specifically, the student will take each of the specific latitude and longitude points from the paper map and type in each number (to 5 decimal points of precision). When one set of points is typed in, the student will press the Add


button. This will draw a line from the last point to the point the student just entered.

At any time, the student may press Undo to remove the last entered point. The student can continuously press Undo in case they mistyped a coordinate at the beginning of the course.

Once the student is finished entering the points, the Done button should be pressed to indicate this.

Electronic Map

To gather interesting points on the map, to see the current boat position and heading, please click on the TrackLayer tab. This information will be updated constantly.

If you wish to see more or less of the map, we have provided Zoom In and Zoom Out buttons, located above the electronic map. Please click on these to see more or less detail as desired.

Information Gathering

Information gathering allows the student to find interesting information from the electronic version of the map. The interesting locations are represented by little check marks over each appropriate location. When the student clicks on one of these check marks, the right side of the screen changes to display the appropriate information. The student will then look at the picture, read the text, or view whatever is available for the selected hot spot.

The teacher will decide ahead of time what type of information (and specifically even what information in each type) the students should be able to find out about. For example, the teacher may decide to only let the


students view information about bridges and certain locations. This selection process takes place at the administration terminal.

Altimeter Information

See Altimeter, below.

Troubleshooting

If there are course lines drawn all over the screen…Make sure you are on the Plotting tab. Press the Undo button until all unwanted lines go away. Please be sure to enter the course in the order which you wish to get to each point.

If you can't find out information about a building/boat/whatever...Unfortunately, you are limited to hot spots that have a check mark picture on top of them. Please be sure to only click hot spots with the check marks. Furthermore, please make sure you are clicking on the check mark itself.

If you don't know the exact current position of the Virtual Voyager…Click on the TrackLayer tab to see this information.

Altimeter

The altimeter is a device used to measure the height of bridges. This information is used to determine if the boat can fit underneath the bridge.

Currently, the altimeter only has a single button which is used to display information about the upcoming bridge on the electronic map.

It can therefore be considered an extension of the electronic map.

Instructions

The student should look through the altimeter view scope to find the upcoming bridge. When the student sees the bridge, they should click the button on top of the altimeter.

Once the button has been clicked, the student should look on the electronic map screen to view the bridge height, boat height, and boat draft. The student will need to do a few calculations(subtract the boat height from the bridge height) to determine whether or not the boat will fit under the bridge.

If the student wishes to find out more information about the bridge, the More Info button may be clicked to bring up specific information about the bridge.

Troubleshooting

If the altimeter click does not cause the electronic map display to change, please be sure the altimeter is properly plugged into the computer.


Conceptualization

Conceptualization Introduction

From 15 January to 26 February 1999, the students concentrated on problem definition and conceptual design. The human-computer interaction (HCI) disciplinary team spoke to the Voyager staff on board the boats and talked to curriculum designers and teachers. From this field work, they were able to create both a baseline scenario which details the existing Voyager experience and a visionary scenario which describes a wide range of possible computer-aided classroom experiences, called collectively the “Virtual Voyager.”

During this time, the other disciplinary teams (software, hardware, and mechanical engineering/industrial design) identified potential enabling technologies based on the forming visionary scenario. Subteams were created to investigate specific technologies. In most cases, these investigations progressed as far as product feature matrices, which list and contrast available commercial solutions.

The Client

The Voyager program was created to teach students about the process of scientific inquiry by allowing a closer look at Pittsburgh’s Three Rivers. Participants are taught about chemical and biological properties of the rivers (checking river quality to see how well the water can sustain life), engineering (using navigation aids to find where they are on a map and following various gauges to see how the boat works), and physics (calculating bridge loads and watching locks and dams in action).

Voyager currently splits these activities into two educational trips, each with its own separate curriculum. The more established Environmental Science program contains activities such as plankton and macroinvertebrate identification, river charts and maps, bird-watching, and water chemistry testing. The newer Boats, Bridges and Water (or BBW) program is targeted towards slightly older kids and teaches physics and mathematics, using activities such as navigation and bridge height calculation.

Running both programs, the current throughput of the Voyager program is 5,000 students per year. This experience is limited by the physical capacity of the two boats currently in use and by the range which students can travel in a school day.

The Charge

The Voyager program wishes to expand the learning experience they offer to those students who are outside the geographical range of the Voyager dock and to those who cannot participate due to space limitations. The goal was to be able to reach up to 10 times the current capacity of students under similar economic constraints as the boat-based program. These constraints force any proposal to have a low annual maintenance cost and to have initial capital costs of less than $20,000 - $30,000.


Baseline

Baseline Introduction

As a starting point, the HCI disciplinary team defined the participants in the current Voyager program and studied the current flow of the program. As an aid to the entire design team, they created a document called a “baseline scenario.” The baseline scenario section details what kids do in each of the two programs through the use of a narrative which imagines a pair of field trips to the existing Voyager.

Field Research

In order to create the baseline, HCI field evaluations were conducted which gathered requirement data by studying the existing Voyager system and conducting initial contextual interviews with Voyager staff, curriculum designers (both involved with Voyager curriculum design and not), and teachers who are familiar with the Voyager experience. Two trips were taken to the boat itself, one led by our customer contact Beth O'Toole and the other mimicking a student visit in which Environmental Science program activities were demonstrated. In addition, base research was conducted into existing distance learning solutions, Pennsylvania state educational requirements for our target age group, and other available voyage experiences.

From the boat visits and interviews with Voyager staff, the baseline scenario was created. A list of the artifacts, or all of the physical objects which are used as part of the Voyager curriculum, was created in an attempt to better understand the kinds of interactions the students have. And the HCI group also created an affinity diagram to elicit and capture elements of both the existing Voyager and desired elements of a new in-class Voyager experience.

ScenarioEnvironmental Science

Identified artifacts in both the baseline scenario and the visionary scenario below have been called out in boldface.

At the grade school parking lot in Bridgeville, Pennsylvania, Ray and the other kids in his 5th grade science class board a yellow school bus. They are going to Pittsburgh for the Voyager field trip. Their teacher, Mr. Fields, got to go to the boat himself several months ago, and last week he brought back a box full of equipment, posters, and other stuff called a Captain’s Chest. Ray and his friends have been working for a week, learning about all the activities they are about to participate in.

After a 30-minute trip, the bus arrives at the Carnegie Science Center parking lot. All the students grab their gear and head to the Voyager dock where they are divided into three groups of eleven, named the Steelers, Penguins, and Pirates. Ray is part of the Penguins group. Shirelle is assigned to be the team leader of the Penguins and the Voyager instructor gives her a set of rotation cards so that she can guide her group through the series of onboard activities.


All the kids board the boat. Before they break into groups, they gather on deck and meet the Voyager crew (the Captain and deck hands) and the three Voyager instructors. The get a safety lecture, including a demonstration of how to put on a life jacket, and are also given instructions in using the “head” (toilet).

Both of the Voyager programs are divided into three shorter “mini-stations” and three longer “stations”. By beginning with the mini-stations, the students get a chance to get comfortable with the boat and meet the staff.

The boat launches and heads down the Ohio River. Ray’s first mini-station is to visit the upper deck for bird-watching. Students identify particular birds with binoculars and bird identification books and log the bird name, quantity, bird activity, location, and river. The data is entered into the computer by the Penguin team captain. The students spend 20 minutes observing birds and then move on.

Next is the River Charts mini-station. On their way there, Ray’s group passes the Steelers who are heading to the Fish Lab. Space is tight on deck and they have to squeeze by. Once in the bow, Ray’s team works together to identify the location of the boat on the river and name the recent bridge they have passed. The team uses river map booklets which are provided on-board for resource material. The Voyager teacher helps them with any questions they have with the material. The Penguins spend 20 minutes at this activity and then move onto the next mini-station.

The Penguins go from the outside deck, through the main classroom, and to a small vertical stairway which leads them down into a classroom called the Fish Lab in the stern of the boat. This room contains a 90-gallon aquarium with live indigenous fish, mature preserved fish specimens in jars, a “Treasure Chest” of various objects related to fish, fish identification charts and cards, a life-sized plastic fish model, and a viewplate in the floor through which the students can see the transmission shaft for the boat motor. Ray is most impressed by the whirring transmission shaft—he’s never seen one in his life! Ray and his teammate Nikki check the temperature and pH of the water in the fish tank and feed the fish. The group also does fish identification on the preserved specimens. The teacher reviews the contents of the Treasure Chest and tells stories to the students about the objects in the box.

After all the groups have rotated through the three mini-stations, it’s time to begin the main stations. Each main station takes about 45 minutes to complete and is based around the same sequence of sample collection, sample analysis, and data entry.

The Penguins head upstairs to the deck of the boat. As they step outside, the cool fresh air which blows in their faces is a pleasant change from the smell of diesel fuel they had been breathing in the cramped quarters below deck. Ray is looking forward to the next activity which is a main station called Macroinvertebrates. Ray and his class at school have spent the


last three weeks learning about macroinvertebrates and he eagerly awaits the chance to touch the equipment and perform real science experiments.

By this point, the boat is heading up the Monongehela River. The boat moves close to shore and idles its motor so that the students, who are standing on the front deck, can collect a river bottom mud samples with a petite ponar. The sample is dumped into the filter bucket, washed and dumped into a tray. Two students take the specimen tray into the cabin classroom and the Penguins look for macroinvertebrate specimens to observe and identify. Specimens are collected into petri dishes and viewed under a specimen scope for identification. Identification data is collected and logged into the computer. Ray is excited! He found and identified a spider mite. After forty-five minutes, they have completed the Macroinvertebrate main station and move on.

The Penguins begin the Plankton main station activities by first performing a plankton specimen collection off the rear deck of the boat. They drop and drag a plankton net and let it drag on the surface of the water as the boat is moving. The net is brought back aboard the boat and the plankton specimen is bottled and brought to the Plankton Lab which is in the lower aft section of the boat. To get to the lab they must go down a narrow vertical staircase in ex-crew quarters. They walk through the classroom and squeeze by the Steelers group who is busy with their water quality tests.

Down in the Plankton Lab each student views their wet mounted slide under a microscope and performs an identification of living specimens with the help of identification cards. The video microscope is used by the teacher to display a rare plankton specimen to the entire class. Ray logs his data on his paper worksheet and hands it off to Shirelle, his team captain, who logs all the team data into the computer. The teacher announces the Plankton lab is complete and asks the team captain to lead the way to the next destination.

The Penguins climb up the stairs, out of the hull of the boat, and move on to the Water Quality main station where they will spend the last forty-five minutes of the trip. The team gathers on the deck and performs four activities:

temperature measurement with a thermometer dissolved oxygen level, water temperature, water pH level

with a dissolved oxygen meter water turbidity with a secchi disk water collection with a kemmererThe water specimen collected from the kemmerer is bottled and brought inside the classroom for further testing for temperature,


titration, dissolved oxygen and water pH. Ray and his partner Alice write down all the data on their work sheets and hand it off to Shirelle, who enters the data into the computer. Ray and Alice can’t believe the results of the day! The water quality on all the rivers is very clean and they are sure they will impress their parents with this news at dinner.

Ray looks out the window and notices that the Captain’s assistant is tying up the boat to the dock. Have four and a half hours really gone by? Is it really time to go home? He grabs his data sheets from the mini-stations and main stations and stuffs them in his pack to take home as souvenirs.

The students disembark and pose for a class picture in the parking lot. Ray is looking forward to putting the photo in his scrapbook since this was the best day of school he’s ever had. He boards the bus, exhausted but thrilled. That night he dreams of becoming an Environmental Scientist who will study ways to keep rivers clean for plants, animals and people.

Boats, Bridges, and WaterThe next week, Ray’s older sister Linda is going with her high school physics class on the Voyager’s BBW program. Her teacher Mr. Samuels has also been on the Voyager and has brought back a Captain’s Chest, but this one is filled with different kinds of equipment. Linda’s class spends three weeks’ worth of their physics period talking about the activities they’re going to do today on the Voyager.

Once they’ve boarded and met the boat crew, Linda’s classmates have several different activities they must perform before Voyager can get underway. One group collects safety data and checks levels of fuel, water, and other fluids. Another makes weather observations, while another measures current and water depth. Still other students raise the American and Pennsylvania Commonwealth flags, while other spell out their school name in signal flags to be flown onboard that day. But Linda has the coolest assignment of all—her group gets to actually start the boat’s engines and collect engine data.

The BBW program also has three mini- and three main stations. Linda’s group moves to the Geology mini-station, where she gets to study a geologic cross-section and sample rocks and compare them to rocks which can be seen in the hillside they are passing. The Voyager instructor shows them a tube of sediment and explains how the location of the rivers relates to the geology of the area and how the landscape has changed over time. They also get to see a core sample which was taken from a lock wall.

In the Meteorology mini-station, the students learn about the importance of weather observation and why the weather is


observed onboard Voyager. Linda gets to use a compass, wind meter, thermometer, weather radio, and weather station to collect meteorlogic data for that day and record her findings on the weather board. Then, the group turns the weather data into a ship code which can be interpreted by other ships. The instructor also explains why the river is a different temperature than the air, and explains how fog and floods occur.

The final mini-station, Lock and Dam, is Linda’s favorite. She and her teammates actually help the Voyager crew navigate through a lock and dam, making measurements in the lock of volume and flow of water and recording the actual gate openings based on the gate opening number from the pre-voyage data collection. They also discuss the dam on the other side of Neville Island, the reasons for specific gates being open more or less, and the flow through the dam.

Linda’s group gets to do the Boat Crew main station first, where she and her classmates become full-fledged members of the Voyager crew. Each student gets a radio headset so that they can communicate with each other. They take different roles: some students act as lookouts, monitoring river traffic, landmarks passed and debris in the river, and communicating this information to fellow crew. Some use compasses to take bearings of landmarks passed. They also talk about how the throttle and steering mechanisms work, watch the shaft in action (through the same viewplate which Ray saw), and trace cables from the pilot house to the engines and rudder. Most excitingly, each student gets to actually steer the Voyager, following the captain’s instructions and using the rudder angle indicator. During the station, some students monitor gauges in the engine room and pilot house, comparing the readings they take with worksheets they’ve prepared back at school to make sure the readings are within acceptable limits.

At the Hydrology station, Linda uses a current meter to measure the current at various places on the river and a depth sounder to measure the depth of the channel. The data she collects is compared to river charts and bottom profiles of the river. Then, the students are led into a room at the top of the boat and the shades are drawn. Using only the radar, Linda figures out where Voyager is on a river chart. When the shades are raised, Linda is relieved to see that she wasn’t very far off!

At the final station, Bridges, the Voyager instructor asks Linda and her friends to determine if Voyager can fit under the local bridges. They have to measure the boat and also look up each bridge in the river charts to find the answer. Then, they count the number and types of vehicles crossing a bridge up ahead and use this information to calculate the total bridge load. As they approach the bridge, they use an altimeter to determine its vertical clearance, and check their finding in the river chart. And, when they are right under the bridge, they get to study the


materials which were used in its construction. Finally, they use a bridge-building computer program to see if they can construct a basic bridge.

During the entire day, Josh and Ann in Linda’s group were collecting data based on all of the activities. At the end of the day, the data is collected on a large poster with a diagram of the rivers on it. As they board the bus to leave, they take the poster with them to study and talk about later in class.

Enabling Technologies

Enabling Technologies Introduction

The baseline scenario and the various iterations of the visionary scenario were presented to all of the functional teams as they were created. As the entire class discussed the scenarios, the concept of a computer-aided classroom trip—a “Virtual Voyager”—began to emerge. Aided by this vision, members of the various teams identified technology categories which might be needed to enable portions of the scenarios being proposed.

The following technology studies were submitted. In many cases, product feature matrices were constructed which distinguish the various options from each other based on categories determined by the functional team. Where possible, price quotes were gathered to allow the team to begin preliminary budgeting.

The study subjects are listed below in alphabetical order.

Boat Simulation

One of the most important elements in the early software architecture proposals was the boat simulator, software which would help drive virtual reality software (q.v.) based on input data from various boat controls. Currently, there are several commercial simulation packages on the market.

Company Product Price Platform Available Comments

Mathworks SIMULINK 2.2 Requesting Windows 95/NT Yes Full-featured simulation engine providing quick turnaround time for design/test/simulate.

Visual Thinking International

Simul8 $495 Windows 95/NT Yes Simulation engine geared towards simulating manufacturing/production environments (business applications).

Powersim Powersim Engine Requesting Windows 95/NT Yes Geared for computationally expensive applications and provides the ability to design UI in other languages such as VB.

Experimental Objects Technology

COVERS 3.1 Free Windows 95/NT Yes Fine print: FREE for personal use; need to purchase license for educational institutions.

CMU --- Free --- Develop A simple behavioral model of the boat simulation is currently being developed.

Table 2 – Boat Simulation Software


However, after carefully weighing in the cost/return factor for these packages, it was deemed preferable to design a simulator to suit Virtual Voyager’s specific needs. The inputs for the simulator may include, but are not limited to: a captain’s wheel, throttle, engine on/off, dock/undock, add fuel, add coolant, and add oil. Based on these input parameters and the boat’s current state, the simulator translates them into the next state of the boat. It produces a set of outputs such as speed, RPM, direction, location, temperature reading, fuel reading, and oil pressure reading. The boat simulator is the primary interface between the physical input devices and the virtual reality rendering engine. Input devices feed the simulator and the virtual reality rendering engine receives the simulator’s calculated results.

Communication (With Real Voyager)

For possible future inter-Voyager communication, an on-board CDPD (cellular digital packet data) modem could be connected to an on-board computer that would collect data (locational and operational) and transmit it to an ISP (internet service provider)

From the ISP, the data will be transferred to the central repeater station where it may be used for comparison against other Virtual Voyager simulations.

Name Data Rate Platform Price Notes

AlphaCom InSat Wireless Modem

~30-40 Kbps Windows 95/98 $500 modem + $170 software

Data rate is due to the use of compression software

Motorola Personal Messenger 100C & 100D

~10-11 Kbps Windows 95/98, Macintosh

Immediate availability

Sierra Wireless MP 210 CDPD & Cellular Data

~10-11 Kbps Win 95/98/NT $1,110 Immediate availability

Table 3 – CDPD Modems

The purpose of choosing CDPD modems over radio modems or other forms of wireless communication was ease of implementation. CDPD modems allow users to connect to the internet within an area of coverage without any additional equipment. (Note that for intra-Virtual Voyager communication, wireless headsets would be used to replicate the scenario on the real boat.)

Although communication between the real Voyager and the Virtual Voyagers was dropped from later versions of the visionary scenario, these options were investigated for possible reintroduction at a future date.

Computer-Simulated Conversation

Another identified technology of interest was computer-simulated conversation or CSC. CSC provides the ability for students access a wide


Name Data Rate Price

AlphaCom InSat ~30-40 Kbps $20/month unlimited

AT&T Wireless ~10-11 Kbps $55/month unlimited

Bell Atlantic Mobile ~10-11 Kbps $55/month unlimited

Table 4 – CDPD Providers

range of questions and answers interactively, as opposed to having to read a frequently asked questions (FAQ) list. There are a couple of existing commercial packages that implement this technology.

Company Product Price # of Q&A max Available System Input Type

Output Type

Grand Illusion Studios

Synthetic Interview

Variable 4,000 Yes 266 MHz Pentium32 MB RAM (128 MB recommended)

Voice, Typed

Video & Audio

Interactive Drama, Inc.

Virtual Conversations

Not specified No maximum specified

Yes 100 MHz Pentium16 MB RAM (32 MB recommended)10 MB of hard drive space

Voice Video & Audio

CMU Synthetic Interview

Most likely free

4,000 Develop 266 MHz Pentium32 MB RAM (128 MB recommended)

Voice, Typed

Video & Audio

Table 5 – Computer Simulated Conversation Technology

During investigation, contact was established with Don Marinelli (CMU researcher and part-owner of Grand Illusion Studios) and Roy Maxion of the School of Computer Science, who offered to provide any support we may need in incorporating this technology into our project. The feature was thus considered as a possible add-on to the overall software architecture, provided there were sufficient resources/funds for this functionality. Due to the modularity of the initial software architecture design, minimal changes are required to support this added functionality. In the worst case, a traditional non-interactive FAQ list can serve the same purpose.

Database Software

In both the baseline an visionary scenarios, the entry and the storage of scientific data takes place. The software group determined that using a third party database program, as opposed to custom software, is the most efficient and reliable way to implement this feature.

There were several key features that were used in evaluating the options. Although price was not the biggest issue (especially as compared to the rather expensive hardware system), it was taken into consideration since a copy would have to be purchased for each running Virtual Voyager program.

Product Name Company Price Web interaction Standalone apps? Mac? Forms

FileMaker Pro FileMaker $199 (retail) dynamic Yes Yes Yes

Excel Microsoft $339 (academic $109) static views No Yes No

Access Microsoft $339 (academic $109) static views Yes No Yes

Visual FoxPro Microsoft $549 dynamic Yes No Yes

Paradox 8 Corel $129 ($299 w/runtime) dynamic Yes ($299) No Yes

Table 6 – Database Software

One major issue was how the information could be disseminated after collection, so it was natural to consider how the software can interact with the


web. All software in consideration can show static views of data, but some can allow users to interact, query the database, and see different views of data dynamically via the web.

Another issue was whether the database could allow creation of stand-alone applications. Since the primary users of the system will be children, who can potentially make hazardous mistakes to the stored data (erasing entries), the software group decided to limit the access to the database to an interface that will be defined during system implementation. By creating a stand-alone application, this interface can not be overridden. System administrators can use the original database software to have full access.

The Voyager program currently stores its data in a database program running on the Macintosh operating system. The software group determined that it is important for the staff of the Voyager program to be easily acquainted with the Virtual Voyager system being developed. So, another issue was if the database software is available on the Macintosh platform, the environment with which the staff is already familiar.

Another feature being investigated is having form based data entry. Forms will allow data to be entered in separated text and numerical fields, in a new window, as opposed to being entered in spreadsheet, in one monolithic window. Forms allow for a better interface, and will lessen the chance of entering data incorrectly. This is especially important since children will be the primary users of the system.

Digital Video Cameras

Early versions of the visionary scenario focused on ways to collect data from an actual Voyager trip to use as part of the Virtual Voyager experience. Live video feeds, or captured and stored video for later playback, was a highly desirable feature.

Company Product Interface Resolution Features Sys. Requirements Retail

Logitech QuickCam Pro Parallel; USB 640x480 Optional lens pack; Tilt/swivel base

PC: Pentium (>100 MHz); Win95/98; Parallel or USB port; 16 MB RAMMac: USB port

$149.95

Kodak DVC323 USB 640x480 still image; 320x240 video

Detachable from base (with 3m of cable); 30 fps

PC: Pentium; Win95 OSR2/Win98; USB port; 16 MB RAM

Super Circuits

PPL-1-1200 FM (wireless) Standard NTSC Video

Wireless audio/video transmitter & receiver; 3 mile range

Sony CCD-Z1 NTSC 270,000 pixels Built in mic; Adjustable stand; rotating camera head

$150.00

Cybertronix Picture Perfection

PAL; NTSC; CCIR; Composite Video In/Out; S-Video In/Out

PAL (720x576); NTSC (720x488)

External trigger, or motion detector trigger

Table 7 – Digital Video Cameras


Unfortunately, all video possibilities were eventually eliminated from the design due to bandwidth considerations. The introduction of an environment based on virtual reality software (q.v.) also made this possible by removing the need for an actual photo-based environment.

Distance Learning Sites

Many institutions and other organizations have begun offering various forms of distance learning (DL) options, and many software companies have products which support them. The most popular of these sites were examined to determine the kinds of techniques used by each.

They were found to rely predominately on chat clients, newsgroups or bulletin boards, and streaming video or audio lectures viewable via technologies like RealNetworks’ RealPlayer. The highest levels of graphical interaction with a site were enabled with Macromedia’s ShockWave; many sites offered much lower levels of interaction.

Organization Type Technologies Comments

Western Governors University

http://www.wgu.com

Online university Traditional, Web Brings together distance learning classes offered already by various schools, classes “designed by corporations and publishers”, and certification for existing competencies. Faculty is made up of people from partner universities, tech schools, companies.

California Virtual University

http://www.california.edu

Online university Video, Web Acts as a clearinghouse for all the DL courses available in California; however, they don’t handle enrollment, grant the degrees, or answer questions about the courses themselves—just pointers to where to go to sign up

Knowledge University Online university Web, Can’t find any reference to “Knowledge University”; however, LearningSpace, the technology they are supposedly using, is a product of Lotus-- a full suite of tools to allow instructors to author courses, deploy them on the web, and manage and grade students.

Colorado University Online

http://www.cuonline.edu/

Online university Web, Java, RealPlayer

Over 100 courses of Colorado U. offered over the web; uses RealEducation product (turnkey system for developing courses (RES 3.0); also a “teaching methodology”)

Stanford Online

http://stanford-online.stanford.edu

Distance learning center

Video, Web, NetShow

Mostly a supplement to a trad. educational experience—lets students pick up a class they otherwise might not have had time for, or take a class which conflicts with another one (watching the lectures they’d miss on demand.) Doesn’t let instructors completely can a class.

University of Phoenix Online Campus

http://www.uophx.edu/online


Internet: AlexWare

Looks just like a “commuters” program but solicits all over the world. Emphasizes interaction in small groups; uses Convene’s AlexWare.

University of Illinois Online

http://www.online.uillinois.edu


Web, Java, JavaScript

U of I has a longstanding distance education commitment using traditional media (videotape, closed circuit/satellite). UI-Online is the internet extension of this. Still completely traditional U of I program, requiring normal admission procedure; not intended for on-campus students (unlike Stanford program) but for “underserved” Illinois population.

Gartner Group Internet Learning Center

http://www.gglearning.com

Online university Web, ShockWave

The only interaction is through ShockWave. Other than that very basic Web interaction: reading, click-on navigation. User cannot enter any info.


http://www.gglearning.com/

http://www.online.uillinois.edu/

http://www.uophx.edu/online

http://stanford-online.stanford.edu/

http://www.cuonline.edu/

http://www.california.edu/

http://www.wgu.com/

Organization Type Technologies Comments

Learning Web by Interchange Techies

http://www.learningweb.com

Online university Web, JScript, ShockWave

Uses chats and bboards as means of communication.

Uses LearningWeb product—integrated chat, bulletin board and transaction services all on separate servers.

IMG University Online

http://www.imguniversity.com

Online university Web Students have their own homepages on this site; allows scheduled chats, discussion groups

Michigan State University

http://www.vu.msu.edu/preview


Web, RealPlayer Video, Audio

Streaming video shows video-based lecture material; allows chats, web-talk

NJIT Continued Professional Education

http://www.njit.edu/DL


Video, I-net, RealPlayer

Video lectures sent to students via regular mail or viewed via RealPlayer; has “Virtual Classroom” conferencing system (couldn’t find more info about this).

Independent Study Program, UC Boulder

http://www.colorado.edu/cewww


Web

Table 8 – Existing Distance Learning (DL) Programs

Force-Feedback Input Devices

A simulation environment such as Virtual Voyager needs to include realistic input devices. Some devices, such as steering wheels or throttles, must act not only as inputs but as physical feedback devices—in other words, they need to move realistically based on conditions. A steering wheel in a driving simulation, to take one example, must vibrate with the speed of the vehicle and become more difficult to control on certain simulated surfaces.

Company Type Product Cost Features Interfaces

Immersion Corporation Mouse FeelIt Mouse ??? Win95

Immersion Corporation Joystick Impulse Engine 2000 $4,395 2 degrees of freedom for motion/tracking and force feedback; 6" x 6"

PC interface card

ACT Labs Wheel/Pedal Force RS $69.99 7 buttons on wheel face; 4-way D-pad; F1 style gear shifter; 270 degree turning radius; Effective clamping system

PC (Win95/DOS)

AVB Tech Wheel/Pedal GCFBW1 $119.98 220 degree steering wheel; 3 lbs. of force output; 8 programmable buttons; integrated shift lever

PC USB

CH Products Joystick Force FX $100 Six built-in force-feedback effects; Two 4-way switches, 5 buttons

Win95

Logitech Joystick Wingman Force $129.95 9 programmable buttons PC USB

Logitech Wheel/Pedal Formula Force $179.95 PC USB

SC&T International Wheel/Pedal Per4mer Force Feedback Wheel

15 programmable buttons; 280 degree rotation

PC Serial (Win95)

Microsoft Wheel/Pedal Sidewinder Force Feedback Wheel

$154.95 PC

Table 9 – General Force-Feedback Input Devices

There are various kinds of wheels and throttles for vehicle simulation games available. However, many of them are shaped like fighter plane throttles


http://www.colorado.edu/cewww

http://www.njit.edu/DL

http://www.vu.msu.edu/preview

http://www.imguniversity.com/

http://www.learningweb.com/

rather than a boat throttle, or as race car wheels rather than ship wheels. Throttles often come with extra buttons for additional capabilities.

For the input devices, electronic wheels and throttles used for racing games on computers were considered. The wheels looked at were the ones that can be secured on a table or platform, and can provide force-feedback to make the boat control simulation more realistic. For almost all of the force-feedback wheels, the force-feedback engine implemented came from Immersion Corporation, and comes with software to write custom force feedback response. The interfaces for the wheels are either through the game port, or USB port. The device from Microsoft was deemed the best candidate because of above-average reviews.

Company Product Cost Features Interfaces

CH Products CH Throttle $40 One 4-way switch, one 2-way switch, 6 push buttons, all programmable; single key and macro programming

PC AT & PS/2 Keyboard connectors

CH Products Pro Throttle $90 Four 4-way switches and four push buttons, all programmable; analog and digital throttle modes

PC AT & PS/2 Keyboard connectors

Thrustmaster Attack Throttle $59.95 4 buttons, one 3-way switch; includes ThrustMapper software for programming the Throttle

PC/Win95 game port

Thrustmaster F16 TQS Throttle $139.95 2 dials and two 3-position switches; 4-way radio switch; completely user programmable

PC/Win95 game port

Table 10 – Throttle-Style Force-Feedback Input Devices

Among the throttles, the CH Throttle from CH Products was chosen as the best candidate because it doesn’t have too many buttons on the throttle and uses an AT keyboard connector. The use of a keyboard connector, not needed for other functions within a boat simulation, would leave the game port free for the use of a wheel.

Handheld Computing Devices

In the early visionary scenarios, many small electronic devices—both for data input and for instrument readouts—were proposed. In one possible architecture, these devices would all be autonomous and would each contain some computing power. Although this was ultimately dropped in favor of centrally controlled display devices, one hardware team did investigate possible low-cost computing platforms. These devices all needed to be handheld and had to have enough power to accept input and drive a display.

Company Computer CPU type/speed OS Communications Options

Price

Compaq Itsy StrongARM SA-1100 59-206 MHz

Linux 2.0.30 IrDA; Serial port Not commercially available

3Com PalmPilot Motorola DragonBall 16 MHz

PalmOS IrDA; Serial port, cellular modem

$200-$300

Nintendo GameBoy Zilog Z80 clone 4 MHz GameBoyOS Serial port $50

Vadem Clio NEC VR4111 MIPS 4000

WindowsCE IrDA, Serial port $1,000

Table 11 – Handheld Computing Devices


Ultimately, the poor cost-to-power ratio of these available devices helped drive a decision to centralize the processing. Although the cheapest option found, the GameBoy, could have been modified to create several useful and realistic devices, the time needed to design and build many different cases and displays was deemed prohibitive. Then, too, a strategy for linking these devices and sharing their data would still have to have been found.

Instrument Panels

To create realistic-looking instrument panels for the boat simulation, the hardware team had to investigate pre-built individual gauges, buttons, and other user controls.

The proposed gauge cluster required electrical gauges which can be found at a number of different locations. This electrical requirement is essentially the only restriction for this technology. Initial research immediately showed that Pep Boys, a consumer automotive parts chain store, carried many of the gauges needed (oil pressure, water temperature, water pressure, tachometer, and others) All had common voltage requirements (+12V) and common interfaces for sending to and reading from the dial.

Input components were chosen to show the price range of the intended technology. The team felt that it would be better to use recycled equipment for a more authentic look and feel.

The assumption in this investigation was that the actual engine control would done in a software simulation. The researched instrument panel components thus needed only to interface with the simulation application.

Microcontrollers

The electronics team considered microcontrollers which were small in size and as efficient as possible given the requirements of specialized peripherals. Since early visionary scenarios were concerned with gathering live data from the electrically operated gauges on the boat, A/D (analog to digital) converters on the microcontrollers were deemed necessary. After some research, the PIC16C7x microcontroller family was determined to offer the best options. The PIC16C77 offers the maximum number of A/D converters per microcontroller, as well as on-chip EPROM and RAM. Also desirable was the included I2C protocol which can be used for networking between the various chips and the asynchronous serial port to interface with an on-board computer that would receive the data.

Under early visionary scenarios, it was undecided if the information about the boat will be read in real-time or if it will be entirely virtual (canned) data. However, with the final visionary scenario, gathering real-time data was


Company Component Part Number Price Electrical Requirements

Precision Electronic Components

Potentiometer RV6N104C-ND $5.70 1/2 Watt, 100 Ohms

Eswitch Push Button Switch EG1315-ND $1.77 Contact rating 25mA/50V DC

Table 12 – General Input Devices

decided to not be a feasible option. In any case, to display data on the physical gauges, digital data needs to converted into analog signals to be sent to the gauge cluster. This will be accomplished through D/A converters. Since microcontrollers were not found to have sufficient numbers of D/A converters on-chip, stand-alone DAC chips were also considered.

The gauge displays also require communications capabilities which will be covered with I2C networking for inter-controller communication and an asynchronous serial port to communicate with the server computer.

Motion Tracking

The virtual porthole device, as described in the visionary scenario, was untethered and handheld, and yet could understand its position in space relative to the room. In order to implement such a device, various solutions for motion tracking were studied.

Model Company Method Freq. DOF Latency #Rcvrs Range Accuracy Price Comments

InsideTrak Polhemus Magnetic 30Hz 6 12ms 2 5ft 0.5in, 2.0deg

$999 for gaming

IsoTrak II Polhemus Magnetic 30Hz 6 20ms 2 5ft 0.1in, 0.75deg

$2875 range more like 3 ft

FasTrak Polhemus Magnetic 30Hz 6 4ms 4 10ft 0.03in, 0.15deg

$6050 range more like 5 ft

Flock Of Birds Ascension Magnetic 144Hz 6 N/A 30 3ft 0.1in, 0.5deg

$2695 $2200/rcvr

FOB/10 Ascension Magnetic 144Hz 6 N/A 30 10ft 0.1in, 0.5deg

$8090 $2200/rcvr

VR-360 Angularis Inertial 500Hz 3 2ms 1 20ft N/A $9200 unseen

V-scope Eshed Science & Technology

Ultrasonic 100Hz 3 2ms 1 12ft N/A $2800 unseen

Cyber Track General Reality

Inertial 30Hz 3 <50ms 1 N/A 1.25deg N/A unseen

Table 14 – Motion Tracking Systems

The high cost for these solutions was a strong contributing factor in the ultimate decision to abandon motion tracking for a much more affordable tilt-sensing design.


Company Model Word Size EPROM FLASH RAM Digital I/O

Microchip PIC16C77 8 bits 8 Kb x 14 None 368 B 33 pins



Siemens SABC504 8 bits 16 Kb None 512 B 32 pins

Siemens SABC167CR 16 bits None None 3 KB 76 pins

Phytec MicroMODUL 8051

8 bits 16 Kb 128 Kb 32 KB 8 pins

Phytec MicroMODUL 167CR

16 bits 32 Kb 256 Kb 256 Kb 64 pins

Table 13 – Microcontroller Devices

Screen—Frame

Much of the focus of the Virtual Voyager participants will be upon a front projection screen which will display a rendered view of the virtual world from the pilot house of the boat. This display will be complemented with front- mounted speakers and fans to provide atmospheric audio and weather effects. Additional speakers positioned around the room could add additional boat and environmental sounds, such as the low rumble of the engines or splashing of water on the bow of the boat.

A frame was proposed to maintain the shape and tautness of the screen. The frame can also lend some realism by simulating the inside of the boat. For example, the frame could form “windows” onto which the rendered image can be projected. This will reduced the size of the necessary image, thereby increasing image quality.

Screen—Lighting Bar

A “realism” subteam studied ways to increase the simulated boat sensation as it related to the front screen portion. A lighting bar was proposed to control the lighting conditions in the classroom and on and near the screen.

Because ambient light which reaches the screen can reduce the quality of the image, the lighting bar would need to keep the user’s area well lit and reduce the light on the screen. The lighting bar could also be used to simulate lighting conditions, such as fog, night, or an emergency.

Screen—Parabolic Mirror

The subteam proposed a curved mirror as a way to project the rendered image onto a curved screen. This would increase the realism of the scene, as well as reducing the number of projectors needed.

Screen—Projector

According to the visionary scenario, the rendered simulation is projected in the front of the room. In order to accomplish this, some type of projection system is needed. There are several types of projectors that could be used with the Virtual Voyager. These include computer controlled LCD projectors as well as computer controlled LCD slides (used with a standard slide projector).

Screen—Material

Used to provide a surface for projection. Again, there are several options available. The curvature of the screen could provide realism, the reflective characteristics determine the quality of the image, and the translucency determines whether the screen can be used for front or rear projection.


Company Product Brightness Resolution Weight List Price

Lightware Lightware VP800 300 Lumens 800x600 SVGA 9.33 lbs. $3,995

CTX Opto CTX EzPro 800 330 Lumens 640x480 VGA 9.25 lbs. $3,995

Table 15 – LCD Projectors

Server Hardware

The server chosen largely depends on the software requirements. The server will be responsible for coordinating all of the I/O devices and rendering the virtual world.

Company Computer CPU type/speed OS Communications Options Price

Apple Computer Inc.

iMac PowerPC 750 266 MHz MacOS, Linux 2.2.x 10/100BASE-T Ethernet, 56Kbps modem, USB

$1,199.00

Intel Pentium II 350/400 MHz Windows, Linux, FreeBSD, OpenSTEP

Ethernet, modem, IrDA, serial port

$1,000-$1,500

AMD K6+3D 350/400 MHz Windows, Linux, FreeBSD, OpenSTEP


$1,000-$1,500

Cyrix Mxi PR300, PR400 300/400 MHz

Windows, Linux, FreeBSD, OpenSTEP


$1,000-$1,500

Table 16 – Server Hardware

Smart/Interactive Rooms

A smart room is generally considered to be any space that has “intelligence” in the sense that it can respond to its occupants, or to external events such as the weather. Such a room is primarily composed of sensors and actuators. Sensors are used to track location of occupants, and sense external data such as the weather. Actuators are used to let the room create an effect in the space to inform the occupants.

Smart rooms are often described in the context of peripheral and focused activity. Things in an occupied room generally command peripheral attention where the main focus is on work. But changes in the periphery are noticed easily, and so schemes for notification of intermittent things, like receiving email, can be mapped to smart room objects.

The main feature of smart rooms is that changes in the environment or actions of a person may be mapped to any controllable device or other action. Following are some examples of current smart room research:

MIT Tangible Media Group

Sensors can be placed on a bottle and its top to provide a binary control (capped and uncapped.) This data can then be mapped onto anything controllable by a binary switch—stereo power, opening an application, dialing a telephone number, and so on.

MIT has also placed sensors in the lobby of a building to generate a signal proportional to the number of people walking through the space. This signal then gets mapped to a faucet valve that controls the number of water droplets exiting the faucet. The drops fall into a shallow pan of water that acts as a lighting valence so that rippling patterns of light are generated in a room based on the activity in the lobby.


Parc Tabs, Xerox Parc

Xerox was the first to really explore this idea, stemmed from Marc Wieser’s research.

Parc Tabs were handheld computers, about half the size of the commercially successful Palm Pilot. They had wireless communication ability, and their position was sensed by a network of sensors throughout a particular portion of the office space at Xerox. People wore them clipped on to their belts. The screen was the major interface, allowing email reading. Some of the applications tested included:

Finding/paging people and things (such as the nearest printer)

Allowing forwarding of phone calls to the nearest phone

Shared drawing environments among Parc Tab holders

The transference of a user’s computer desktop to a visited computer

Mapping messages to a particular place and/or time

Allowing objects to relay data, accessible only in the space around them

Interactive white boards

Voting in meetings

MIT: The Intelligent Room

Facilitated interaction with the room via speech recognition or by pointing to an interactive display. However, the current speech system can only handle 25 sentences. The pointing gesture recognition system is still in beta development. It works by comparing where your finger is to its predefined rectangular areas for the given projection.

It keeps track of up to four people in the room by using a motion-based visual tracking system. This feature is aimed at creating a sense of virtual meetings for people not present in the room. There is currently no interaction between the room and objects. It will be 10-15 years before the technology is available for a full-fledged environment.

Software Communications

The early proposed software architecture required a modular object-oriented communications sub-layer capable of supporting remote operations on multiple hardware platforms. There are two main competitors in this area: the Common Object Request Broker Architecture (CORBA), and Sun Microsystems’ Java.

Java RMI was ultimately deemed the better of the two options. It offers the ease and platform independence of the Java programming language without the complexity of system design or cost of CORBA. CORBA was designed for high end, enterprise computing, while the Virtual Voyager system is essentially a local area network. The desired modularity of the system can be implemented by both CORBA and Java, but a majority of the services are provided in Java.


Technology Base Concepts Advantages/Disadvantages Platform Cost

CORBA Distributed Objects

Enterprise Comp. (transactions)

Client/Server model

Designed for multi platform multi language enterprise computing.

More complex.

ORB Ports may be unstable

Visibroker:

Win32, and commercial UNIX

TAO: All commercial and UNIX platforms

$$$

$$$ (free trial)

Free

Java RMI, Swing, JDBC

Remote Method Invocation

Object to Object model

Multiplatform.

What you code, is what you get.

Easier for beginners to understand.

Java 1.2 is CORBA compliant

JDK 2.0 - Win32 and all major UNIX platforms

Free

Table 17 – Software Communication Technologies

Java is also available from a single industry leader. A cheap or free CORBA implementation is usually provided by a campus research group, and may be buggy and/or unsupported.

Streaming Internet Video

In the initial phases of the project development, the idea of having live contact with the Voyager was investigated. The simplest method of achieving this was to use streaming video sent across the internet from the boat to the classroom destination.

Product OS System Req.'s Minimum Bandwidth

StreamCapabilties

Live Video Costs

VivoActive

www.vivo.com

PCMAC

Web Server w/MIME types

28.8 Dependant on Web Server

No VideoNow 149

PowerPlayer 12.95

RealNetworks

www.realaudio.com

SCOWinNT 4.0Linux 2.0FreeBSDSolaris IrixHP/UX Digital Unix

Any Web Server

3MB RAM + 60k per video + 20 KB per Audio stream

Disk space 2 MB + 15MB per hour of Audio

14.4 (Audio) ISDN 5-10 streams

T1 100 Streams

T3 1000-3000 streams

Yes Basic - free (25 seats)

Basic Server Plus

-$695-RealProducer-RealPresenter-1 year tech support

Table 18 – Streaming Internet Video Technologies

The problem with live streaming video is feasibility. The only company that provides live streaming video is RealNetworks. In order to achieve the minimum video quality for the video to be useful requires a very high speed data connection, which both the boat and public schools currently do not have. It is technically possible to create a high-speed connection from the boat using multiple cellular phone modems and routing software. This is, however, technically difficult and exceeds the low maintenance design goals of the project.


http://www.realaudio.com/

http://www.vivo.com/

“Virtual Map” Platforms

A virtual map device (ultimately called the e-map) was a software team proposal based on the visionary scenarios. Its intention was to illustrate navigation concepts. As a key part of the system, it was deemed to warrant its own enabling technology investigation to identify possible platforms and commercial mapping software options.

After discussing different technological approaches for providing a virtual map, a web browser emulation was selected as the target technology to be researched and documented.

The technology required for developing a virtual map application as a web browser was divided on two parts; software development tools and data sources.

Software performance is directly related to development complexity. For example, developing an application using Visual Basic is faster and easier than using Java or C++. On the other hand, a Visual Basic application performs slower than a Java or a C++ one. Therefore, the proper software development tool to be selected should balance performance with complexity.

Each of these three development tools has strengths depending on the kind of application to be developed. First, Visual Basic is appropriate for developing applications that link different tools because most of them use Visual Basic as the programming control language. Second, Java is appropriate for developing web-based application because is a machine-independent language. And third, C++ is appropriate for developing highly computational demanding tools because it is not an interpreted language.

Even though a preference for using C++ as development tool was identified, joining all team members’ development skills allow any of the three development tools to be used. The best approach is using an architecture that can connect modules written in different languages so that each team member can use the language of greatest familiarity.

As for the data sources, virtual map users will need access to different kinds of data; images, drawings, and historical info are some examples of possible kinds to be considered. Copyright for all data to be used must be purchased because data is going to be used in a commercial application.

“Virtual Porthole” Platforms

Another unique device in the visionary scenario, the virtual porthole, also spawned its own research. At the time, the device as conceived as handheld. Investigation determined that there were several commercial-off-the-shelf handheld color touch-screen devices, all of which could present still images and prerecorded video via standard internet technologies including JPEG,


Product Name Company Price

Terra Server Microsoft Price per picture:$24.95 Large$13.95 Medium$07.95 Small

Yahoo maps Yahoo N/A

City Planning City of Pittsburgh N/A

Streets 98 Microsoft Software freeCopyright reserved

Table 19 – Commercial Mapping Software

GIF, AVI, QuickTime, and HTML. Their data was to be stored locally on the device or streamed via HTTP from a server in the classroom via wireless ethernet.

Device Mfgr CPU RAM OS Storage Screen Battery Networking Pen/Keyboard

Clio Vadem NEC VR4111 MIPS

16-32 MB WinCE Pro 24 MB 640x480x8bit 9.4" LCD

12 hours (LiIon)

both

Point 510 Fujitsu 5x86 100 MHz 8-56 MB EDO Win98 or Win 3.11

1.6 GB 800x600x8bit 10.4" LCD

5 hours various wireless LAN

pen; software keyboard

Point 1600 Fujitsu Pentium 166/MMX

32-96 MB Win98 4.1 GB 800x600x16bit 10.4" LCD

4 hours various wireless LAN

pen; software keyboard

Stylistic 1200

Fujitsu Pentium 120 16-80 MB WinNT/98/95 or DOS 6.22

2.1 GB 640x480x20bit 8" LCD

5 hours pen

Stylistic 2300

Fujitsu Pentium 233/MMX

32-96 MB WinNT/98 4.1 GB 800x600x20bit 8.4" LCD

5 hours pen

Table 20 – Virtual Porthole Platforms

In this formulation, the students would interact with the device via the touch-screen interface, implemented as web pages and viewed with a standard web browser. A device with a keyboard would further allow data via web based forms.

Device tracking could be added to the virtual portholes so that the devices would have context depending on where they were located and how they are held. However, the cost of tracking is probably not worth the marginal benefit. Further, the web site would be easily updated by curriculum designers.

Virtual Reality

A virtual world was an early consideration for the Virtual Voyager project. In a virtual world, an animated model of the real world is displayed in which the user can interact. The software group decided that using a virtual world engine would be a good option for our overall project performance and would allow us to make a very extensible prototype. This alternative has the advantages of having a fixed virtual world as the user environment, which the user can use several times without having to interact with the outer world or other live sources. In addition, other features can be added, and other virtual worlds can be modeled. It gives the advantages of modeling the world according to our needs, against having to capture a real world and adapting the project to its varying situations.

This alternative would be primarily simulating a real world, but it could also work along with an interactive situation in other parts of the project. Interconnections between the virtual world and input from an outside source would not be very effective. However, interaction is an important issue in our project, so the users should be able to interact with the virtual world and receive feedback from the system.

There are some existing virtual models of Pittsburgh, so we could preview what a virtual model prototype would look like. Some professional modeling may be required for building a more realistic virtual world for Pittsburgh, or any other area that is desired.


Company Product Features Plataforms/ Requirements Price

Carnegie Mellon Alice Plug-in/Authoring Tool

3D Interactive Graphics Programming environment for Win 95/98/NT.

Plug-In Allows viewing of Alice virtual worlds.

Authoring tool allows to create worlds

Windows 95/98 or NT 4.0.

Pentium running at 90 Mhz

Fast VGA graphics.

WRAM>VRAM>DRAM

16 megs of RAM

Soundblaster-compatible sound car.

FREE

Kinetex 3D Studio MAX® R2.5

The world's best selling professional 3D modeling and animation software for PCs.

Export to VRML, Alice, Quake model, etc.

Microsoft® Windows NT® 4.0 or Windows® 95

64 MB RAM and 200 MB swap space minimum

Graphics card supporting 800x600x256 colors

CD-ROM drive

$3,495

Stichting Mathematisch Centrum.

Phyton Interpreted, interactive, object-oriented Programming language.

Interfaces to many Calls and libraries, as well as to various Windowing systems (X11, Motif, Tk, Mac MFC).

Portable (UNIX, Windows, DOS, OS/2, Mac, Amiga)

Supported by C compilers.

FREE

Idsoftware Quake II 3D action game

Can be customized as an virtual world engine

Free level editor and server bot can be downloaded

English Language Version of Windows 95 or NT 4.0 with 100% compatible computer system Pentium 90 MHz processor

Win 95: 16 MB RAM required (24 MB recommended) Win NT 4.0: 24 MB RAM required

100% Sound Blaster-compatible sound card Joystick and mouse-supported

Supports LAN and Internet play using the TCP/IP protocol.

$36.95

Table 21 – Virtual Reality Software

We thought Alice would be a good option for our project because it allows interactivity with the user.

Alice supports the features we were looking for in our project such as: taking control of the boat, more capability in modeling a virtual world; and it also can provide new feature options for our project: allowing travel in other places, time, or environment (air, space, underwater, etc.).

Alice is a virtual world engine that allows the user to create its own scripts that control the motion of 3D objects on a PC environment. There are a variety of things that Alice allows doing in objects, like moving, changing sizes, and making sounds. It also allows the user to explore the world while the objects perform these scripts, or to script the world explorer itself (since the explorer is also an object in this engine). Alice has been used for making


3D games (some of them networked and multiplayer), simple animations and for creating animated diagrams of 3D technical diagrams. Alice does not run on the Mac, or Unix systems. Although it doesn’t need any special 3D hardware to run, Alice will take advantage of any 3D board that accelerates Microsoft Direct3D. It can give a perfectly acceptable performance from a fast VGA board (in millions of pixels per second). Although a fast CPU is good, fast video is more important to Alice. WRAM gives a better performance than VRAM, which is generally faster than DRAM.

Alice uses Python as a programming language for the animation scripts. The hand painted textures are applied to all models in Alice using Amazon Paint, which allows the artists to apply hand painted textures to 3D models. Quake is a good virtual world engine, but the programming task to customize the virtual world is complex. Furthermore, we need to purchase the client software for every display, although the server is free.

Another technology looked at in depth was Informedia. This technology is meant for video storage and was pursued during the earliest visionary scenarios. Informedia provides a nearly unlimited storage space for video. Informedia was cheaper (free), readily accessible, required no maintenance, and required no additional equipment (save for a camcorder and some VHS tapes, which would be required by all databases used for this concept). Unfortunately, it required access to the database and technology from the classroom. The feasibility of this plan was finally deemed not likely considering the alternatives.

Virtual Reality Headgear

Since virtual world software was explored, a team also investigated headgear which allows for an immersive viewing experience. Although virtual reality helmets (or VR helmets) were ultimately ruled out, many suitable models were uncovered in the study.

Device Manufacturer/ Distributor Resolution Headtracking

i-glasses I-O Display Systems dual 180k pixel 789x230 per eye (effective 263x230) @ 256c

Yes

i-glasses X2 I-O Display Systems dual 360k pixel Yes

i-glasses Protek I-O Display Systems 640x480 (per eye?) Yes

VFX-1 Interactive Imaging Systems/3DIST/Mindflux

dual 180k pixel 789x230 per eye (effective 263x230) @ 256c

Yes

VFX-3D Interactive Imaging Systems dual 230k pixel @ 24/32 bit colors

Yes

Dynovisor (monoscopic) Takara/Retinal Displays single 180k pixel, 789x230 (effective 263x230)?

No

Scuba (monoscopic) Philips/Retinal Displays single 180k pixel, 789x230 (effective 263x230)?

No

VRD/BigTV (monoscopic) Virtuality/Retinal Displays single 180k pixel, 789x230 (effective 263x230)?

optional gyroscope headtracking

Mediamask Nissho Electronics/Olympus dual 512k pixel



Eye-Trek Olympus dual 180k pixel

PLM-A 55E Glasstron (monoscopic)

Sony/Mindflux dual 180k pixel No

PLM-S 700 PC-Glasstron (monoscopic)

Sony/Retinal Displays/Mindflux

dual 550k pixel? No

LDI-100 (NTSC)/LDI-100E (PAL) (monoscopic)

Sony dual Mega-Pixel: 832x642x3 per panel

No

Glasstron Sony/Retinal Displays/Virtuality

dual 180k pixel

Personal Monitor (monoscopic)

Personal Monitor single 180k pixel No

STV-E Nissho Electronics/Shimadzu

NTSC-TV resolution

Model 133 Virtual Reality 2560x1024

VR4 Virtual Research 247x230

VR4000 Virtual Research 247x230

FS5/FS5I Virtual Research 640x480

V6 Virtual Research 370x277 Yes

V8 Virtual Research 1920x480 per eye (effective 640x480)

Yes

Datavisor Hi Res n-vision 640x480ni, 1280x1024int

Virtual Binoculars n-vision 640x480 per eye optional

Datavisor VGA n-vision 640x480

Datavisor 80 n-vision 640x480ni, 1280x1024i

Vissette Pro n-vision / Virtuality 300 kPixel

DV-4 (Vissette Pro OEM) n-vision 300 kPixel

CyberEye CE-200S General Reality dual 180k pixel, 789x230 per eye (effective 263x230)

CyberEye CE-200M (monoscopic)

General Reality dual 180k pixel, 789x230 per eye (effective 263x230)

CyberEye CE-200W General Reality

Vista Vision (monochrome) Vista-Controls dual 640x480

See-Thru Armor Vista-Controls

MRG 2.2 (monoscopic) Liquid Image

MRG 3C (monoscopic) Liquid Image

MRG 3vga Liquid Image

MRG 4 Liquid Image 480x234

MRG 5 (stereoscopic) Liquid Image

MRG 6 (monocular & monochrome)

Liquid Image

ProView 30/80/100 Kaiser Electro-Optics Inc. 1920x480 per eye (effective 640x480?)

ProViewXL 35/50 Kaiser Electro-Optics Inc. 1024x768 per eye (full color triads?)



ProView 50ST Kaiser Electro-Optics Inc. 1920x480 per eye (effective 640x480?)

KEO HiDef 60/90 Kaiser Electro-Optics Inc.

SimEye 40/60/75/90 Kaiser Electro-Optics Inc. 640x480ni, 1280x1024i

VIM 500HRpv Kaiser Electro-Optics Inc. dual 180k pixel, 789x230 per eye (effective 263x230)

VIM 1000HRpv Kaiser Electro-Optics Inc. 800x600

VIM 3-panel Kaiser Electro-Optics Inc.

Full Immersion HMD VIM 6-panel

Kaiser Electro-Optics Inc.

Kopin Monocular HMD Kopin

V-Cap 1000 (monocular) Virtual Vision 640x480

FOHMD (Fiber Optica) CAE Electronics

Cyberface 2/3/4/5 Leep

PT-01 Optics1 Inc.

E-ZView/Viewtek Optics1 Inc.

Eyephone Nissho Electronics

Table 22 – Virtual Reality Headgear

Visionary Solution

Visionary Solution Introduction

Immediately after presenting the baseline scenario, and as other teams formed enabling technology investigations, the HCI team began iterating through various visionary scenarios—details of a potential Virtual Voyager experience. Early visionary scenarios were used as discussion platforms both with the Voyager staff and in-class; refinement of the visionary scenario gradually led to a list of design principles and facilitated initial architecture designs from software, electrical, and mechanical engineering groups.

Considerable changes took place during the four major iterations of the visionary scenario. Topics explored included the degree of interaction possible between the Virtual Voyager and the existing Voyager program, and the possibility of using the Virtual Voyager architecture to create different exploration themes in the future (such as boat trips down different rivers, or trips in other kinds of vehicles.) Although the scenario evolved as new principles were discovered, the current visionary solution still represents the large-scale view of an eventual system.

The visionary solution illustrates the proposed approach and technologies under consideration. Its purpose is to help the team and others to envision how the end-users would make use of the system and to reason about how it would modify the existing work process.

The main focus of the Virtual Voyager project, after finalizing the visionary solution, was to create tools for teachers and curriculum designers to enable


them to create educational experiences that will be participatory and interactive.

Participant Definition

As part of the visionary solution, the team identified three base user populations for the Virtual Voyager product:

Student—A 4th or 5th grade child who participates in Virtual Voyager as part of a class group of roughly 30 other students. By targeting younger children, the intention is to better engage the student in a playacting experience, create a larger pool of technology-aware users (though not necessarily proficient in a given technology), minimize breakage of equipment, and reach participants who (current Voyager instructors tell us) tend to get more involved in the experience.

Instructor—In a traditional grade school setting, the leader of the Virtual Voyager experience, most likely a classroom teacher or possibly a science teacher. In the current Voyager program, such instructors may not have a high level of science or math background and may need to be furnished with extensive pre-designed curriculum materials. In fact, the teachers like pre-packaged curriculum as it means they do not have to do curriculum design themselves. At the same time, however, state studies show that the classroom teacher has a high level of autonomy in the classroom and is primarily responsible for how material is presented. The teachers must deem that the activities in this experience are appropriate for their students and that it will not be too time-consuming to set up and administer.

Curriculum designer—These are the people who will be designing specific curricula who must be provided with the tools they need to design compelling educational experiences. Though all instructors are curriculum designers in this sense, this is the group of users who help design new data sets for the Virtual Voyager experience. Although this group is not specifically targeted in this initial project, the base technology had to be designed with this future constraint in mind.

Design Principles

As visionary scenarios were created, a set of guiding design principles emerged. Once identified, each aspect of the future design was weighed against this principle list, which was broken down into four areas:

The student experience . . .

Must be hands-on and participatory

Must have multiple stations and multiple activities

Emphasizes group cooperation

Emphasizes process

Must be completely safe

The curriculum designer . . .


Must be enabled by each system and tool provided, allowing the creation of compelling student experiences

Must not be bounded by a specific defined curriculum (though a representative experience will be chosen as a design case)

Must be able to provide experiences which are not available on the physical Voyager

The existing Voyager program . . .

Must be largely unaffected—the current crew will continue all their duties and any recording and sensing devices placed on the boat will not require their attention

Must continue to train and prepare teachers for the Virtual Voyager much as they do for the physical Voyager (both in the use of devices in the new Virtual Captain’s Chest and in the use of Voyager curriculum materials

Must not lose funds—the Virtual Voyager program will be self-funding and will be capable of reaching many more classes than the physical Voyager (a 10x increase)

The data comprising the Virtual Voyager simulation . . .

May incorporate synchronous elements, but will be largely asynchronous; the use of asynchronous data . . .

Allows the duration of the experience to be adjusted to many different remote needs

Allows Virtual Voyager to run year-round and at any time during the day

Allows any number of Virtual Voyagers to exist simultaneously, limited only by the capital cost of the equipment

State Curriculum Requirements

Discussion with the Voyager staff revealed that state curriculum requirements must be met by any new educational experience. The Pennsylvania department of education maintains a list of standards which dictates what students in grades 4, 7, 10 and 12 must learn by the time they enter the appropriate grade. The schools are expected to work from this list of standards and develop their curriculum accordingly.

The experiences in the visionary solution were matched against these state requirements as shown in table 23 (next page):


Standard Requirement Virtual Voyager

4th Grade

Identify life processes and organisms with similar external characteristics. Know that all living things need air and water to survive.

Virtual porthole can show organism and any related information (pictures, text, etc.).

Identify waste and pollutants from manufacturing plants. Identify pollutants and their effects.

Could be done by ‘time travelling” back to the 60’s when the Mon was dead.

Students should know earth processes such as oxidation, weather, erosion, knowledge of different seasons to explain effects on animals.

All of our feedback devices can show how temperature, oxidation, pH, depth, etc changes with time (say measured in seasons).

Identify the effectiveness of graphic reproduction (say film, sketches, pictures).

Could see how effective learning about organisms is via computer models which represent parts of the animal graphically.

Use of basic computer input devices or software or online searches

Virtual Voyager itself incorporates many disparate computer input devices.

7th Grade

See how environmental changes affect survival of organisms and species. Identify environmental impacts that waste has on environment

Can again be effected by “time travelling”, or by a specific pollution-based virtual scenario.

Distinguish the differences between fresh water and salt water in terms of life

Can be done by placing the virtual ship in any geographic location.

How to use tools/instruments to measure size, weight, shape, and temperature of the living and non-living. Use of computer here is important.

A number of stations can be created that involve these sorts of instruments.

Problem solving. Scientific theory and facts. General concepts which are well embodied in the entire Virtual Voyager system.

• Explain how water is necessary for all life.

• Explain how the physical components of aquatic systems influence the organisms that live there in terms of size, shape and physical adaptations.

• Describe the life cycle of organisms that depend on water.

• Identify organisms that have aquatic stages of life and describe those stages.

Allows all sorts of traditional experiments / labs / stations to be incorporated into the Virtual Voyager surroundings.

Table 23 – Pennsylvania State Science Curriculum Requirements

ScenarioTeacher PreparationMrs. Clark is a fifth-grade teacher at Valley Elementary School. Last year, she heard about a new program designed by educators in Pittsburgh, Pennsylvania called Virtual Voyager. Based on a real boat which takes school kids on a four-hour trip along Pittsburgh’s Three Rivers, the program allows grade school teachers to turn any room into an imaginary boat. The virtual boat then becomes the setting for all sorts of learning opportunities. In addition to the provided curriculum materials which are based on the programs developed by the instructors on the real boat, many other subjects can be brought “on-board” and taught in the context of a river voyage.


After hearing about success with Virtual Voyager at other area schools, Mrs. Clark recommended that Valley look into it. She was sent to Pittsburgh for a two-day training session that summer, where she took a trip on Voyager, experienced the environmental science and “boats, bridges and water” curriculums first-hand, and learned more about the philosophy behind the Voyager educational experience. Then she returned to Valley Elementary to plan out her own curriculum for her students.

Now it is November, and the Virtual Voyager materials are about to arrive. Mrs. Clark and the other fourth- and fifth-grade teachers at Valley have been prepping their classes for two weeks, spending a part of each day discussing the activities which the students will participate in. The Virtual Voyager will be set up at Valley for a week, with each class getting a full half-day to take their voyage.

Set UpSeveral different use models for VV were proposed, each with different funding, staff, and expansion requirements. Here, a Voyager staff member delivers and sets up the system. Ultimately, a simplified approach which allows teachers to do all set up was adopted.

On Monday morning the Virtual Voyager van, painted to resemble a boat, pulls up in front of Valley Elementary. The driver, Stan, is wearing a Virtual Voyager crew uniform. Stan is met by Mrs. Clark’s teacher’s aide, Mr. Stone, and about a dozen 4th and 5th grade students who have volunteered to help set up. Stan opens the back of the van and begins to distribute the smaller boxes to the students; he and Mr. Stone carry the largest crate. Two of the students carry a long and mysterious bundle which looks like a roll of carpet with some cords attached to it.

They all proceed to the school's lunchroom, where the Voyager will be "docked" for the week. First, the carpet is unrolled to reveal a color-coded layout of the Virtual Voyager’s deck. Stan explains that the layout shows where all the boxes should be placed, and the students begin to arrange the pieces of the boat. In addition to the boxes from the van, the school had provided some tables, chairs, and a riser. Stan and Mr. Stone help place these on and around the Virtual Voyager layout.

Brandon is working to assemble the communications center. A box has been opened and the equipment inside has been spread out over a table in the middle of the room. Mr. Stone helps Brandon insert the green cords into the green plugs and the red into the red. In the meantime, Kelly is hanging some posters—a Pollution Timeline, a map of the Three Rivers, and pictures of the real Voyager.

At the front of the room—swiftly becoming the bow of a boat—four students have been assembling a lightweight PVC-pipe frame. A muslin screen is stretched across it, and the frame is raised almost like the hoisting of a sail. Stan adds a crossbar to the front of the frame, climbs a stepladder, and quickly hangs lights and other devices from the bar. In the meantime, Mr.


Stone unpacks a video projector and mirror behind the screen, placing them according to the guidelines on the layout and instructions on the projector itself. In front of the screen, underneath the bar, the riser is positioned so that it forms a raised area at the front of the boat—the pilot’s house. A table is lifted onto the riser, and kids begin to unpack yet another box full of equipment to put on the table.

A fundamental idea of Virtual Voyager is that an educator can create any activities she wants to within the space of an imaginary boat. “Bow” and “Stern,” used throughout the scenario, represent convenient physical spaces to separate a class into; what goes on in those areas is up to the teacher.

As the VV design team chose portions of the solution to implement, the focus was on sets of enabling artifacts which could be developed to create a base experience—the piloting and navigation of a boat. Stations involving such activities as chemistry or history can take place anywhere on the boat and require no special equipment; these were left out of the limited prototype developed.

After 45 minutes, the room has been transformed. The largest crate has been positioned in the center of the room just in front of the communications table. Stan slides open a compartment on the case to reveal connectors and a coiled power cord, which Mr. Stone takes to a wall outlet. As Brandon, Kelly, and the other kids watch, Stan quickly connects all of the other equipment. To their surprise, each device has been placed on the Voyager layout carpet just above sockets which are in the carpet itself. Kelly looks closely as Stan connects a cable, and she can see that the cords which were on the outside of the carpet roll, and which are now running underneath, have connectors which peek up at various places to allows things to plug into them. “All right, crew, we’re ready!” Stan says. “Brandon, fire it up!”

Brandon flips the switch on the crate, and after a few seconds the screens begin to flicker to life. Stan shakes hands all around and congratulates his crew as an image from the main Virtual Voyager computer, inside the crate, is reflected onto the curved screen surface at the front of the room. From the kids’ point of view, standing in the “boat,” it looks like the screen is really three large windows which look out the front of Virtual Voyager. Stan says goodbye to his team and tells them that he hopes to see them again at the end of the week, for teardown. He leaves the lunchroom as the rest of Mrs. Clark’s class starts to file in.

Pilot House and Engine Room station (Navigation activity)Since Mrs. Clark brought Virtual Voyager to Valley Elementary, her class gets the honor of taking the first voyage. During the morning, they’ve been divided into three groups (nicknamed the Steelers, Penguins, and Pirates) and they have chosen roles within the groups for each station.

The Steelers are going to start the day in the Pilot House and Engine Room station. Jamal is the Captain for the Steelers group. He steps up onto the riser which simulates the ship’s bridge and is immediately struck by the realism of the scene. The screen is showing the dock and the Science Center to the port side, and in the distance, a bit to starboard, the fountain at Point State Park is flowing. Just ahead of Jamal the USS Requin is bobbing right off Virtual Voyager’s bow. From the speakers behind the screen, Jamal can hear water lapping against the side of the boat and birds calling from the trees on


shore.

Directly in front of Jamal is the ship's wheel. Just above the wheel is a set of gauges and LED indicators showing everything from heading and speed to the depth of the water. Jamal puts on the wireless communication headset. He starts the checklist procedure. First he conducts a radio check to make sure everyone's radio is working properly. "Navigation?" (Check). "Engine Room?" (Check). "Bow Mate?" (Check). "Stern Mate?" (Check). Next Jamal radios the Engine room the check the status of the engines.

Sarah, the Engineer, is sitting in a chair at a table at the back of the room. She and her assistants have a panel of gauges and controls in front of them. The Captain calls to the Engineer to check the status of the engines. The Engineer scans her gauges and performs a few calculations on the fuel tanks, then radios the Captain that all systems are go. The Captain gives the order, Sarah turns the knob—and the engines roar to life! The thundering engines startle the Engineer and her assistants—everyone can hear them, but they are loudest in the “engine room.”

Next Jamal radios Navigation to see if they have finished setting the course. Juanita has just finishing plotting it, using the river chart spread out on the navigation table; for this section of the class, their orders are to navigate down the Ohio to the High Level Bridge. David checks the radar scope one more time to make sure that a barge has cleared their path. Linglin monitors the depth sonar to make sure the ship doesn't run ashore. On the table, a virtual compass indicates where north is—not in the Valley classroom, but in the virtual world of the boat. The radar, sonar, and other navigation equipment, like Jamal’s and Sarah’s gauges, look like their counterparts on the real Voyager—but they all reflect the position and heading of the Virtual


Voyager instead. Juanita radios back to the Captain that all is clear to get underway—and she’s suddenly thrilled and nervous to think that they’re about to set sail!

The “virtual porthole” referenced in three sections of the scenario may need some additional explanation. The “porthole” part of the name is simply an attempt to keep the device in a nautical theme, while connoting that the screen is a window to another place. The device is a kid-sized handheld screen, with special function buttons, that can be used for many different activities; in this case, the screen is displaying another view of the virtual world shown on the main front screen. There’s one important difference: position sensors within the virtual porthole allow the user to aim it anywhere and “see” in that direction.

The Captain then radios the mates at the bow. Earlier in the morning, while the class was dividing into group back in their classroom, Simon and Letisha had demonstrated the proper method of donning a life jacket. Now they have another important job—to check for debris in the river before Jamal can start. To do this, they use a virtual porthole—a handheld screen which they can aim over the side of the boat to “see” the virtual river surface. All is clear, so they radio the captain to announce that it is safe to get underway.

The Captain radios the engine room to engage the engines ahead one quarter as he sounds the horn to signal the rest of the crew. He turns the wheel to starboard as the images on the view screens show the ship turning away from the dock. Navigation is busy tracking the movements of Virtual Voyager and radioing the Captain to make minor course adjustments; the team back in the Engine Room continues to monitor engine status. And the students all look up in surprise: as the boat starts out onto the river, variable speed fans mounted on the crossbar at the front of the room have begun to create a gentle breeze, which varies as the boat picks up speed.

When he has a moment to spare, Jamal grabs the virtual porthole to check river traffic and also in hopes of spotting a rare breed of waterfowl—a button on the porthole allows him to zoom in as if he were looking through a pair of binoculars. There's not much time for bird-watching, though—after a short time Navigation radios that the weather station is reporting fog and that they'll have to navigate to the next lock and dam with nothing but the radar and GPS receiver.

This part of the scenario is a concession to an earlier concept of the Virtual Voyager’s interconnected-ness to the real Voyager. Our original scenarios proposed a wide-band-width connection to the boat in real time, with video and audio from the actual voyage being avail-able to remote students; this was dropped for technology reasons as well as for social reasons (difficult for a large number of Virtual Voyagers to all interact with the real ship.)

Suddenly, an unfamiliar voice crackles across the Steelers’ headsets. It’s Trisha, one of the instructors from the real Voyager, checking in! The instructor is on land, back in Pittsburgh, and is sitting at a desktop computer tracking Virtual Voyager classes on the web. She can see where Mrs. Clark’s class is on the river. She points out that the class should be able to see the real Voyager as it passes by them to port. Sure enough, a minute later the computer screen on the left shows an image of another ship heading down the Ohio. Jamal chuckles as he thinks how fun it would be to run his ship into theirs, but he knows that Mrs. Clark wouldn’t think it was fun. It’s cool to know he could do it, though. Let those kids on the “real Voyager” try a stunt like that!


Stern station (Water quality and Macroinvertebrates activities)

Although the Virtual Voyager experience could end with the navigation activity, there are many opportunities to cover other requirements within the boat setting, as per the state requirements for elementary education information above.

Each year, Mrs. Clark does a unit which introduces her fifth graders to simple science experiments. After reviewing the curriculum booklet provided by the Voyager staff, she decided to incorporate these experiments into the virtual voyage. She feels that the imagined environment is truly rich and memorable for the kids, and she doesn’t want to miss an opportunity to make the experiments more real for them.

Some of the necessary devices were part of the Virtual Voyager package, and the rest of the lab equipment was borrowed from the local high school. Towards the stern of the “boat,” Mrs. Clark’s parent volunteer Ms. Johnson has set up a pair of tables with all the gadgets laid out.

The Pirates team has started the day in the stern. Mark is looking over the Water Quality table and thinking that some of the stuff there looks like his older brother’s chemistry set. But there are other devices which he recognizes from pictures that Mrs. Clark showed them of equipment on the real boat—a dissolved oxygen meter, temperature readout, and pH meter.Earlier in the week, Amelia’s mom Ms. Johnson had taken them outside to a local stream and they had each collected a water sample. Mark takes his vial of water around the table and performs each water quality test in turn: temperature, titration, dissolved oxygen and pH. Mrs. Clark is also having each of them log the numbers they get onto a sheet. Next week, after the Virtual Voyager is gone, Mark knows that they will be gathering all of the data together and charting it so that they can compare the water samples.

Next to the Water Quality table is the Macroinvertebrates table, with trays and big magnifying lenses to look for tiny water insects. In addition to creek water, Ms. Johnson had helped them collect bottles of gunk from the creek bottom. Now the Pirates set up trays and fill them with the gunk.


Tamara is looking through a magnifying lens. She is disappointed that she cannot find a spider mite—they looked so cool in the pictures they studied! But her excitement quickly returns as her partner Joshua holds up a second virtual porthole. By clicking the buttons, they can see images of bugs which have been retrieved over the years by Voyager. They press another key on the virtual porthole, and part of the screen shows sketches of sample macroinvertebrates to aid in the identification.

Bow station (Flags, Shore information, Bridges activities)The Virtual Voyager curriculum booklet had plenty of suggestions for possible activities, and Mrs. Clark has adapted a couple of them for her third and final station. But there’s a signal flag activity which Mrs. Clark and her aide Mr. Stone have come up with themselves. If it runs smoothly, they plan to send a suggestion back to the Voyager team to be incorporated into future curriculum booklets.

The final group of students, the Penguins, start in the Bow station with the signal flags. As Virtual Voyager pulls away from the dock, Captain Jamal uses his horn to hail a passing barge. Patrick and Mary, on the boat, have to send a hailing signal to Jean and Sharon, who are playing the “barge.” The barge, in turn, signals back to Virtual Voyager.

Mary is holding the third virtual porthole device, and with it she is looking at a map of the rivers. The map in the virtual porthole isn’t as detailed as the paper navigation charts, but it has one great advantage—Mary can use the buttons on the device to select each area along the riverbanks. Pressing another button reveals information about the docks and buildings located at that point in the bank. Mrs. Clark has asked each of them to take five minutes and find an interesting spot along the Pittsburgh rivers—and Mary decides on a lonely private dock just across from Brunot Island. She makes a note on her log sheet and passes the virtual porthole to the next student.

Lamar and a few other students are paying attention to the upcoming bridge. They work together to try to identify the bridge from their book of river charts, and they radio the Navigation team to see if their result matches the current position. Navigation radios back readings from the depth sonar, radar, and GPS devices, which Lamar records on a sheet. Lamar and his friends use a virtual altimeter to calculate whether or not the boat will be able to fit underneath the bridge. The altimeter looks like a gun; when it is pointed towards an object and the trigger pulled, it reads off a height based on the angle at which the altimeter is held. But the Virtual Voyager altimeter is special—it can be pointed at the front screens and can report the heights of bridges and other objects in the virtual world.


“Captain? The bridge is clear. Proceed.” Lamar relays the message to the Captain, and Virtual Voyager sails on. As they pass under the bridge, the Captain contacts his crew and tells them that their leg of the voyage has been successful.

After an hour, it’s time to rotate to the next station. Mrs. Clark makes the announcement a few minutes early so that kids have a chance to finish logging their data, cleaning up the chemistry equipment for the next group, and saying a final goodbye to their teammates on the navigation headsets. Then each team’s rotation manager leads the rest of the team to the next station. The Virtual Voyager passes the Science Center again on its way down the Monongehela for the second leg of its journey, and Mrs. Clark jots a few notes to herself. Everything is working wonderfully—the kids are as focused as she’s ever seen them—but she’s already having some new ideas for next year’s voyage.


Device Realization

Device Realization Introduction

Through March and April, the Virtual Voyager designers began to design and build the set of devices which had been envisioned in the first half of the semester.

Before this could happen, consensus had to be reached on a reasonable subset of the functionality described in the visionary solution. This was done based on several criteria:

Devices proposed in the visionary scenario were combined where possible; for example, a separate virtual binocular visualization device was collapsed into the virtual porthole.

Client feedback gathered from the Phase I presentation allowed the Voyager staff to express their views.

A meeting with curriculum coordinators for Voyager further narrowed down the scope.

As indicated in the visionary solution notes, portions of the Virtual Voyager which did not strictly depend on new enabling devices were dropped from consideration.

Class discussions eliminated some of the artifacts as well as some artifact functionality.

The teaching staff approved the final decision.

Given the list of devices and programs which needed to be implemented, the class then split into three functional groups which were cross-disciplinary. In addition, the software group continued to work to create needed infrastructure, and a new volunteer group formed to create a virtual world to act as a prototype data set.

In this final section, each implemented device, program, or subsystem is discussed in narrative form (the process story for that artifact) In addition, all technical details of the artifact’s design, software, and hardware are listed.

In each case, the report relies on information furnished by the team which created the device. Where information was not supplied, occasionally it has been drawn from earlier written records.

Supporting Technologies

Virtual Voyager Computers

Process Story

Throughout the design of Virtual Voyager, it was always assumed that a computer or set of computers would form the backbone which would attach disparate input and output devices together. Early on, the hardware and software disciplinary teams had to consider the distribution of processing over


all these devices; had each input/output device been given more processing power (as investigated in the Handheld Computing Devices research, page 37), less processing power would have been needed in the central computer(s) and vice versa.

High costs for handheld processors and the very small processing requirements of most of the needed devices led the architecture teams to decide that the processors should be centralized. That meant that each device became much simpler, but that more computers were needed to tie them all together.

Additionally, the separation of the team into three groups, each concentrating on their own device or set of devices, meant that each team tended to design around their own computer. Although a future version of the product could conceivably combine some functions, the prototype version developed here ended up with four separate computers, networked together to provide communication, and each driving one or more of the devices.

Once the decision to run four machines were made, their specifications could be drawn up. All of the teams had designed for Windows as the underlying operating system, but in the end the machines had to run different versions of Windows—Windows NT, the more stable version, where possible, but Windows 95 for machines which required game port device drivers or enhanced function graphic cards (features which are not due to be supported in Windows NT until version 5.0).

Design

In the implementation phase, the four computers were specified and their sharing of functions defined.

The computer running the navigation software is configured with Windows NT 4.0, while the other three computers are configured with Windows 95. The configuration of each computers is as follows:

State Server computer - The GSS (global state server) software runs under Windows 95; the same machine has a display and can serve as the administration terminal. The ship’s wheel, throttle, and gauges are also connected to the server, with the throttle and wheel connected to the game port, and the gauges connected to the serial port. The state server machine also has an Ethernet card to support network connection, and a sound card to provide ambient sound.

Screen/Projector computer - This Windows 95 computer is responsible only for rendering Virtual Voyager’s Alice world and sending the output to the projector. Two video cards in the machine allow a standard monitor for configuration and setup, and a separate card to handle the direct video output for Alice. The machine also has an Ethernet connection, used to receive information from the GSS about the position and heading of the virtual boat.

Porthole computer – A second computer running Alice is required by the virtual porthole device. Its parameters and configuration are identical to the computer used for the screen/projection—two video cards, a standard monitor for setup, and Windows 95 as the operating system. In this case,


however, the second monitor is the virtual porthole itself. Additional connections from the porthole attach to the computer’s game port and serial port, enabling the porthole buttons and the porthole’s tilt sensors. An Ethernet connection allows the Alice world to receive position and heading information from the GSS.

Navigation computer – The final machine is the only one which can run Windows NT, since we do not need to access the game port or run a second video card. This computer is the only one used by the children in a traditional sense, where the e-map program is accessed via mouse and keyboard. It has a large monitor to facilitate the use of the e-map. Again, it has an Ethernet connection to the network to receive information from the GSS. And a single device, the altimeter, is connected to the computer’s serial port.

Software

To find specific information about the software which runs on the Virtual Voyager computers, both commercial and custom, see the section for the specific device or program below.

Hardware

To see detailed specifications for the computers which were used to run the prototype, see the Computers and Cabling section on page 9.In general, Virtual Voyager requires four Windows class PCs with sound cards, game ports, and Ethernet network capability. Fewer computers may be used if portions of the Virtual Voyager device set are not needed.

Headsets

Process Story

On the actual Voyager, communication among personnel is very important. The crew not only needs to perform ship-to-shore communications as part of their operation routine, but they need to be able to communicate with each other from any part of the ship.

Early designs for Virtual Voyager tried to capture some of these processes and simulate them for the students. Although the idea of actual communication with the Voyager captain or with Voyager staff members was pursued, it was eventually dropped, along with all requirements for connectivity outside of the classroom.

But it was still important to the team to have an element of aided communication, not only to allow focused conversation in a loud classroom, but also for the experiential value of wearing an actual headset. In the final prototype, students wear inexpensive short-range headsets. They are lower-tech and easier to maintain than computer-based communication systems, and help lend an feeling of importance to the ritualized conversation which is carried out with them.


Design

The final store-bought product was chosen mainly for its sufficient operating range and wide availability through Radio Shack stores. This ease of attaining the product makes replacement much simpler. The operating procedure is also relatively easy—talking into a headset causes transmission to all other headsets in range. The headsets may also be uses it in a manual mode, where a button must be pressed to transmit.

Note that each pair of headsets comes ready to transmit on two channels, labeled A and B. All headsets which need to be communicating need to be set to the same channel. The availability of a second channel allows two sets of students to be communicating independently, which teachers may find useful for future applications.

Hardware

Radio Shack Headset #21-406.Transmits 49MHz FM.9V battery required.Operating range is ½ mile.A pair costs $50 (sale priced; $70 list)

Administration Terminal

Process Story

As the software team conceived and designed the GSS and boat simulation architecture, it became clear that some kind of administrative control program would be needed. The teachers would have to be able to begin, end, and reset virtual voyages, as well as have a way to monitor what was happening. Perhaps not as important to the teachers, but needed for diagnosis of problems by Voyager personnel, the program would also have to be able to detect which devices were plugged in and working at any given time.

Thus the Administration Terminal program was born. It runs on the same computer which hosts the GSS and boat simulation, and via that computer’s keyboard and monitor allows the teaching staff to oversee the experience, usually from a corner of the classroom.

While the administration terminal did not change in substance over the course of redesign, it did emerge several times as a likely candidate for enabling functions which might not be accessible from the other devices. For example, as the demonstration task was defined, it became clear that the boat would have to be “docked” at some point and be allowed to “refuel.” Although no device explicitly supported a refueling function, it was made possible, and swiftly implemented, via the administration terminal’s ability to directly edit parameters in the simulation (such as fuel tank levels.)

Design

The administration terminal is used for three purposes. It will allow the user—a teacher overseeing the virtual voyage—to start, stop, and pause the


simulation. It can be used to see if a component is working correctly. And, in the full design of the system (but not implemented for the prototype), it will allow loading of different virtual environments into the simulation. The administration terminal is not intended to be used by the students who are participating in the simulation.

Simulation control – The administration terminal allows the user to start, stop and pause the simulation, and invoke “disaster scenarios” (i.e., change the parameters of the system and allow the students to respond accordingly.) This feature will be used by the teacher or Voyager staff member to actually run the simulation, by the administrator to determine any problems with the system, and by the virtual world developer to test any newly created virtual worlds.

Maintenance and Diagnosis - This will allow users to determine if other components are set up and functioning correctly. This feature will mostly be used during setup at a school.

Loading and Storing of Virtual Worlds - The loading feature allows a virtual world to be loaded into the simulation. When new worlds are created, the curriculum designer will need to be able to load, test, and store new world information and parameters. This feature of the system has been planned but not fully executed.

Software

The administration terminal program can run on any system with JDK 1.2. It has been tested on Win9x, WinNT, and Solaris.

Hardware

The program requires a standard Windows PC, monitor and keyboard. Network connectivity is needed if the program is tracking devices which are managed by other computers (as with the virtual porthole or altimeter in the prototype setup.)

Alice World

Process Story

In the original conception of Virtual Voyager, actual video from real voyages —whether live or recorded—figured heavily. Some kind of connection to the “actual boat experience” was desired, and this didn’t seem possible with footage and images from the real boat. Early proposals ranged from video cameras which captured trips from all angles for later playback, to live cameras worn by students on the boat and sent out to Virtual Voyager classrooms across the country. Problems were identified with the sheer amount of data involved, as well as social interaction problems—how many different classrooms could be integrally involved with the operation of one boat at a time?—and logistical problems with having to schedule around a limited number of actual voyages.

But when the idea of Virtual Voyager as a boat simulation arose, many of these objections became moot. In a full-fledged simulation, where all of the


visuals are completed generated by a computer, the students have complete control of their environment. And future curriculum designers can take future classrooms to entirely new, even imaginary places.

The new problem which arises is how to create those simulated vistas, and how to make them look as realistic and as interesting as possible. As the idea for a full simulation developed, a team did an enabling technology study of existing virtual reality software (q.v.) Alice was ultimately chosen as the best solution; in an early feasibility study, the following conclusions were made:

Alice provides all of the functionality that needed for the prototype development.

Alice is free. There are no copyright fees or any payment needed for using this software as a development tool.

Alice runs on the PC platform, which is the most common type of platform for portability issues.

All of the development tools and software needed to model worlds in this engine are available to Carnegie Mellon students at no additional cost.

It is being developed at CMU, which is a great advantage for technical support and use of previously designed software. This enables Virtual Voyager staff to better understand and use this software.

Alice is relatively easy to implement, which is a great advantage to develop a prototype of the software. If necessary, the virtual world engine can be changed later without affecting the rest of the system.

An additional reason to use Alice, not made explicit at the time, was that one of its primary developers and maintainers was present in the Virtual Voyager team, as well as several students who were being trained in its use for another class.

When Alice was settled on as the basis for the virtual world, a subteam was formed of people who could create a sample world for the prototype. After using a preexisting world for the first presentation, developing versions of this sample world were demonstrated in the second and final presentations.

Design

The virtual world needs to be centrally located on the Virtual Voyager computers, but each device which requires a view of it needs to run its own copy of Alice. The GSS data, and a special program called AliceLink, allow the multiple copies of Alice to maintain different views onto the same Alice world. Ultimately, the central database can contain not only multiple Alice worlds, but different scenarios for possible trips within a world.

The world is displayed on a screen at the front of the classroom, simulating windows from the pilothouse of the boat perspective. The students should be able to pilot the boat via the control devices (wheel, throttle, and so forth), so position information within the world must be read from the global state server. Some restrictions should be added to the moving degrees of freedom of the boat (no lifting movements), unless a new context—a plane, a magical flying boat—is desired. If the navigational mode is provided, there must be


some restrictions for the river boundaries, and solid objects as well. This way the boat will not navigate outside the river and will not pass through an obstacle such as another boat or a bridge pile.

The virtual world environment should also include some animation rendering such as birds (for a bird watching station), boats and other objects in order to make the world more active. Some other objects could be seen with the help of other display devices such as the virtual porthole, in which the world can be seen without any movement restrictions. The world should also have a modeled background, so it can give a more realistic view.

The virtual world will display the world according to where the controls tell them to, but it also depends on the boat simulation software providing information such as the speed and power of the boat. There will be some different scenarios like emergencies in which the boat movement will be restricted by the boat simulator, and some displays can be uploaded from a file manager to provide this emergency situation.

As a future development, the virtual world needs to respond faster, especially within the porthole display. To enable this, a better porthole tilt sensor will be needed. Moving the input devices closer to the boat simulator may help decrease the latency between changing an input device and the output on the screen.

Software

AliceAliceLinkJDK version 1.2.1 (should be backwards-compatible to 1.1.5 or earlier)

At this time, Alice runs best on a Windows 9x operating system.

Hardware

VooDoo II display card (or any display capable of rendering D3D)A network card is also needed to synchronize two or more Alice world displays via AliceLink.

Sound

Process Story

Sound was always an important part of the design. Ultimately, it had been hoped that both ambient sound (the river, birds) and simulation-driven sound (the motors, a passing barge) could be combined and broadcast into the room. An early idea was to localize the sounds within the classroom, so that the sounds of the boat were realistically placed. The more complex ideas were dropped both out of time considerations and because of the split among different groups of the sound-producing parts of the system.

Alice has its own sound capabilities and was ideal for certain sounds (ones that were initiated by devices that are connected directly to the Alice world, like the button for the ship’s horn on the wheel). The GSS machine was


deemed adequate for other ambient sounds, and a small sound server application was written to supply these.

Thus, the prototype system had to integrate sound from two different sound cards and broadcast them on normal speakers. To achieve this, 55W speakers from Radio Shack and the least expensive amplifier that produced a reasonable sound quality were bought. The initial design involved creating cables to join the two signals and pipe them into the amplifier. An early trial with this demonstrated, however, that standard PC sound cards do not have the necessary diodes the sound card output to prevent the signal from one computer from entering the other computer via its headphone jack, ruining the jack or even the board. As a result, an inexpensive mixer from Radio Shack was used this to combine the two signals.

The sound server itself also presented some problems. Originally, the idea was to write it in Java and thus integrate it more tightly to the GSS and boat simulator programs. However, Java in its current version cannot mix two or more sounds; when Sun releases an announced update, the sound server can be rewritten.

Using C++ or C to implement the sound server under Windows would have required extensive knowledge in DirectShow programming using DirectShow SDK. The final decision was to use Visual Basic, which is simple to use and can support sound mixing.

Even after these concessions were made, the sound server still will not mix more than two sounds at once on some hardware. This is thought to be a limitation of certain sound cards.

The sound server was supposed to be embedded in the boat simulator, which was also written in Visual Basic. However, this version of the boat simulator was abandoned in the final week; as a result the sound server was orphaned. The boat simulation’s TCP connection code was ported to the sound server, and it became a stand alone application which can communicate with a TCP server (similar to both the GSS and boat simulation.)

Design

Sounds in Alice, which can play only one distinct sound at a time, were left up to the discretion of the virtual world builders. The rest of the sounds were handled by the sound server application, which plays different sounds according to the state of the world:

River sound - Always plays

Engine sound - Depends on the current RPM (revolutions per minute) of the engines as reported by the boat simulator

Crash sound - Plays when the boat collides with a object in the world

Horn sound - Plays when the horn button is pressed on the wheel

More sounds can be handled by the sound server, if not by the Alice world.

Figure 3 – sound_infile.txt Figure 4 – sound_wavfile.txt


Two configuration files are needed for the sound server. One, sound_infile.txt, specifies the TCP information, while sound_wavfile.txt specifies the wav (sound) file locations.

Software

Requires a 32-bit Windows platform (NT or Windows 9x).Tested on NT 4.0 and Windows 98.

Also requires the ActiveMovie control (comes with Internet Explorer 4.0 or greater.)

The sound server program is packaged as boatsound1.cab. All components within the .cab file (DLLs and OCXs) must be placed in the Windows system folder. To be on the safe side, install VB 6.0.

Hardware

A sound card is needed. The following sound cards were tested by Microsoft and have been guaranteed to work for the ActiveMovie controls:

Truevision TARGA 2000 Pro, DTX, and RTXmiro Computer Products miroVIDEO DC30miro Computer Products miroVIDEO DC20Creative Labs Sound Blaster AWE32 PnPFAST Electronic AV MasterWinnov Videum AVConnectix Color QuickCamBroadwayATI All in WonderIntel Smart Video Recorder III

Mixer: Optimus Stereo Disco Mixer SSM-50

Amplifier: Optimus SA-155 Integrated Stereo Amplifier

Speakers: Optimus Pro X77

Global State Server

Process Story

In Virtual Voyager, many specially built input and output devices—throttles, wheels, gauges and screens—work together to display and control the same boat simulation. The key component which allows these devices to work together is a program known as the global state server, or GSS.

The GSS facilitates the transaction of shared, system wide variables between the separate software and hardware components in order to control the state


Figure 5 – Sound System Setup

localhost <- remotehost name5000 <- remotehost port9900 <- localhost port

C:\sound\water.wav <- water soundC:\sound\boat.wav <- engine soundC:\sound\horn.wav <- horn soundC:\sound\crash.wav <- crash sound

of the system, acting as a moderator. When one value is updated by an input device, all components in the system are notified of the change simultaneously.

The earliest design decision in the development of the GSS was to use the capabilities of the Java programming language's Remote Method Invocation. The reasons behind this were simple. First, the Java language works quite well as a development language for rapid prototyping. Second, network programming is a very difficult skill to master. The inherent design principles of Java hide the intricacies of this from the programmer, allowing novices to write powerful network applications with a steep learning curve. Finally, Java RMI allows the programmer to easily interface with other RMI systems. Whole data objects may be transparently transferred across a network with a single function call. This ability greatly magnified the capabilities of the GSS. Without RMI, the GSS would be limited to storing primitive data types (for example, integers, strings, and boolean values.) Java RMI allows the GSS to store literally anything.

Design

The final Virtual Voyager architecture centers around the idea of modularity, allowing components to be easily modified, added, or removed from the system. The global state server maintains all the states of the entire system, such as the world Virtual Voyager is in (whether the Three Rivers or the Amazon), the boat’s current heading and position, and the engine status. All of the components communicate with the GSS, fetching current states and updating new states as defined by the functionality of each component.

The key to modularity lies in the common server interface that defines the language with which a component can talk to the GSS. Defining this common interface means that the GSS does not have to worry about what kind of functionality is provided by a particular component that it is talking to, allowing a given component to be changed without having to change the GSS or any other components connected to the GSS.

The components that comprise the current architecture are: boat controls, gauges and other instrumentation, an electronic map, virtual reality displays, the virtual reality engine, an environment manager, a boat simulator, and an administrator terminal. The boat controls are physical devices such as the wheel, throttle, engine valves, and any other control devices that affect the state of the boat.

These devices mainly feed control information to the GSS, but may also receive information back from the server if they are force feedback devices. The gauges and other instrumentation are devices that display the current state of the various parameters of the boat, such as the engine RPM, speed, position, or engine temperature. These devices receive various boat parameters from the global state server and display them appropriately. The virtual map is a device that displays navigational information such as the river chart and the location of the boat, as well as allowing the user to interactively plot the course of the boat or request additional information about the various spots on the map. The virtual reality engine is the component that is responsible for generating the virtual world environment in a displayable form.


It receives information such as the boat’s location and the current world from the global state server to render an appropriate view of the virtual world. The virtual display devices, which can be stationary (e.g. pilot’s display) or mobile (e.g. virtual porthole), display the view of the virtual world rendered by the virtual reality engine. The virtual world environment manager provides the server with the information regarding the virtual world that the Voyager is currently in, and any corresponding information related to the world (e.g. maps, types of organisms found in the world, or environmental parameters). The boat simulator interprets the input from the boat control devices compared against the current environmental and boat parameters to determine the most realistic behavior of the boat. The administrator terminal will be the point through which all or most of the states in the global state server can be viewed and modified.

The GSS provides the following functionality to the client programmer:

The ability to create, delete and change variables

The ability to create and delete variable types

The ability to search by variable name and type

The ability to retrieve all variables of a given name or type

The ability to “listen” to a variable (i.e., monitor its value)

Next to the ability of RMI to transfer any data object, data listening is the greatest asset of the GSS. Once a component notifies the server that is wishes to listen to a variable, the GSS will notify the component by way of a callback function whenever the variable is updated.

Currently the GSS can only handle a limited number of initial variables within the startup_variables.txt file, and the code to read these values is hard coded into the GSS. In the future it would be advantageous to remove the hard coding and to instead use the capabilities of the java classloader. To do this the variable type given in the startup_variables.txt file would need to be the same as the filename for the variable class. This string can then be used by the classloader to automatically instantiate an instance of that class. The code would look something like this:/* read in the type string into a local variable typestr, read the inital value into string valstr. */Class cls = ClassLoader.loadClass(typestr);Constructor construct = cls.getConstructor();Object o = construct.newInstance(valstr);

Since the GSS stores all data as objects, the object o can be added to the GSS with no difficulty.

Software

The source files required to compile the GSS are listed and described below:

Source File Description

GlobalStateServer.java Main source file for the GSS. The actual server is implemented here.

ClientClass.java This GSS helper class is used by the GSS to keep information on a client


Source File Description

component—for example, a list of the variables a component is listening to.

VariableClass.java This GSS helper class tracks all data for a single variable in the system, and provides an interface to that data. This data includes: the variable name, type, value, and a list of component listeners.

ErrorCodes.java This class encodes the error codes returned by the GSS.

startup_variables.txt This text file contains a listing of the initial variables and state of the system, and it is read by the GSS at startup. The format of the file is a list of strings formatted is as follows:

variable namevariable typeinitial value

The current initial values that can be read by the GSS are: null, boolean, character, double, float, integer, long, short, string, vector3d, locandheading

ClientInterface.java This file contains the Java interface that a client needs to implement if it desires to be notified of variable updates.

StateServerInterface.java This interface holds the method prototypes used to talk to the GSS.

GSSWrapper.java This class implements the StateServerInterface. It allows a component to merely instantiate this class to talk to the GSS without having to extend any other classes.

Makefile The Java makefile for the GSS

Table 24 – GSS Source Files

The GSS will compile and run on any platform that contains JDK version 1.1.5 or greater and a network connection.

To compile the GSS:

Make sure you have all of the above files.

Type make at the command prompt

After a successful compilation, it is necessary to create the RMI stubs for the files. Type the following lines at the command prompt:rmic GlobalStateServerrmic GSSWrapper

Hardware

The GSS can run on any platform which supports Java; all of the Windows machines used in the Virtual Voyager prototype (both NT and Windows 9x) are GSS-capable.

Boat Simulator

Process Story

As soon as Virtual Voyager became a boat simulation, a simulator was needed. Although commercial simulation programs were considered (see the Boat Software study, page 31), it became clear that it would be necessary for the software team to craft a custom simulation program.


The boat simulator’s function is easy to understand. The software’s primary job is to report the current state of the boat while simulating the next state by taking into account all the inputs from external devices such as the captain's wheel and throttle.

Design

The input information is available to the boat simulator via the global state server, and values created by the program are written back to the GSS as well. In addition, the boat simulator takes into account external environment factors such as river current and wind.

In each cycle of the simulation, all current input values are taken into account to create new simulation values. For example, the current angle of the wheel, speed of the boat, and RPM of the engines might be taken into account to calculate new values for the position of the boat in the virtual world. Changing this position value causes the Alice display devices to update their view from the boat.

Software

The boat simulator was coded in Visual Basic 6 using VB’s built-in TCP connectivity. This allows the program to act as a TCP client to the Java-based GSS.

Hardware

The boat simulator runs on any Windows machine. For the prototype, is uses the same machine as the GSS, but if a network card and connectivity to a GSS machine is provided, the boat simulator can run remotely.

Piloting Station Overview

In the piloting station, four students take the helm of Virtual Voyager. The station includes several specialized input and output devices: the captain’s wheel, a rudder angle indicator, two throttles, and gauges for RPM, water temperature and oil pressure. And most dramatically, the projector and large forward screen display the Alice virtual world to the entire classroom.

The roles and responsibilities in the pilot station are as follows:

Pilot/Helmsman Steers the boat

Monitors radar, compass and rudder angle indicator

Control lights and horn

Watches for buoys and channel markers

Executive Officer (XO) Navigates (passing navigation commands to piloting station crew)

Communicates with navigation station via headset radio

Port Engineer andStarboard Engineer

Monitor the following gauges:

Tachometer (Engine RPM)


H2O Temperature (water cooling the engines

Emergency engine shutdown (red button)

Warm engine ignition (green button)

Oil pressure

Monitor the emergency radio channel for distress calls

Watch for debris

Control the throttle for the port or starboard engine

Screen and Projection

Process Story

From the beginning, the project designers envisioned a large screen or screens as being the centerpiece of a virtual experience. The prototype screen includes stereo speakers to create ambient sounds, but the original designs also included a special effects lighting bar which could be used to create special lighting effects (simulating a storm, for example) and variable speed fans to create wind.

As the visionary scenario began to take shape, the mechanical engineering team started to focus on designing devices and props that can be used by students in classrooms. Initially, they envisioned three projection screens arranged in the front of the room (as apparent in their original sketch employed on page 55.) They also considered having one large screen which curved parabolically.

Many other issues were raised and options discussed as design continued:

Space requirements - After interviewing teachers at several school districts, a limitation was set on the possible size of the Virtual Voyager classroom. The average elementary school classroom size is 25 feet by 40 feet. A major issue with projection systems is that they require many feet of space between the projector and the screen itself. This would lend to the most wasted classroom space of any of the setups in question.

Brightness - Another major concern was the brightness of the picture to be displayed to the students during the simulation. An insufficiently bright projection system may become washed out in lighted environments, even ones with low levels of lighting. Dim projection systems also suffer from dim perception of pictures when the screen is viewed from a sharp angle. Through various demos, it was determined that approximately 700 ANSI lumens of light are needed for an adequate rear projection setup.

Screen Size - Screen size is a major issue when it comes to displaying the virtual world. It is ultimately aesthetic, but the concern was with just that: the realism of the simulation. A projection system allows a large display size that is only constrained by room size itself. A television system poses many problems when it comes to its screen size. The larger a television's screen, the more expensive and heavy the television


becomes. And even large television do not generally have the same picture size as a projection system.

User Interference - User interference was a concern mainly with the front-projection system. With such a system, if students get in the way of the projection beam, it will cast a shadow for everyone else on the screen. It is also a minor issue with television sets because they are so small and one student can effectively block a whole set for everyone else. Because of these issues, a rear-projection system was chosen.

Portability - Portability was a big issue with regards to the projector and television setups. The problem with a television is that to get anything that has a reasonable size requires a huge and heavy box. Portability was an issue with some of the projectors evaluated, so candidates which did not have handles for easily carrying were eliminated. Ultimately, the projector system won out. The screen was not hard to make portable since by properly constructing the frame, the actual screen can be rolled up.

Power consumption - Power consumption was something we talked about at first. We had to be sure that whatever system we came up with would have reasonable power requirements for a school. However we soon realized that all the projectors on the market have power requirements that can easily be met by any school.

Cost - The cost function was based on the number of displays, as well as the cost of the display system. Since each display requires a dedicated processor (which would cost somewhere between $700 and $1200), the seemingly economic television monitors quickly become expensive if an attempt is made to construct a more immersive environment. For example, a one-projector system could be used to create a slightly curved, seven-feet wide image for about $6500; by contrast, a system of four monitors could be set in a semi circle of a similar size for roughly $6000.

Ease of implementation - Ease of implementation was an important issue for two reasons. First, in order for a prototype to be completed on time, something straightforward to implement had to be chosen. Secondly, the project is intended to be reproducible. A complex or custom display would be a distinct hindrance in any attempt to create a duplicate system. In this respect, a system of monitors is much more straightforward to implement, since it requires no focusing of projectors nor setup of screens.

Ease of maintenance - Once the Voyager goes into use, it should be maintainable with a minimum of effort. This includes set up and break down of the system, as well as troubleshooting. In these respects, television monitors have a great advantage over projection systems, since projectors need to be focused and adjusted for keystoning, while monitors can simply be plugged in. Similarly, the attendant difficulties in setting up an eight-feet wide screen disappear with a monitor system.


Design

The eventual decision was to employ rear projection, a mirror to lengthen the throw and thus require less room to get a larger image, and a curved screen on a frame built by the class.

This decision was taken to keep the projector out of children's way (rear-projection), to create a more 3-D effect (curved screen), and to cut down on the space needed (mirror). Seven samples were obtained of different types of rear-projection screens. All were tested; eventually the "Studio" material from Gerriet's International (a company in New Jersey) was chosen.

The selected screen size was 10.5'w x 7'h. This size was used so that when the screen was curved, a 9'w x 6.5'h image could be projected. This size affords a large image within a reasonable space requirement.

The basic form of the screen frame had been settled on during the early design phase. The final design task was to detail the frame in such a way that it could be produced with available facilities in time for the prototype presentation. Chromoly tubing was chosen for the top supporting curve because of its strength to weight ratio, and aluminum tubing was used for the bottom curve because it is light and the strength requirement for the bottom curve is not as demanding. As a note, chromoly tubing is not a common material and may take a while to get. ABS pipes were used for the rest of the structure because it is a easier material to work with. Additional tensile wires were used to strengthen the vertical supports. Additional improvements that are left to be done to the frame include surface finishes (painting, sanding) and, if possible, curving the tubing more accurately (using a tubing roller). However, as is, the screen frame system is functional and is able to support itself and the screen material.

Hardware

Screen: Gerriet's International "Studio" material, hemmed sides - 10.5'x7', 8" on-center grommets along top and bottom

Frame: Chromoly tubing - 1.125" diameter, 0.058" wall thickness ABS pipe - 3" diameterAluminum tubing - .375" diameterTensile wirePicture wire6 eye-bolts

Projector:700 ANSI Lumens1025x768 resolutionVGA input connector


Wheel and Throttles

Process Story

A captain’s wheel was clearly an important part of a boat simulation. Enabling technology investigations (see Force-Feedback Input Devices, page 36) made it apparent that there were several good candidate devices on the market. The availability of force-feedback wheels, which would allow the simulation to cause the wheel to pull as if from river current, suggested possible future enhancements for not much more initial outlay.

The intention had always been to craft a more realistic ship’s wheel to replace the car-style wheels available. This had not been done at the time of the prototype demonstration.

Available throttle input devices were also identified. The decision was made to connect the two engine throttles and the ship’s wheel together into one input device.

Design

Among the available force-feedback devices, an Interact V4 Force-Feedback wheel was chosen because of its price and also the fact that the wheel tilt is adjustable, making it easier to fit for future alternate casings. The wheel allows one hundred eighty degrees of freedom, and has a few programmable buttons which could be used for additional functions.

However, for the implementation phase, the wheel with force-feedback was discarded and replaced with a simple wheel that uses 2 axis and 4 buttons. The reason for the switch is that there was no easy way of accessing the X-axis of the force-feedback device as it uses a serial input method. Another problem that was encountered was the inability to add the

second throttle. Since both throttles use the Y axis of the second joystick device, and rewiring the second throttle did not work, the only possible solution to add the second throttle was to connect the second throttle to another computer and feed the input signal back to the server computer. For the present configuration, the wheel is connected to the connector on the throttle, and the throttle is connected to the game port in the back of computer.

The wheel and throttles send their signals to the computer via the game port. The signals then need to be propagated through a specially written device driver and sent ultimately to the GSS, thus causing the simulation (and the virtual world) to respond appropriately.


Software

The specially written device driver must be loaded on the computer which will host the ship’s wheel and the throttles.

Hardware

The devices used to build the wheel and throttles are all Windows compatible and run on a standard Windows 9x PC. The computer hosting the devices must have a game port, which is usually housed on the sound card.

Gauges

Process Story

The final devices needed for a realistic piloting station were various gauges, one set each for the port and starboard engineers.

The housing for the gauges and the input devices to be used by the port and starboard engineers are identical. The housing was made of wood, both stained and unstained, in an attempt to relate to the design of the frame for the screen. The surface that the actual inputs and outputs will be located is raised at a slight angle towards the viewer.

The building of the system of gauges was developed in multiple stages:

The first stage was the testing of sample gauges purchased early in the semester. The reason for doing this was to get an idea of the operation of the gauges and to determine what was the best way to control them.

The second stage took the majority of the early design phase. Here, it was determined what types of interfaces were feasible and easy enough to use. When we entered the detailed design phase, all parts had been chosen and most had been procured (including electronic components and the microcontroller.) The only parts which were not yet available were the actual gauges to be used. Because of this, most of the team’s time was spent on ensuring that the rest of the gauge system was ready and debugged, since there would not be time to waste when the gauges were available.

Once the gauges finally arrived, the focus moved from software development to the building of the hardware platform. Specifically, the gauges had to be connected and placed in the pre-built boxes. Ultimately, the separation of the tasks forced by the constraints of part availability resulted in an efficient use


Figure 6 – Sample Gauge

of time. Since the testing of the gauges was completed up front, the system was completely assembled within a day of receiving the gauges.

Design

Many options for distributed control of the gauges were considered, but based on past experience with many of the parts, the choice was made to use parts that were slightly more expensive but much easier to work with. The main parts that were involved in this decision were the microcontroller, the digital analog converters and the instrument gauges.

The internal design of the gauge electronics went through a fundamental change from the expected design as more was found out about the capabilities and options available. The original design was to use a number of individual microcontrollers which were low performance with few capabilities each. A reason for using these was the low cost and the fact that these are in common use in the CMU community and thus assistance would be easy to find. After looking at the issues with regard to the low-capability microcontrollers, it was determined that the work associated with dealing with these microcontrollers was not worth the benefits of low cost and common

use. Instead, a microcontroller from a company called Siemens Microelectronics was chosen. One of the electronics group members had worked with Siemens and had contacts who were willing to donate the $180 evaluation boards to the project. The Siemens microcontroller had many peripherals including serial ports, A/D converters and many digital I/O pins. This made it possible to run the whole gauge panel from a single microcontroller and would enormously simplify the tasks facing the gauges group. Using the new microcontroller, the interface to the computer was also simplified because the evaluation board contained a complete interface for RS232 signals so that the board could be connected directly to the virtual


Figure 7 – Gauge Architecture

world server. An added bonus of the Siemens microcontroller evaluation board is its wire-wrapping area for component placement as well as the large memory size, 64k of RAM and 256k of Flash EEPROM. The gauges group has already received the donated board and started preliminary code development.

On the alternate side where the microcontroller interfaces the gauges, the gauges group found D/A converters that had serial inputs which also simplified the interfacing. By using the high-speed synchronous serial channel on the Siemens microcontroller and using chip-select lines on the D/A converters, the gauges group can easily generate 0-5V on up to 16 DAC outputs. The next part of the design was to use the 0-5V to control the instrument gauges. Since the gauges worked by varying the current (at 12V), it was determined that the gauges group could either use an op-amp to vary the voltage between 0-12V with a fixed resistance and thereby change the current, or a current limiting op-amp would be required. These options were a problem because the only op-amps that could supply the required current were rather expensive high-power op-amps. The gauges group did however find an op-amp with the exact current capabilities required and it had a current-limiting input so that the op-amp could be used as a buffer and could limit the current by inputting the 0-5V from the DAC to get full deflection on the instrument gauges. In order to test the hypothesis of the gauge operation, a prototype instrument cluster was built which included two gauges controlled from a variable resistor.

The choice of the gauges was made both for reasons of cost and complexity. We required special electrical gauges for this project because of the nature of the control data. Our choice then was immediately limited to a specific gauge manufacturer where we had to order parts from through a local auto parts dealer. In the design phase, we narrowed the choice of gauges from the 20 located on the boat down to the 8 core gauges which gave enough information so that the Virtual Voyager experience could be expanded in the future. We had many problems trying to get the parts because the auto parts store was not a preferred vendor of ICES. Based on the time it would take to get the parts, we tried ordering the parts weeks in advance. Unfortunately, it was not until the Monday before the final presentation on Wednesday when we received the eight gauges. We worked many hours in those days before the final presentation to connect the gauges with the wiring we had in place awaiting the gauges.


Figure 8 - KC-161 Microcontroller Board

The asynchronous serial link to the servers was the initial link that sent data to the gauge controls. The Siemens microcontroller board had a serial port with all the required line drivers already in place so getting data from the computer was very easy and a simple matter of writing interrupt drivers to record the data messages.

The microcontroller as stated earlier and in previous documentation was the Siemens C164CI 16-bit microcontroller. This part was picked mainly for its ease of programming and large number of peripherals, especially the serial ports, the fast external interrupts, and the large number of I/O pins. The program developed to run on the microcontroller was interrupt driven, and it performed the operations of debouncing the input buttons for the engines. It received serial data from the server as well as transmitted data upon receiving the button presses to start or kill the engine. Additionally, the program generated frequencies to be sent to the tachometers, and used the synchronous serial interface to communicate with the digital analog converters.

The buttons used for engine control were simply used to pull one of four pins on the microcontroller high. On those pins were pull down resistors and the pins programmed so that when the pin went high, an interrupt was generated in the microcontroller. A timer was programmed to debounce the four switches at once.

The digital analog converters had a dynamic range of 0-5V. Since values could be set for the analog ground and analog reference, the ranges were put at the smallest possible range that would move the gauges at full deflection. The digital analog converters had 8 bits of precision, so it was necessary to decrease the range between the analog ground and reference to get the best resolution on the gauges.


The gauge drivers consisted of darlington transistors in order to drive the 100ma load with minimal input current from the DAC. One of the issues with the DAC is that it could only source a very limited amount of current. MOSFETs were chosen for this control, but the required parts could not be procured soon enough.

The only problem faced in the entire gauge project was dealing with the characteristics of the linear regions of the transistors. The operation of the gauges in a real boat or car is through the use of a sender—a variable resistor that takes some physical measurement and uses this to vary the resistance between the gauge’s input and ground. Since an electronically variable resistor that could dissipate the required power could not be found, the transistors had to be used instead. The problem was that the voltage inputs put onto the gauges varied with time. This meant that if the system was turned on and the needle were moved to full deflection, they would slowly continue past our desired stopping point. For example, the fuel gauge would continue to go past the Full mark. After experimentation, it was discovered that if the gauges were left on for 5 to 10 minutes, the ranges stabilized. It was therefore decided to program in the ranges required after the gauges were left on for 10 minutes. Unfortunately, this may result in the gauges not seeming to move when the system is first powered up. In fact, they are simply slowly moving up to the required positions.

Message to the Microcontroller Example Description

T[12](00-99) T260 Set Tachometer on panel 2 to 60% of the maximum

W[12](00-99) W130 Set the Water Temperature on panel 1 to 30% of the maximum


O[12](00-99) O175 Set the Oil Pressure on panel 1 to 75% of the maximum

F0(00-99) F000 Set the Fuel level to 5% of maximum

V0(00-99) V046 Set the voltage to 46% of the maximum

Message to the Server Example Description

S[01] S1 Start engine 1

K[01] K2 Kill engine 2

Tables 25, 26 – Sample Microcontroller/Server Messages

The whole gauge system is very easy to operate. In order to set up the gauges, the only thing to be done is to connect power, connect the primary gauge panel to the server with a standard 9 pin serial cable, and then connect the primary gauge panel to the secondary gauge panel with another standard 9 pin serial cable. The serial cable between the two gauge panels contains the signals for the tachometer, and the gauges as well as the connections to the buttons and the voltages, +5V, +12V and 0V.

To start up the system, the 7.5V power supply is plugged into the microcontroller board which will immediately give the board power (shown by an LED turning on). By pressing the reset button on the microcontroller board, the gauges program will be started (as shown by a LED flashing at 50Hz). Next the 12V power supply can be connected to the microcontroller board at its respective socket. This will immediately turn on the power for the primary gauge panel. The secondary gauge panel is enabled by connecting the serial cable between the primary and secondary gauge panels.

Hardware

Siemens C164CI microcontroller on Phytec KitCon-164CI boardMaxim MAX510 Quad, Serial 8-bit DAC (2x)Fairchild Semiconductor 74AC139 Dual 1-of-4 Decoder/DemultiplexorTIP120 Darlington Transistor (6x)7.5V power supply 12V power supplyAutometer 3316 Fuel Level GaugeAutometer 3522 Oil Pressure Gauge (2x)Autometer 3531 Water Temperature Gauge (2x)Autometer 3592 VoltmeterAutometer 3991 Tachometer (2x)Various wirewrap sockets, ribbon cable and 9pin serial connectors

Navigation Station Overview

The navigation station allows four students to perform course plotting and tracking for Virtual Voyager. The piloting station students rely on the navigation station to create their course, ensure that the ship stays on track, and radio deviations and correction information back to them. Several special devices are in the navigation station, including the virtual porthole, emap, and altimeter.

The roles and responsibilities in the navigation station are as follows:


Navigators (2) Set up paper map with pre-plotted course

Enter course into emap computer (working together to read and key in values from paper course)

Monitor compass and GPS readings

Contact piloting station to verify that course is set

Follow and enter actual course, calculating deviations in degrees and radioing piloting station with corrections

Deckmates (2) Monitor weather conditions (temperature, wind speed, air pressure)

Monitor radar and depth finder

Use altimeter to measure the heights of bridges

Use virtual porthole for visual confirmation of course

Use emap to find out additional information about bridges, islands, and other locations.

Paper Map

Process Story

The need for a paper map grew out of a navigation station group study regarding the electronic map system, or emap. These points and conclusions are summarized here as the process story for the paper map.

The first idea was for a fully digital solution. For this, two separate displays would be required, one for the two course plotting students and one for the two deck mates. The deck mates’ sightseeing map would display the entire area that the ship will be traveling in. Since the scale will be small, the river will be smaller and there will be more room for displaying information. In the navigation map, the scale will be much larger, so the course can be plotted accurately. The navigation map will scroll as the ship moves, while the sightseeing map should remain constant. These two views can be integrated on to one display or shown on two displays. There are two possible configurations for this layout:


1

21

2

3

3 4

4

Figure 9 – Possible Configurations for Fully Digital E-Map Solution

In the first scenario, the two groups are on opposite sides of the screen and facing each other. The groups will have to communicate verbally to express actions that must be taken related to the maps.

Advantage Disadvantage

Only one screen is needed, which is less costly and promotes a more efficient use of screen space.

Too much intra-student communication may be required.

Table 27 – Advantages/Disadvantages of Fully-Digital E-Map Configuration 1

In the second scenario, the two groups are standing next to each other and looking opposite directions at the maps.

Advantage Disadvantage

Easier to communicate between groups. More hardware required. Groups can get easily distracted.

Table 28 – Advantages/Disadvantages of Fully-Digital E-Map Configuration 2

The overall advantages and disadvantages of this solution scenario are summarized in the table below. The biggest concern is the significantly high cost.

Advantages Disadvantages

It is easier to update the course. More expensive. (initial cost)

$5000 for the touch screen and another $3000 for a LCD projector. The display is designed to be vertical, so we will have to modify the cabinet considerably.

Only one map needs to be provided to the kids, so it will reduce confusion on having to read or input information between several types of maps.

More implementation time needed for every virtual trip developed.

It would automatically calculate the distance between the boat location and the planned rout ( Although this may not be really an advantage if we review our design principles )

The map is stationary. Less accessible for the kids.

It would reduce operational costs in paper maps, drawing material and plotting of the maps.

Fewer activities are done. The optimization of the process will lead to a reduction of the users needed to obtain all the information.

It might reduce calculations needed that are too difficult for the kids to do.

A bigger screen is needed in order to allow the same interaction with the other map options.

It can add or remove layers as what the teacher wants the kids to see at that time. The same map can have several looks and information displayed.

It doesn’t give the hands-on experience of using a real map.

A cool Graphics Display can be used. (3D Topo Map) It will make interaction more difficult with kids trying to do everything in the same display.

Table 29 – General Advantages/Disadvantages of Fully-Digital E-Map

In the hybrid scenario, the same large table as with the full digital scenario is used. The whole table is a touch-screen. The left third is the paper map; the right third is comprised of two 15” monitors. These are actual displays, which will cut down the cost. This approach places all displays/maps near each other.



Plotting course and doing extra calculations help students.

More expensive than the simple paper model, but still cheaper than the full digital one.

Can separate students into pairs if so desired, or can now work conveniently as one large group. Whichever the teacher prefers (though we think it's 2 and 2).

The touch screen may not be durable.

Can act as one giant dashboard. (keeping map always shown, but having full interactive info screens or sonar).

May have the problem of too many students touching the screens

Can combine activities, or tie in what you're viewing on the large map better to the interactive displays.

Less kid-proof

Students need to know scale for mapping from computer screen to paper version.

Having the real map is a great benefit.

The students aren't actually changing/touching the actual map, so we can constantly re-use them.

Table 30 – Advantages/Disadvantages of Hybrid E-Map

In a final scenario, a paper map and e-map combination were considered. This version has a paper map and at least one separate interactive display. The paper map could be laminated, or under some plastic cover, so students can constantly change what’s drawn on it (i.e. plot a course). The interactive display is a touch screen that can show information for any “hot” item. It also can display the compass, other boats, and so forth


Low cost: < $300 Cannot retrieve info from the paper map directly, but we can from the e-map (so not really a disadvantage, but we thought this should be brought up as an issue).

Less implementation time Paper map is harder to update as we make corrections of the course (more messy)

Light easy to move around If we are doing time-travel it's harder to update paper map in the matter of minutes which we can do with the e-map: so we could have some inconsistency…

Physical feel of the real map Paper map is disposable - once used (esp. if we want kids to keep it) it's gone. New ones needed.

Reality: doing plotting as on the real boat The errors on the paper map cannot be automatically corrected. However if the paper is coupled with e-map, corrections can be done on e-map.

Can have a cross-bar (ruler) to give more of a physical feel

If we want kids to keep the e-map printing might be costly.

Students learn how to read the real map and relate this to the external information

It might take longer to plot the course and interactive with it than if we would only have an e-map.

More explicit collaborative experience if one student on e-map and the other on the paper map and they have to communicate (e.g. coordinates…)

Paper map more prone to wear & tear

Learn to read the real map

Learn the difference between the real map and the electronic map: how are they manipulated, type of info they contain, etc…



It's going to be more challenging to map(compare) between the real map and the electronic map (e.g. latitude and longitude ), hence more educational

Flexible: any kind of map can be provided: real map, or fill in the blanks map, or create your own map, or correct the current map…

Can bring other info on the electronic map, such as shore info about buildings, wildlife…

As many kids can touch the paper map without causing a system failure.

If power outage, can rely on paper map still to do some activities

Table 31 – Advantages/Disadvantages of Paper/E-Map Combination

A comparison among the three options is summarized in the table below:

Approach Cost Implementation Flexibility

Paper X Fastest Good

Hybrid x+800 Slower Better

Electronic x+7,500 Slower Best

Table 32 – Comparison of Three E-Map Options

Under the project’s time and cost limitations, the paper approach was adopted. However, either of the other two approaches could adopted as a future improvement over the prototype.

Design

The paper maps used by the first navigator will be similar to the navigation maps used on board the real Voyager. In addition to the information provided on the real map, latitude and longitude information and identification of interesting places (such as the old jail in Pittsburgh) will be available. The maps used will be 11” x 17” color sheets of paper that can be easily and cheaply printed.

In addition to the paper map, the students will be provided with tools needed to plot and measure the Virtual Voyager’s course. These supporting materials are colored pencils, a protractor, a T-square, a ruler, an eraser, and a carrying case. The pencils will be used to plot the actual course and the pre-plotted course in different colors.

The protractor will be needed to measure the heading angles. The T-square will be used to locate specific coordinates on the map. The ruler will be used to measure distances on the map.

The approximate cost of the paper map setup is $60 and $2 per additional map.


E-Map

Process Story

When the navigation map functions were laid out as explained in the Paper Map section above, certain capabilities were left to be implemented in an electronic map application, or e-map. This e-map application was going to have to provide a way for students to plot a course, display the actual tracked course of Virtual Voyager, provide information about areas of interest on the map (such as bridges), and facilitate an altimeter device to allow the students to discover the heights of bridges.

A layered design was chosen for the e-map, in which these different kinds of information could be superimposed separately over a map of the Three Rivers. This interface allows the disparate map functions to all coexist without cluttering up the base map display.

Design

With the basic principle in place, the creators of the e-map software decided that all interaction should be done with only the mouse and numeric keyboard, simplifying the interface. The screen was subdivided into the large map and a control button and information display area, as follows:

Electronic map area Shows the river

Displays the pre-plotted course as a full line

Displays the actual course as a dotted line

Shows milestones (check points)

Has a boat icon to represent the position of Virtual Voyager

Could optionally show other boats, barges, and river traffic

Display latitude and longitude around the edges, spaced based on the scale of the map

Buildings, islands, and other shore attractions are numbered so that students look for them based on latitude and longitude rather than a name

By clicking on a numbered object, a pop-up window displays more information in the form of text and/or pictures.

Compass At top right corner of the screen

Ideally, used to move the map around instead of the scroll bar

Zoom in/out button Below compass

Allows map view to be expanded and contracted

Plot mode button Pressed to begin plotting the actual course.


A menu is then displayed:

New Point

Undo

Delete

New Point brings up a dialog window which prompts for entry of the latitude and longitude of a point. Once coordinates are entered via the numeric keyboard, the Go button on the dialog causes the point to appear. This process is repeated for each point of the course.

Navigate mode button Once a course is plotted, the Navigate button switches to navigation mode where hot spots are enabled and the map can be moved and zoomed.

Legend/Scale display Below Navigate and Plot buttons

Gives map scale, latitude and longitude.

Is covered by the menu during Plot mode

Additional functions The user interface for Navigator 3 adds four additional types of display information:

Speed, direction, and location

Weather - Wind speed, visibility, temperature, and pressure

Depth finder

Altimeter display – Bridge height, water level, draft of boat

Modularity was a key concept of the design. The layered nature of the e-map means that the main software is only responsible for displaying the map, while pluggable layers provide functionality on top of this interface. The four functions implemented for the prototype and detailed above are enabled by a PlotLayer (used to take pre-plotted course inputs from the user), the TrackLayer (used to track and monitor the course of Virtual Voyager), a BridgeLayer (which allowed the user to click a bridge on the map and displayed relevant information), and the AltimeterLayer (which received a signal from the altimeter device’s button device and calculated information for the bridge which the device was pointed at.) Each of these layers can be disabled or enabled by specifying which layers are desired in an external configuration file.


E-Map

Plot Layer Track Layer Bridge Layer

Altimeter Layer Altimeter Button

Figure 10 – E-Map Layered Architecture

The e-map itself has the capability to display an image of a map with optional levels of zooms. It also can translate the user's mouse location over the map region to the corresponding latitude/longitude coordinate.

The PlotLayer allows the user to enter course coordinates in latitude/longitude coordinate system which is displayed as connected line segments on the map, and has multiple levels of undo.

The TrackLayer displays the location and heading of the Virtual Voyager both textually (GPS location in terms of latitude/longitude, and heading in terms of degrees clockwise from the north), as well as visually with an icon being displayed on the map representing the boat's location and heading.

The BridgeLayer displays sets of hot spot icons on the map, and when the user clicks on a hot spot, it displays the image of the bridge along with relevant information about the bridge.

The AltimeterLayer waits for a user to press the altimeter button connected to the e-map computer, and automatically figures out which bridge Virtual Voyager is heading towards and displays appropriate information (angle to the bottom of the bridge, bridge height, etc.)

Note that the e-map is programmed in a very extensible manner, allowing a new layer to be added without requiring main e-map classes to be recompiled. If a new layer is to be added, the class is simply added to the layers.txt file and the e-map will find and load the new layer automatically.

Classes required to run the e-map Emap.classCoordinate.classLatitudeCoordinate.classMeterCoordinate.classScreenCoordinate.classPaintContext.classMapImage.classMapPanel.classLayer.classSettings.classModule.class

Class files required for the altimeter layer AltimeterLayer.class AltimeterWrapper.classBridge.classBridgeInfo.classaltimeter.dll

Class files required for the bridge layer BridgeLayer.classHotSpotLayer.classBridge.classBridgeInfo.class

Class files required for the plot layer PlotLayer.class

Class files required for the track layer TrackLayer.classBoatIcon.class


In the future, the interface into the main e-map class should be further tested and solidified so that layers may more flexibly display and manipulate information to and from the map.

Software

Requires Java run-time version 1.2.

Hardware

Requires PC running Windows NT or Windows 9x.

Porthole

Process Story

The virtual porthole originated from discussions as to how to best present a convincing virtual space to a group of students. Large fixed projection screens at the bow of the boat would establish the scale of an outdoor space, but only provide a fixed range of view into the virtual space. The use of several of these large fixed screens was eliminated for cost concerns. The central question became how much representation is needed to convince participants that the virtual world is more than just an image projected on a screen at the front of the class, but is in fact a true space that they are immersed in. The goal was to provide an experience that “was better than just watching another video”, as one student characterized his Voyager trip.

On the real Voyager, the captain needs to look ahead to see where to steer the boat, the students look towards the side of the boat to things on shore, and the crew needs to look at areas immediately surrounding the boat. Clearly the main screen could not afford all of this. The virtual porthole arose as a more cost effective solution that provided task-focused viewing controlled by whomever had the need to view something other than what was on the front screen. Task-focused viewing would also allow for tracking an object as the boat moves by it. For the cost of an additional screen and projector, three or four portholes could be built.

Once the Porthole had been established as a viable solution, it was soon realized that it was possible to provide other kinds of views into the world such as X-ray views, disjoint worlds, or external sources such as a web page.

Next, a brainstorming session was held to establish all the possible avenues for implementation, examining issues that each discipline had concerning its form, usability, hardware and software functionality. Following are the results of the brainstorming outline of all the issues that needed to be addressed in the design development of the porthole:

Task scenarios and use cases

The primary task of the porthole is to provide a window into the virtual world that is maneuverable by a student or teacher, allowing the user to find, study or look at things both on the virtual boat or in the world.

Disjoint worlds might also be viewed. Some examples of disjoint worlds include the boat seen at a different scale


in order to disclose a closer look at engine or linkage parts, or a macroinvertabrate world that a student could explore.

A secondary task of the porthole is to view other data, in the form of photographs, videos of bridges, or web pages.

In an effort to center the porthole design around percieved user needs several use cases were developed to aid the design process. The porthole could be used:

In a “scavenger hunt”. This is modeled on the real scavenger hunt the kids currently perform on the boat. This would foster exploration of the virtual world as well as the boat.

As an aid in solving disaster scenarios. The porthole could provide views of the weather not seen to the naked virtual eye, allow someone to see through the virtual fog, or see the depth of the river bottom, or find a leak in the hull that needs to be fixed.

For typical sightseeing activities such as bird watching.

To find debris in the water that the boat must avoid.

To look to the side when docking the virtual boat.

To see microscopic views of plankton.

As a fish finder to show all the fish swimming in the vicinity.

To look at cross sections of fish to display anatomy.

As a radar screen.

Used by the teacher to point out things in the Virtual World.

Dimensions sensed

The mapping from the real world to the virtual one could be along a number of dimensions. The number of dimensions sensed directly affected the hardware selections and costs of construction.

3D - Three degrees of freedom, pitch, yaw, and roll (which refer to rotation about the x, y and z axis) are enough to provide orientation sensing. This can provide any view into the world from a fixed position. However, it would be impossible to look behind objects because to do so the object would have to be translated around.

3D would be easily implemented with magnetic tilt sensors or accelerometers attached to the device.

5D - This is essentially orientation sensing plus the x, y location within the classroom/virtual world. The lack of z,


or height information would prevent the user from looking over or under a virtual object.

An RF (radio frequency) system could sense x and y positions within an entire classroom. Movement in the virtual world would require walking around in the real classroom. This raised a host of issues related to whether the interaction would have to be scaled or clutched, as well as safety concerns. This solution actually provides more complete sensing than the magnetic 6D sensing mentioned below.

Cost is a question, but it would probably be cheaper than 6D magnetic sensing.

6D - This uses magnetic sensing for full 6D orientation and positional sensing. This has one serious limitation—the positional sensing is limited to a 6’ radius, the range of the antennae system sensing the magnetic fields. Thus this is not really a 6D solution because to translate more than 6’ requires other input methods such as buttons.

This could also be accomplished with 5D above plus an additional button for z direction.

Other dimensions – Buttons on the device could replace any of the dimension just mentioned above.

The porthole could automatically sense just about anything in the virtual world. This could include hotspots that when navigated to, do certain things. The model for this is the web-based VRML protocol (Virtual Reality Markup Language).

Navigation The number of dimensions sensed directly affects the method of navigation in the virtual world. With the orientation sensing only, navigation must occur through some other means such as pressing buttons to move forward, backwards, and possibly left or right. If zooming were required, then that too would have to be implemented with buttons.

The 5D solution would allow one to move in the virtual world as one moves in the real one—theoretically. Since the virtual boat would model the real boat, which is 60’ long and 18’ wide, if the classroom space the virtual voyager was set up in were not at least this large then some scaling would have to occur. This would give the potentially sickening effect of seeming to run through the virtual world when you were walking through the real one. The issue of having to look at a screen while walking through a real world that by necessity had some desks in it could be hazardous.


The 6D sensing really wouldn’t provide true 6 degrees due to the limiting sensing range of the 6D antenna. Translation would still have to be solved in a similar fashion to that mentioned in the 3D solution. Its costs also made this solution a less desirable one.

Form factors Several different form factors for the porthole device were proposed and discussed:

Body mounted options, including handheld, hip supported, shoulder supported, and back supported

Floor-mounted

Ceiling-mounted (on some sort of portable track)

Other object mounts (pole, desk, moving structural arm)

Combination—The device would be designed for short periods of handheld use, and then hung up at various locations that may be specific to certain tasks.

Weight relief The object cannot be so heavy that students cannot carry it for extended periods. If it is, then other form factors must be chosen. This is dependent on whether the device is wireless or not. For mounted versions of the porthole, counter-weighting was discussed as a way to alleviate undue stress in moving the device.

Other issues discussed at this time included overall safety, what kinds of features were needed on the porthole, whether the device should be wireless or tethered, what type of screen was required, how the buttons should be implemented, and whether the device itself would contain the full virtual world processing power or whether it would just be a screen hooked to an external processor.

Time constraints were the significant factor in deciding what to implement. The lack of time prevented the normal design cycle of iterating over the different options listed above. As a result, decisions tended to be made based upon their ease of implementation.

The porthole was implemented for its primary task only, to provide a view into the virtual world. However, implementation of secondary tasks such as web browsing really require little extra hardware or software and could easily be incorporated into the design. The only thing to be implemented would be mouse movement and selection which could be accomplished with the programmable button interface.

There was a lot of discussion as to whether the porthole should be handheld or fixed. Freedom of movement in the virtual world had to be balanced against safety and weight issues in the real world. Since we did not have time to investigate these issues during the design, it was decided to generate a prototype that had the potential to be both with little modification. To that end, the porthole is a self contained unit with its own power supply and tilt sensors.


It is pole-mounted, but may be easily removed for handheld use. No thought was given as to what the appropriate size of the screen should be.

Only orientation sensing was implemented because it was the least expensive solution and did not require implementation of other systems (such as an RF transmitter in the 5D solution). Issues of safety, scaling between virtual and real worlds, and simulator sickness pushed us towards a fixed location for the porthole with no translation sensing. Orientation sensors could be swapped out for 6D sensors to provide more than just the orientation sensing that was implemented.

Without translation, it was no longer necessary for the porthole to be wireless and the more cost-effective tethered solution was used. Both power and data lines were run up through the pole to the porthole screen. The use of a tether also made it easier to have a remote computer actually generating the images for the screen. This reduced the bulk of the porthole itself.

A joystick with 4 digital channels and 2 analog channels was deemed the easiest way to implement the button functionality. It was felt that 6 buttons was enough to do a lot of things since they could be remapped in software easily. The case of the porthole screen was altered to accommodate the six buttons, 2 on the left side and 4 on the right. All indicators will have to be implemented in software since time prohibited their implementation in hardware

In terms of future research and enhancement, the porthole prototype provides enough functionality to confirm or disprove some of the design decisions made during the course of implementation.

The design decision to make the porthole a fixed device was made with very little investigation as to its consequences. Because the current prototype can be dismounted from its pole and used as a hand held device, it is possible to test both versions against

each other. The study would most likely have to be limited to adults due to its current weight, unless power supply with its heavy transformer is moved from the porthole out to the other end of its tether. The major focus of this inquiry should involve navigational issues. The pole mounted design prevents a fully egocentric view of the world that a handheld device would provide. You rotate about the pole rather than yourself. It should be determined whether or not this is a significant hindrance to users by designing some navigational tasks that test the limits of each approach.

Since the implementation of degrees of freedom has a significant impact over how the virtual world is experienced (through bodily motion or finger motion), as much testing should be designed as possible to explore this interaction. The current sensors must be replaced with a faster frame rate since they only provide 2 frames / second which is far too slow to be useful. It would be


relatively easy to swap the 3D sensors out of the porthole for 6D sensors as well. It could then be determined if 6 degrees of freedom would provide any usability advantages.

Another area of investigation should be to determine whether the appropriate size screen was chosen. This can only be tested in a limited way since the overall size of the porthole casing cannot be easily changed. However, the image size can be reduced by cropping it down to determine whether or not the screen size could be made smaller and thus lighter. How small it could be made would of course be determined by how many kids could reasonably see it at once. Future research might look into the possibility of using a Palm Pilot sized device for an individual child to use to view the world. At that size, weight relief and costs are much less of an issue.

Finer-grained studies of the button interface need to be done too. Specific control sequences should be studied to determine what should be implemented with buttons and how to best map those controls to the software.

Mechanical improvements need to be made to make the prototype fit the use cases better. Specifically, the default position of the porthole is currently looking at the ground, whereas it should be vertically oriented the same way our eyes are. This change could also allow for improvements in the support structure. It might make sense to add wheels to the base with some way of locking them so that it could be moved around more easily.

Design

The Porthole is a pole-mounted flat panel display device with 3 degrees of movement that affords a different view of the same virtual reality world displayed on Virtual Voyager’s main screen. The view displayed is based on the Porthole’s orientation determined from tilt sensors within the device. Students physically tilt the screen or rotate it about its support pole to adjust their point of view of the rendered scene.

The porthole can also show enhanced views of the VR world or other data, for instance, “X-ray vision” cutting through fog, or web page images of plankton.

The user interface arose by default from the decisions made

by the other groups and the lack of time to iterate any design alternatives. A minimal task goal was laid out for presentation purposes. The porthole in the presentation task was considered to be part of the navigation station. Its main use was to allow one of the navigators to view the shoreline when docking so he could communicate to the captain how far he was from the dock. It was also to be used to determine depth readings of the river.


The on/off status of the porthole is controlled by Virtual Voyager’s main computers.

The porthole prototype is comprised of a flat screen in its own housing, roughly the dimensions of a laptop, that is attached by a short horizontal support to a vertical PVC pole. The porthole and its horizontal support can slide up and down the vertical pole, allowing adjustment for viewers of different heights. The porthole is locked into a specific height via a tightening knob and peg system. The porthole may be rotated 360 degrees around the vertical pole, or about its horizontal attachment. The porthole casing is mounted to the horizontal support via a ball and socket attachment allowing for all directions of rotation. The pole support is mounted on a chair base to counteract the torque the weight of the porthole causes.

The porthole’s power and data cables are external to the pole and are received by a vacuum formed plastic box attached to the backside of the porthole. So while it is possible to rotate a full 360 around the pole, the cords prevent continuous rotation past 360 degrees.

The original casing for the screen was altered to accommodate the six programmable buttons. Two buttons on the left side of the case, one atop the other, are for zooming in and out. Holding either button depressed activates a continuous zoom in the chosen direction. Four buttons arranged in a diamond pattern on the right side of the casing are for programmable features. The implementation of these buttons for the presentation were for translating forward, backwards, left or right. Internally, the buttons were connected to the joystick controller.

The software that runs on the porthole is virtually identical to that which runs on the computers that render the main screen:

Alice Alice will be used as the rendering engine for the Virtual Porthole. Overlays will be used for the text notifications that alert the user when an enhanced mode is enabled. These overlays (rendered on screen) are similar to the text messages that show up in games like Quake.

GSS The Virtual Porthole will communicate with the Global State Server to acquire information about the virtual world. Communication will be established via TCP/IP sockets over an Ethernet network. The view will be rendered locally based on the orientation received from the tilt sensors. All of the location and control information is accounted for through the GSS. The porthole computer is only responsible for rendering the world via Alice.

Terminal Driver A terminal driver is required to receive information from the tilt sensors and convert it into useful information that can be utilized by Alice. Alice will poll the driver for the current orientation when it renders each frame. Latency is a huge concern as the frame rate could drop considerably if the terminal driver is unable to provide orientation data fast enough. Therefore, the driver will


buffer data so that a recent data point is always available for Alice.

The communications driver interfaces the virtual world software with the tilt sensor hardware. The driver provides an API supporting three necessary functions of operation: initialization, data query, and termination. The initialization step sets up the computer hardware for communication, which takes place at 38.4 Kbps. The last step of initialization is to start the update thread. This thread begins by telling the tilt sensor to continuously send updates, and then continuously waits for the tilt sensor data. Whenever data is sent it is stored. The data query returns the last set of values returned from the sensor. Since the update thread runs continuously with other tasks, the calling program will never have to unnecessarily wait for sensor data. This prevents latency in the calling application. When there is no communications port activity, the thread sleeps and uses virtually zero processor time. The termination step stops the tilt sensor from sending continuous updates and frees all resources allocated on the computer.

The following is a list of all the hardware components of the virtual porthole:

Screen A common desktop flat panel display was used for the screen. The display is bright, full color, and has a wide viewing angle. The flat panel screen is much lower in cost than anything that could be custom built.

Computer The 3-D rendering of the virtual world requires a large amount of computing power—especially hardware-accelerated graphics. A desktop computer is a most cost-effective solution which provided the amount of computing power required. The computer is equipped with a game port used to interface with the buttons on the porthole, a serial port used to interface with the tilt sensors, and a 3-d graphics card. An Ethernet network interface card is used to provide network connectivity to the local Voyager network. The operating system must be Windows 9x (currently any version of Windows 95 or 98). Alice, the 3-D rendering software, requires the Win32 subsystem. However, Windows NT cannot be used as it has known issues with its joystick driver software.

Tilt sensors Orientation information is provided with three degrees of freedom from a digital tilt and temperature compensated compass and dual linear axis tilt system. This functionality is provided by the EZ-COMPASS-3, a single board device from Advanced Orientation Systems Inc.

The unit outputs continuous heading, magnetic field,


dual axis tilt and temperature data over a standard RS-232 serial interface. The azimuth is generated from a 3 axis semiconductor magnetometer with 12 bit (0.08 degree) resolution. The linear tilt information is also available with 12 bit resolution.

The dimensions of the board are 2.5 inches long by 2.5 inches wide by 1.0 inch tall. The device requires 9-18 VDC for power. There is a single connector for the RS-232 interface and power connection. A cable was constructed for the board with a 9-pin DSUB connector and 12 VDC power supply.

One of the problems with magnetic tilt sensing is the low frame rate available from the device. A more expensive device would most likely offer a better frame rate. While the low frame rate could not be completely compensated for, a robust multithreaded communications driver was written which hid the latency problems.

Magnetic tilt sensors were chosen since it was unsure if the mounting pole would be included in the final design. The magnetic tilt sensors could easily be used in a free-roaming device if required. At the time the devices were purchased, a free-roaming device was the lead virtual porthole candidate design. However, in hindsight, the pole as an integral part of the final design could be used to fashion a more suitable tilt sensing mechanism.

Buttons The buttons on the virtual porthole are based on a Gravis GamePad. This is an analog joystick device with two axis of directional control and four push buttons. The housing of the GamePad was not suitable to the virtual porthole, so it was necessary to make customizations. The rubber pad push buttons were replaced with standard, self-enclosed push buttons. These were attached to long wires for flexibility in placement, and then attached directly to the GamePad PCB.

The virtual porthole requires that the host computer run Windows 95 or 98 solely to support the buttons. There are supposed to be drivers for analog joysticks for Windows NT, but they do not work. Despite numerous service packs that were touted as having resolved the problems regarding this, Microsoft still is not able to write working drivers. Therefore, Windows 9x must be used

Software

As detailed above the virtual porthole requires Windows 9x on its host computer, Alice, and the custom terminal driver.


Hardware

EZ-COMPASS-3 tilt sensor board (Advanced Orientation Systems Inc.)Custom 9-pin DSUB connector and 12 VDC power supply cableGravis GamePad joystick (parts)


Altimeter

Process Story

Another device developed was a virtual altimeter to be used by the group in the navigation area. The altimeter may be used to measure the heights of bridges, buildings, or any other items on the virtual projection screen. The output from the altimeter can include height, angle, and straight-line distance. Here is another opportunity for an activity developed around certain mathematical skills, specifically those of trigonometry. To use the altimeter, the student points the altimeter at an object, and presses a button. The information is then outputted into the e-map application.

In early concept prototyping, two designs were created. One looked more like a typical altimeter gun, while the other was an attempt to create a less gun-like device, to appease those who might object to weapon connotations.

Design

The altimeter will consist of a single button inside a cylindrical casing which the Navigator will press to determine the height of the nearest bridge. The altimeter is attached to a clamp which will clamp to a table and allow the altimeter to roll on an axis. The altimeter has two cables attached to it which provides 12V power and a serial cable which connects to the computer.

The current setup fixes the altimeter to a stand and allows it to rotate along the x-axis (roll). The reason for fixing the altimeter on a stand is to prevent the students from pointing it elsewhere. The altimeter will have one button which when pressed will provide the height of the closest bridge on Navigator 3’s computer. In future versions, the angle and distance to the bridge can be provided, allowing the student to calculate the height using basic trigonometry.

The final form decision was to make the altimeter feel like a telescope. Therefore, PVC pipe is used as the "eyepiece" and is attached a cable box which houses the wires associated with the button. Holes were drilled on the top of the pipe to fit the button and attached steel-L bars inside the pipe, helping the navigator aim at the object. The final altimeter is assembled with screws and epoxy glue, and painted chrome to match the porthole. To attach the altimeter to the clamp, a hole was drilled in the clamp and it was attached to a ball joint. The joint was rubberized to make it stiffer, preventing the altimeter from falling.

The altimeter is a simple device consisting of a 12 volt power supply, a push button switch to trigger the


Figure 11 – Altimeter Circuit Diagram

altimeter and a 1 Kilo ohm resistor. Figure 11 shows the circuit diagram for the altimeter.

The altimeter is connected to the navigation computer through the serial port. To trigger the altimeter, one must press the altimeter push button switch which will complete the circuit. This create a 12 V difference across the resistor (and pins 5 and 6) which is recognized by the serial port driver which in term triggers the software setup to bring up the bridge information.

In addition to the classes required for the e-map, the altimeter requires the following Java classes and components:

Class files required for the altimeter AltimeterLayer.classAltimeterWrapper.classaltimeter.dll (must be located in the e-map directory or on the Windows path)

Note that the altimeter was not fully tested on the PC due to lack of time. The bridge location algorithm is very crude; it simply finds the bridge with the closest x-coordinate in the direction that the boat is heading. A better algorithm would figure out if any bridges are displayed on the large screen and display the closest one.

Software

Must be run under Windows NT or 9x.Requires Java 1.2 or higher.

Hardware

Push-button switch12 V power supply1 K resistor


CreditsThe designers of Virtual Voyager, along with their discipline and functional affiliations, are listed below:

Vincent Allen HCI Pilot HouseBenjamin Bostwick Hardware NavigationMatthew Bosworth Hardware Pilot HouseRuben Carbonell HCI NavigationCarlos Chivardi Software NavigationSachin Chheda Hardware NavigationWei-Lung Chuang Software NavigationGregory Chiselko HCI PortholeDennis Cosgrove HCI PortholeJui Dai MEI PortholeElliott Delaye Hardware Pilot HouseFred “Chuck” Doerr Hardware PortholeJames Garrett Software Navigation (Staff)Susumu Harada Software NavigationSean Householder Hardware Pilot HouseKevin Kendall MEI PortholeWillie Kobori MEI NavigationJim Kong MEI Pilot HouseTham Kriengchaiyapruk Hardware Pilot HouseMary Kung Hardware Pilot HouseYen-Pang Lin Hardware Pilot HouseJason McDowall Aviation TA (Staff)Kyle Oppenheim Hardware PortholeEmilee Patrick HCI Pilot HousePazhani Pillai Software Pilot HousePatricia Pomar MEI PortholeDarius Rad Hardware PortholeJennifer Rode HCI Pilot HouseJonathan Rosenberg Software PortholeDan Siewiorek HCI Porthole (Staff)Aleksandra Slavkovic HCI NavigationAsim Smailagic Hardware Pilot House (Staff)Thom Verratti HCI PortholeAlejandro Vanegas Software Pilot HouseJolin Warren Hardware Pilot HouseWilliam Wong Software Pilot House

Ruben Carbonell and Thom Verratti, the editors of Virtual Voyager (a field trip without leaving the classroom): Final Report, would like to thank the functional group editors Greg Chiselko, Mary Kung, William Wong, and Wei-Lung Chuang, as well as all the other members of the class (who, for the most part, got all of their submissions in on time!)


*** outline *** - carnegie mellon school of computer …asim/rpcs06/voyager99_final_report.doc ·...

Documents

* outline * - carnegie mellon school of computer …asim/rpcs06/voyager99_final_report.doc ·...