Qualcomm sets up competition to stimulate IoT innovation

Large, profitable companies, once they’re firmly established in their markets, invest a lot of money in R&D to try to find next big things, new areas that will fuel the revenue growth of tomorrow. Qualcomm has done remarkably well in the mobile chip business and has spent more than $42 billion on R&D over the past three decades. More recently, the company has been focused on the Internet of Things (IoT), hoping to stimulate development that uses Qualcomm technology in this nascent, vast and amorphous market.

Last month, the company backed an IoT developer project that involved pitting two teams of technologists against each other in a competition called “Invent-off.” In a story of threes, the teams, consisting of three people each, spent three days together in a large room, starting with a basic set of tools (soldering irons, screwdrivers, vices, pliers and so on), computers, phones, sensors, a 3D printer, and a DragonBoard 410c each. The DragonBoard is a single board computer with a Snapdragon mobile processor and other system elements, such as I/O, memory and power. Ideally, the application would make use of data gathered by the sensors, which would be processed on the DragonBoard and perhaps interact with one or more phone applications.

After three days, a panel of three judges picked a winning team, which received a $25,000 grant to take their invention to the next level. Under the hashtag #WhyWait, Qualcomm filmed the contest in five episodes. The opening question was “If you could use technology to save a life, what would you invent?” The save-a-life part was one of the constraints on the inventors. Their invention had to plausibly be able to save a human life.

Now, no one can invent and build in three days something likely to save an actual life, but both teams did produce pretty good prototypes of their inventions in that time period. The Orange team came up with a working-enough prototype of a crash warning system for solo cyclists. The Blue team demonstrated a proof-of-concept for a snakebite-anti-venom drone delivery system, designed for India and other snake-prone regions. Why orange and blue? Go check your team schedules to see how those colors line up.

The teams reflected the generally narrow demographic found in the engineering trade, but there were two women, one on each team.

Claire Griffin, a mechanical engineer fresh out of college, was the hardware specialist for Orange team. Youngest of the lot, she brought a feisty attitude to the project, despite her anxiety at the contest’s being her first “high-stakes, low-time” competition. A recent graduate of Stevens College in Hoboken, N.J., Griffin works as a civilian contractor for the Navy, lives in Philadelphia, and is daughter of an FBI agent. She originally set out to study medicine, switching to mechanical engineering while still absorbing biology. Not at all intimidated by being a woman in a man’s world, she characterized herself as “bubbly” most of the time, but admitted that she can go from there to “claws out” in an instant. Prior experience working on a construction site certainly helped her learn to deal with unvarnished maleness, although she noted in an interview, “I’ve never had an issue with anyone being disrespectful.” She applauded her parents for “being supportive of every crazy thing I’ve tried to do” and cited stints in theater, band and Shakespeare competitions. “Right now I’m completely happy with the mechanical side,” she said, but admitted that electrical engineering has some allure and Silicon Valley is “not unappealing.”

Hanna Sarver, a software engineer teaching and pursuing a second master’s degree at Berkeley, did much of the coding for Blue team. The fact that she grew up in Silicon Valley with two parents who worked in tech makes her story seem kind of familiar. She discovered her interest in programming in her second year of undergrad, when she took up Python, finding it “intuitive” and “powerful.” She described her experience in the very male world of Silicon Valley as positive, calling her working environments “supportive.” She did qualify that by saying, “There are always so some small occasions where [gender] intrudes, but overall I’ve had a positive experience working in engineering.” Some of her projects have included wonky areas like network infrastructure, operating systems for routers, and networking protocols.

Orange team was led by Mike Senese, a manic tinker and editor at Make magazine who plays himself on TV. Trey German, a soup-to-nuts computer engineer with a broad range of skills from actual metal to coding, handled Orange’s software.

The tiller on Blue team was helmed by Ian Ingram, a robotic artist or an artistic roboticist, whichever you like, who has been a fellow, lecturer or resident (sometimes in combination) at a sequence of institutions in Europe and the United States over the past decade. With a pair of master’s degrees (one science, one art) from MIT and Carnegie Mellon, Ingram brought both whimsy and practical experience to the table. Mike Ogrinz — whose formal title, Senior Vice President, Bank of America, belies his multifaceted role as an R&D project manager and inventor there — looked after hardware duties.

Although they had their roles, team members on both sides approached their projects collaboratively, with everyone pitching in as needed. During the judging at the end, the Qualcomm representative, in her preamble, just threw out on the table that she’d be happy to work with any of them as colleagues. So, in that sense, it was a victory all around.

As the starting pistol went off, competitors were trash-talking about “ideas that can change the world” and “interesting ways to solve a problem.” Both teams realized that their problem domain was somewhere in the zone of medical applications. But from there, they took decidedly different approaches. Orange was fast out of the blocks, getting down to building and soldering right away, while Blue spent a lot of time just talking about ideas.

