Tag Archives: Arduino

Tinkur Park Assist


Val and I recently got a new car – a Subaru Outback.¬† The 12 year old Subaru Forester was still doing ok, but it was time to get a new car with better safety features.¬† However, the new Outback was a bit bigger – length and width.¬† And since we’d used up a significant¬†portion of our garage space for Tinkurlab’s workshop, I wanted to park the Outback as close to the garage door as possible to leave maximum room in front of the car to walk between the workshop and our house.¬† What to do?¬† Hang a tennis ball from the ceiling?¬† Not for a maker!¬† Time for a new project!

Introducing Tinkur Park Assist, a project to help you park your car irresponsibly close to the garage door, with only inches to spare.

“a project to help you park your car irresponsibly close to the garage door, with only inches to spare”


Tinkur Park Assist is pretty simple, consisting of an ultrasonic range sensor to determine the distance between the wall and the car, a big LED for feedback about the distance of the car from the sensor, and an Arduino to make sense of it all.  I initially used an IR distance sensor, but I found that an ultrasonic sensor works much better for the car which is highly reflective and curved.  It seems accurate to within an inch.

I also had the opportunity to design my own housing for the project to hide all the messy wires and electronics.  I chose to 3D print the housing, which was much easier vs. previous housings that were constructed of acrylic milled with a CNC machine.  After a few iterations of the 3D model design, I was able to create a housing that has openings in all the right spots and has an easy to add / remove snap-on lid.

How it Works?

Tinkur¬†Park Assist continuously monitors the distance between the ultrasonic sensor and whatever is in front of it.¬† If the distance hasn’t changed in a while, the LED light turns off.¬† When the distance starts changing, the LED light turns yellow¬†as the object in front of it gets into close range (< 5.5 feet in this case) and turns green when the object is in the ideal range (30 to 38 inches from the sensor in this case).¬† If the object is too close (< 30 inches), the LED turns red.¬† Tinkur Park Assist also saves the 3x last distance values, using the median value for making decisions¬†to reduce false positives from random fluctuations in data (ex. a person walking in front of the sensor).

What’s Next?

I’ll give some time to test Tinkur¬†Park Assist.¬† I think likely iterations may include:

  • Tweaking trigger distances.
  • Increasing the sampling rate for faster LED changes.
  • Tweaking the “no motion detected” logic and thresholds to make sure the LED is off when a car isn’t approaching.

How to Learn More?

Check out the docs and source code at https://github.com/TinkurLab/TinkurParkingAssist.

Check out the 3D model at https://www.thingiverse.com/thing:2836728.

Tagged , , , ,

Das Bot 2.0 – Now with more beer!

How quickly time goes by. ¬†It seems like we only just completed Das Bot v1.0, but with Oktoberfest 2012 quickly approaching we started one of the biggest projects we’ve completed to date – Das Bot 2.0. ¬†Instrumented¬†beer on a grand scale!

The final setup, ready for the party to start.


Das Bot is a system for monitoring and controlling access to beer through RFID tags. Built on top of an internet-connected Arduino, the system accepts an RFID tag,¬†checks¬†to make sure you’re registered, opens the solenoid valves in the beer lines, lets you pour a beer and monitors how much you’ve poured, saves the data to a database, and prints out a receipt. Oh, and there’s prize badges you can win as well. There were three beers on tap this year (a homebrewed Dunkelweizen, a homebrewed Hefeweizen, and a Hofbrauhaus Oktoberfest) and each beer was tracked independently.

The Hardware

Das Bot contains the following pieces of hardware:

  • Arduino (with Ethernet shield) – the brains of the operation. This¬†micro controller¬†is what reads the RFID tags, talks to the PHP/MySQL site, controls the solenoid valves, prints to the thermal printer, and reads the data from the flow meters.
  • RFID Reader – reads the values from the RFID chips and sends the value to the Arduino.
  • 3 Solenoid Valves – similar to the ones on Adafruit’s site, these valves are normally closed (restricting access to vital beer) and are only opened when the Arduino gives the go ahead. After 10 seconds of no beer flowing, they close again. Since these draw more current and run at 12v, we used an old 12v wall wart we had laying around to power these (through the relay).
  • RelayThis relay controls the power to the solenoids.
  • 3 Flow Meters – we used the ones from Adafruit to send the flow data to the Arduino.
  • Thermal Printer – printed a welcome message, current stats, and final pour total for each pour.
  • Electrical Box – from the big box home improvement store, this water (and beer-proof) project enclosure was perfect for housing the Arduino, printer, and other electrical components.
  • RGB LED – when the light turns blue, pour your beer
  • Piezzo Buzzer – something this complicated needs to beep. Ours beeps when an RFID is successfully read.
  • Jockey Box – this converted cooler has a 7-pass plate chiller inside and once covered with ice, chills the beer as it flows through. This means no need to keep the kegs in giant plastic tubs with 800lbs of ice.
  • Tap Handles – no jockey box is complete without custom milled tap handles.
  • The Override Switch – this can not be over-appreciated. Buried in an undisclosed location was a switch that would override the arduino and open the solenoid valves. In the event of catastrophic failure, this is the switch represented the difference between beer and no beer. I’m always going to support the side with beer.

