Often times we include a picture of our simulator in our publications. It turned out to be an interesting problem, because if we want to show a cab - we need light; if we want to show the projected scenery - we need to have a dark room:

The obvious solution is to compose parts that we need from both images:

But we decided to take it a little further and use actual screen shots from the simulation instead of the pictures of the screen in a dark room:

Gimp has a perspective tool that is designed to do something like that and here is the result:

The extra benefit of this approach is that it’s possible to put any scenery into the picture using a template, without taking pictures, but by simply taking screen shots:

Alexander Shyrokov

Hello ecebloggers,

I’m very proud today because I’m writing about my first experiment. The experiment builds on two of our previous studies. In one of them Zeljko Medenica found that when speech recognition performance is poor, having to use a push-to-talk button results in worse driving performance than using ambient recognition (you can find the paper on his study here). In his thesis Oskar Palinko found that drivers divert their visual attention from the outside world when using the push-to-talk button. This happens because drivers often cast a glance away from the road in order to locate the push-to-talk button before operating it.

A simple solution to this latter problem may be training drivers not to look for the push-to-talk button. However, just like users of consumer electronics in general, drivers are not willing to be trained for long periods of time in order to use an in-car device. The goal of this study is to determine if simple training, such as verbal instructions issued before driving, would improve drivers’ visual attention directed at the road ahead.

The experiment setup is shown in the picture below.

The experiment involves our high fidelity driving simulator and eye tracker. I’m also using three cameras: one to record subjects’ head movements, one to record hand positions while driving, and one to record the eye tracker laptop screen. The eye tracker laptop shows the video captured by the two eye tracking cameras but there is no elegant way of saving this video.

I’ve started the experiments this week with Oskar’s help so I’ll be able to post about results very soon!

Have a good one,

Nemanja Memarovic

The last few weeks I have been working on designing a new driving experiment which would compare different user interfaces for entering license plate numbers into the police cruiser system for checking records. The two user interfaces are manual and speech. To be able to achieve this, license plates had to be added into our simulations. I have built on the results of Zeljko Medenica’s work to put in license plates as textures in the DriveSafety simulator computers. These worked only for some car models, because of the way textures are applied to them. Here is an example of successful applications:

The plates had to be made larger than in real life, because of the limited resolution of the projection system (1024×768). This way, the plates became readable from moderate distances and still preserved a realistic feel.
The experiment hypothesizes that a voice input system would have a beneficial effect on driving performance compared to using a manual interface.

We would also research if completion time would be longer for either of the two methods. Further, looking at the eye-tracker data, it would be possible to say which method demands more visual attention. My bet is on the manual UI. We will post all interesting results on this blog.

Oszkar Palinko

Probably everybody has at least some experience with the GPS-based personal navigation aids. They usually provide directions using voice prompts and information displayed on LCD screens. While such devices appear to be less distracting to use than paper directions, in-car displays may distract drivers from their primary task, driving.

In order to assess how different in-car navigation aids affect driving performance and visual attention, we conducted an experiment using our high-fidelity driving simulator. The simulator is also equipped with an eye-tracker which provides information about subjects’ visual attention. The following picture illustrates how the experimental setup looked like.

There were three navigation aids that subjects tested in this experiment: paper directions (turn-by-turn directions with a map printed on a sheet of paper), standard PND directions (a map displayed on an LCD screen with turn-by-turn directions delivered through voice prompts), and voice-only directions (just voice-delivered turn-by-turn directions). Participants were driving on a two-lane city road with markings and a light traffic was introduced. The following picture shows one snapshot from the simulation.

We recorded three measures of driving performance from our driving simulator: lane position, steering wheel angle, and velocity. Higher variances of these variables represent worse driving performance. We also calculated the percent dwell time on the outside world for each subject using the data collected by the eye-tracker.

Our results showed that using paper directions degrades driving performance (lane position variance, steering wheel angle variance, and the mean velocity were significantly different between the paper and other navigation aids) and visual attention significantly more than using either a navigation device that provides voice prompts with a map or a device that provides voice prompts only.

Regarding the visual attention, the time participants spent looking at the road ahead was significantly higher when using the voice-only aid than when using either the paper or the voice and visual aid. On average participants spent around 94% of time looking at the road when using the voice only aid and around 89% when using the voice and visual aid.