At first, they both focused on kids, trying to keep kids safe. Despite making technical progress hooking this up to that, Orange was concerned that the ideas that popped up readily lacked wow. The team took a short walk outside to gain some perspective and found itself following a thread of people being incapacitated while engaging in solo sports like paragliding, cycling and skiing. From there, it was a short hop to the bike safety system, which would use a helmet-mounted accelerometer to detect a crash, then call emergency services and set off flashing lights and a siren located in the main unit on the bike. Once back inside, the team set right to work, with Griffin working on the case, Senese figuring out the sensor mount, and German writing the code.

Blue first came up with an abstraction, a “Tricorder” (using a Star Trek reference for something that can sense, compute and record — modified to substitute “communicate” for record), and then went down a long road of pondering sudden infant death syndrome (SIDS), acute cardiac arrest, addiction-related loss of consciousness, hurricane intensity detection — all the while looking over their shoulders with increasing anxiety at Orange, which was busy beavering away on the other side of the room. Ingram had been surprised to learn not long before how many people die of snakebites in countries like India, which has a lot of poisonous snakes. Something that could help snakebite victims might be good, but he wasn’t sold on his own idea. He played devil’s advocate to himself, but was out-argued by his team members. So, snakebite detection and treatment system it was. The system would assess the victim’s vital signs for patterns indicative of a snakebite, transfer health data to medical professionals, and — in a leap of technological faith — launch a drone to deliver anti-venom from a depot to the field.

After calling a doctor to find out what one vital sign would convey the most information, Blue decided to go with heart rate. The system would use GPS for location, process the data gathered by the heart-rate sensor on the DragonBoard, connect to other devices and the internet, and display both victim location and the nearest poison control centers. Sarver wrote an Android app to communicate with the drone and autonomously direct it to deliver the anti-venom.

Now it was a horse race. Griffin used a 3D printer to make a case that would mount on the bike frame. Ogrinz got to put some of his project management skills to work, redirecting his teammates when he found them both working on the same facet of the project. Blue got the drone to take off and land. Orange got the LEDs firing in an attention-getting pattern and hooked the sensor-actuated app to connect to the Internet.

As the clock ran down, Orange turned to the presentation, and, perhaps reflecting Senese’s show biz background, it was pretty slick. Blue scrambled across the finish line without ever having tested its app end to end. The first full test would be before the judges. Sarver said, “The time and resource constraints helped define the project better.” Griffin noted, “In the last 45 minutes, the adrenaline started pumping.”

Whereas Orange turned out a whole road show, Blue had to do a lot of arm waving to describe parts of the system that didn’t exist.

During the Orange demo, Griffin crashed the bike on purpose, but the batteries flew out. German finally conked the helmet hard enough to set off the siren and the LEDs. Senese had stats on deaths and injuries from biking, boating, backpacking, and skiing. The physical prototype was pretty polished, thanks mostly to Griffin’s maker skills.

By contrast, Blue barely had time to figure out what to say, and the demo was mostly about getting the drone to take off and land. But Blue painted a picture of how the fully implemented system might look.

In the end, it came down to processing, the thing that the Snapdragon chip was doing on the DragonBoard. In Orange’s case, it was just logging the sensor data and relaying messages to various places when a threshold was hit. In Blue’s, it had both cloud and local functionality (in case of no connection) and did the heart rate monitoring locally, sending only summary information to the cloud component. Based on ambition, application complexity, and thorough use of DragonBoard resources, the win was awarded to Blue.

Mike Roberts, a senior director of product marketing at Qualcomm with responsibility for developer marketing efforts, spoke for the company on the contest. Asked why Qualcomm decided to go this route, he described a changing landscape. In the past, customer relations were a matter of holding hands with a few large telecommunications companies and device manufacturers. With the changing nature of the marketplace, Qualcomm needs to engage a whole new set of potential buyers now, many of which are quite small. The DragonBoard was created to open up the power of Snapdragon to developers with potentially limited resources. Roberts’s main pitch to maker-style developers who might otherwise use a Raspberry Pi or Arduino platform is that DragonBoard offers a path to scale to a commercially viable level. The company can bring in resources all the way up to contract manufacturers if the product-market match justifies them. He described the purpose of DragonBoard as “the democratization of hardware.”

So, aside from finding and funding a potential app (Blue does get the $25,000 for the next step), the contest also highlighted the developer program. If that crash-warning system or anti-venom dispatcher were deemed suitable for a broad audience, a developer could move from the development platform to a real product over a well-traveled path. An IoT app that fits with DragonBoard functionality will have both local and cloud components. A lot of data spins off remote sensors, but most of it should be kept off the internet. As Roberts put it, “edge intelligence” is important to many IoT apps.