Closeup shot of the solenoids

The override switch. Luckily, this wasn’t needed this year. But it’s nice to know it’s there.


The Software

The hardware was almost the easy part of this project. We had experience with Das Bot v1.0, so adding some additional sensors wasn’t too difficult. The hard part was getting everything to talk to each other at the right times, with the right data.
Here’s what the software side looked like:
  • Arduino code – this is the air traffic control system. When an RFID chip is read, it sends the data to a web service and gets back the user’s current status. If they’re not registered, they get one (and ONLY one) free beer before they’re required to register. The flow meters are opened and activity from the meters is recorded. After 10 seconds of no flow, the system closes the valves and sends the pour volume data to the web service. The Arduino then prints out a receipt listing pour volumes and any badges that were won on this pour.
  • PHP/MySQL – a website used to store and present data during the party. The web service components were built using some simple PHP with a MySQL back end. The dashboard (running on an iPad taped inside the kitchen window during the party) presented current keg stats, leaderboards, badge summary, and other interesting bits of info. We also included the calibration for the flow meters in the database to allow for different keg sizes and to help more accurately record the data.

The welcome message displayed once an RFID tag is scanned

 The Dashboard

Want to become mayor of the Hofbrauhaus? Brag about having the largest drinking vessel? Why not turn an entire party into a drinking game? With all of the data we were collecting, it seemed natural to present this information back to the user. The thermal printer can only present so much data. The kegs were also under the table, making the “just lift it to see how much is left” method rather difficult. So, we created the dashboard to give a quick way to see how much fun we were having (note to self: next year, add a “fun” meter).

The dashboard presented the current leaders, the amount of beer consumed for each keg, the 5 most recent pours, and some other random stats. Some badges were mysteries, only visible once unlocked. Others were hinted at by the icon. Either way, the best way to win a badge was to drink beer. Actually, that was the only way.

How much fun are we having right now? Oh, THAT much. This was displayed on an iPad safely taped to the inside of the kitchen window. It was visible from the taps.

Future Enhancements

Some ideas for the 2013 Oktoberfest:

  • Integrate the photobooth¬†– haven’t been inside the booth in the last hour? No beer for you!
  • More badges to win – need target different needs in people’s psyche, not just the “I drank more than you did” desire
  • Allow “offline” badges – someone won the beer stein race, but we’ll never remember who it was. We’ll need a way to award spot badges from mobile devices.
  • More notifications when a badge is won – I’m thinking car horns, disco balls, or fireworks. Perhaps all three.
  • Breathalyzer integration – imagine tracking this against the volume consumed overlayed with the photobooth pictures. None of our friends will ever be politicians.


Additional images from the project:


RFID chips. Everyone got one. There were also zip ties to attach the chips to your beer stein.

The custom tap handles came out well.

The system, all condensed.

Water and electricity don’t mix, so we taped the electronics inside the cooler to the lid.

Additional photos can be found on Flickr




*Disclaimer – Please note that this system was built for responsible adults. EVERY person in the “leader boards” either spent the night (and likely much of the next day) at the location or were driven home by a designated driver. We might mix water, beer, and electricity together from time to time, but we certainly don’t drink and drive.

Tagged , , , , ,

BBQ Lab (v1.3) – Smoke Density

BBQ is about low, slow, and smoke. And while the temperature sensors in BBQ Lab have already take care of the low and slow part, none of the instrumentation really addresses the smoke part. ¬†So the newest upgrade to BBQ Lab in v1.3 is the addition of a smoke sensor that measures the smoke in parts per million. ¬†I’m not actually as concerned with the exact measurement of the smoke as I am within the ability to relatively measure it throughout the duration off a BBQ.

The sensor is relatively simple – a MQ-2 sensor that detects the presence of smoke in parts per million and outputs an analog voltage that corresponds to the measurement range of the sensor. A 0 voltage corresponds to the low range of the sensor and a 1023 voltage corresponds to the high range of the sensor. Everything else in between represents gradients between the ranges. I any case what matters to me is identifying a reading that corresponds what I consider “good smoke output” and displaying the measurements via the trending graphs and real time alerts so I can take action based on the information.
BBQ Lab Propane Sensor

MQ-2 Smoke Sensor

BBQ Lab Propane Sensor

Knob to Adjust Sensitivity

I also ordered a bunch of other gas sensors, including a MQ-6 sensor that detects the presence of propane gas, which I’m to use to detect when the smoker’s flame blows out – such as on windy days. ¬†I’m also working on adding a automated propane control value that throttles the propane to achieve an ideal temperature – so the sensor can be used as part of a safety control system.
Hopefully I’ll be making a BBQed Brisket this week – so stay tuned for notes, pictures, and video.
Tagged , , , ,

Visualization and RoadLogger

