background

For a while I have maintained a little webpage. I hurriedly put it up because I needed a place where I could easily and quickly dump nearly a thousand photos so that my friends to get copies for themselves as well as view photos. Already owning a domain and some hosting, I put up a site using WordPress as a CMS and using NextGen Gallery to deliver photos. Back then, using WordPress as a CMS was not nearly as good of a choice as it is today. Back then it was a tough decision between using Joomla or Drupal and losing the ability and ease of WordPress for better functionality or choosing to depend on plugins with WordPress. Assuming that WordPress would keep improving even though 2.4 and the themes available for it were not so amazing, turned out to be a good leap of faith as WordPress 2.8 and now 2.9 are pretty amazing.

The initial goal of my site was to make my photos available as nice web resolutions as well are reproduction quality resolutions so people could grab copies for themselves. From there it kind of took a life of its own. Slowly I added pages do document the projects I did, the art that I tried to do, ways to contact me and a blog to try to keep pace with my life. Then one day I woke up and realized that while I loved my photography, the main focus of of my page should be my projects because they really show more about me than anything else. That coupled with the fact that potential employers started asking for web portfolios really drove that change. As the functionality of the site expanded, I thought it looked really quited dated and not very inviting. Its simplicity seemed to save to an extent, but it certainly was no looker (see below).

Getting the momentum I needed to make a change was hard to come by. After suggesting that someone get a website to display her photos and noticing that a friend was looking to make a website was the kick in the pants that I needed to get off my butt and implement a new theme.

After playing around with a couple of themes, I was ready to buy one when I discovered a free template that I liked. It turned out to be a little broken and needed some severe rewriting to make it do the things I wanted it do when I wanted it to do them. However, its probably better that I rewrote a theme that was free than one I paid someone for.

One of the problems with almost all the free WordPress themes is that they almost never have any of the top shelf features. Themes using jquery for awesome drop down menus and news feeds are just starting to show up; and none of the free themes had the visual pop of many of the themes of the top shelf themes. After looking through a couple dozen themes, many of which were going for ~$50 I realized that the cool visual effects were all pretty similar and were all using the same FREE (for non resale use) image slider: “cu3er.” cu3er was supposed to be easy to implement, so I took the plunge. It wasn’t too bad. Download it, Unzip it and start making it work.

the config.xml file

cu3er is pretty damn well documented which made my life pretty easy. Working off the demo, the slide show was very slick, however I wanted to utilize a few features that really make  me love cu3er. While the transitions are really slick, the thing that really puts this slide over the top is the ability to add fly in overlays that can display text. With some visual trickery like semi-opaque frames these decriptive captions make a slider more than just a piece of eye candy, they can be used to create a visually attractive introduction that summarizes the content of a site. Additional code can also be added to make both the description and the image behind it click-through-able so that they can serve as a link to whatever is being described. Suddenly, the eye candy is super useful. Of course you also want the images to also rotate to make this object live and fulfill its purpose. To make all of this happen you need to edit the config.xml file that comes with cu3er. The first step is to add the following to the settings section of the file:

The settings above set options such as rounded corners, time options on the slide show and the colors/fonts of different objects/controls. If you want to dive in and customize this, I highly suggest looking in the cu3er documentation. While they do not have nice sample code; they provide detailed descriptions of the options available.

Once the settings are programmed in, the actual descriptions, links and urls need to be included for each slide. This can be done as follows:

Then its just a matter of saving the file (the screen captures with highlighting are from notepad++). Note that I renamed the images folder images2 to prevent naming conflict with the images file in the WordPress theme I was using. Note that you MUST include paths from the content file onwards or the images will not load. This is not apparent when you run the demo.

integration with the theme

If I opted not to use a theme that auto-generates the home page via PHP, integration would have been a little more straight forward. Having unzipped the cu3er download previously,  the next step was dropping it onto my server into the folder of the theme that was planning to use, I added the following code to the index.php (it might be differently named in another theme, but we want the php file that generates the home page):

The  above code should be added in the place where you want cu3er to appear. Since I wanted mine to show just under the header, I added those lines just under the PHP code that fetches the header. There are some important items here: by using the swfobject.addLoadEvent(function(){}) call arount the swfobject.embedSWF function we are telling the slideshow to draw in a way that makes it compatible as tested with IE 6 and 7 as well as Firefox 2.0+. Without the additional load event, the slideshow will only render correctly in IE8, Firefox 3.6+ and Chrome. I feel like very small  amount of delay thats only noticeable when loading over slower connections is an acceptable trade off for that kind of backwards compatibility. Also, take note that there is an extra div wrapper in my code that is used to put the shadow graphic on the page.  (a copy of the shadow image is near the bottom of this page)

If you aren’t using a theme that generates a home page or if you just want to put cu3er on a standard page, you can just use the same code that is provided in the html file in the demo or you can use my version below:

Again you want to add this into the right place. You can see the </head> and <body> tags that indicate that it might be a good idea to the have the javascript calls in the header and the actual box in the body. You need to do this to make sure that it works right in Firefox. Also adding the line to the top of the javascript script (the second one, not the call): swfobject.switchOffAutoHideShow() supposedly also helps resolve problems with Firefox 3.5 when adding cu3er via html. I never ran into those problems, so I cannot be sure that line is needed.

Again, you can put the items where you want. Note: the only real difference between the demo and the version that I have above is that I added the wrapper with a shadow. the shadow image is below (click for full image):

The only unresolved issues have to do with CSS and they aren’t things that I care too much about. The shadow is more exposed in IE to the point where the cube looks back/top lit vs the front/top lit shadow that shows in Firefox and Chrome.

conclusion

That pretty much wraps it all up. Not too hard at all to add some amazing visual effects that can really make your page pop. Feel free to cross browser test my site. you will notice that the CSS isn’t perfect, things fly a little out of place in IE6, but then again I don’t know of too many sites that look the same in IE8 as they do in IE6.

My code for the cu3er implementation works great in Chrome, Safari, Firefox 2.0+, and IE8/IE7/IE6.

I still am thinking about rolling this into a free theme as soon as I get the hang of using PHP to generate XML. Hopefully that will happen soon! UPDATE: Due to the cu3er license, I will not be doing this.

Any code on this specific page, people are free to use. Project was completed started Feb 26th, 2010 completed Feb 27th, 2010.

The Vampower, a power saving power strip, is an award winning design project that was part of a joint class in product design and development (PDD) co taught by the FW Olin College of Engineering, the Rhode Island School of Design (RISD) and Babson College. The team that worked on this project included two designers from RISD: Will Harris and Danny Kim, two engineers from Olin College: Bennett Chabot and myself, and a Babson College business student: Anand Virmani.

This product design prototype was the result of work in user interaction, design for manufacturing, electrical engineering and many hours of sweat and hard work. It was completed over Fall 2008 with minor work extending into the Spring of 2009.

the background

