Well, I shouldn't really say building a fingerprint-operated  lock so much as modifying a lock and building/programming the control system.  One day about 4 weeks before the end of my freshman year, I was browsing eBay and found fingerprint readers for $15/piece.  I decided to buy two as I whimsically daydreamed about the cool things I could do with fingerprint readers.  Days later, the readers arrived and my roommates and I quickly began to think of ideas for projects.  We found a number of ineffective fingerprint recognition programs or great ones that were not compatible with our readers.  We did however find a wonderful demo kit from Neurotechnologia Inc.  I e-mailed them, explaining I wanted to do a student project with their software and they were good enough to send us their software development kit free of charge.

 I then did some reconnaissance on our door locks.  They are standard institutional locks produced by Best Locks.  I found that to activate the external door knob, we simply needed to redesign and cut a pin to replace the solid one in the lock.

The Lock

I selected a position for our locking mechanisn and then set out to find a solenoid.  I originally hoped to use a double-throw solenoid that would allow me to lock and unlock the door without continually using power.  In the interests of control system design and machining time, I eventually decided against this and purchased a simple, single-pull solenoid that fit in the lock.

 The Solenoid Placement

Measuring out the pin, I CADed a new pin that was sized to slide back and forth in the lock,thereby unlocking the doorknob.  Simulataneously, my friend Clark McPheeters designed a mount to hold the solenoid in place.  The next day, we set off to the machine shop to cut our parts while Aisaku Pradhan coded the software to run our system.  In a feat of awesomeness, the parts were cut in 14 hours, the software was coded in twelve, and the system worked the first time we integrated all of the components.  Talk about solid teamwork.

The Pin Drawing


This was the reassembly process:



 The final product allowed the exterior door knob to open without compromising the keyed functionality of the lock (for safety and practicality reasons).

The software The Lock


Software Design:  Currently, the system relies on a server computer running the software to actuate the locks.  Additionally, because we didn't have time to design a peripheral controller, the lock uses a low-voltage relay powered directly off the active pin on the serial port to know when to oopen and close the lock.  In a future revision, I hope to move to free, open-source software and algorithms.  I would at the very least like to have an ethernet-enabled controller that will allow multiple scanners to be used with one server or to make a controller that does the fingerprint processing and authenticates against a central server, but with the ability to function off-network as well.

Hardware Design:  The hardware works great, though it is specific to our Best locks.  If I plan to use this system ono a house or car, I would need to redesign the lock hardware.  But, the integration with the software is very simple, so I don't forsee that being a big issue.

