Projects

From CS219

Jump to: navigation, search

Contents

Authentication and Secure Communication

  • People:
    • Nicolai Munk Petersen <nmp a?tt webcore d_t eu>
  • Project Summary:
    • I am working on a project on authentication and secure communication for mobile clients (cell phones). I currently have a working back-end system that third-party application developers can query and users can login to via a web interface. The next challenge is to roll-out this Kerberos/PKI hybrid authentication system to the phones. Hence, users will be able to login on the phone using their Kerberos identity or be automatically logged in as part of the PKI handshake process. In addition, there need to be performed a threat analysis and a performance evaluation - real-life application developers that are willing to use it could be a great.
  • Comments:
  • Proposal:
  • Diagrams and graphs:

Driving Or Not

  • People:
    • Tin Yau Chong <chongtin@msn.com>, <chongtin@ucla.edu>
  • Project Summary:
    • Given a set of data points that know as a motorized transportation, we would like to distinguish if the data set belongs to a person who was taking a bus or driving himself. To do this, we will analyzing GPS reading and the background noise of the data.
  • Details:
    • This project mainly consist of two parts, and they are the sensor-side program for the phone, and the data analyzing part.
    • Sensor-side Porgram:
      • The sensor side program is written by python for Symbian OS, and loaded on Nokia N95 cellphone. It allows user to take data while she is driving or riding a bus.
        • GPS data point will be taken every two second with vertical and horizontal accuracy.
        • GSM data point will be taken every two second.
        • Two seconds of background noise will be taken every 60 seconds.
        • Date will upload to sensorbase every 30 min. or if the user press Stop.
    • Data Analyzing:
      • The methods we are going to use are GPS-based point scanning, and background noise analysis with support vector machine. For details, please reference our project report.
  • Proposal:
  • Project Report:
  • Project in ZIP format:
  • Project Demo Page:
  • Gallery:
  • Result:
  • Interesting Thought:
  • Comments:

ParaWorld

  • People:
    • Cho-Nan Michael Tsai <chonan.tsai@gmail.com>
    • Pei-Chun Payne Cheng
    • Chien-Chia Chen
    • Jih-Chung Fan <jcfan@cs.ucla.edu>
  • Project Summary:
    • ParaWorld is a GPS-enabled strategy/RPG gaming system that allows a player to participate in a game by performing physical activities in the real world. Physical activities that result in a location trace, a picture and/or audio clip captured by a Nokia N95 mobile phone will affect his or her game character and the overall game status. The game interface in Nokia will provide mostly text-based, real-time player status info. Player-generated data are uploaded and maintained in a backend database. The visualization for the game world will be created using Google Map API. Visit our official game website![1][2]
  • Term Paper
  • ParaWorld Website:
  • Proposal:
  • Status:
  • Figures and Screenshots:
  • Comments:
    • Please feel free to add any comment :-)
  • Final Demo:
    • 1. Project Overview
    • 2. Web Interface [3]
    • 3. Game Play Demo
    • 4. Quest
      • campus tour
      • allergy
      • census
    • 5. Evaluation
      • Image matching
      • Avg. response time
      • Playability
    • 6. Conclusion
    • 7. Demo Video [4]
  • Experiment Result:
    • 1. Response Time of Commands [5]
    • 2. Power Consumption measurement [6]
  • Source Code:
    • 1. Cellular Phone Module (Jih-Chung Fan)
      • Install Packet [7]
    • 2. Website and Web Interfaces (Chien-Chia Chen) [8]
    • 3. Database
      • ParaWorld data dump [9]
      • ParaWorld table and constraint creation script [10]
    • 4. AP Server and Image Processing (Pei-Chun Cheng) [11]
  • Documentation:
    • 1. Final Project Report [12]

Parking Alert System

  • People
  • Project Summary

