
MobiPool was my Capstone project for the Informatics program at the University of Washington. This is the abstract for the project:
Adam Argo, Senior, Informatics
Mentors: Batya Friedman and Dave Hendry, Information School
Car ownership in urban areas has been on the decline in recent years. Factors such as increasing costs of fuel, parking, and insurance; increased availability of public transit; and alternatives such as ZipCar and FlexCar have all contributed to this decline. However, people still often need to get places that their regular means of transport cannot accommodate, and may need to share a ride with someone. Drivers may also want to share rides, either to share the cost of fuel or parking or to use the HOV lane. People are also increasingly using social networking websites, and recently using these websites on their mobile phones, to manage many aspects of their lives. MobiPool uses existing social networking infrastructure and mobile phones to connect people to rides they may need. By using Facebook’s interface to peoples’ existing social relationships and a website designed specifically for mobile devices, MobiPool lets people find and share rides with the people they already know, all from their phones. The prototype of the application’s usability will be investigated using think-aloud studies with current Facebook users to evaluate breakdowns in completing tasks and improving usability. Future work on the project involves tighter integration with other sources for destination events, synchronizing rides with external calendar applications, and device-specific native applications to access the system.
Another description
MobiPool uses the Facebook API to access the social relationships already established on the site, and then lets them use that information to share rides or find rides. It was specifically targeted at mobile devices, and this prototype was specifically geared for the iPhone. To eliminate barriers to entry, it was designed as a website that uses various mobile WebKit CSS properties to create a native look and feel on the iPhone. In the forthcoming project submission video there will be more about its design, development, and evaluation.
YouTube video
Files
Screenshots:
Technologies used

Door Robot
My Door Robot isn't a single piece of software so much as a cool project with various pieces of software I've written and hardware I've created. The original premise was that I wanted to be able to unlock the front door to my apartment building wirelessly and remotely. I purchased a small wireless transmitter/receiver setup from eBay and wired it to the existing infrastructure so that I could unlock the door from anywhere about 200m away. This was fine, but I wanted to use my phone to unlock it, so I had to keep working.
The second step allowed me to open the door from literally anywhere. I purchased a USB relay box from Serial Controls that allowed me to activate the remote through software. I implemented an iPhone application, a WAP page, and also a text messaging interface (script piped through sendmail) to open the door to the building. Simply text "open" to a given number and the door opens.
The last step was to create a device that used a servo motor to turn the deadbolt to my apartment door. This idea came from the guys at Makers Local 256, who used USB keys for authentication to unlock the door. This servo is controlled by a Freeduino board. The relay board sends a signal to this board, which in turn flips the deadbolt. A reed switch detects if the door is open or not, and the door waits five seconds after unlocking to lock again. If it's not open, it'll lock, otherwise it'll wait another five seconds. There's also a button on the door to unlock it and an override switch that keeps the door unlocked for an extended period (say, taking out the trash or getting the mail).
I've since repurposed the original remote to be used as a "hidden key" to unlock the door in the event of a power or Internet failure, and hardwired the relay box to the building infrastructure to open the front door. Because of the nature of the servo, if it has voltage applied to it, the deadbolt cannot turn. The remote is a manual override for this. If the power is out completely, the servo will be able to rotate, so I can use old-fashioned keys to enter the apartment.
Recently, I've added another piece of hardware I made (pictured below) that senses when the buzzer is pressed. When this happens, a notification (currently a text message, but soon an Apple Push Notification when it is implemented in iPhone OS 3.0) is sent to my phone alerting me. This is useful when the UPS man comes and I'm not home, but would like to let him into the building to deliver my package.
Here's a YouTube video of the project:
Screenshots
Technologies used
Freeduino board from HVWTech.com, R4Box from Serial Controls, wireless setup from eBay seller e-MadeInChn, Visual C# for interfacing with the relay, iPhone SDK, and PHP to tie it all together.
Downloads:








Computer Vision Video Game Cheating
I had some interest in computer vision, so I decided to try to learn what it's all about the only real way: by doing. My roommate was spending a lot of time playing a mini-game in Fable 2, which seemed like a perfect task to conquer using computer vision.
After acquiring a webcam, a USB relay board, and sacrificing an XBOX controller, I sat down and wrote some software using OpenCV (and, more specifically, the OpenCVDotNet library). The code is pretty straightforward -- it takes an image from the webcam, looks at a specific area on the image (which can be drawn by the user), and checks to see if the pixels match certain criteria for similarity in color. I've tried to make it highly adjustable because I've noticed that the closer the pixel matching is, the more reliably it performs. The analyzed screen area is generally small -- approximately 30 square pixels or less -- but this has proven to be adequate to accurately have the computer play the game for me.
I'm unsure, but I think the game itself limits the "chain" one can build to about 30. Visually the system appears to operate as it's supposed to, but at around the 30th "pull" it fails. There is no visual indication that it is not reacting fast enough. I'm currently working on object detection for uses both in this game and otherwise.
The biggest drawback is that it's a bit slow. Using this to control, say, a Guitar Hero game wouldn't work super-well because of the delay between capturing the video, processing the images, and then triggering the relay. I've seen other projects that used photosensors to quickly respond to games like that, but for this game it seems to work decently. I think with appropriate anticipation that workarounds could be accomplished for games like Guitar Hero or Rock Band.
Here's a YouTube video of the project:
Images
Technologies used
USB Relay Board from Endurance RC, Visual C#, OpenCVDotNet




Facebook Desktop - (launch site)*
Facebook Desktop (better name pending) was my attempt at designing a superior user interface for Facebook. This was made two design iterations ago, when things were quite a bit different. Since Facebook has changed its direction to be more similar to Twitter, this is kind of an irrelevant website, but a good example of integrating their API to create a different kind of interface.
This website is still in a very preliminary version, but demonstrates the potential functionality such a website could create.
Technologies used
PHP, MySQL, JavaScript (particularly the Ext platform), and the Facebook API.
* requires a working Facebook account