Tag Archives: GPS

Week 9: more reading and reference collecting

One of the types of sensors I’m looking at are mobile GPS sensors that attempt to determine what mode of transportation one is using, and from that and the GPS trajectory estimate one’s environmental impact (carbon footprint in particular). I’ve found 3 systems doing this so far:

  • Carbon Diem (previously known as Carbon Hero). Carbon Diem is designed to run on GPS-enabled mobile phones (Blackberry and Nokia N-series now, but “platform and provider agnostic”). As this article indicates they have been working on the system since 2006. They are trying to raise money, and focusing on the corporate market initially. The app claims to “tell if you drive, fly, take the train or walk”, and if they can sign a deal with a carrier or handset maker they could potentially launch to consumers in Spring 2009. According to this Guardian article, “the software was almost 100% accurate in working out when people were on airplanes or trains; it was between 65-75% accurate at guessing when people travelled on buses”.
  • Ecorio is a similar application for Google’s Android platform. It also uses GPS to detect the mode of transportation, and estimates carbon output from that. There is apparently support for detecting how efficiently you are driving, which is an interesting twist (though not sure how you provide the feedback when the user is driving). Ecorio also provides suggestions for reductions, such as links to Google Transit, and carpooling info. There appears to be some “what if” functionality built in as well, such as how much carbon will I emit if I start taking public transit half the time (screenshot in this article). Users can also purchase carbon offsets from the phone. There are plans to port the application to other platforms (iPhone is mentioned, but would be difficult given the restrictions on background processing). I wonder if this can be run in the Android SDK simulator, with Bluetooth GPS as input?
  • UCLA’s Personal Environmental Impact Report is another phone-based system. Currently in closed beta, runs on Nokia GPS-enabled phones. They are including other environmental factors, like smog.

It would be interesting to get a hold of some of these sensors and see how accurate they are compared to just recording the odometer & fuel usage information, or marking commutes on a map from memory.

I’m really liking BibDesk, the Mac OS X BibTeX manager. One really nice feature is being able to link URLs or local files to references. So you can save a PDF of a paper to your hard drive and link the BibTeX record to the file for easy access. It can also show you a nearly instant preview of how the currently selected item will be rendered in LaTeX. There are a bunch more features I haven’t dipped into yet, such as auto generation of cite-keys and automatic managment of your PDFs.

I’m still not quite sure how to cite web sites. For now I’m using the misc BibTeX type, and putting a \url{http://...} in the Howpublished field, which seems to produce reasonable output.

Planned items from last week:

  • Read 4 papers from literature review list
    • Understanding mobility based on GPS data [DONE]
    • Learning Transportation Mode from Raw GPS Data for Geographic Applications on the Web [NOT DONE]
    • Displaying dynamic carbon footprints of products on mobile phones [DONE]
    • Energy efficiency: rebounding to a sound analytical perspective [NOT DONE]
  • Start building table of possible sensor inputs [STARTED]
  • Add publications from PET workshop paper to BibTeX [DONE]

Other accomplishments this week:

  • Added a bunch of papers to lit review on Khazzoom-Brookes Postulate
  • Added several more papers while tracking down references from PET paper

Hours worked: 15 (target: 15 hr)

Plans for coming week:

  • Read 4 new papers from literature review list
    • Learning Transportation Mode from Raw GPS Data for Geographic Applications on the Web
    • Energy efficiency: rebounding to a sound analytical perspective
    • New Ways to Promote Proenvironmental Behavior: Expanding and Evaluating Motives for Environmentally Responsible Behavior
    • A Definition of ‘Carbon Footprint’
  • Add more sensors to list
  • Write up notes from papers read during PET paper lit review
    • EcoIsland: A System For Persuading Users To Reduce CO2 Emissions
    • Taking the Guesswork out of Environmentally Sustainable Lifestyles

Pointers to work products:

Cool links:

  • Nothing I can think of
Advertisements

ICS 699 Fall 2008 week 2: GPS data displayed

Having gathered some GPS data using the AMOD AGL3080 GPS data logger, it’s time to download it and start taking a look at the data.

I’ve been meaning to read up on the AGL3080. The user manual and quick start guide are available online (they are also put onto the flash). My unit shipped with the 2.0 firmware, but the AMOD website shows they have version 2.2 now.

The GpsPasSion forum has a thread discussing the AGL3080. Lots of good info there, need to go through it all. One major issue is the static navigation feature on many GPS devices (including the AGL3080). Static navigation appears to be a hack that GPS chipset vendors have put into their devices to help car navigation software. The GPS data is filtered so that the location doesn’t jump around even when that’s what the GPS signal indicates. This is almost certainly not what I want, so I need to turn static navigation off. Luckily AMOD has created two versions of the firmware for the AGL3080: one with static navigation on, and one with it off. Need to dredge up a Windows PC to reflash the firmware though. :/

For quick experimentation, the GPS Visualizer web site looks pretty nice. It’s a web service that will slurp up raw GPS data (among other inputs) and display it in a variety of ways. Here’s my first GPS track displayed via Google Maps. This is interesting, but really what I want is the GPS data shown as little breadcrumbs, not a continuous line. GPS Visualizer has a lot of options, so perhaps this is possible. It’s not clear what happened at the end of that track where it jumps over to the pier near Ward Warehouse, as I certainly didn’t go there. Here’s the same data as a Google Earth KMZ file, where you can do a flying tour.

GPS Babel appears to be the Swiss Army knife for GPS data. It takes in a variety of GPS data inputs and spits out processed data. It’s multiplatform, and licensed under the GPL, which is nice. This looks like the way to go for local GPS data processing.

Once the GPS data has been massaged into a nicer format, the next big step is segmenting it into different transport types. I’m thinking of a multi-pass process where the first step looks for obvious possible segment endpoints such as: long periods with no satellite fix, sudden changes in speed lasting > 1 minute, and location discontinuities. A second pass goes over each inflection point and looks at the data on either side to see whether it is really a change in the type of transport (like getting out of a car and walking) or just stopping at a traffic light.

I’ll be on a mainland trip for the next week, so I don’t expect to make much if any progress between now and next Wednesday. After that I’ll be back for only 2 days before heading out to Seoul for Ubicomp and the Ubiquitous Sustainability workshop, so I’ll be focused on preparing for that in the little time I have.

I was hoping to bone up on LaTeX this week, but it didn’t happen.

Past week accomplishments:

  • Web research portfolio started
  • Downloaded first weeks’ worth of GPS data
  • Dug up information on GPS logger, found issue with static navigation
  • Generated initial plot of GPS data in Google Maps and Google Earth
  • Continued logging GPS data and travel diary

Hours worked: 10ish (target: 15 hr)

Plans for coming week:

  • Continue recording GPS data & travel diary on trip
  • Read workshop papers if they are made available

Pointers to work products:

Cool links:

  • Nothing springs to mind

ICS 699 Fall 2008 week 1: GPS data logging

This week was mostly preliminary activities. As mentioned in my intro post, I’m currently investigating whether I can determine the amount of greenhouse gas produced by transportation using GPS data points. The basic idea is this:

  • Collect data on where a person is located and their speed every few seconds via GPS
  • Upload that information to a computer periodically
  • Infer from GPS data what modes of transportation (walking, biking, driving, riding bus, riding train, riding boat, flying, etc) were used for each segment of each trip
  • Determine the length and approximate speed of each segment
  • Using the length, speed, and mode of transport for each segment, estimate the amount of greenhouse gas produced
  • Provide a variety of analyses on the data such as: total GHG production per day or per week, calories expended, “what if” comparisons between modes of transport (how would my GHG production change if I traded in my Impala for a Prius?)

Obviously, to get started I need data, so I’ve started carrying the AMOD AGL3080 GPS data logger daily. The reason I went with the AGL3080 is that it stores the data onto built-in flash memory that can be mounted like any flash drive. Most GPS data loggers have some custom driver (OS-specific) that you have to install in order to get the data off, but the AGL3080 will work with any computer that can mount a USB flash drive.

I figure that for regular usage, there can’t be much special effort required to gather the GPS data. I’ve been clipping the included strap to one of my belt loops and turning it on before heading out of the house in the morning and turning it off when getting home at night. This is wasteful in terms of battery usage, since the data logger spends several hours each day inside with no view of the GPS satellites (and no useful data to record even if it could see the sky). However, requiring the user to remember to turn the logger on before going outside and off when coming inside seems like a recipe for constantly missing data. I’m also not making any special effort to put the logger somewhere with a better view of the sky when I’m in a car or riding the bus, to reflect how it would be used by a normal user.

I’ve been collecting data for about a week now. I haven’t downloaded or analyzed the data yet. The batteries (recharegable Eneloops) seem to last about 2 days before needing to be recharged. In addition to the GPS data, I’ve started a travel log in a little notebook, recording where I went that day and via which modes of transportation. This should be helpful when segmenting the data so I have some “ground truth” on what mode I was using when the data was collected.

Converting from GPS data to mode of transportation is where the magic happens. It may be the case that certain types of transport, like jogging and bicycling, cannot be reliably distinguished using just GPS data. However, for some types of transport (like jogging and bicycling) we might not care since both have very low GHG emissions. Telling car trips and bus trips apart could be tricky, and it’s an important distinction. I am hoping that the raw GPS data will be enough (buses usually make frequent stops, they accelerate and decelerate slower than cars, riders often wait at stops before getting on the bus), but the bus routes are another source of data for differentiating the two modes. Bus route data could be retrieved from things like Google Transit or bus maps, but it could also be crowdsourced, allowing users of the system to indicate which segments were by bus and then applying that to other users data.

If GPS data turns out to be insufficient, 3-axis accelerometer data could be another cheap simple source for disambiguation. The acceleration profile of different vehicles, fused with GPS data might tell a bus from a car.

Once the segmentation/identification has been done, there is still the issue of converting it into GHG emissions. My impression (as yet not backed by citations) is that this is a fuzzy area where the results depend greatly on what assumptions you make. If this turns out to be the case, then I plan to make the GHG calculation formula exposed for user modification. This allows users to see what assumptions have been made (important since the results could be deliberately skewed in favor of one mode of transport or a particular product), and experiment with the assumptions and see if they can come up with something better.

Past week accomplishments:

  • Started logging GPS data and recording travel log
  • Came up with ideas for ICS 413 project
  • Started looking at LaTeX again
  • Got permission from grad chair to submit research portfolio in web format
  • Thought about and wrote up more details on ideas about tracking transportation GHS emissions via GPS data logging (above)

Hours worked: 10ish (target: 5 credits * 3 hours/credit = 15 hr)

Plans for coming week:

  • Start web portfolio
  • Download initial GPS data, start visualizing in Google Maps/Earth and maybe Excel
  • Read AGL3080 manual, check out available logging rates
  • Investigate LaTeX options for Mac OS X
  • Install LaTeX
  • Try getting uhthesis LaTeX style working on modern LaTeX

Pointers to work products:

  • Just this blog post for this week

Cool links:

Google’s Chrome browser (currently Windows-only) looks interesting. It’s based on Webkit (which also drives Safari), so hopefully this means that we’ll see better support for Safari around the web (and certainly on Google sites).

The Chrome comic book explains the details of why it’s interesting. They even discuss their testing process (they apparently do regression testing on millions of crawled pages from Google’s caches) on page 9. They mention TDD on page 11. 🙂

DBEDT is now producing monthly energy reports. Lots of interesting data in there. Philip has suggested I throw it into Swivel and/or Many Eyes, but I haven’t undertaken that yet.

Mozilla Ubiquity seems like an interesting project. The demo video looks cool, not clear how rigged the demo is though. 🙂