Parking policies can be hazardous to your wallet. Even though you pay the parking meter for an alloted time, a second too late is enough for a parking officer to leave a citation on your vehicle. The Parking Alert System reduces the risk of getting your vehicle cited, or towed, by notifying the user when their vehicle is about to violate one of the parking policies that the car is subject to. The Parking Alert System does this by, first, classifying the user as driving the vehicle or parking. An adaptive learning algorithm takes in GPS readings, along with inertial measurements (accelerometer), from the phone, to determine whether the car is in motion or parked. In the event of parking the vehicle, the system will lookup the parking policies for the immediate location (GIS information) and, if the system confidence is not above a threshold, prompt the user to confirm the parking policies. A centralized server will maintain a safety margin for the vehicle, and, if the safety margin falls below a threshold, the sytem will SMS the user to check on the vehicle. [13]

  • Project Proposal [14] (updated May 4th, 2008)
  • Project Diagrams
  • Final Presentation [15] (updated June 7th, 2008)
  • Final Demo Video [16] (updated June 7th, 2008)
  • Comments:

Road Quality Meter

  • People:
    • Alireza Vahdatpour <alireza@cs.ucla.edu>
    • Benjamin Chang <bychang@ucla.edu>
  • Project Summary:
    • In this project we aim to monitor the quality of roads using the accelerometer data coming from Nokia cellphone. Road quality can be an important factor in choosing the directions from one place to another. Unfortunately, there is no up to date service on the web that can inform people about the quality of roads and streets. When people are driving in their car, cellphones are usually in a fixed position on dashboard, ..... Our goal is to interpret cellphones accelerometers output as a measure of road quality (Both specific potholes and road general condition), tag data with appropriate GPS and time information and upload it to a server that visualize this information in a map for users.
  • Comments:
    • Rahul Vaidya
      • How would you differentiate a specific pothole from the user moving the phone around in the car?

Thanks for the very good point. There are two different situations: 1- When the user is taking to the phone. In this case we can check if a call has been made. 2- When the user is just moving the phone. In this case, from out experiments, we believe that a good signal analyzer can detected these situations easily.

      • You might want to let users add custom annotations. For instance, up north in San Jose there's a portion of the northbound 280 freeway where the lane lines have completely faded away, and when you're driving home from work the low setting sun glares off the road. The two combine for a very potent driving headache, and could cause accidents.
  • Progress:
    • So far, we have developed our reporting module(which sends data at 5 minute intervals). We have also designed the module that monitors and reports 3-axis accelerometer data. We still need to develop our website to report the results that were found by the reporting module, as well as continue to work on an accurate algorithm for determining when a pothole has been encountered. We have had much more difficulty than expected in that area and are thus possibly cutting some of our feature set out in order to gain higher accuracy in our results.

Here is a sample output from vertical axis of the N95 accelerometer, while we are driving.

  • Web-side code [17] (updated June 10th, 2008)
  • Cellphone code [18] (updated June 11th, 2008)
  • Final Report [19] (updated June 11th, 2008)
  • Road Quality Meter Site [20]

GEOX : Deriving Geographic Interconnections <-- click here for more!

  • People:
    • Kyo Lee <kyolee@cs.ucla.edu>>
    • Rahul Vaidya <rahulnvaidya@gmail.com>
    • Mohammad Rahimi <mhr@cens.ucla.edu>
  • Project Summary:
    • We will investigate an analytical methodology to study complex spatial and temporal dynamics of a population by using coarse location information from the mobile phones. With the data obtained by aggregating the geo-traces of individuals that represent a population of some specific region in Los Angeles, we can derive a network of interconnected regions, which information will be valuable for various other science domains such as epidemiology, transportation network planning and urban planning. Within the scope of this class, we will deliver a prototype version of web-based software tools for sharing and aggregation of coarse-grained geo-traces from mobile phones and visualization of both the derived network and the analytical results. We will explore APIs from the Google Map and FaceBook to provide interactive and user-friendly applications that can manage a large scale of data and users once deployed.We will also study the methodology for effectively and efficiently collecting coarse location information by examining various GSM-based and GPS-based location mapping technics, and focus on mapping such information to regional representation that is visually coherent and trivial.
    • Proposal
    • Cell Tower Centroid
    • Available Regional Data
    • Final Report DOC
    • Final Report PDF
  • Comments:

