In our last post Mark explained the software components and structure of KLAS (Kingsbury Location Awareness Systems). These components allow the system to take in data from an external source, estimate the user’s location (more on this in a minute) and then utilize that data to provide both navigation and tour guide capabilities.

The location aware portion of the system had to have a method of determining the user’s location through the use of some external infrastructure (e.g. GPS, Wi-Fi, RFID, etc.). After some reading and discussion, Mark and I decided that we needed a reliable indoor infrastructure, one that could either be easily developed, or ideally, one that was already established. We found, in the reading, that GPS indoors was considered mostly as an unreliable method, and RFID, although very accurate, was relatively expensive and too short range for our application. Looking at Wi-Fi, we found that it was acceptably reliable in this type of environment. The best part is that because Wireless Internet is so prevalent, the infrastructure in many locations is already established. It was thus why we chose to use Wi-Fi (IEEE 802.11) for our system.

To develop our specific location system using Wi-Fi, we had to investigate our target location (Kingsbury Hall) to determine the coverage and location of the Wi-Fi Access Points. We found eight UNH Wireless Access Points located on the second floor, equally spaced to cover the majority of the area. We then added two more Access Points in a few weak areas to give our system a total of ten Access Points to utilize.



Here we see two examples of the KLAS Access Points. The one on the left is a typical UNH Wireless Access Point, and on the right is one of the two Access Points that we added to provide stronger coverage in a few areas.

Our next step was to create an algorithm which would read in the Relative Signal Strength Indicator (RSSI) values from the Wi-Fi card on our PDAs and then determine the user’s location based on that data. To do this we spent a bit of time investigating the pros and cons of the methods used by other researchers, utilizing either probabilistic or deterministic models. We found, through testing and our reading, that Wi-Fi signals are highly susceptible to environmental changes such as the thickness and density of walls, the amount of people between the Access Point and the user, and even the relative humidity of the area. We decided, with the help of Professor Andrew Kun and Oskar Palinko, that due to the size of the area and the system’s environment, using a calibrated deterministic model would be best. This essential meant that we would evenly space master location points (also called reference points) throughout the floor. These points would then be compared to the user’s actual location to determine which master location they are closest to.

Through this testing we found that although the Wi-Fi structure was able to provide a reasonable estimate of the location, our initial points were too close, causing multiple real-time points to map to one reference point. This allowed use to gauge the reference location spreading, which eventually provided us with a total of 46 points for the entire second floor. After further testing with these points, it was found that there were still areas that had a tendency to “group” together. This was seen because of the fact that the building’s features caused certain areas to estimate the same master location. Recognizing this, we were able to break up the floor even more generally into 16 areas, which could be used by our system to categorize the user’s current location.



This map shows the even spread of the 16 user areas throughout the floor, as well as the locations of the ten KLAS Access Points. Dividing the floor into these areas allows for our system to have a built in buffer for the variations in the environment, as well as any variations that might be present in the user’s device itself. This allows for a more stable, reliable system, which is used, as Mark mentioned in his post, to provide navigation and tour guide capabilities for our users.

We hope to continue to refine our system in the next few months, making it even more reliable and stable. This will allow us to conduct more research in the area of the user interface, and hopefully give us the opportunity to develop a simple, intuitive system which will make KLAS a useful tool for all.

Matthew Lape

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

If you haven’t heard by now Microsoft’s http://maps.live.com has updated their routing algorithm to account for traffic. Check the box next to “Choose route based on traffic” to recalculated a route with traffic added into the equation.

The technology behind this is called Clearflow. Microsoft’s Adaptive Systems and Interaction group has created traffic models to predict congestion and find the quickest route.

Last week, Lieutenant Mark Liebl of the NH State Police started testing new versions of the Project54 navigation application and the Project54 handheld application.

Jon Oppelaar installed a USB GPS unit (GlobalSat BU-353) in Mark’s cruiser. This unit performs significantly better than an older GPS unit that was intalled several years ago, and it will enable Mark to test Jon’s navigation application. The application integrates Microsoft MapPoint into the Project54 environment. Here’s Jon (in the passenger seat) tweaking software settings in Mark’s cruiser during the installation of the USB GPS unit:

Andras Fekete worked on updating the software that allows a handheld unit to control the in-car devices (see picture below). Andras has already successfully deployed handheld technology in the Lee, NH police department, which we describe in a paper that will be presented at IE08. We’re now looking forward to getting Mark’s feedback about Project54 handheld software.

While Jon and Andras were installing new hardware and software, Mike Farrar talked to Mark about using the Project54 handheld computer’s imager, not only as a 2D barcode reader (e.g. for driver licenses), but as a camera. Mike is developing software that will allow officers to take pictures and tag them. Tagging can be done using voice commands, which should speed up data entry. It’s worth mentioning that Mike is developing his software using the Symbol MC-70, which comes with a cell modem. This opens new opportunities for getting data to officers in the field, especially in urban areas. In fact, the new version of the MC-70 also has a built-in GPS unit, again presenting interesting opportunities for law enforcement applications.

Thanks for testing all this harware and software Mark!

Andrew Kun

The January/February 2008 issue of Speech Technology Magazine has an article on Project54. The primary subject is the Project54 speech user interface. It’s a fun read.

The article includes interesting quotes from Project54’s Bill Lenharth and from Lieutenant Mark Liebl of the New Hampshire State Police (NHSP). Mark has been involved in formulating requirements for the Project54 system and testing our designs since the inception of the project. He has also helped deploy the system in over 300 NHSP cruisers.

Toward the end, the article mentions two areas of our ongoing research. One of them is the investigation of how various characteristics of in-car speech user interfaces (SUIs) influence driving performance. We’ve been conducting experiments with human participants in order to evaluate the influence of individual SUI characteristics on driving performance. E.g. we have investigated the relationship between speech recognition accuracy of in-car user interfaces and driving performance. A small correction to the article: we do not conduct our experiments using Project54-equipped cars - the experiments use our driving simulator.

The second research topic the article mentions is our investigation of the effects of in-car navigation devices on driving performance. This is collaborative work with Tim Paek of Microsoft Research. One question we hope to answer is when drivers feel compelled to look at the GUI of a navigation device, even if they have speech output from the device. This is an important question since taking your eyes off the road while driving is potentially hazardous. Note that one of my graduate students, Jon Oppelaar, has integrated Microsoft’s MapPoint into Project54. Mark Liebl is testing Jon’s software on the road (this is the “voice-enabled GPS unit” in the article).

Andrew Kun

Check out YourPND.com - they’re marketing a service that allows you to record your own navigation instructions to be used by a commercial navigation device. You can also have your spouse, a friend, or whoever else record the instructions. The service is currently only available in Dutch with an English version coming.

In his book Wired for Speech Clifford Nass points out that the type of voice (male vs. female, happy vs. sad, etc.) used by a speech user interface makes a difference in how people perceive the user interface and, by extension, how much they like and trust the device they’re interacting with. One key point made in the book is that people prefer voices similar to their own (this is the similarity-attraction effect). I’m not aware of any studies on how a user would react to a machine talking to him or her in the user’s own voice. How do people like such extreme similarity? I wonder if the YourPND people ran some user studies. If not (or if they’re not publicly available), this would be interesting to do.

Andrew Kun