It all starts with a problem. The problem is that 129 million mega-watt hours of electricity is lost every year due to so called latent power use. This kind of latent use includes obvious competitors like stereos and computers in standby to the cell phone charger that sits on the outlet every second of every year; quietly using power. To understand the magnitude of that power, latent or vampire power we like to call it uses approximately 10% of the residential power used in the US every year. In terms of power generation it is the equivalent of building 6,000 wind turbines that are 600 feet tall. Since monetary figures can also be drivers for purchasing a device that saves power, we estimated that the average home owner loses $160 to this vampire power use. It is definitely a big problem, but some devices like a cable box or an internet modem don’ work right if they are disconnected from power; so the real world impact regarding the amount of energy savings is less but most likely still very significant.

In addition to the green reasons for wanted to build a new power strip; the power strip is one of those items that companies are always trying to redesign. From simply rotating 90 degrees to the more exotic items on the market like the power squid; people have been searching for a better power strip. We decided that since we were looking to solve the green problem with power strips, we would also take a shot at making a more user friendly and more appealing power strip.

The result was the Vampower power strip; a truly different solution…

the problems and our solutions

To really understand the scope of the problems that potential users of the product that we were endeavoring to design would face, we did a large number of observations of people interacting with their power strips as well as a large number of interviews. From that user data we were able to discern a number of unmet physical needs, as well as a desire to save power if it could be done. Through a process of design exercises and a few more rounds of user feedback, we were able to come up with a rather concrete set of requirements.

To share a few of these requirements and the solutions that we devised to satisfy, I will first share a pair of physical/form factor requirements:

The first one I want to share is the idea of modularity, a notion born for the need for flexibility.

We photographed in many places where power strips were used.  In very few of them did we see 6 or 12 receptacles in use (the common number on a strip). When less were needed, it was not a huge problem, but often when someone wanted to have 8 devices attached to a 2 receptacle outlet there was often either a splitter in use or some sort of daisy chaining going on; creating a potentially unsafe and definitely unsightly nest of wires. Our solution to this problem was the introduction of modularity into the power strip.

We considered other alternatives to our final design. From outlet pads to Power-Squid like form factors we settled on a set of rotatable modules that could be connected and disconnected to build a power strip of just the right size. It was one of the ways that we sought to put the right number of outlets in the right place and cut down on the clutter.

The second is the notion of discrete size a solution to the need for more accessibility.

We found through our research that people often tried to fit their power strips out of sight and tucked into small spaces. This creates a problem when using traditional power strip as the AC-DC power converters used in many of our modern electronics take up so much space that only 4 of the 6 outlets are used on a power strip, meaning that a second power strip is needed. Items like the Power-Squid solve this problem but at the cost of taking much more space. Our goal in attacking this problem was to make every outlet on the strip more accessible without increasing the form factor to the point where the item was no longer space efficient.

We looked at a variety of alternatives and settled on making something with rotating plugs. Through this design we were able to avoid increasing the footprint of the power strip dramatically, while at the same time we were able to make it more likely that user would be able to access every single outlet on our power strip.

The next two requirements and solutions have to do with effectiveness as a power saving device. In the most basic sense, the best way to save power would be to simply turn off the power flowing to devices and turn them back on again. By observing people who did this regularly with their power strips to save power, we identified several distinct “pain points” that stood between people wanting to save power and actually doing so. I will share two critical items below:

First, is turning the power strip off after use.

One of the subjects that we encountered wanted to “green (her) lifestyle” and so took great pains to turn off her power strips that were not in use. For aesthetic reasons, she hid her power strips behind other objects. To turn them off she used a walking stick to flip the switches as they were not easy for her to reach. From these observations and others like it, we were able to determine that a device that we wanted to build would likely be placed somewhere where accessing the device would be difficult and that we would need to allow users to easily switch off their devices. Our interviews also provided another design/engineering target, our users want to turn everything completely off. They didn’t want another device that “leaked power.”

We looked through many different ideas on how to turn off the power. While many of our users said that they would have no extra problem taking an extra step to turn their devices on, it was a major problem to remember to always turn them off. We thought of remote hard wired switches, wireless devices, an iphone app and other countless ideas before settling on a self calibrating circuit that sensed current and simply turned off when the current dropped below a % threshold from its peak use. This would prevent users from forgetting to turn off the device, while walling devices from still consuming even a little bit more power.

The second item is the reverse of the previous process. We needed an elegant way to restore power to our devices.

Again we are faced with the same general scenario as above. Our users tended to hide their power strips, so turning them on often involved uncomfortable reaching or use of the walking stick. In this case, doing the turn on operation needed to be remotely activated. There are many AC-DC converters that can sense when they are connected to devices and thus activate and throttle their power that way. Unfortunately, since we aren’t looking to sense connectivity we had for other ways to activate our devices.

Because we did not want our users to have to keep track of a remote, we looked at motion sensors and current sensing mechanisms. Our users surprisingly liked the idea of a clapper as long as they did not have to worry about it accidentally turning their devices off. Since this was going to be an on only mechanism; we decided on using a clapper type sensor to turn the power strip on for 30 seconds after which the current sensors cut power to any device not using enough power to be determined to be “on.”

the product

Once we found our requirements and synthesized our user feedback to the point where we felt like we had solutions to the problems that we wanted and our users expected us to solve. Through several iterations of presenting prototypes to our users, we arrived at the following design:

We decided on three different components that could be plugged into each other. The first was the clapper sensor and timing mechanism, along with more standard tech found in high end power strips like power filtering and a circuit breaker. The second was the “smart power” module with the current sensor inside. This smart module would be the backbone of the product as it fulfills the promise of the product:

An exploded view of the product shows the current sensor inside a housing with a 4 plug connector (pins not shown). The idea would be to use three pins for the standard electrical pins while using the 4th as a signal pin to turn on all of the “smart power” modules. The last component to our system was the “constant power” module, a connection that would always provide power in the manner of a regular power strip while retaining the benefits of modularity and accessibility. We built this component so that our users wouldn’t need another power strip to connect their devices that they always wanted to be on like their DVR or broadband modem.

the business model

After we built the product we kept in mind our costs and figured out that we could offer significant value to our customers at the $30-$40 price point while we would be able to make a significant profit from the device. In terms of surveying our users on what the final package should look like, we settled on a four module basic package of 2 “smart power” and 2 “constant power” modules in addition to the master switch/clapper. The green lines indicate the “smart modules”. (power cord not rendered)

conclusion

We wished that we had the resources to take this further, but as there was no real place for IP (except on the design of which other copies already exist) we did not decide to take this idea further. There are also some problems that were not fully solved in this exercise. There is no way to differentiate between the kinds of modules except for via coloration. One of the ideas that we wanted to implement would have been a way to differentiate the models by shape.

Though the project was not as polished as we wanted it to be, we were able to make prototype(s) for testing and found that the idea was well received. We called this one a success as it was deemed the best design at our expo and photographs of our work were taken to be used in the RISD admissions materials.

This project was completed during a course on robotics taught by Prof. Dave Barret at Olin College. The final project for the course, the goal of the project was to navigate a maze using a Surveyor robotic platform. As part of this project, additional sensors were added to the robot. This writeup will focus on the addition of the sensors because they illustrate an example of engineering problem solving skills as we extended the capability of a platform beyond its original design. This project was completed with collaboration from Leif Jentoft.

background

The challenge of this final project was that the surveyor platform only contained a single sensor, a video camera. Furthermore, the platforms were running a parallel programming language called Occam Pi that made making the maze solving algorithms pretty easy, but adding sensors difficult. Because of the distinct difference between the colors of the walls of the maze and floor, a color differentiation algorithm using the camera could be successful in navigating the maze. All of the other teams chose to take this approach. While a few of the teams did have success with this approach, we chose to install a few Sharp infrared distance sensors instead.

We knew from the beginning that there were significant issues with this approach. Like most sensors, the Sharp IR distance sensors that we were trying to use output only analog voltages between  a low voltage (almost zero) and the high power rail.  The Surveyor used a Blackfin DSP chip as its CPU. By design, it was limited to having only digital inputs so we needed to provide the Surveyor with some sort of digital values so that we could use IR distance sensors to help us navigate the maze.

The Occam SDK for the Surveyor platform could not yet read serial values at the beginning of the project. While this functionality was added to the  SDK midway through the project, it was too late for us to use.

the micro-controller

For this kind of application, there were many choices of applicable micro-controllers. Because I had worked with a PIC extensively in the past and my collaborator was also very familiar with PICs as well as the C code used to write code for them, we chose to use a PIC over other available solutions. The PIC we wanted was a PIC16F690; it accepted a wide range of voltage inputs and had everything we need in a very small package. On the downside, Microchip (the company who made this PIC) didn’t offer a free compiler to use this PIC16 series controllers and we were unwilling to take the time to figure out how to use third party libraries. For that reason we opted to use an overpowered PIC18F series PIC. Because the Surveyor used 3.3V and not the more standard 5v as its source, we needed to use a low voltage PIC to ensure proper operation. We opted to use a PIC18LF2221 because it had built in math functions, plenty of analog and digital IO pins and an internal oscillator that we could use to clock the PIC. The LF indicates that it can be used at lower voltages.

The plan was to use the PIC to translate the analog output from the IR distance sensors into a PWM (pulse width-modulated) signal. Because both the Surveyor and the PIC had processors that were clocked, we could effectively translate the analog signal into a digital pulse. We chose a linear relationship between the length of the pulse and the voltage to help determine the distance. Because there were problems changing inputs and accessing different digital inputs on the Surveyor, we changed our initial conceptual design from one PWM signal line per sensor to a scheme that used inputs to tell what sensor was being read and then had the value sent along one PWM channel that was used by all the sensors. We considered this part of the design to be a work-around for a bug that was either in the base code of the Surveyor’s Occam Pi based code or in the hardware itself. Because we didn’t have another robot to debug on, or much time to figure this out; we simply used the workaround as a solution. We considered this less than ideal as we knew it would make the PIC code seem a little messy when compared with our ideal design.

circuit

The circuit diagram above describes the wiring of the PIC and the sensors. The 10k resistor between ground and pin 1 as well as the 10 micro-Farad capacitor bridging power to ground  between pins 19 and 20 are needed to run the PIC without an oscillator and are not particulars of our design. The sensor ground and power were also filtered to clean up the analog signal from the IR sensors. The important items that were included on the design are single PWM signal out line and the four sensor enable pins that match four different analog inputs.

code/logic

After setting the proper configuration bits we then worked on the logic needed to make this system work. The code needed to run this PIC was written in C using the Microchip 18C compiler and associated libraries. The logic portion of the code used to run a single sensor the example shown below.

Inside of an infinite while loop (because we want our code to always be running on the PIC waiting for input signals), we used the following logic:

if (INTCONbits.T0IF == 1 && PORTCbits.RC4 ==1 ){ //if the timer interrupt goes off…and sensor 4 is selected

INTCONbits.T0IF = 0;  //reset the timer interrupt flag, we now have ~1000 clock ticks to process everything else

//get RA0 analog in

ADCON0 = 0×03;                           // select AN0 and set GO_DONE bit to start A/D conversion

while (ADCON0bits.GO_DONE); // do nothing until the A/D conversion is done

pwm0 = ADRESH/4;//input from RAO, 8 most significant bits

//generate the pulses

if (counter < pwm0){PORTBbits.RB0=1;}

if (counter > pwm0){PORTBbits.RB0=0;}

}

When the Timer (set to expire every millisecond) went off and if the Surveyor had set the enable pin for this particular sensor high, then we set the digital out to high if the scaled analog input is greater than a counter than counts the number of milliseconds that have passed. We set the bits low when the counter is greater than the analog input, thus generating a crude PWM signal.

The counter is incremented at the bottom of the loop.

counter++; //counts the number of milliseconds

if (counter > 50){counter=0;} //reset counter to set PWM to 100Hz

When the counter goes over  50 we reset the counter to 0 so that way we get a 100hz PWM signal as an output. We then sampled the sensors to allow the  vehicle to follow walls and see open spaces in front of it. This logic code was the same for each sensor with the exception that the enable bit and the analog input were received on a different ports.

conclusions

In conjunction with wall following algorithms, our robot was able to solve the maze. Though, other teams succeeded in using the camera to complete the challenge, our robot was also successful. Our work on this sensor integration was preserved so that students in the future would be able to easily integrate analog sensors into the Surveyor platform.

This project was shown at Olin Exposition in the Spring of 2008.

This was not really an engineering project and it was done for a class that really was not an engineering class. The name of the class was User Oriented Collaborative Design and this project was more of a thought exercise in which implementation was not required and a path to implementation was not a part of the project. Because of the way that the class was structured, I was part of the team that was tasked to design something around surgeons.  Throughout the project we struggled with contacting our users and with divisions on the team. I would not call it the prototypical team experience, but in the end we pulled it out and everything turned out OK. Having worked with design students from the Rhode Island School of Design later on in my career, the quality of the art done by a team of engineering majors is nowhere near the amazingly beautiful renderings that are produced through collaboration with real designers. Because that project contains possibly sensitive materials, this is the design experience I am choosing to share. This was a sophomore level class completed in the Spring of 2007.

Collaborators on this project were: Eamon Doyle, Clark McPheeters and Mathew Roy.

background

The purpose behind this class and the project was to get engineers to think about people. One of the hallmarks of the Olin education is a focus beyond just technical specifications and impressing on students the notion that engineering is about creating solutions for people. The entire class focused on people and the psychology/design tilt of the class was shocking to some and a welcome challenge to others. We were asked to take off our technology hats  and try to focus solely on what would provide value to our users.

observations

As a team, we were tasked with a user group that we would think of as our clients. That design target did not include a specific problem to solve. The goal the vagueness was to try to make us think broadly. We were one of two teams assigned to look at the lives of surgeons. Going in to the project, we did our best to wipe our minds of the preconceptions that we had of the group. We started off doing observations of surgeons in their natural environment. We visited a few hospitals and found a few doctors on break willing to talk very briefly about their lives. However, this tactic was very tough because our user group kept very tight schedules. In terms of observations, our breakthrough came when we were allowed to visit the hospital see the rooms for the residents and observe surgeries. The observations of surgeries and the way that residents conducted themselves outside of the operating room allowed us to create personas that allowed us to move through the design process.

personas

To move forward in the design process we needed to abstract our observations. Even though we did not record real names in our notes, we needed to separate the characteristics of our users from feelings we might have had due to the particulars of each observation. In order to achieve that separation we were taught to create fictional characters, the set of which would accurately represent the qualitative data that we gathered during our observations. More that just a vessel for the data, a persona should also include details that reflected who this character is, what their values are and tell a story about them. A sample persona that we created for this project is shown below.

The story here was to try to portray the younger generation of medical professionals. While there is no clear generational divide, we really aimed to portray someone who has grown up comfortable with the internet, video games and technology. Many of the details came from our interviews of people who met that classification. The favorite video game characteristic was invented to harden the idea in our minds that we were specifically looking at people who were part of the “Nintendo” generation, people who were still young enough to grow up with that first, popular, at home console released in 1985.

ideation

Once the personas were created, we came up with ideas through a series of exercises, including perception maps, based on the values that were expressed in the personas. After littering the walls of our work space with many different ideas, we chose about a dozen to sketch out. We then created interaction narratives for each to along with each of the sketches. The ideas were then presented to a group of surgeons for review. They provided us with feedback that we used to refine and select appropriate concepts. Through four or five rounds of this process were were able to arrive at a final concept. In order to explain the concept, I will attempt to present it through an interaction narrative.

A second stage narrative for the final concept is below:

The narrative tries to show how  a potential user would interact with the concept. In this case the we are showing the Carter persona interacting with the surgical training game that would eventually become the concept we would take forward. More accurately, this narrative portrays the young doctor entering the hospital and engaging in some competitive banter with another young doctor. Because the game is a serious training aid, it would involve some sort of fake body as well as monitors to replicate common endoscopic practices. Because endoscopy is now the most common kind of surgery and the one practiced by our real life users, we chose to focus on that kind of surgery. The game would be scored based on the accuracy and speed of the surgery. Random complications would require addressing to complete the surgery. More difficult procedures would also lead to more points. The point system is critical as it offers a reward to using the training aid; a facet that the current training methods of stapling foam and using endoscopic tools to move dried beans between cups cannot provide. At the end of the narrative, Carter and his friend set up a rematch for a later date.

conclusions

Once we had come up with a concept we had to make a mock up so that we could demonstrate the interaction that would be facilitated by the device. While we did not have tho think about the technologies that would make our device work, we did have to make a foam mock up. Since the realness of our concept was what set it apart from many existing surgery type video games we felt like we had to mack a mock body. Mannequins were well above the budget we were given to complete the project and other human like props were simply appropriate/unrealistic. Therefore, we ended up making one out of foam. Not being art students, the foam body was less than optimal but it served the purpose of allowing us to demonstrate how an interaction with our device would go.

A followup the Carputer V1, this project was started with the intention of putting a more powerful device into my car. The idea of this was not about cost savings; but rather to have incredible flexibility for the device. While the current build of the device is really used for music and GPS navigation, other potential devices like taking video from a web cam and displaying diagnostics from a Megasquirt fuel injection computer were one of the possible uses that motivated the project. Besides, it makes a pretty interesting conversation piece.

background

Car computers are nothing new. It seems that they are actually a dying concept now that the capabilities of GPS units now often include the ability to play music; nevertheless I didn’t want a pre-made solution where everything worked. Unlike the V1 of this project, I wasn’t going to hack some system; I plan to use a real windows PC. The first reason for this was that unlike in V1 of the project, I would not be trying to break any new ground; increasing the chances of success. Using the resources at Mini-box.com and at MP3Car.com, it was pretty easy to piece together a system that could very simply be placed into a car and should work pretty well from the start. Looking into the different form factors of hardware was one of the hardest decisions to make. If I were to start over; I would consider investing in the smallest form factor out there: the Pico ITX PC. Unfortunately, at the time of this writing I am a student and thus on a bit of a budget. For that reason I chose some of cheapest hardware that I could buy.

the hardware

motherboard/CPU/memory

When looking at the options out there for making a Mini-PC of any kind; at the time of this writing VIA seems to have the market in a tough spot. Thanks to the “netbook”, that is changing pretty fast. Intel has poured their energy into some pretty impressive low voltage hardware that they are willing to sell for pretty cheap. Thanks to Newegg.com we can pick up a really basic Intel motherboard with a single core Celeron already on it (with a heat sink) for the paltry price of $70. This is about half the price of a VIA setup.

Called the Intel Little Valley motherboard, its a mini ITX board, meaning that it measures 10cm on a side. Right after I made this purchase, another version that was fan-less was released. I don’t think there are advantages to one version over the other unless space is a concern. The heat sink has the greatest height of any of the components on the board. To make life easy, I just grabbed a single 2gb stick of RAM to use as memory. I am sure that everything would have run just as well on 1gb; but since RAM is very cheap, I saw no reason not to step up to double the RAM. The board also only has a single DIMM slot; so its not expandable later. At 18.99 from Newegg.com; the cost of the RAM was pretty negligible.

power supply

When it comes to power supplies, there are not a lot of choices if you want a solution that will just work out of the box. The best place to get them is a retailer/manufacturer @ www.mini-box.com. Mini-box has a whole line of PSUs that are meant to run off the dirty 12volts that are in your car. The units are meant to accept a wide range of voltage (6v-24v) so as to deal with the voltage fluctuations caused by cranking the car. Because I wanted to preserve the flexibility on install, I chose the smallest of the units. Called the M3 Pico-PSU, it can supply more than the needed amount of wattage for a ultra low voltage CPU like the one used on the Little Valley board.

One of these types of power supply units is probably a must. Using one of these is much more efficient that using an inverter and than an AC power brick and it includes other features like auto turn on and off with ignition and protection against the the thump effect that can be caused by car audio equipment. This component set me back about $80.

display

There are a lot of display choices out there, but the general consensus is that the best touch screens for the dollar are those from Xenarc. That doesn’t mean they come cheap. The screen was by far the most expensive part of my  system. The screen that I chose to use was the lowest model that Xenarc offers. The 705TSV.  It is  a 7 inch resistive touchscreen. The benefit to going for this model over others is that its LED back lit and therefore consumes about half the wattage of the other more expensive models. At ~8w of consumption, we are really nitpicking in terms of power, but I planned to use as much existing wiring as possible; and I did not want to stress the wiring of a nearly 20 year old car (its all pretty high gauge).

Shown above, the screen is nice and black which should match the trim of my car pretty nicely. The screen turns out to be really really bright and is only hard to see when there is direct sunglight on it. Its pretty high quality, but one of the nice things about the screen is that video cable and the USB interface are in one cable which will make the running of the cables pretty easy. I got this for a steal at $210.

the storage

I could have opted for an automotive grade HD, a boot from CF and host of other more exotic options. However I figured that shock mounting a regular laptop HD would do just fine. Having already had a 60gb hard drive lying round; it was no brainier to simply use it. To interface it with a board it also needed to be IDE. Newer versions of the Little Valley board have SATA ports; but to use an IDE drive I needed to get an adapter to the laptop spec IDE which included power. Luckily, being the nerd that I am I had some of those lying around too.

gps

The GPS hardware being used currently is just a basic USB GPS. its installed using the driver it came with. Like most other USB GPS devices…its actually a serial device with a USB converter. This means that in the Windows device manager, it shows up as a serial device. To make detection easier and to make sure that things stay consistent, I would recommend assigning the GPS a static COM port and manually setting that in the GPS software.

the software

operating system

I love Linux as much as the average nerd does. I pay homage to the gods that delivered Ubuntu to us…but in terms of a car PC you pretty much have to run Windows unless you really want to write your own front end and GPS software. If you have to run Windows, it pretty much has to be XP. If you have the resources, XP embedded is nice but a lot of work. Because I wanted to make things as easy on myself I installed a copy of Windows XP for Legacy PC’s. Its light and with a little work you can get all of the little things you need to be installed. One of those was a custom Bluetooth stack; but since the standard Windows stack is hardly functional; I suggest getting the stack recommended by the manufacturer of your dongle. The same can be said for the drivers of any other devices you install. Its not hard as long as you set up the machine in a simulated environment first.

front end

Most car PC GUI’s are really ugly. The RoadRunner interface is one of the most functional with plug-ins for all sorts of cool features. Coupled with a Skin/Add-on package called LSXVOID, it becomes beautiful-ish too. You get inertial scrolling as part of the package. And the software is all free too. Its a pretty win/win. I would tell you where to get the software; but a google search will point you to better results as many of the downloads for the newest versions of the software were found on forums. There aren’t any real tricky configuration options either. A few things to keep in mind. Depending on what GPS software you decide to use and what media player you use, you will need to make sure that RoadRunner is configured to use those applications, otherwise things could become more than a little tricky. Also its important to have a newer version of flash installed in order to get the full use of the LSXVOID add-on. Inertial scrolling had some issues for me at first due to having a crippled, old version of flash installed which was needed because of a driver issue. Once I took care of the driver issue and upgraded flash…all of the problems simply went away.

gps

GPS software is tricky. I-Guidance software is not the best out there; but it has an automotive mode and has has integration directly into the RoadRunner software package; features that made it the most attractive option to me. Its pretty easy to install. Nothing special. Configuring the GPS was pretty easy too. The software works well. To make sure that the GPS is detected after hibernation, assign the GPS hardware a static com port and in the GPS menu in I-Guidance, do not let the software auto detect. Tell it exactly what COM port the GPS device will be on.

media

I am not a big fan of WinAmp; but it is the media software that best integrates with the RoadRunner UI. Given that the UI concerns top anything else since I did not want to write my own UI…I just ran with it. It works fine. Exporting Itunes play-lists are a pain (send them to Windows Media Player first) but it can be done.

Installation