Project M

Use the hyperlink above to find more information about the project.

  • People:
    • Min Mun < bobbymun@cs.ucla.edu>>
    • Sasank Reddy <thecleanmachine@gmail.com>
    • Jason Ryder <jryder@cs.ucla.edu>
    • Vids Samanta <vids@cs.ucla.edu>
  • Project Summary:
    • Applications exist today that are able to use the current location to deliver customized information. But what if we can take advantage of a history of such data? In our work, we plan to build mobility models for individuals that summarize frequent locations and repeated routes. In addition to building models of individual mobility, we will explore methods predict the location of a user based based on past history, compare the mobility of individuals or groups to figure out who exhibit similar profiles, look into methods to protect privacy by using resolution control mechanisms (adding noise, hiding samples, etc..) to see how pattern generation gets affected. Our application driver deals with walkability associated with a route - once we identify a frequent routes that a set of people take (and thus have a higher potential to verify) - we will ask them to document that route in terms hazards (objects in the way, problems with infrastructure) and inconveniences (stairs/high grade hills). A by-product of this project is a framework to allow data collection campaigns to be authored, executed, and visualized in a rapid fashion.
  • Comments:
  • Proposal:
  • Final Reports
    • Campaign Framework [21]
    • Selective Hiding:Model Based Spatial Cloaking[22]

LoCal

The Calendar Reminder System that Knows Where You Are

  • Team Members:
    • Konstantinos Niktas <kniktas@cs.ucla.edu>
    • Natalia Vinnik <nvinnik@cs.ucla.edu>
    • Anand Mehta <anandm@cs.ucla.edu>


  • Project Summary:

Most reminders people create are time-based. They can use a calendar feature in their phone or on some computer application (e.g. Outlook, Google Calendar, etc.) Any reminders that attempt to be location based, involve putting a post-it near that location. This isn't feasible for something like the grocery store, school lab, or even when you are close by to a friend. In this project, we present LoCal, a location-aware phone-based reminder system, that allows a user to associate reminders and alerts with a specific location. Locations can be defined by GPS, Wi-Fi Access Points, and Bluetooth devices. A user can define an alert, reminder, etc. and then associate a location with it. Since Bluetooth can also be used to define locations, a location can also be associated with a friend's cell phone, PDA, laptop, etc.


  • Comments:
    • Place your comments here or use our blog

BlueSense

  • People:
    • Donnie Kim <dhjkim a?tt cs dot ucla>
    • Dae-Ki Cho <pinecho a?tt cs dot ucla>
  • Project Summary:
    • Lost items can often be frustrating to find alone. But imagine your entire neighborhood helps you find them! BlueSense is a participatory sensing system that eases the partaking of helping others and higher the opportunity to find your lost item tagged with a small Bluetooth dangle. Reported lost items are automatically published to a small set of participants who has a better chance to locate your lost item. This can be based on the route you took during the day and the participant's mobility range. Whenever participants discover a missing item within his/her range, available location information (GPS/GSM/WiFi) is directly sent to the owner of the lost item. While many design issues exists in architecting the system, including security/privacy, scalability, and power efficiency, this project will focus on experimenting and maximizing the performance of detecting and locating a lost item within different environments using Bluetooth equipped mobile phones.
  • Comments:
    • Nicolai (08.04.24): I like the general idea, the technical scalability issues, and search heuristics must be fun to develop. I would suggest focusing on the human-location feature. Most people carry a cell phone with bluetooth and some have other location devices too (e.g. GPS). Say you are searching for a person and that person is close to another person with a GPS then you can attest the finding with an exact location without revealing the identity of the middle-man (directly, at least). It is not possible to triangulate users based on the cell id because each phone can only "see" 1 at a time, but what if you had multiple phones close to each other?? I would spend some time thinking about the scalability issues. How do you make sure you don't flood the network if too many people are querying it at a time? Some kind of context-aware heuristic (manual or automatic) might come in handy? Best of luck!
  • Project
  • Proposal:
  • Check Point Slides:
  • Final:

