Case Study: Traffic Jam Alarm

Combining Natural Planning with the Maker Project Canvas

This article is an example of combining the Maker Project Canvas with David Allen’s “Natural Planning Model” to define a project. He describes this model in his 2014 TEDx talk. It is an informal five step process that we usually follow to accomplish a project. It also describes a very natural way to use the canvas.

Like Simon Sinek’s “Start with Why” idea, the process starts with understanding why you need to do the project. The next step echoes Stephen Covey’s concept of ‘begin with the end’: envision the outcome. Both of these ideas are captured in the canvas goal section.

The next planning step is to brainstorm ideas for the project. The canvas can be used several ways to collect these ideas:

  • Conceptual brainstorming with the simplified canvas
  • Creating alternatives with multiple canvases
  • Remixing solutions from other project canvases

After brainstorming ideas, the next step is to organize. The canvas ‘checklist’ format naturally structures idea collection. Idea collection happens between canvases, within canvas sections, and at the element level. Once a canvas is selected, you get a sense of which elements are the most critical for the project. These elements might need more thought or challenge your skills.

This leads to the final step in the planning process: selecting your next action. You might select an easy element to work on as a small step to get the project rolling. Or, you may want to focus on how to deal with one of the more challenging elements. The series of next actions are what gets the project completed.

Defining the purpose of the project

“Many men go fishing all of their lives without knowing that it is not fish they are after.” — Henry David Thoreau

Purpose drives goals. Before defining the outcome of the project, understand why you want to do it. A good framework for this combine the Job-to-be-Done view with Lean’s 5 Whys. Let’s apply it to this project:

I want to be warned about this!

Your morning commute is generally OK, but some days are nightmares. You want an alert for heavy commuter traffic. Let’s fill in the blanks for the Jobs-to-be-Done phrasing.

When I’m getting ready to go, I want an automatic traffic alert so I can plan an alternate route.

Next, apply 5 Whys questioning:

  1. Why do I want an automatic traffic alert? Because I don’t check traffic on my phone.
  2. Why? Because traffic is usually not too bad.
  3. Why not check anyway? Because I start doing emails and social updates. This can make me late on a good traffic day.
  4. Why not resist? Social technology is addictive. It should serve me, not act as a gateway to wasting time.

You now have a clearer understanding of why you want this. Note that it usually takes fewer than 5 ‘why’ questions to get there. Let’s look at another part of the problem statement.

The phrase ‘when I’m getting ready to go’ is pretty broad. It could mean going to the airport or on a road trip. Let’s constrain the problem to work commutes.

So, using the above, the Job-to-be-Done can be rewritten:

When I’m getting ready for work in the morning, I want an automatic traffic alert indicator so I can plan an alternate route.

How will we know if the solution is good enough? We need an envisioned goal to measure it against. How about:

The prototype indicator will focus function but will have a rugged form that sits on my desk.

Brainstorming Concepts

We now have the Goal section defined, so it’s time to brainstorming concepts. For simplicity, let’s restrict the exercise to two alternative concepts. Each can appears on the Concept canvas with different colored notes. The Goal section is, of course, the same for each alternative.

Concept Canvas showing two alternatives

The alternative in green uses a monitor to show heavy traffic. This has the advantage of showing the map. It adds complexity to the project since the monitor power must be controlled.

I chose the alternative in blue instead. It uses a simple red light to show heavy traffic. I like having a simple interface that is NOT another screen to check. I think we’re spending way too much time staring at glass rectangles.

Filling in the details

A full canvas shows the details for this concept. Rather than show alternative canvases, tradeoff decisions are discussed below. The Form and Function elements are summaries of the Concept canvas sections. Let’s walk through the Function side first.

Initial Maker Project Canvas

For this prototype, the commute information is hard coded. So the user interface is dead simple. Apply power and see the indicator light color. The ‘actuator’ uses Neopixel RGB LED lamps. They are set with serial communication from a single digital output pin.

The Arduino Uno and Raspberry Pi boards are too big. The Raspberry Zero is much smaller but lacks WiFi. The Particle Photon is a good solution for the processor. Adafruit makes Particle/Spark NeoPixel Ring Kit that mounts the Photon and has 24 Neopixels. Its circular shape is perfect for mounting in the lid of the Mason Jar. A separate 5V wall ‘wart’ supplies power via a DC jack mounted on the lid.

We need to know two things to show traffic status.

  1. Is it time to check commute traffic?
  2. If so, what is the status?

Rather than rely on internal timers, the local time is obtained from I used a 4 hour window centered around my normal commute time to check traffic. This allows some variation in actual leaving time. It also has enough tolerance to absorb daylight savings time changes. Crude but good enough. The REST call is hardcoded for my location. Google Maps Distance Matrix API provides the traffic conditions. The REST call is hardcoded for my commute. So is the commute information like average time and alert limits. This keeps the prototype simple.

