These project ideas can be roughly divided up into several different themes:
Description: The basic idea here is to add location-awareness to the web. This might include location-enhanced blogs, attaching virtual notes to a place, or a "dashboard" that always lets you see, for example, the nearest Starbucks as well as the general crime level in your area.
I'm open to several possibilities, including:
Volunteer or independent study for the first semester, same or for pay for second semester.
Description: The basic idea is to estimate the number of people in places by counting the number of wifi points / bluetooth points detected. An example usage would be answering queries like "how many people are in the cafe now?" and "how crowded is the bus right now?"
We have an initial implementation in Java for WiFi. We would like help in developing a Bluetooth version, in gathering data (ie sitting in cafes and such and periodically recording the number of people there as well as the number of wifi and bluetooth points sighted), as well as basic web development to get the system deployed and used in Pittsburgh.
Volunteer or independent study for the first semester, same or for pay for second semester.
Description: Place Lab presently uses a database of access points to determine one's current location. One problem, however, is that this database is completely open. That is, any person can download this database and then see all of the access point MAC addresses and their locations, which is illegal in some states (for example, listing WiFi access points is illegal in California).
Doug Tygar and I have come up with a potential solution for locking down the database, by encrypting the database using pairs of proximate access points. The problem is that this also blows up the database quite a bit. One idea is to use a Bloom Filter (a probablistic hash table) to store access points. The upshot is that you can only see the location data for access points you are physically in front of.
The basic theory is there, but there's also a question of implementation and efficiency. There's also lots of room here for other security mechanisms as well, for example, putting fake data to detect cheaters.
Expected Research Contributions:
Also see:
Description: Text below taken from the original Place Lab Challenge Paper.
Generally, [with location-based services,] we think people would want to interact with some location-enhanced service or fetch some location-specific content so communication would be a normal part of the usage model. However, it is worth noting that the private disconnected mode is worth exploring. First, there are times when you may be near [Access Points] that are available for positioning but not available for communication (they might be private, belong to another provider, or maybe you didn't pay your T-Mobile bill last month). In these cases you might interact with offline web content in an "occasionally connected computing" (OCC) model supported by .NET and other frameworks. For example, if the Zagat restaurant guide was an OCC location-enhanced site, you could make the content available offline and use it with live location information. In this way, you could get information about nearby restaurants without actually revealing location data to the Zagat server.
So the goal of this work would be to make it easy to enable a web site as a location-enhanced site, as well as download the content and use the content in an OCC manner. Some potential systems issues here include:
Expected Research Contributions:
Also see:
Description:
Imagine if we could extend existing instant messengers in the
following ways:
Individually, each of these are slowly starting to happen, but there
hasn't been coherent thought as to how to combine these in new ways
that really helps people solve everyday problems.
Some potential thoughts on how next-generation IMs might be used:
Expected Research Contributions:
Also see:
Description:
One way of meeting someone you need to see, synchronously either
online or
offline, is to go through lots of negotiation beforehand, to
decide on a specific time and a place.
Another way of doing this is to keep calling them, resulting
in telephone tag or "camping", where your phone keeps calling theirs.
Another intriguing possibility enabled by new technologies is to use
some form of soft coordination. Here, both parties would just say
that they are interested in meeting with each other some time in the
near future whenever their schedules and locations coincide.
Here, computer systems (probably on their phone or PDA) could use
some notion of calendars, location, and activity level to suggest to
both parties that now is a good time to meet.
Expected Research Contributions:
Also see:
Description:
Imagine if you could one day go to Home Depot and buy a pack of
sensors that you could just plug into standard electrical sockets,
with all of these devices wirelessly federatating and providing
useful services for home owners.
For example, some of these sensors
might broadcast a signal letting people know where they are at
roughly the room level. You could imagine taking the electronic
equivalent of a label maker, plugging in the sensor, labelling that
sensor as "kitchen" or "bedroom", and then simply plugging it in.
Nearby devices could simply receive a signal telling them where they
are.
Another possibility is that these devices could become
people detection sensors. These sensor devices could have
low-quality microphones and motion sensors to estimate the number of
people in the room. You could simply plug one of these into each
room, making it feasible to run a query like, "find me any empty
meeting room".
One appeal of this approach is that it avoids having to deal
with the problem of energy management. Another advantage of this
approach is that end-user devices only need one single network
interface to be able to receive a wide variety of data. In other
words, the complexity of sensors is shifted from being a physical
hardware problem to a software protocol and data representation
problem (potentially solving another hard problem with ubiquitous
computing). Lastly, this approach also provides a simple systems
model as well as a business model for deploying ubicomp into
the home.
There are lots of questions here, however. For example:
Expected Research Contributions:
Also see:
Gaetano Boriello's privacy workshop paper
Description:
Expected Research Contributions:
Also see:
Description:
Expected Research Contributions:
Also see:
Communication Tools
1. Newell Simon Hall 3002
2. Newell Simon Hall
3. At School
9. Ignore
Sensor Systems
Smart dust
Ubicomp Privacy
Location History
Roughly speaking, the kinds of projects in this area can be organized into two
themes. The first theme tries to generate meaningful data from one's location
history. For example, can we go from:
timestampAA locationAA
timestampBB locationBB
timestampCC locationCC
to a richer location history, such as:
timestampAA locationAA placeAA eventAA peopleAA
timestampBB locationBB placeBB eventBB peopleBB
timestampCC locationCC placeCC eventCC peopleCC
The second theme looks at ways of using this location history in useful
and novel ways. For example, see the application
Eventster below.
Description: Currently, computer systems can use systems like GPS and Place Lab to determine locations, but these locations may not necessarily match people's perceptions of where they are. For example, a computer system might be able to determine that it is at 37.47N 122.26W, but if asked where a person is (perhaps the most common question on SMS and cell phones), a person might validly reply:
The goal of this work would be to increase our understanding of how people perceive where they are, and what they are willing to communicate to others. The latter issue can be fairly complex, as it may involve issues of privacy (ex. not wanting your boss to know exactly where you are) as well as specificity (only people local to CMU would really know where "Newell Simon 3002" is, "at school" might be more useful).
It's also possible that distance affects replies. For example, if an inquirer in China asks where you are, it is probably more useful to say you are in "Pittsburgh", whereas if the inquirer is only a few blocks away, it might be more useful to say "At Craig and 5th St".
Some potential research methods include asking people to do a diary study, doing some kind of experience sampling method, as well as some lo-fi prototypes.
One way results from this study could be useful is in understanding what kinds of services people find useful in different situations (since I'm in a bookstore, book services would be useful). Another way is in automatically disclosing semantically meaningful and privacy-sensitive IM status messages to others.
Expected Research Contributions: This project seems fairly difficult to do well, so it's probably better to do two or three short and quick studies to flesh out the design space better. In the long run, understanding how people make these kinds of decisions could greatly improve our ability to model how people perceive places, affect our understanding of how to build privacy-sensitive systems, and improve ubicomp services.
Also see:
Description: Currently, it is fairly easy for computers to determine geographic locations, for example "at 37.2N 137.5W", as well as coarse-grained places, for example "Pittsburgh" or "corner of 5th and Madison". The problem, however, is that it is fairly difficult for computers to determine notions of fine-grained places, for example "Tom's kitchen" or "NSH Atrium". It would be very useful to have a service that could help computers identify these kinds of places.
It should be noted that there are many different notions of places. For example, here is a non-exhaustive list:
There are actually several possible projects here. The key here is to have a compelling story that actually addresses an everyday need that people already have.
Expected Research Contributions:
Also see:
Description: While it is possible to create a raw history of timestamped locations, this information is only marginally useful for certain kinds of applications. In many cases, what is desired is a notion of what was going on at that time and that place. For example, it would be really useful to be able to retrieve all photos of "Jane's wedding" without having to manually tag each of those photos.
As yet another example of a Google hack, imagine if we could do the following:
A good start here would be to figure out common design patterns for calendars on web pages, and then figure out some algorithm that makes it very easy to screen-scrape those calendars into more semantic forms. This algorithm could then be deployed to scrape out events from a variety of web pages, creating a repository of events.
Another possibility is to extract personal events from email, using the same algorithms.
Expected Research Contributions: This is a fairly difficult project to do well, and could use lots of ideas from machine learning, web crawling, and databases. However, it could also have a huge positive research impact, and could be a core service for many future ubicomp systems.
Also see:
Description: Given technology trends, it is very likely in the near future that each individual will be able to keep a personal history of all the locations they have been.
Assuming that each person will have one of personal histories, what are interesting and useful visualizations for helping people process and understand things? For example:
One way of doing user tests is to give people some GPS device to record where they were all day, and then use that data in a visualization the very next day, asking them some simple questions, like where did you have lunch the other day, etc.
Expected Research Contributions:
Also see:
Description: Figure out the right extensions to HTTP and the right way of making it easy to create and deploy location-enhanced web sites.
Expected Research Contributions:
Also see:
Description: Events are the basis for modern graphical user interfaces. They provide a clean abstraction for separating input from output, as well as a simple model for describing user actions. Can the same be said for ubicomp? In other words, can events be used as a simple and natural way of building ubicomp systems?
For example:
The first part of this project would probably entail some kind of field study and lo-fi prototypes to see whether or not events are useful, and if so, in what cases they are most useful. The second part of this project would involve figuring out the systems issues involved. For example, who has access to my alarm clock? How are events actually sent wirelessly? And how can any person actually understand what's going on?
Expected Research Contributions:
Also see:
Description: The event-driven approach described above is only one possibility for end-user programming. What other possibilities are there?
One avenue that might be useful to explore is to look at architectural styles. Architectural styles are similar to design patterns, except that they describe macro-level structure rather than micro-structure (ie the overall system rather than just the interaction between a few objects). Some examples of architectural styles include blackboards, data flow, client-server, layered, and event-based.
The first working hypothesis here is that there might be specialized and simple end-user programming tools that make it easy to develop certain kinds of programs that fit certain kinds of architectural styles. For example, Apple's Automator seems very well suited for data-flow oriented programs, but doesn't handle other kinds of architectural styles as well.
Assuming that there really are simple and specialized tools for each kind of architectural style, the second working hypothesis here is that scripts generated by these tools can be mixed and matched to create larger-scale systems. This would raise the level of abstraction of programming ubicomp systems above lines of code and above design patterns, pushing development towards the higher-level notion of architectural styles.
Right now, I don't have a good example of this, but it would be a good exercise to reverse-engineer some typical ubicomp applications, and see if the basic idea could be applied to those apps.
Expected Research Contributions:
Also see:
Description: Any reasonable extension to Topiary (a prototyping tool for location-enhanced applications) is good.
Expected Research Contributions:
Also see:
Description:
Expected Research Contributions:
Also see:
Description:
The basic idea is to look at what kinds of natural language location queries people make, and to try to support those (where feasible).
So a common one from craigslist.org is missed connections. "I was the good looking guy wearing so-and-so, you were the cute girl in the grocery line. Want to get coffee?" Another example would be "Did anyone see this hit-and-run?" or "Did anyone take a photo of this event?"
The interesting thing here is, assuming that people have a diary of their locations, the guy in this scenario could post this query to the Eventster web site, stating the time and location. Then, people could download a bunch of these queries (imagine that they are like RSS feeds that users subscribe to), run them locally against their diaries, and see if any of them might pertain to them.
These examples use past location information, but you could also imagine using future information. "I'm looking for a rideshare down to Palo Alto this Sunday..." or "I'm heading to Nepal next week...". [Note: This definitely seems possible, but I don't have a fully compelling story for it yet - JIH].
It's also possible to use the same system for current events. Imagine having a universal "what's going on near me?" on your mobile device. The Eventster could aggregate data from listings of such events, like craigslist.org, meetup.com, classifieds, CMU talks, etc, to make it easy to see what's going on. A first cut of this project could use pre-defined web sites and screen scraping to extract events, but future versions could greatly benefit from machine learning techniques that can crawl web pages and "find" events. [Note: This one strikes me as the most compelling example - JIH]
Again, the key is to encode the location info in a simple manner and to let people run it against their personal location diaries, so individuals disclose no information of what was in their diary unless they choose to contact the person making the post.
Expected Research Contributions:
Also see:
Description: The basic (and very high-level) idea here is to do some kind of field study examining what kinds of real-world location queries people are already making, and then doing lo-fi and then hi-fi prototypes of a system to support those queries.
Some examples of such queries include:
There are lots of possibilities for field studies. These might include observing how people use instant messenger or cell phones (ie what kinds of location queries people make with friends and colleagues), or observing how people use listings like classifieds and Craigslist (ie what kinds of queries are made to communities). Depending on the results of your field studies, you might come up with really interesting systems to support activities that people are already trying to do.
Expected Research Contributions:
Also see:
Description: (I blame my younger cousins for this one...) In the cartoon Pokemon, the protagonist often encounters animals he has never seen before. When this happens, he whips out his Pokedex, a small device that proceeds to identify and giving a short description of that individual.
Given modern technologies, it is possible to start creating tools like this. Imagine using a camera phone, taking a picture of an animal (or a plant), and then identifying what that animal is.
Obviously, this is a hard problem. But we can also throw in location data to help filter things out (for example, some animals are only seen in certain geographic locations). We can also have an interactive series of questions as well. For example, the system could ask, "Is it a bird?", and use the user's response to help filter down the possibilities.
Expected Research Contributions: New interaction technique merging computer vision, location information, and end-user feedback to find information.
Also see: Jie Yang's work
Description: Can make use of buddy list / social networking info
Expected Research Contributions:
Also see:
Description:
Expected Research Contributions:
Also see:
Description: There is already a lot of cool and useful data out there, ranging from data describing places, Geographic Information Systems, data about books, social networks, and so on. How can we apply these data sources that already exist for ubicomp?
Here are some example cool data sets:
Expected Research Contributions:
Also see:
Description:
Expected Research Contributions:
Also see: