Category Archives: CSDL

ICS 699 Fall 2008 week 3: slow week

I was on the mainland most of the last week, so I haven’t accomplished much on ICS 699 stuff. I gathered some more data, using the new technique of adding a waypoint (via the flag button on the AGL3080) when changing modes of transportation. I have noticed that it is hard to remember to do this, so the waypoint data is definitely incomplete. Philip suggested that I augment the waypoints with voice memos (possibly via some iPhone application) to record what is going on at that point. Of course one still has to remember to do it. 🙂

I’m thinking that instead of focusing on this constant data collection, I should try a controlled experiment where go through a planned route traveling both by car and on foot while carefully recording where I go. Correctly segmenting that data stream would be the first milestone for the automated data analysis. I also realized that rather than a completely generalized system (that can distinguish between walking, biking, cars, busses, etc), just being able to tell when you are driving and when you are not would provide a large portion of the data I want.

While traveling, I kept the GPS data logger on in airports until it was time to board the plane. However, I think while in the airports of connecting flights I frequently didn’t get GPS signal, which would be a problem for any type of automated analysis of air travel. Perhaps the best that the system can do is detect when you have traveled by air and offer to import the detailed information from something like TripIt.

Sunday is the Ubiquitous Sustainability workshop at Ubicomp 2008, so I’ll be assembling a short talk on PET in case that turns out to be useful.

Past week accomplishments:

  • Continued logging GPS data and travel diary

Hours worked: 2 (target: 15 hr)

Plans for coming week:

  • Prepare 2 short presentations for the 2 Ubicomp workshops I’m attending
  • Present to CSDL for Ubicomp practice
  • Read workshop papers
  • Continue recording GPS data & travel diary on trip #2
  • Attend Ubicomp
  • Write up workshop notes

Pointers to work products:

  • Blog post

Cool links:

  • Academia is a sort of social networking site for academics. It provides a tree view of institutions, and a canonical place to put up an academic profile page. Right now UH has one department and one person listed.
  • ImageStamper is a solution to the problem of authentication of CC licensed images. Say you grab an image from Flickr that is CC licensed, but later the owner changes the license and harasses you about your use of the image. ImageStamper keeps a timestamp of the image and the license it is shared under for future reference.
  • LimeSurvey is an open source package for running online surveys. Might come helpful when evaluation time comes.
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. 🙂

Introduction to my CSDL peeps

My name is Robert Brewer, and I’m in the ICS PhD program at UHM. I’ve been bouncing between academia and industry for 16 years in Hawaii: I took my first class at UH in Fall 1992, joined CSDL in the Spring of 1993, left to found LavaNet in the summer of 1994, came back to UH to finish my ICS MS in Spring 1998, graduated in Spring 2000 and went back to LavaNet until the Fall 2005. I worked as a sysadmin in the ICS department for 3 months in the winter of 2005, and came back as post-baccalaureate student in the Fall of 2006, and rejoined CSDL. I formally entered the ICS PhD program in the Fall of 2007, and at that time I left CSDL to join LILT to work as an RA on the HiMax grant (now known as the Ubiquitous Wireless Applications group). I’ve come back to work with Philip on my PhD dissertation in CSDL, but I’m still working as an RA in LILT so I’m a part of both research groups.

My current research area is working on using information technology to address issues of climate change and sustainability. I wrote this position paper (Carbon Metric Collection and Analysis with the Personal Environmental Tracker) for the Ubiquitous Sustainability: Citizen Science & Activism workshop that is happening before Ubicomp 2008 in Seoul in a few weeks. I also have a workshop paper based on my work in LILT (SocialSense: A System For Social Environment Awareness) for the Devices that Alter Perception workshop, also at Ubicomp.

Now I’m trying to carve a dissertation topic out of the vision for PET. My first attempt is looking at whether GPS data (from an off-the-shelf GPS logger) can be used to calculate one’s carbon emissions due to transportation. Hopefully the GPS data can be used both to determine what mode of transportation is being used (foot, car, bus, train, plane, etc) and the length of each trip. There is other research in this area, so I’ll be looking at that as part of my literature review.

By the end of the fall 2008 semester, I’m planning to have my research portfolio ready to submit to the ICS department by the end of the semester, and have a dissertation proposal either complete or well underway.

Installing MacPorts from the Command Line

I wanted to install MacPorts on an Xserve using ssh. This involved doing two things I had never done from the shell: mounting a disk image and running an installer. Here are some quick instructions in case someone else needs to do this. It is assumed that you have already installed Apple’s X11 and the X11SDK per the MacPort install instructions.

  • ssh to the Mac OS X system
  • Download MacPorts
  • Mount disk image
    • hdiutil attach MacPorts-1.5.0-10.4.dmg
  • Run the installer
    • sudo installer -verbose -pkg /Volumes/MacPorts-1.5.0/MacPorts-1.5.0.pkg -target /
  • Add /opt/local/bin (and probably /opt/local/sbin) to your path in whatever way your shell requires
  • Update MacPorts to the latest version
    • sudo port -v selfupdate
  • Unmount the disk image
    • hdiutil detach -verbose /dev/disk4
    • The device was displayed when you mounted the image, if you forgot it then run mount

JavaScript Charting Packages

I was looking at Google Finance and marveling at their nice interactive chart. Such a chart would be very sweet for Hackystat or a Saunders kiosk. I thought “surely someone has written a open source JavaScript charting package”, and began Googling.

Later I realized that Google Finance is using Flash for their chart (boo!) so the playing field is not quite level.

Ffor interactivity I could only find one package: Emprise JavaScript Charts. It looks pretty sweet, but it is commercial so it’s not clear how useful it would be for Hackystat.

Other JavaScript charting options (none allowing scrolling and dragging as far as I can tell) are: PlotKit, Plotr, and WebFX Chart Widget.

One problem with making charts via JavaScript is the lack of a good cross-platform drawing system. The implementation page from WebFX Chart has a pretty good summary of the situation. It appears there is no perfect solution, but Canvas seems to be the best cross-platform option.

There appears to be a lot of activity in this area (many of the packages listed are pre-1.0) so perhaps this is a case where procrastination will pay off.

Sadly, I cannot seem to find a link to the paper I remember reading that showed that procrastination can be effective when purchasing a compute cluster to work on a particular project. A cookie for any CSDLer that can dig it up! 🙂