Social Mirror

  • People:
    • Kyle Dorman <kyledorman@ucla.edu>
    • Ji Yeon Lee <leejiyeon.jay@gmail.com>
    • James Hou <jameshou@ucla.edu>
  • Project Summary:
    • Have you ever wondered just how social you are? In this project, we aim to measure and capture the social behavior or, to be more precise, the social interaction of an individual. We will initially record and log all conversations that an individual has. We will then capture the basic metrics of social interaction such as how often and how long are his/her conversations. We will also identify any temporal and spatial patterns a person may have; that is, when and where do they have the most conversations? Last, we will investigate speaker recognition to see if it is possible to identify three other characteristics: how many different people a person interacts with, how many conversations are with a group rather than just 1 other person and how many different people a person talks to during the day.
  • Project Proposal: Social Mirror Proposal
  • Project Wiki: Social Mirror Wiki
  • Project Homepage: Social Mirror Homepage
  • Final Project Report: Social Mirror Final Project
  • Zip containing all files: Social Mirror Files
  • Comments:


Public Transportation Awareness System

  • People:
    • Faisal Alquaddoomi <falquaddoomi@ucla.edu>
Basically, I want to pair people up with public transportation routes that coincide with their usual travel path, and then have them report on public transportation conditions once they start using said suggested routes.There are two phases to the idea:
  1. Route Suggestion: The mobile phone will constantly relay position information to the server, which will slowly gain confidence in the user's regular routes, perhaps over the course of a week of training. Once regular routes have been identified, the server will compare their route to known public transportation routes and send suggestions to the user in the form of alerts received on their phone (either through the logging application or through SMS). Once the user accepts a route, the server will be notified that they are now using this route, which begins the second phase.
  2. Route Refreshing: The server will establish that a user takes a particular public transportation route, either by being told explicitly by the user or by analyzing the location trace (most likely it will be explicitly told). The user will, when taking the route, notify the server of the conditions of the route while using it. For instance, if they are taking a bus, they will notify the server of the actual time that the bus arrived. The server will compare this information to the official schedule, and make this information available both on a website and possibly in the form of alerts to users who use the same route (perhaps later down the line). Additional information may optionally be collected, such as crowdedness, 'bumpiness' of the journey as collected from an accelerometer, noisiness, personal notes, etc. to build a more detailed profile of different public transportation routes in the interest of providing this information to the public.
The general idea is that a user who is sitting on a bus is most likely going to have a lot of time on their hands; why not harness it to do some in-field blogging? Optionally, additional metrics may be computed which might be of interest to the end user, such as money saved, reduction of pollution footprint, increase in time not spent driving, etc. as a result of using public transportation.
  • Project Progress:

I've been working exclusively on phase I, mostly in trying to get the GIS data imported into the database server. I've modified the tracer application written for the homework project to log some more features that I'm interested in capturing (accelerometer values, for instance, at the time that the GPS position sample is taken). I'm storing the data to a temporary sqlite database via a web service that looks a little like sensorbase's, since I don't have the PostGIS database working to store anything to yet. Once I manage to get the database server working, I intend to first concentrate on allowing users to subscribe to routes manually, then to send updates about the routes they're subscribed to, then to query the system from their phone, and finally to do the route matching.

Personal Identification via Activity

  • People:
    • Robert Chen <mr.robertchen@gmail.com>
  • Project Summary:
    • In a mobile environment, users may want to make spontaneous connections with others close to them (e.g. exchanging personal info at a conference via Bluetooth). In such situations, we want to make sure that the people we are connecting to are currently in the same room, or at least very close to us. If two user devices want to verify their locations, the devices will simultaneously record an audio clip of the sounds in the present environment. Using these clips, the two devices can then generate a signing key. If the two users are in the same room/area, then the audio clips collected will be the same, and hence, both devices will generate the same signing key.
  • Comments:
Personal tools