"We're going to Ohio!!" My colleague Joelle said as she looked up from her computer screen and smiled at me. "We are going to Ohio!"
"OK, cool," I said. "What are we going to do in Ohio?"
On that day, we got the go-ahead to attend one of the biggest developer conferences in the US — Codemash. It is a unique event that gets developers together to learn about current trends and methodologies across different platforms and development languages. Of course we were very excited and began to plan immediately.
We decided to have three sections for our booth space: an ideation space to generate ideas with the visitors, a workshop corner for hacking and an element to generate attraction – something playful, but still IoT-related.
Boats, boats, boats
Since the event took place at Kalahari Resorts, a gigantic water park, our first idea came easy: let's build boats! Boats are perfect. They float and they are awesome. But then we thought that having developers take their boats equipped with a Raspberry Pi and lithium batteries to the pool might cause some complications. We know that at a conference, connectivity is already questionable, but in a waterpark?
After racking our brains for a while, we decided to go for slot car racing. Fun as well and operational without swim trunks!
Combining racing and heart rate
The idea was simple. We would have the players play a slot car racing game. The top speed of each racing car would be limited to the heart rate of the player. The faster the heart rate, the faster the car could go. The player would still be able to control the car with the typical Carrera controller. Since IoT is about getting data from different sources (here a pulse sensor and a controller) to serve a purpose (racing), this game was the perfect fit for something that demonstrated IoT while also being fun.
As expected, like most hardware products, this idea quickly became bigger and more complex.
Overview of the moving parts
Any project that involves hardware consists at least of the following: hardware (sensors, actuators, microcontroller, Firmware), connectivity and application (user interface, database).
For sensors we decided to use optical pulse sensors. Placed on a finger tip, they measure the minimal changes of opacity when the heart pumps blood into a finger. It provides an analog signal that can be read by the analog input of a microcontroller. We hacked the controller of the Carrera tracks and connected both to analog inputs as well. To sense the cars, we build IR light barriers under the tracks and connected them to interrupt pins. Interrupts react even if the microcontroller is currently doing something else.
For outputs we placed two LEDs to show the pulse and a motor controller shield from Pololu to output power to the tracks.
For the microcontroller we used the Arduino UNO R3, a very robust Atmega board complete with analog-to-digital converters and a wide range of add-on hardware (shields).
Without going into too much detail, after some complicated approaches to catch the pulse in a dynamic way, we learned (again) that the static way that the code example of the pulse sensor provided was very efficient. The maximum speed consists of two parts: a minimum speed that works if someone has no heart and a part that depends on the current pulse. The output voltage is defined by how far the controller is pressed and limited by this pulse-dependent maximum speed.
To exchange data to the application we decided to use the UART serial communication via USB. In our case, it was the most stable way, but it could be substituted by any other wireless communication. We built a small protocol on top.
The application was built in Processing, a Java-based IDE. The main part is the state machine going through the following states: Enter player Names > Player name screen > Starting lights > Racing screen > Winner screen > Highscore.
The design was made to look like a retro arcade game, which was a real hit among Codemash participants.
Our tip: don't do hardware
Hardware sucks! In the end, I always arrive to this conclusion. You can't compare hardware development with software development. There are just so many variables as to why something doesn't work and the debugging time is ten times higher. My advice: don't do hardware!
But in the end, everything turned out fine. The racing game attracted lots of visitors and many of them brought their families as well. As a father myself I can confirm: if you can keep the children busy, the parents can have a lot of time to chat ;-)
I'm very happy that we could be at Codemash to help build something vivid and meaningful in the world of IoT.
A quick note
This project is just a proof of concept. Our racing track concept is just 0.2% of the way to a real product. It's an early stage prototype to test with users and is not intended as a full-blown product that's ready for mass production. However, for the exhibition it was great.
If you're interested in equipping your racing tracks with this software, we're happy to share what we did with you via Github. And if you tried the racing track out during Codemash, please remember to share some photos with us. If you need assistance, don't hesitate to get in touch: email@example.com
Interested in the Geeny platform? Join us!