Trinculo’s Attic Booth – USITT 2013

Trinculo’s Attic Booth – USITT 2013

For our 2013 USITT booth, we decided we wanted to something more exciting than just a table full of products. We had been doing a lot of interesting one-off projects, but most of them aren’t very compact or portable. After looking at our recent jobs to see what we could show off in the booth, we settled on a football field goal simulator and some LED battery-powered signs. We decided to combine the two control systems we’d developed into something that would showcase the many ways our systems can be used in experiential marketing.

The Design

Stronger Than A RobotWe decided we really liked the aesthetic of a turn of the century carnival game, but we wanted to update the look and the interaction a little bit. We had the fabulous Cass Malloy (aka @TrinculoRobot) design a carnival strength tower, and the amazing Ellen Juhlin created some goofy sound effects for us, while we built the electronics that ran the system and pulled all the pieces together.

The final result? Rather than just hitting a lever that physically shoots a shuttle up a tower, our system consisted of three independent parts:

  • A light-up strength tower
  • A target puck that you smacked with a hammer
  • A tablet that displayed your score, played the sound effects, and tweeted updates

Additionally, power and internet were not included with the booth, and trade show rates for these things are notoriously expensive. Wifi at this show was listed as $485 per device; electricity was a little more reasonable, at $180 for 10A service during show hours. Being the crafty electronics geeks we are, we decided to simply use the electricity in our hotel room, and bring it with us to the Expo floor each day – making our booth 100% battery-powered!

The Puck

The first part we developed was the target puck. This had a single-axis 250g acceleration sensor in it, plus an Arduino Fio, a 3.3V step-up board and a 2xAAA battery holder. It was milled from a solid piece of 4″ diameter delrin, and was largely indestructible. The software was very similar to what we used on the football simulator, but it used a single axis (instead of three), and we quickly discovered that the impact profile needed to be a bit different.

Here’s an average impact from the foam hammer:
Hammer Impact
This is very different from the football kicks in that there’s a zero crossing in the middle of the impact. Because we were squishing the puck into a surface, from which it then recoiled, the force started in one direction and then reversed.

When we started looking at the raw analog-to-digital conversion (ADC) reads, we got some nice spikes, but we were usually catching a read somewhere in the middle that was below the event threshold in the football data. The football software was written so that it looked for a series of readings above a particular threshold; as soon as the readings dropped below that threshold, it considered the event done and transmitted the data. On the puck, this meant that we were only getting half of the event due to the zero crossing. To compensate, we added a “ride through” logic that allowed an event to continue within about 3 ADC reads if it once again went above the threshold value.

The only other thing we needed to change was a funny detail we had discovered when developing the football: spring contacts in battery holders work great, except during impact events. On the football, we used a completely soldered-in rechargeable battery, eliminating the need to dig into it to change batteries, as well as negating the spring contact issue. Since we did have spring contacts in the puck, we had very short moments (on the order of tens of milliseconds) during which the batteries would be disconnected. We simply added a large 470uF capacitor to the input side of the voltage booster. This 100% solved the problem, as the 3.3V step-up circuit could simply draw down the capacitor while the batteries were disconnected.

All of the data processing happened in the puck’s software: it integrated the absolute value accelerations over the impact event time, eventually coming up with a single number. In testing, this number ranged from about 50 in minimum hits to over 450, but it was looking hard to get over 300. The puck simply output this number (50-300+), but there was no top limit on it – it kept integrating as long as the sensor was reading above the event threshold. This number was actually a speed, but it was in arbitrary units; we’ll discuss later on how to get a speed from this number and how we adapted this range into a final score. The number was transmitted via Xbee radio to the tower (which also forwarded the number to the tablet via bluetooth).

The Tower

Next we developed the strength tower. This had 18 RGB LEDs, plus some lights in the top to light up Trinculo when a high score was hit. The physical tower was made up of printed graphics, UV coated and glued to either sintra (the gear and background), frosted plexi (Trinculo), or 1/2″ gatorboard. We cut out all the funny outlines on a band saw, and did all the circles on our CNC mill. The RGB LEDs are based on WS2801 LED drivers, so instead of having to actively drive them, we could just send them a 32-bit color value, which got displayed on the LED.

The tower had three basic modes: an attractor look, an idle (off) look, and a score playback series. The attractor look was generated using a cellular automaton system called “Forest Fire.” Cellular automata for lighting design deserves its own blog post (or an entire book), but the briefest explanation is this: an off pixel has a random chance of becoming a blue pixel (a tree), a blue pixel has a random chance of being a pink pixel (on fire), and fire spreads to adjacent blue pixels. Pink pixels then become off pixels. Overall, it was a very simple system to implement with 18 pixels, and it created a fully generated non-repeating pattern. (You can find more of our work with cellular automata in lighting design here.)

