Lessons from the Hackathon at the 2016 AT&T Dev Summit
First things first: If you’re going to a Hackathon it’s best to get your team together in advance to establish roles and hash out a concept. Many hackathons have themes, so it doesn’t hurt to prepare accordingly with a decent idea. And it’s good to get a mix of skills and personalities. Team Luxoft led by Jim Darrin settled on the It Can Wait category for the 2016 AT&T Dev Summit Hackathon.
Making a concept
Our concept was pretty simple: make a product to stop texting while driving. In case you need to know about the dangers of driving while texting, I recommend Waren Herzog’s heartbreaking documentary about about the problem, “From One Second to the Next.”
In 2012 AT&T had an entire hackathon devoted to ending texting while driving, with a $20,000 grand prize going to the Rode Dog app. Rode Dog barks at you if someone in your group spots that you’re texting while driving — not exactly a real solution. There are other apps out there; Google Play shows dozens of apps related to putting your phone into drive mode.
It’s obviously a big problem that needs solving.
The technical difficulty is detecting whether a phone in motion belongs to the passenger or the driver. GPS signals aren’t precise enough, and you can’t expect the driver or passengers to always let the app know who is who. There are some farfetched ideas, like Apple’s patent to visually recognize a driver in a moving car. Meanwhile Cellcontrol has neat windshield mounted gadget that detects driver and passenger zones, but it costs $129.
Our team wanted to create a cheap and automatic solution to prevent texting while driving.
With all this in mind, we grabbed an Arduino board with Bluetooth and theorized it could be plugged into the car’s ODB port, which is usually found near the driver’s steering wheel. With a little bit of modulation, the low energy bluetooth signal would form a 3–4 foot bubble near the steering wheel. Once the bluetooth bubble was activated, all we needed was an app that could connect to the bluetooth signal and then disable distracting apps. Every time you’d pick up the phone and move it towards the steering wheel our app would run interference.
We named our app Odysseus, after the sea farer’s experience with The Sirens. The Sirens were notorious for tempting sailors with their singing towards a rocky demise. Odysseus desperately wanted to find out how the sirens sounded without crashing his ship. So he ordered himself lashed to the mast after pouring wax into his sailors ears. Temporarily deaf, the sailors piloted safely through the deadly straights while incapacitated Odysseus listened to the tempting songs. Today psychologists call Odysseus’s actions a commitment device.
Day 1: Building Odysseus
We arrived at the Palms Casino on January 1st, 2016. After the big crowded kickoff in the main hall, and visits to the vendor booths, we found more categories to compete in: M2X API, AT&T Data Rewards API, and the Intel Edison Board. The two APIs looked useful because they could be used monitor and reward good driving habits. The Intel Edison board offered a $5,000 best-of prize, so we decided to give it a try.
The Edison board proved tricky to setup in beacon mode. Yuri and Kris agreed the equivalent Arduino was better, faster, and cheaper to work with for this concept. By the end of the day the Edison board finally cooperated, making the nearby phone go into Odysseus mode.
The M2X API was recording the interactions between the Edison and the phone, and we could send out data rewards based on good driving. Finally, Kris and Yuri built a website which would allow you select which apps would be affected by Odysseus mode. I put together the presentation and we got some rest around 1am.
Day 2: Judging
At 11AM a panel of judges came by and gave us 3 minutes to present. Everything worked well and we were relieved to be done. We decided to relax at the casino with some drinks. In hindsight relaxing wasn’t the best idea. More on that later.
By 4PM we knew we were in the top 20. Out of 120+ teams that felt pretty good. We grabbed our gear and went back to the main hall to present on stage. Here is where ran into trouble.
The stage was packed, and teams ready to present were milling on the edges. Kris had to power up the Edison board, set it to beacon mode, and then test the connection with our Android phone. Several Edison boards appeared on the list, all broadcasting the same ID. Kris tried setting a unique name to avoid this problem, but it wasn’t broadcasting correctly.
So minutes before our presentation we realized we could not demonstrate the phone going into Odysseus mode near the Edison beacon.
Luckily we had a presentation on hand and Yuri jumped on stage and walked the crowd through the slides. Check out the video:
Yuri did a great job and got good applause, but we hung our heads when our hardware demo refused to work. We thought we had blown it. Nonetheless our concept was tested earlier by the judges, and the codebase was validated. In the end we placed 1st place in the “It Can Wait” category, which netted our team $5,000.
We came away from the hackathon happy that our idea actually worked and that we placed 1st in the It Can Wait category. We could have improved our odds with a little more preparation. Presenting on a crowded stage in under 3 minutes is a completely different experience than working from our quiet and technically predictable workspace.
Alternatively, we could have used a backup hardware solution with the trusty Arduino. Clearly these are some 20/20 hindsight musings here, but take it as a lesson when competing in compressed time frames. It doesn’t hurt to be over prepared.
Here’s what we learned:
- read the rules before arriving
- target specific categories to maximize cash winnings
- ask for free hardware from vendors
- stress test your product before going on stage
- have a backup
- create a slideshow presentation in case all else fails
- find out the circumstances of a stage presentation
- rehearse your presentation
See you next year AT&T Hackathon!