As I recently tweeted, “Information is no longer a scarce resource – attention is”. ¬†While technology, the internet, and the web of things have made amazing things possible, they have also given rise to vast amounts of information that are accessible almost anywhere at anytime. ¬†Given this overload of information and often trying to find better way to determine what information is relevant and to improve the effectiveness¬†of¬†consuming¬†it, I’ve recently found myself intrigued by data visualization – taking lots of data, analyzing¬†it , and presenting it in a visual way that conveys a different point of view then the data could alone. ¬†As a photographer, the phase “a picture is worth a¬†thousand¬†words” comes to mind. ¬†And so to learn a bit more about this area of tinkuring, a few months ago I started reading¬†Visualize This: The FlowingData Guide to Design, Visualization, and Statistics¬†in which Nathan Yah¬†describes his approach to visualization, including tools, approach, design – quite an interesting mash up of¬†disciplines.

Realizing the first step towards visualization if to have data to¬†analyze, I created a Arduino project called RoadLogger to use on a roadtrip to New England last summer with Val. ¬†RoadLogger (v1.0) logged the location, speed, altitude, direction, and driver of our car ever second, using a USB GPS antenna and a microSD card to data storage. ¬†While I haven’t had time to post info about RoadLogger and finish¬†analyzing¬†the 32,000+ datapoints, I’ve been thinking about what might be interesting way to analyize the data and present it visually. ¬†Here’s a quick list of thoughts:

  • How many miles did each driver drive?
  • What was our average speed per state?
  • Who was the faster driver?
  • What was the average time from 0 – 60 mph per driver?
Any other ideas?

Until I get around to doing some more work on this project, check out my first basic¬†visualization¬†“Am I A Foodie”¬†at another one of my blogs Until It’s Done.


Tagged , , ,

BBQ Lab – Instrumented BBQ

My wife РVal Рand I love food.  We love to cook it, eat it, and share it with others.  And one of my favorite foods is BBQ.  So a few years ago, we purchased a small smoker to try our hand at making some BBQ.  So first, let’s talk about the BBQ rig.  We live in a smaller house and didn’t want to invest too much money into a smoker until we proved our dedication to the craft, so we purchased a Brinkman gas vertical water smoker.  A vertical water smoker basically looks like a freestanding locker, with a fire in the bottom, followed by a wood pan, followed by a water pan, followed by a few racks for the good stuff Рpork butts, briskets, sausages, etc Р, and finally the exhaust chimney.  I chose the gas model because I thought it would provide more precise control to maintain the temperature of the smoker.  And so it was for a few years that our little smoker produced some really good BBQ.  However, smokers take quite a bit of tending.  You need to make sure the fire it lit, there’s enough wood and its smoking, there’s enough water, the smoker is at the right temperature, and the food isn’t overcooking.  That translates into going outside every 15 Р30 minutes to check on the smoker, making a few adjustments, and repeating for 8 Р12 hours.  It’s an all day affair.

Enter the instrumented smoker РBBQ Lab v1.0.  My friend Matt turned me onto Arduinos a few years ago.  Since then I’ve tinkered with a few Arduino basics Рblinking lights, using switches Рbut I didn’t really have a focused project.  And so it was that my first true Arduino project was instrumenting my smoker.

BBQ Lab v1.0 consisted had the following capabilities:

  • Measurement of smoker temperature
  • Measurement of food temperature
  • Measurement of humidity at exhaust chimney
  • Measurement of ambient outdoor temperature
  • Sending data to a web service every 10 seconds which is logged to a database
  • Display of data on a web page with an auto refresh every 10 seconds
BBQ Lab v1.0

Arduino board with Ethernet shield.

BBQ Lab v1.0

Breadboard with leads to Arduino and inputs from thermocouples and humidity sensor.

BBQ Lab v1.0

Thermocouple probes. The smooth one is for the food, the one with the bolt screws into the side of the smoker.

BBQ Lab v1.0

Web page displaying real time smoker temperature and humidity.


Since BBQ Lab is still undergoing improvements, I haven’t created a permanent mounting solution as of yet.  It currently resides in a Rubbermaid container which protects it from rain and snow.

BBQ Lab v1.0 made is debut in March 2011 tending a 6 lb pork shoulder.  I setup a small Netbook computer with the BBQ Lab status page and glanced at it every few minutes to check the status of the pork.  While I still had to go outside every once in a while to adjust the temperature or check the smoke, it certainly reduced the overall number of trips.  I also emailed a link to the BBQ Lab to Val and a few friends, which had the awesome effect of having a crowsourced BBQ.  As the temperature rose too high one of my friends IMed me.  Later, when the temp droped severly because of a flame blowout, another friend sent me a text.  It was a group cooking effort Рit was awesome!

Since then BBQ Lab has gone through a few revisions and cooked more yummie BBQ Рwith the continued help of friends watching the instrumentation.

BBQ Lab v1.1

  • Added Google Charts to show temperature and humidity trends over time

BBQ Lab v1.2

  • Added smoker temperature and food temperature thresholds with send text message alerts when thresholds are exceeded

BBQ Lab v.Next Potential Features

  • Smoke sensor to determine smoke density
  • Solenoid valve to throttle propane flow depending on smoker temperature and smoke density
  • Gas sensor to detect flame blowouts and turn off propane flow via solenoid valve
  • Igniter to reignite flame
  • Posting updates to Twitter
  • Data analysis and visualization of past BBQs
Tagged , , , ,