While these findings supported our hypotheses, one interesting thing was that the majority of the participants expressed that they would prefer using the navigation aid which provides both the visual and voice directions. Based on this, we propose for our future work to model the glancing behavior of the drivers, which would enable us to predict when one would require next instruction, so we would be able to issue a voice prompt. This in turn would enable drivers to keep their eyes on the road at all times, while still being able to have the next instruction in a timely manner.

Lots of other experiments regarding this issue will follow, so we’ll keep you posted!

Zeljko Medenica

Check out this cool multitouch game (via Interactive Multimedia Technology):

Multitouch Space Invaders! from multitouch-barcelona on Vimeo.

Andrew Kun

Check out the new audio preview button on YouTube:

Pretty neat, and it was inspired by web comic xkcd (via Lifehacker)

Andrew Kun

As posted a few months ago, Matthew Lape and I were given the opportunity to work on KLAS, the Kingsbury Location Awareness System. With the help of Professor Andrew Kun as our adviser and Oskar Palinko as a source of valuable insight, we were able to create a simple navigation application and tour guide application using the Project54 framework as our software development platform. While the work is still in progress, here are some of the results of our summer work.

Taking a look at KLAS, there are primarily two software components: the location determination application and the user-interactive applications. I will briefly describe the user-interactive applications while Matt will discuss the location determination side of things in another post. KLAS is a location awareness system that utilizes IEEE 802.11 RSSI readings to obtain a user’s location. This location information can be useful in various applications. The applications we decided to focus on for KLAS is a tour guide application and the navigation application.

This is an example of the map display in the KLAS Navigation application. The PDA on the left depicts what a user will see if they are in the shaded orange region. The arrow is the direction the user needs to go. If the user follows the arrow, the image on the right PDA will be shown. The right PDA image depicts where the user is currently and shows how to get to the destination.

This is an example of the Tour Guide application for KLAS. The image on the left depicts where the user is currently (somewhere in the shaded orange region) and a selected room (in red) that the user wishes to learn more information about. The user can cycle through nearby rooms to learn more information about it.

The image on the PDA on the right is shown if the user selects the “Room Info” button in the left image. Currently, the room number, the occupants, and some information about the room and occupant is given. The user can also cycle through the rooms in this screen and also press “Map” to navigate back to the map display.

As we continue to work on this, we plan on playing a lot more with the GUI and using Project54’s SUI as well. We hope to perform some user studies and experiments with different methods of pedestrian navigation and also conveying information. Stay tuned for some more information about KLAS brought to you by Matthew Lape!

Mark Taipan

Hello ecebloggers,

As some of you may know professor Andrew Kun is teaching a Ubiquitous computing course this fall. So far it’s been a lot of fun

I’m a big fan of Nine Inch Nails. The band is known for its good music as well as their visualizations on shows. Recently they published their first post and revealed their secrets for visualizations: ubiquitous computing!

They’re on tour right now so you may see it yourself. If you’re from the area (NH) you may join me at Verizon Arena, Manchester on November 8th.

Have a good one,

Nemanja Memarovic

I just ran across Slideshare, a (beta) website that lets you share slides (yes the name is descriptive). I uploaded my first set of (PowerPoint) slides, and now I can embed them in this post - very cool:

Andrew Kun

We have already reported on the arrival of the TouchKit as well as on its initial run. This time, we present our sturdy new mounting solution for the whole system. We have accomodated the display screen of the TouchKit in the middle of a hollow desktop. Here is the author with the solution.

It can be noticed that the TTT is tilted. This allows easier manipulation by a single user either by standing in front of the screen or sitting on a higher chair. The tilt angle is adjustable. The TTT can also lie flat which would allow easier information sharing around the table. The tabletop is mounted using hinges and a simple prop-up mechanism shown in the following image.

The table itself is a standard office desk which was customized for our needs.
Besides for running TouchKit projects, this setup can also be used for TouchKit development. The image below shows the mount of a keyboard and mouse on the tilted table, which provide a basic development environment.

Further action plans include buying and installing a short-throw projector device, which could be mounted onto the bottom of the tabletop. This would allow the screen to be lowered to a horizontal position and still have a maximum projection window size.

Let me know below, if you have any comments on the solution. Thanks,

Oszkar Palinko