The score playback looks were based off of the sound design; while there were about a dozen different sound cues, the lighting cues only had four different looks. If you scored between a 200 and a 950, it played the standard look: each LED took 85 milliseconds to turn on, and the “fall” afterwards took a fixed amount of time (that is, harder hits fell faster). If you scored below 200, only the bottom two LEDs turned on (matching the sound file), and then fell.

If you scored between 950 and 999, we had a special “teaser” effect for you: the score shot up a little quicker, lit up all 18 lights, and almost hit the top, but then it hesitated and fell back down. It sounded like this, with hints of the big win sound, but it didn’t quite get there.

If you scored 1000 or higher, we had a pretty fantastic lighting and sound cue. All 18 LEDs lit up, and then the Trinculo head flashed (via some white LEDs along the bottom edge) in time with the big bell rings, while the RGB LEDs flashed completely random colors. The “shuttle” then fell and there was a final head light up on the final horn noise.

The lighting was in sync with the sound, but the cues were so short that we just started them at the same time and they never really got out of sync. It looked complicated, but it worked like magic!

The Tablet

Finally, we developed the tablet app. We used a Google Nexus 7 tablet, which we picked because we were able to completely change the lower-level operating system with very little effort – Google makes it easy to modify the Android base system, unlike Samsung and other Android tablets. In this way, we were able to put it into a basic kiosk mode, removing all “window dressing” like the home button across the bottom of the screen. Our App took the data from the puck (transmitted via the tower) over bluetooth, played back the audio, and displayed the score. It also had its own twitter account, where it tweeted people’s scores and an invitation to visit our booth. If folks entered their twitter handles with an @, it actually tweeted at them; we had many people’s phones vibrate, notifying them of their tweet just after they hit the hammer, which was a little bit magical.

Running the System

So, with internet costing $480 and power costing $180, how did we afford this? We cheated a little. We had two giant sealed lead acid batteries that we were able to charge in the hotel room and cart in every day to run the booth. (One battery also worked as ballast to keep the strength tower from falling over.) For the internet we used a little wifi access point, which got us internet access through the 3G network (no 4G in Milwaukee, apparently).

The Scoring

Final Leader BoardIf someone hit the puck hard enough to light up Trinculo’s head, we had a prize for them: a big button that said “I’m Stronger than a Robot” to go with our little robot buttons. We didn’t want to give too many of these away (not everyone can be stronger than a robot!), so we needed to set the top of the tower to be relatively hard to hit. The neat thing about this being software-defined was that we could just decide what the range was. In testing, we only saw a few hits over 300, with 400 being pretty hard to get (and only after some practice). We also never saw a hit under 50. So, we decided to scale this 50-300 range and scale it to 100-1000. This is a pretty easy transformation – in non-generic terms, you take the score, subtract 50, multiply it by (900/250) and then add 100. So if the puck transmits 237, we subtract 50 (187), multiply by 900/250 (673.2) and then add 100 (773.2); the final score is rounded off to 773. To go back, you do the operations in reverse.

The absolute highest score we got was 2833 – almost 3x what we thought would be a hard score to get. To revert back to its base number, we first subtract 100 (2733), multiply it by 250/900 (759), and then add 50, giving us a value of 809. Now, I said earlier that this could be turned into a speed. We read the ADC every 600us, or about 1667 times per second. The sensor outputs data in g’s, where 127 = 250g and -127 = -250g. One g is 9.8m/s2, so each bit of the reading is equal to 19.29 m/s2. Since our timeslices are 600 microseconds, that’s 0.0006 seconds per reading. So each step of the magnitude reading is equal to 19.29 m/s2 * 0.0006 seconds, or 0.0116 m/s.

From this, our minimum reading of about 50 is equal to a speed of 0.58 m/s. The threshold to win a button is 3.48 m/s (about 8 miles per hour). So what about our grand winner at 809? They hit the puck hard enough to propel it at about 9.4 m/s, or about 20 mph. (And if I remember correctly, it did manage to fly across the floor a bit.)

Some Interesting Data

I have two final graphs to share. The first is all of the scores arranged chronologically on a scatterplot. While the top scores do increase with time (likely due to the hammer’s foam degrading), the overall average scores stay pretty flat:
I was also pretty happy to see that while there seems to be a phenomenon of “repeat scores” (pairs of scores that are equal), there is no clear banding. This indicates that we’re getting pretty decent smoothing of the data from the ADC reads – it’s not pegging into only a few values due to the limited ADC resolution.

The second graph is a histogram of all hits, which shows some interesting clustering. The two big clusters are below 200 (basically a miss), and then around 700. This matches with my experience that it’s pretty easy to get between 500-1000, but pretty hard to get over that. Overall we saw 315 hits, and 74 of those were over 1000 – not bad compared to our goal of 50 hits over 1000:
Hits Histogram