Greg, Peter, Clay, Dewitt, Terry, Jason, Preston, Rasmus, Bernt, Raymond, Charlie, Cruz, Mike, Tim
Our goal was to experience the challenges that Silicon Labs’ customers experience and experiment with rapid prototyping and development techniques. We decided to build a Goldberg Machine that serves a beer as we can set up many different scenes to test various features of IoT devices including our microcontrollers, wireless, and sensor products. Lots of good ideas came out of our first meeting but not all of them were realized due to time constraints. We ended up spending 2.5 days to build, develop, and debug everything with 130 IoT devices.
“Ok, Google, Beer me.”
We kicked off the first scene of the Rube Goldberg Machine by ordering a beer through Google Voice and EM357 ZigBee board. You can see the full sequence on the video but I can introduce some of the most notable projects here.
The RF4CE baseboard transmits audio over the air to an RF4CE receiver connected to a PC. An application on the PC listens for that audio and when it gets a full packet it should perform speech recognition to check if the audio contains “beer me”. If it does it will trigger the rocket launcher to position itself and shoot at a balloon. The balloon is setup next to a sensor so that when it is popped it triggers the sensor to set the pin on a ZigBee on/off module which then notifies that gateway it’s ready for the next scene.
The gateway sends an MQTT message to the IBM BlueMix service, which is hosting a deployed Node-RED application. This app will route the incoming message, parse out the message string and send that string over SMS to a phone. The phone is sitting in a raised box such that when the SMS comes across it will vibrate and slide down to trigger the sensor to start the next scene.
The scene is activated over the ZigBee network by the ZigBee Gateway sending an HA On command to the first ZigBee node. This node is preprogrammed to set a GPIO high when it receives this command. This pin is connected to the EFM32 Starter Kit in which it triggers an interrupt. The EFM32 Starter Kit was programmed to generate a 38 kHz modulated signal that matches the Roomba IR Protocol. This signal was generated using a timer to generate the 38 kHz carrier and turning this on and off functions that were timed by another timer. With the Roomba IR interface, you could drive the robot forward, turn it sideways as well as start automated cleaning processes. In this scene we only used the FORWARD command. The IR control signal was then fed through a MOSFET to an IR diode which transmitted the signal to the Roomba.
Right in front of the Roomba there was a plastic tub with a glass of water in it. When the Roomba moved forward and hit the tub, the glass tipped over and the water flowed into the bottom of the tub, where the resistive water sensor was placed. The voltage output of the water sensor was read using another EFM32 Giant Gecko Starter kit. If the read value was above a threshold the EFM32 would set a GPIO high that signals to the connected ZigBee node that it should send an ON command to the ZigBee Gateway.
The scene is activated over the ZigBee network by the ZigBee Gateway sending an HA On command to the first ZigBee node. The first node is a ZigBee output module in series with the battery that activates the elevator carrying a steel marble up to the top of the track. As the marble travels down the track, four ZigBee input sensors are placed around various areas of the track connected to contact sense points that are tripped by the marble. The contact sensors trigger events within the gateway’s rule engine.
For the start, a ZigBee output module’s PA7 is connected to a 1k ohm resistor in series to the base of a 2N2222 transistor. The transistor straddles two sides of a piece of cardboard with separate pieces of copper tape on each side. The collector is wired to the plus side of the AA battery and the emitter is wired to the negative side of the battery. This allows the ZigBee output module to wirelessly control the elevator.
For the four input sensors, each ZigBee module was taped with mylar tape to the Space Rails nearby spots along the trail length. 30 gauge wire connects PA7 and GND from the module to each track rail where the wires were then secured with conductive tape. The steel marble as it hits the two pieces of tape, effectively shorts the two contact points triggering the input sensor. No input hysteresis / de-bounce electrical circuitry was employed so the input sensors were innovatively written to only accept one message per second to avoid flooding the gateway with redundant messages.
In this hack, the ZigBee Node ended up serving as a simple wireless IO controller, sending On/Off signals to the EFM32GG, and relaying when the beer was dispensed.
Due to familiarity, the EFM32 + Simplicity Studio was used for a majority of this hack. At its highest level, the code on the EFM32GG would wait for either a button press or the ZigBee HA ON signal to start a pour routine. Once this is detected, a pre-programmed state machine starts running, moving the arm to locations in 3D space that were pre-determined to successfully actuate the lever for beer pouring. Since complexity was not desired, a simple time-based state machine was used. Once the movement sequence was complete, a GPIO was toggled to signal to the ZigBee Node that the actuation had been completed.
To make future development easier and allow for more code reuse, a PCA9685 driver and Servo wrapper library were also developed for this hack.
There are some further improvements to be made in the future but we’re satisfied that we learned a lot about pros and cons of developing different applications with existing IoT solutions in a short time. Besides, this was a ton of fun for the team!