In my cast, I just put the components in my glove box, taking power right off the terminal block located just on the other side of firewall in the engine bay. That is the primary power for the system. The on/off is keyed off the ignition via the power supply. To play music, I also had to replace the stock stereo (it needed it badly) so that I could have an aux input. The ground is run to the chassis ground used for the car alarm (also just on the other side of the firewall. Making my job easier is the fact that the ECU for the car sits right above the glove box, so places to run the wire through the firewall were already in place.

For now, I am calling it done!

Other Notes

I was going add up all the costs and post them…and even though I spreadsheeted everything down the screws that I used…most of those details really aren’t useful to anyone else since they are highly vehicle and install specific.

I chose a Sony stero because the lighting matched my interior and because I could keep using the CD changer that was installed on the car at least 15 years ago.

As part of a research project into bio mimetics, this robotic was rebuilt with the hopes of being able to replicate the omni directional movement of a  spider. The original platform was built by Thomas Michon, Bonnie Charles and Leif Jentoft at the FW Olin College of Engineering. As part of this project, the electronic controls were replaced with a Matlab driven servo controller, the transmission was redesigned, and the platform was redesigned. Most of the experimentation revolved around different algorithms regarding angle of the legs to control movement.

This project was completed with collaboration from Leif Jentoft during spring of 2007 using resources from the Bio-Mimetic Robotics Lab at Olin College supervised by Dr Gill Pratt.

background

I walked into this project after the initial design was done. At that point a PIC was running the electronics and the platform was extremely heavy. Mechanically, the system also faced challenges due to the way it was designed. It used cables to extend and retract the legs and was driven by a crank shaft and some cams that lost much of the power to friction. So even though the goal was to explore  the ways in which we could make the platform into an omni-directional walker, the first task that we would have to tackle would be a mechanical redesign. Looking at the way that legs worked we used the mechanical redesign to lead us to possible movement algorithm solutions.

redesigning the platform

Initially the big work was making the platform movable without too large of a motor. The existing transmission had too much power loss and the chassis was too heavy for effective movement. By limiting our design to structural components and thinner plastics we were able to significantly lighten the platform.

Cutting drivetrain losses was a little harder. The original device used a crankshaft of sorts to move steel cables through places in the holes in the chassis. Even though graphite was used to try to lessen the friction, the system had a hard time moving. To cut the friction, we redesigned the system to work using teflon coated mountain bike brake cables that rested inside of vinyl casings. Coupled with the weight decrease, we saw now had a platform that writhed mightily when activated.

the legs

Strafe, the robot, still could not move in a controlled fashion. Based on papers on the mechanics of legs we were able to determine that the platform was missing some critical characteristics that allow legs to work in nature. Most legs are essentially a combination of springs and pendulums. While their pendulum nature makes them efficient we felt like we could achieve a measure of success regarding just movement if we introduced a little spring into the legs; a determination we based on the theory the springy-ness of a leg in conjunction with proper positioning was the critical element that allowed legged systems to conserve the momentum needed for motion in a specific direction.

To add springy-ness to the legs, we cut the vinyl casings up and added 3 inch legs made of concentric spring loaded brass tubes. This system allowed for a degree of compression even when the leg was fully extended.

control

After the mechanical redesign, we wanted to get right to the experimentation with movement algorithms. To do this, we ripped out the old electronics control system and replaced it with a servo board that we could easily control. Since we did much of our modeling in Matlab, we chose to use a servo controller that had libraries built for it that interfaced directly with Matlab. Through several iterations of control code, we were able to record video of the platform moving in specific directions.

conclusions

At the end of the day, this project was a success. Both Leif and I planned to pick up the project again at a later date; but due to scheduling and just moving on/getting busy we were never able to go back to this exciting project.

This project was completed for kicks during the summer of 2007. It started out of from a want to create something useful that could handle music playback and prevent me from getting lost, as well as to help me learn more about Linux. It was marked as complete by fall of 2007. The writeup was completed as the project was ongoing, unlike many other items on the project pages where the write ups were done after the project was completed.

The system is composed of 4 main parts: a GPS receiver, a Nokia 770 internet tablet, a usb hub and a USB 2.5 inch hard drive. All of these parts were put into a 1991 BMW 318is.

By fall of 2007 the parts were removed and I had moved onto planning the second generation carputer.

background

At time that I am writing this document I am currently at the tail end of a rather full summer vacation. I still get a summer vacation because I am a still a student. I currently attend the FW Olin College of Engineering in Needham, Massachusetts and am a junior working on my ECE degree there. I am also the owner of a 1991 BMW 318is, a car that I love because of its light weight, m-tech suspension, retro looks and delightful driving dynamics.

In my current summer job, I have had the chance to work with some very basic embedded computers and have spent the hours in transit between work and home dreaming up a project that I could complete on my own that would implement the skills that I have now. Considering that I plan to drive across the country from Oregon to Massachusetts at the conclusion of this summer, I figured that a car computing project would be fitting.

Originally I had intended to make a mini-itx based system that used a low power Via-c7 processor mounted in the trunk. The display would be a 7-inch touch screen. Considering that just the processor, bare bones kit, and display would run me close to $600. I would expect the entire project cost me upwards of $750. While I could certainly afford such a project, it hardly seemed like a worthwhile cost when I all I wanted to do was to have a device that acted as a GPS and played music. Also, running wiring to the trunk and back again would not have been a pleasant task. Time was also an issue as I needed a project that could be completed in 3 hours a night over the course of a week. Thus, the idea of a simplified cheap system was born.

More than being cheap, however such a system would need to also be low power. Considering the age of my car, one can assume that the electrical system is not nearly as robust as the systems that go into new cars today. Back then the ABS computer, ECU , radio, CD changer and power door locks were the only things that needed to be powered. Also because I like the stock appearance of the car and because I want to keep everything more or less original there will be no cutting, no new radio, and the CD changer will still have to work.

To find an appropriate price target, I needed to make sure that anything I made would be substantially cheaper than anything currently on the market. A Tom Tom Go 910 does nearly everything I would want…and at a price point of just under $400 is an absolute steal for a commercially available solution. Therefore my initial pricing goal is $200, which incidentally is the cost of a bargain GPS receiver with a screen size between 3.5-4 inches. I will allow for incidental costs up to $250 which considering the capability of the system is still a relative bargain.

picking up the pieces

control unit/display

To make a project like this work, the first thing I needed to find was a control unit with all of the right characteristics. Initially my gut instinct told me to look at PDA’s, but I wanted to have at least a 4 inch screen to look at. So, most of them were not going to work; the ones that did work were at budget busting prices of at least $400. At this point I was about to head down to Fry’s and pick up a TomTom Go 910 at the bargain basement price of $389.99, when I spotted a refurbished DT375 thin client with an 8.4 inch touch screen for a meager $155.

While even this would likely blow my $200 price target, it wouldn’t blow away my $250 budget. After taking measurements I was slightly less elated. Measuring in at 8 inches by 9.5 inches, the unit was simply too big to fit nicely in my car. Along with unanswered questions about USB host capability, sunlight view-ability, and the availability of Bluetooth modules, the unit was looking like a no go. The unit also ran Windows CE…an operating system with little support and even fewer programs. So that DT375 while a hell of bargain wasn’t going to do it for me. Given more time and a car with a larger dash this might have been the ideal solution.

I was however very encouraged that thin clients were a solution that I had not thought of before, and therefore other solutions must exist as well. While frantically searching the web for a solution I stumbled upon the solution in the form of a Nokia 770 internet tablet. At $129 shipped from Buy.com (new in the retail box) this was a complete steal. With a sunlight viewable high resolution display, Bluetooth, wifi and a nice black finish, it was perfect.

Sporting a 4.3 inch touch-screen that seems bigger than the measurement indicates (due to a high res screen) and a compact form factor, the Nokia 770 also met the physical requirements. With a large community to support this product as a result of its open source OS (it runs a variant of Linux) mapping applications and media software is readily available. It is also a very low power product, meeting another one of my requirements. Sporting a dual core 252mhz TI 1710 OMAP processor, the internet tablet lacks a little bit of muscle but not enough to dissuade me from making it the center of my project. Furthermore as a contingency in the case that the project didn’t work out, I had an excellent new toy that I could use to access my other computers because of the fact that it has a built in VNC client.

gps unit

Well once the control unit was decided upon, it was time to buy a GPS receiver. Keeping budget in mind and wanting one of the latest SIRF III receivers I opted to purchase an OnCourse 3 Bluetooth receiver. It has WAAS and EGNOS integration and is pretty nice and small. Its rubberized black exterior also lacks the tacky looking silver plastic and super bright multicolor LCDs that other GPS receivers have.

At $49.00 shipped from buygpsnow.com, it was the cheapest option available. Unfortunately for me, I didn’t think this purchase through as well as I should have (considering the Nokia 770 find was still making my head spin) as this GPS receiver requires power (not solar) and doesn’t have the auto on feature that other receivers have, but it does have auto off. The irritating result is that I have to push the power button on the GPS unit to turn it on. Also if I didn’t plan on also using the GPS unit with my Moto Q as well, it would have been prudent to use a USB mouse style GPS as it would have always been powered when the system is on since the USB GPS receivers are bus powered. If I can find a USB GPS for cheap, somewhere in the future, I will make sure to be pick it up as it is more suited to a car system than a Bluetooth GPS receiver (a USB gps would have also saved me about $10 at the cost of not being able to use my phone as a GPS unit).

usb hub

If I had been willing to hack apart my Nokia 770 internet tablet, this would not have been necessary, but as they are, the Nokia internet tablets don’t support USB host capability out of the box. With a little parameter change in the OS and 5v dc supplied to the USB port they can do just fine. Alternatively you can hack in a power jumper between the power port and the USB (this also allows charging over USB) and then power devices without a hub. Since I am planning to run a fairly power hungry 60gb 2.5 inch hard drive off in this system, I figure getting a hub was well worth it. The trick was finding one that was easy to hack so that it provided 5v on the upstream line, something that is in violation of the USB spec. Wonderfully, enough no hacking is required if you buy a powered hub that violates USB spec out of the box. A little bit of searching allowed me to score the perfect hub on Newegg.com for a bargain basement price. The Anyware UH-204D usb hub has a nice aluminum enclosure. It also takes in 5v power and leaks that power on the upstream line. Again, there were ways that allowed me not to use the hub, but I figured with so many devices that use 5v dc to charge, it could be a power terminal as well as a feature that adds scalability to my project. Perfect!

data storage

I want music. Lots of music. For that reason, I needed at hard drive. Considering that I have a 67gb of music and a 30gb Ipod that was barely big enough for me to fit my favorite music on…I needed to have some serious data storage in my car. Since I was able to pick up a 60 GB hard drive for free since I already had it and a scored an enclosure off Newegg.com for 5.99+shipping (a Link Depot ENWB-25B-SS), it isn’t the best enclosure out there but it does the job.

wiring

Note that the GPS and the Phone will communicate data to the Nokia internet tablet via Bluetooth so they won’t need to be connected to power when their batteries are charged. Separate power will be used for the hub and for the internet tablet, because the charger on the internet tablet is a “smart” 5v charger that sends pulses up the line and also includes an IC to protect the battery from overcharging.

comprehensive parts list

system cost

The above price projection is for all of the parts needed to build my system. The cost of materials needed for installation doesnt count as part of my pricing goal because they would be needed even if I had bought a Tom Tom Go 910 and wanted to wire its power directly into my stereos wiring harness and not use the cigarette lighter for my system. Likewise, if I had elected to use the cigarette lighter for power, the additional parts would not have been needed.

total cost breakdown

Below is the cost to build and install same system that I built.

If there is an item that is marked as not having a cost to me, it means I had it on hand and thus did not count against my budget. The cost is the amount of money it would cost to replicate the system from scratch.

configuring the os and the software

Darkness and a lonely night made for a perfect time to play with my new little Linux machine. Certainly since this is not an out of the box solution, I need to change some settings and install a little bit of software.

the operating system

The Nokia 770 internet Tablet uses a build variant of the Debian distribution called Internet OS 2006 (or 2005 or 2007) which even though it was built in-house by Nokia was left as an open source OS. Nokia also offered it support to the independent developers that wanted to create applications for the internet tablets that they have made (N700, N770, N800). They called their software development platform Maemo. The open source nature of the SDKs for the internet tablets means that there is a dearth of applications available for this platform. It also means that this OS out of the box is a good option. I don’t need to install another OS. I don’t need to worry about Gentoo, XP Embedded, or Windows Mobile. Because of the nature of the community that is developing for this platform, many of the applications that I will be running are open source and thus are free (though donations are encouraged).

installing x-term

In order to make the OS more hack friendly I needed to install terminal, since no terminal was included to make the 770 internet tablet at least a slightly difficult to break the OS. The Maemo suggested X-Term emulator was downloaded and the packages installed. The installation files can be found here:

http://770.fs-security.com/xterm/

To use the internet tablet to its full potential, we need to be able to log in as root. Since there really is no easy way to do this in Internet Tablet OS 2006, I downloaded an application that forces root access on the 770. Called BecomeRoot, it is part of the OSSO-Xterm installation package. Just type in “sudo gainroot” to get root access.

Alternatively the guide below gives the same information with more help on how to install the packages in Linux.

http://examplified.net/guide/Nokia_770/Install_XTerm_and_Root_Access/

enabling usb host mode

To enable USB host mode not a whole lot needs be done. All that was done was to enter the following command into X-Term:

echo host > /sys/devices/platform/tahvo-usb/otg_mode

To turn the 770 internet tablet back to peripheral mode:

echo peripheral > /sys/devices/platform/tahvo-usb/otg_mode

That’s it.

maemo mapper

Installing this software is a breeze. It displays maps without any difficulty as long as there is an internet connection. This software worked wonders while my phone had high speed internet access even at 60 mph it had no problems pulling maps for me to use.

Once I got into low speed areas (anywhere outside major interstates and metro areas) it becomes unusable. Also the directions and voice features really do not stack up to the quality of the offerings available through a regular GPS. This software’s lack of features would be the major downfall for this system.

canola

While Canola was still in beta it was the best media player option available for my use since it was the only one out that is currently designed to be used without a stylus. I didn’t want to have to deal with using a stylus while in the car if I could help it so I went ahead and installed this very glitzy media player.

connecting the devices

bluetooth gps

This one is really easy. All you have to do is pair the device via Bluetooth and the Nokia 770 can just use it. Just like that.

usb hard disk

Once the hub was prepared and host mode enabled, all I had to do was to plug the drive in.

moto q smartphone

This is also really easy. Simple pair the phone as a Bluetooth device. The phone needs to have data access enabled as well as web access enabled. From there we can all surf the web with no issues. That is all the work that is needed.

improving the workability of the system

To make a better system, the powered USB hub would have to go. Also the Bluetooth devices would likewise have to go. Everything would be liked over USB and through an unpowered hub. Power would be supplied though a single 5v adapter. The GPS and the HD will always shut off when the GPS does and the 5v DC power converter would be removed from the system. This rework is fraught with risks. To make devices be able to run off of an unpowered hub, there would have had to jumper the power and the 5v on the USB (not an easy solder), also there could possibly be more than the 900mA of current getting pulled through the device. That high of a current pull that could either damage the device or the battery even though both should be able to withstand such a drain I am unwilling to risk my device (even though it was cheap) until I get a higher paying job or the internet tablet is out of warranty.

Perhaps in the summer of 2008 I will rework the system so I can have one integrated power bus. Such a change will lengthen the build but also help me get the cost of my homebrewed system under the $200 bar.

hitting the $200 price goal

Quantity Part Vendor Price Shipping Cost
1            Nokia 770 Internet Tablet  buy.com        129.99    0            129.99
1            USB GPS                          geeks.com     28.00     0            28.00
1            USB hard drive enclosure   newegg.com    5.99      4.99       10.98
1            USB 2.0 hub-unpowered    newegg.com    1.49      0.97        2.36
0            misc USB fittings               fry’s               0          0            0
1            2.5 inch HD 60gb IDE        overstock.com 24.99    0            24.99
Totals(USD)                                                        190.46  5.96        196.32

This pricing chart also reflects the changes specified in the “improving the workability of the system” section. That’s right…a cheaper and better version is possible, though at this point it’s all theoretical and I put none of it to practice.

the eplilogue

At the end of the project, Maemo Mapper simply isn’t good enough. I tried the Nokia Maps application and was likewise disappointed. It is worth noting that the Nokia Maps application didn’t work out because it was slow. So slow and system intensive on the 770 that you simply could not use both it and Canola at the same time.

Canola also had problems. It takes forever to index 60gbs of music. And it basically locks up the tablet while it is parsing. I would not recommend more than 4gbs of music for this reason. The sound quality out of the 770 is better than anything you can get out of an ipod but certainly not as good as you can get out of a high end Sony Walkman (in fact not even close).

In the end I abandoned this project and elected to build a regular car PC using a Mini ITX board running Windows XP. See the Carputer 2.0 page for more information and a similarly detailed write-up.

This project was completed as sophomores in college in the fall of 2006. This writeup is being done nearly 3 years later in 2009.

background

Even though only one of us would pursue mechanical engineering as a major, I think we thought of ourselves as gear heads back then. Eamon had a keen interest in fuel injection due to the work he was attempting on his car at the time. To try to keep our project as simple as we could, we focused on the simplest kind of electronic fuel injection. We planned to replace the carburetter with a throttle body with a single injector. In a single cylinder engine like the one we had, there was little reason to make a more complicated system. The project then would have several parts, the first would be system design, the second would be the code and the third would be the physical build.

Generally, the benefits of electronic fuel injection is efficiency. For small engines, that concern isn’t worth the cost or performance penalty of such a system. Our project was purely academic in nature and was not intended to bring significant gains.

system design

Identifying the critical components of the system was easy, we knew we needed an injector to put the gas into the engine, a pump to move the gas from the tank to the injector, a throttle body to inject the gas into, sensors to tell the state of the system, a circuit board that translated the PIC output into powered action and a battery. The battery was needed because we wanted to keep things as simple as possible, but we needed electricity to power the pump, the PIC and other assorted circuitry.

Our rough  diagram is above. Sometimes drawing some stuff on the back of a sheet of homework over lunch leads to good idea. Just remember its a concept diagram….not a wiring diagram.

the code

In this section, i *could* post some C code, but that wouldn’t add any value to what we really did. Instead I will tell the story.

The first thing we did was create the look up table that contained the values that we needed to calculate the amount of gas we needed based on the RPM and air flow into the engine. Our system had a 16×16 table with RPM and airflow as the axes that determined the amount of gas we would be injecting. We intended to keep the gas line at a relatively constant pressure, therefore the table contained a factor that was to be converted into a time value that told us how long to hold the injector open. Based on our understanding of other systems, the duration of injector pulse is also how some commercially implemented systems control the amount of gas entering the engine.

Our two sensors both reported analog voltages to the PIC. In the case of the RPM sensor, the result was a very rough sine wave. To make this work, we changed the voltage of this signal to place the threshold of the digital input of the PIC such that we could detect rising and falling edges of what could now be considered a square wave. Every rising edge meant one rotation had passed. The period of the wave was measured and converted to an RPM value.

The analog voltage from the air flow sensor conveniently fell within the range of voltages that could be detected by the PIC using an analog input. After characterizing the sensor, we converted the nearly linear voltage readout into air flow numbers.

Once we got our numbers, we used the look up table to get two values. Since the values from the sensors usually would not line up with the references from the table we got high and low values. We then linearly extrapolated a more precise value. Since the equation for volumetric efficiency was not linear, the approximation was not perfect, but it was more accurate in most cases than either just a high or low value.

An additional feature of the code was the ability to run rich at start up, much in the same way that a choke helps small engines start more easily and how fuel injection systems for larger engines run in open loop mode for a little while. This mode did not use a different table it just linearly added a little extra gas for the first twenty seconds by adding an extra RPM based factor to the length of the injector pulse.

the physical build

To make the system work, we needed to replace the carburetor with the throttle body and mount the sensors. The air intake was disassembled and the carburetor was removed. A piece of aluminum stock machined with a mount for the injector and a mount for the air flow sensor took the place of the carburetor. The pump was mounted in line between the injector and the gas tank. The circuitry and other electronics were just mounted on the chassis of the pressure washer. The engine was still going to have to be pull started.

the end

At the end of the day, the project was not a complete success. The engine had trouble running due to a dirty signal off the RPM sensor. During our required class demo, an attempted demo of the systemthat wasn’t supposed to include the engine running accidentally shot gas out of the injector and onto the floor…much to the chagrin of our professors.

We still presented the project for an Olin expo though!

This project is being written up almost three years after its execution so the writeup may be a little hazy.

There were two collaborators on this project: Eamon Doyle and Clark McPheeters.

background

The project started with a silly idea. As freshman at a small engineering college my roommate Eamon and I were always trying to think of creative ways to do something novel. We had heard from the upperclassman at the college about all the crazy things they had done and as the last incoming class prior to our schools first graduation; there might have been some inkling of wanting to also leave a legacy. On a whim, Eamon purchased a few USB fingerprint readers from eBay. Now back then, biometrics were novel. Facial and fingerprint recognition were far from standard gimmickry on laptops, and the notion of password-less protection was so novel that it still seemed like some awesome, super secret, spy-movie worthy way to secure data. However, unlocking a computer with a fingerprint reader is slow and kind of lame. In the movies it was always a combination of biometrics that opened a door. Since we hard these fingerprint readers, we figured that we would give it a try, one biometric at a time.

the SDK

Reading the fingerprints were easy, but the application that came with the readers was only good for filling in passwords. We needed more flexibility than that if we wanted to actually do something. As freshman, we knew nothing about embedded platforms of any kind and the only programming experience that either of us had was on windows PC’s. After unfairly blaming our respective high school computer science departments for that deficiency, we set about looking for a .net SDK (software development kit) that we could use to trigger an external device.Through a little work and a lot of luck, Eamon hit gold. He found a company in Lithuania that thought that we were pretty cool kids and gave us a copy of their thousands-of-dollars-for-sale SDK for free, the only stipulation being that we send them pictures of our application, the story of our project, and put their logo on our poster when we presented. We didn’t know it at the time, but the VeriFace/VeriFinger software would roll out in about a years time as the software behind the IBM/Lenovo biometrics packages.

Once we got the SDK up and running on the PC it was time for me to put my C++ skills to use. Using their demo as a starting point I realized that the easiest way to make the system work would be to use the serial port on the device to output a high string to open the door when a finger was recognized and low string all other times. Looking back, now it seems like a very messy solution, but as a freshman I simply didn’t know any better. After writing a few lines of code and more than a few hours, the app was done, we had a faint but consistent signal output when the system recognized a previously enrolled fingerprint.

The picture above shows the finished software in action. For the most part the GUI from the code example was retained. Databasing and logging features were added in addition to the serial signaling on successful print match.

the hardware

While I was coding the other members of the team, Eamon Doyle and Clark McPheeters were busy making the parts needed to make the system work. The first order of business was to take the lock out of the door. There weren’t rules against this when we were freshman in college…but there were rules against it by the time I was a junior. Views of the disassembled lock are below:

Once the lock was disassembled, a solenoid was selected that would be small enough to fit into the empty space and pull the locking pin on the door lock. One of the design goals was to make sure that the keys for the door still worked in the event that the system stopped functioning, as the system would be running on a Windows machine we thought this to be a neccesary precaution. As freshman, we all learned how to CAD, but for the purposes of conceptual design, things were still done on paper first. We also didn’t want to damage the lock at all, so any mounting would have to be done without screws, glue or brazing. To make it work, Clark and Eamon set about designing a solenoid mount.

As shown by the above placement, a mount that took advantage of the geometry of the case would hold the solenoid in place. We also needed to make a new plate to replace the one that keeps the handle from turning and therefore the door from opening, By actuating that plate we would be able to open the door using both the key or using the solenoid to move the plate. Once the design was set, a CAD model of the lock and new pieces was made to ensure that everything would fit together as planned.

The next step was actually making the pieces. From the CAD design, Clark and Eamon milled the pieces out of aluminum stock. The mount was made first:

As can been seen from the pictures above, the geometry of the mount is precision made so that it can make use of the cuts in the lock to hold the solenoid in place. The next step was to make a replica of the plate that we need to move. We could not modify the original since we would have to restore the lock completely to original condition once we moved out at the end of the year. Photos showing the manufacturing of the plate are below:

Like the mount, this was also milled out of aluminum. Given the training that we had at the time, it was the best choice. It would probably be a good choice again too, if we had the access to the same kind of machinery and could just find small blocks of scrap aluminum stock lying around.

putting it together

Once all the components were made, the lock needed to be reassembled with its new parts and tested. At this point, the software was working, but we knew that we didn’t have the power needed to open the solenoid just coming from the serial port. We knew we would have to take some DC power from the inside of the PC to make it work. What we didn’t know was how much power would be needed to operate the solenoid. Therefore, testing with a power supply served two purposes. Photos of the assembly and the testing are below:

On the first try the testing was successful! All that was left was to present it…and eventually install it on our door!

presentation/epilogue

On the day of the presentation, we were ready to go. Looking back, we were really proud of the work we had done. Most of us had a pretty rough semester; but the world seemed all better now that we felt like we had something pretty cool to present. We took the time to make sure that our poster /demonstration stood out too!

People seemed to think it was pretty novel too. Though I think the facilities workers liked it the most. Their managers were much less thrilled by the latest in alterations to campus equipment. Of course, as soon at it was over; we installed it so that we would use it from the week after our presentation to the date after which we were kicked out of the dorms for the summer.