Moving on to the Form section, the Use Patterns are also straightforward. The Mason jar sits on a desk or shelf where it is visible in the room. A simple glance indicates how the commute is looking in the morning. It also lets family members know how your return commute is looking.

The prototype is working in a benign environment (my desk). The components center around the Mason jar and Adafruit board. Both are off-the-shelf and do not need finishing. The Adafruit board fits in the lid, so a variety of widemouth jar sizes can be used. The only fabrication is drilling mounting holes in the Mason jar lid.

Testing is done with serial debugging. I can’t control traffic, so fake API responses will test traffic checking. If I could control traffic, I would not need this device…

Now that the project is organized, what parts should be worked on first? The biggest challenge is in writing the code to handle the API calls and run the indicator. That is a natural consequence of having the project focus on Function and keeping Form simple. Because the Form side is so simple, I chose to just get it done first. Then all my attention could be on the code development. It also gives me a physically stable platform.

Simple Form: Adafruit Photon/Neopixel board mounted on a Mason jar lid

Implementing the Function

“No plan survives first contact with implementation.” — Andy Weir

With hardware literally in hand, the logical next action was to work on the code. A few changes to the approach in the canvas were made:

  1. The Particle Photon/Core has a nice set of Time functions that sync to their cloud. So, there is no need to use the API.
  2. I used a Particle Core (formerly Spark Core) in my build. It does not support https calls to the Google Maps Direction Matrix API. So, this was overcome by using a PHP script on a server to get the commute time.

The idea of using a PHP script on the server was a ‘re-mix’ from a previous project. Offloading work from the local device is generally a good idea anyway. The Google Map REST call for the morning commute looks like:

Addresses are of the form: 123+Main+St+Franklin,+NJ. You’ll need a Google Maps API key, which you can get here. The return commute call just swaps the home and work addresses. Due to laziness, separate PHP scripts were created for each commute direction. The native Particle Time function was used to select which one to use:

if (Time.isAM())
client.println(“GET /YOUR_PATH/commuteAM.php HTTP/1.0”);
client.println(“GET /YOUR_PATH/commutePM.php HTTP/1.0”);

I wanted the light to ‘breathe’ when it was on. The first version used a brightness factor that linearly increased then decreased in each cycle (a triangle wave). The brightness factor is then used to scale the LED RGB color. A more soothing version uses a sine wave to ‘breathe’. Since the Particle doesn’t have a native cosine function, a simple approximation was used:

// — — — — — — — — — — — — — — — — — — — — — — — — — — — — — 
// COS : cosine approximation. Input is 0 to 360 degrees
// — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
// Cosine approximation where x is in degrees
double COS(double x)
double Cos = 1;
   double a = 1;
double b = -0.00012345; // 1/90²
   // bound x to (0,360)
if (x<0) {x+= 360;}
if (x>=360) {x-= 360;}
   if (x<=90) {Cos = a + b*x*x;}
if ((x>90)&&(x<=270)) {Cos = -a -b*(x-180)*(x-180);}
if (x>270) {Cos = a + b*(x-360)*(x-360);}
   return Cos;

The depth of the breathing effect is decreased by setting the scaling factor on the cosine (496 below) to less than the DC offset (511):

// don’t turn fully off
brightness = (int)(511.0 + 496.0 * COS(cycleIndex));

The LED color is then the brightness factor divided by 1024. The division is accomplished by a bit shift operation:

// update NeoPixel colors
if (lampState == LAMPS_ON)
// multiply by brightness factor
ledR = ledR * brightness;
ledG = ledG * brightness;
ledB = ledB * brightness;
// scale by max value of 1024
ledR = ledR >> 10;
ledG = ledG >> 10;
ledB = ledB >> 10;
if (lampState == LAMPS_OFF)
ledR = 0;
ledG = 0;
ledB = 0;

Example code can be found at Github.

Form tweaks

Traffic Jam in a jar… (note the Core’s blue indicator)

A nice thing about having everything on the Mason jar lid is being able to swap it to other size jars. I moved it to a larger jar that had a diffusing screen insert made from an old keyboard flex circuit and tracing paper. The flex circuit came from a keyboard my son took apart as a joke on me when he was little. I was annoyed and extremely proud he figured out how to do it! So it has a sentimental value to me as well.

The final form of the project. Bigger Mason jar with a light screen made from a keyboard flex circuit.

Here’s a couple of videos:

Moderate Volume mode
Normal Volume mode
“Lost time is never found again.” — Benjamin Franklin


Learn more about the Maker Project Canvas here.

  1. Download the Concept and Full canvas PDF files from Github.
  2. Download the Maker Project Canvas Workbook from here.

I would love to see examples of how you use the Maker Project Canvas in your projects. Please share! Tangibit Studios

Like what you read? Give Tangibit Studios a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.