During the first semester of my freshman year, I and Ashely Walker (Olin '09) designed and built an active suspension for Lego cars for our final project in Engineering of Compartmentalized Systems.  In this project, we controlled Lego motors with a PCMCIA input/output card.

 The CarThe Car

The suspension was modeled after an independent rear a-arm style suspension.  No springs or shocks were included to simplify the model.  A 2-axis accelerometer was placed on the frame and was used to sense the direction of gravity.  A simple PID controller was implemented in Simulink.  This was the outcome.  Video in .wmv format

 The control system left a bit to be desired.  Further tuning of the PID values would have been ideal.  Additionally, I would have liked the chance to modify the interpretation of the accelerometer.  We "pretended" that it functioned like a gravity switch and always indicated which way it was oriented, but it actually showed acceleration.  Because we ignored that fact for the sake of simplicity, it caused the jumping behavior some interesting startup behavior.  All in all, I believe it was a successful project.

Another issue that we encountered was the difference between the two motors.  The Lego motors came in two varieties: ones that could be approximated with inertial drag, and ones that could be approximated with viscous drag.  We were unlucky enough to get one of each.  It didn't matter which kind we got so long as they were identical.  We discovered that trying to correctly model the two types of drag relative to each other was not the best solution.  Instead, I asked classmates very nicely until I managed to find a spare motor, which we subbed in to make the system function.


In Principles of Engineering at Olin College of Engineering, Clark McPheeters, Aisaku Pradhan, and I attempted to install a self-built fuel injection system on a 10 HP Briggs and Straton-powered pressure washer.  To start the project, we used information from the Megasquirt fuel injection system to understand how to control fuel input and calculate the required amount of fuel for a given engine state.

The victim:

The Pressure washer


Hardware purchased:
Cadillac Heated Oxygen Sensor
GM Intake Air Pressure Sensor
Volvo 24 lb/hr fuel injectors
Volvo Fuel Rail
Volvo 2 bar Fuel Pressure Regulator

We machined a spacer plate to go between the carburetor and the engine block to house the fuel injector and the air pressure sensor.  This item allowed us to maintain the carburetor functionality of the pressure washer for testing purposes and also maintained the butterfly valve on the carburetor, which simplified the build and decreased the number of purchased parts.  The two holes in the spacer near the top allowed vacuum lines to pass between the block and carburetor.

Spacer Block


The fuel rail was cut and brazed for the single injector and mated to fuel pressure regulator as follows:

  The fuel delivery setup

With the fuel rail, exhaust pipe (fabricated from some scrap), fuel pump, and other fuel delivery items assembled on the engine, the system looks like this:

 The assembly


In addition to the physical system, we built a control system using a Microchip PIC from the 18F family.  It looked like this:

Control Circuit


The control system attempted to use a manifold air pressure and oxygen sensor based control algorithm.  The entire system worked with the exception of the spark sensing circut.  We tried to measure the engine speed by amplifying a home-built inductive pickup placed around the ignition coil after initial attempts to read off the spark plug itself failed.  We tried to sense ignition events by reading the peak of the waveform.  We filtered the signal using an RC circuit.  However, the course ended before we managed to sense spark directly off of the spark wire.




When I set out to learn Git a number of months ago, I was first disturbed by the lack of good HTTP support like Subversion had.  If you are limited in the ports you can (or want) to open to users, Git over SSH poses some issues and I had little success with Gitosis and Gitolite.  I finally stumbled across Smart HTTP (git-http-backend) and found that it handled git updates and commits over HTTP/HTTPS very well.


There are a number of tutorials out on the internet that tell you how to set up one repo with Smart HTTP, but I couldn't find any that would allow multiple repos.  I wanted this functionality so that I could use HTTP authentication with multiple repos so that some could be private to me, some could be private to various groups of developers, and some could be public (if I so pleased), all without the cumbersome and, frankly, security-troubling method using SSH.  So, here's a little Apache config example to run many Git repos over HTTP.


I use digest authentication and SSL, so I'll assume that you either know how to set that up or at the very least can change to basic authentication.


This seems like a fairly scalable and easy way to pull of more than one repo over HTTP with non-ssh-key-based authentication.  If you happen to notice an error of can tell me how to improve this little tutorial, let me know.


<VirtualHost *:443>
ServerName your.domain.com

DocumentRoot /var/www/ThatPlaceYouKeepAllThoseRepos
<Directory />
Options FollowSymLinks
AllowOverride All
ScriptAlias /repo1/ /usr/lib/git-core/git-http-backend/
ScriptAlias /repo2/ /usr/lib/git-core/git-http-backend/

<LocationMatch "^/repo1">
AuthType Digest
AuthName "Members Area"
AuthDigestDomain /test
AuthUserFile /etc/authfile/.htdigest
Require valid-user
SetEnv GIT_PROJECT_ROOT /var/www/ThatPlaceYouKeepAllThoseRepos/repo1
<LocationMatch "^/repo2/">
AuthType Digest
AuthUserFile /etc/authfile/.htdigest
AuthName "Members Area"
Require group yourdevelopers
SetEnv GIT_PROJECT_ROOT /var/www/ThatPlaceYouKeepAllThoseRepos/repo2
ScriptAliasMatch \
"(?x)^/git/(.*/(HEAD | \
info/refs | \
objects/(info/[^/]+ | \
[0-9a-f]{2}/[0-9a-f]{38} | \
pack/pack-[0-9a-f]{40}\.(pack|idx)) | \
git-(upload|receive)-pack))$" \


A few links that I found helpful in this process (thanks to everyone who blazed this trail before me):
Pro Git: Smart HTTP Transport
git-http-backend(1) Manual Page
Git over http(s)