Lessons After the Failure of Anki Robotics

Anki’s Vector (above) was created using the Qualcomm Snapdragon 212 , an SoC originally designed for mobile devices like smartphones. Vector was built (Image source: Anki Robotics)

Anki Robotics, the company behind the popular consumer social robot Cozmo, and its successor, Vector, was shuttered and laid off its entire staff in late April. But while the company is no longer shipping products, the lessons learned from creating a consumer robot from a smartphone SoC are still valuable to any embedded engineer or developer.

Daniel Casner, a robotics systems engineer, and former senior hardware engineer at Anki, took the stage at the 2019 Embedded Systems Conference (ESC) in Boston to talk about the development of the company’s flagship robots and the takeaways that can be gained for robotics and IoT developers.

Define What a Consumer Robot Is

Casner told the ESC audience that, first and foremost, Anki’s strategy was to look at consumer robots as products in and of themselves and not platforms. “A lot of companies say they’ve created a consumer robot, but what they’re really doing is releasing a platform and relying on third parties to create the worthwhile content,” he said. “People use the iPhone as as an example of why platforms are great. But remember when it was first realized there was no App Store. It relied entirely on a set of built-in apps.”

At the end of the day Casner said, as buzzword-y as it sounds, robots are IoT devices – albeit ones with more moving parts and interactions with the real world than others. For anyone that thinks otherwise, Casner argued there are quite a few similarities between robots and what are thought of as typical IoT devices: Both are spending a ton of time processing sensor data; they’re network-connected devices; they’re largely headless (having no direct user interface like a touchscreen) and largely unattended; they have a power envelope that differs from a typical smartphone; and they occupy a low-volume market relative to mobile.

Beware of Smartphone Assumptions

While many chip vendors are beginning to open up IoT divisions to service these smaller markets with chips usually reserved toward mobile products, Casner said there are pitfalls and challenge for developers looking to leverage smartphone SoCs, particularly with robotics.

Smartphone SoCs come with packed-in assumptions that Casner noted can lead robotics engineers into trouble:

First, “they assume there will be a display connected to a display peripheral and that activity revolves around user interaction,” he said. However, robots like Cozmo and Vector have no direct user interaction, and instead rely on voice control or commands from an external controller (in Anki’s case it was the user’s smartphone).

Thermal dissipation was another issue that was a larger problem than anticipated, particularly with the more high-powered Vector robot, Casner said. “Mobile SoC’s assume they can be pressed against the back of a screen and the screen will dissipate heat,” he said. Without a screen there’s nothing to account for the extra heat.

Mobile SoCs are also geared more toward low duty cycles – you wake the device up to handle a command, it handles it, then goes back to sleep. Robots on the other hand, often need to always be on and monitoring.

Tied into this, Casner said are assumptions around the sensors connected to mobile SoCs. Many mobile SoC’s only support two cameras, for example (one for the front of the phone, and one for the back). Robotics needs more. Vector uses four cameras, for instance.

In the smartphone SoC world, sensors are for user interaction, taking better pictures, and a few health and fitness applications, Casner said.

There are also challenges around the user and content security model to overcome. “If you want to encrypt the disk [on a smartphone] you can rely on user to enter a password,” Casner said. “But you can’t do that with a headless, unattended device – you’re not going to enter a password on your thermostat every time your power goes off.” He also noted that TrustZone is a form of DRM, more concerned with the security of content than anything else. “If you’re not watching Netflix on your robot it’s not helping,” he said.

Choose Your Operating System Wisely

Casner joked to the audience that he and the Anki teamed “tried every operating system so you don’t have to.” Anki eventually settled on Embedded (Yocto) Linux for its robots, but getting there involved a lot of trial and error to find the right OS to fit its needs.

He outlined the pros and cons of several popular options for IoT devices and consumer robots:

Android

“Smartphones run Android and Soc’s are made for Android,” Casner said. Silicon vendors put Android first and QA testing is done on Android.

But Android hasn’t been very successful outside of smartphones (anyone remember the Ouya gaming console?). Even products like tablets and TVs haven’t been able to successfully or satisfactorily implement Android. “[Android] has never caught on in a big way… it’s pretty much just for cellphones,” Casner said.

Android also works on a interactivity-based power model that may not be suitable for most robots. The OS also has comparatively low reliability and relies on the user to fix errors such as a lost WiFi signal. And since the OS is designed very much around the roughly two-year lifecycle of cellphones, there’s no need for its developers to tackle certain issues that could be critical in robotics applications.

Android is also all about apps, which flies in the face of Anki’s “robot as a product” ethos.

Android Things

Android Things is the IoT adapation of Android. But Casner said it was “not mature enough when we tried it.

“[Android Things] is still fundamentally headed – even if you’re using it to build a headless devices it’s still rendering the Android logo on a screen all the time in the background.”

While the OS is intended for companies that want to built hardware but not write a lot of software, Anki ultimately decided Android Things was too much overhead and not enough payoff. “And additionally, to make it work we needed support from the vendor that just wasn’t there,” Casner said.

Brillo

Brillo is the OS developed for Google’s OnHub router (“Another product too early for its time,” Casner said). Brillo was a pre-Android Things attempt to make an IoT Os out of Android. But in doing so Casner said they threw the baby out with the bath water.

“ What they ended up with was a Linux OS with a really weird C/C++-based user space that no one really knows how to program for.” Brillo ended up with a huge learning curve and was never officially released.

Firefox OS, SilkOS, and Chromium OS

Other options like Firefox OS and SilkOS lacked support or were officially discontinued (support from the open-source community not withstanding). And while the Anki team was able to use Chromium OS as a reference for building other mechanisms, the actual Chromium OS library, libchrome, proved to be too large to fit on their devices. “Unless you’re building a Chromebook, Chromium is probably too heavy for you,” Casner said.

Anki eventually found its solution in Embedded (Yocto) Linux, a Linux build intended for headless and unattended devices. Yocto has also been gaining traction among the IoT groups of silicon vendors. Casner said the Anki team found Yocto to have an easier learning curve than Android, was more practically open source than Android, and it was built around the idea of replaceable pieces.

Embrace Mobile SoCs…And Their Challenges

Casner was optimistic however that future robotics developers won’t have to go through many of the same pain points as Anki. “The ecosystem is changing,” he said. “We started down this path two years ago and a lot has changed in that time. Silicon vendors are targeting IoT and edge computing more and more. [IoT] doesn’t have the volume mobile has, but vendors think it’s going to and they’re starting up IoT business units.”

Those same vendors are also starting to realize Android is not appropriate for IoT and are adding embedded Linux support into their SoCs, he added. “There’s starting to be a few targeted IoT chips, but it’s not a priority for R&D, and there’s nothing specifically for robotics.”

Given that, Casner believes mobile chips will still probably be a cheaper option for developers simply because the volume of mobile drives the price down. He recommends engineers go for mobile over purpose-built, even when dealing with sensors.

He also advises repurposing peripherals. He cited the GPU as a prime example. In a smartphone the GPU is there for games and 3D textures, but it a robot it can be leveraged for artificial intelligence computing applications.

All said, Casner believes the best way to deal with these challenges is to accept them and be prepared. An unattended devices is even harder than a headless one, and a robot combines the two. How do you handle errors, diagnostics, and reporting, for example,z on a device with no user interface that has to function on it’s own? “Embedded software is hard,” Casner said. “Most likely if you’re designing a robot or IoT device nobody is solving your problem…you have to think outside of the box.”

For more on Anki Robotics read our feature article that delves furhter into the development of its Vector and Cozmo robots.

Chris Wiltz is a Senior Editor at  Design News covering emerging technologies including AI, VR/AR, blockchain, and robotics.

North America’s Premier Battery Conference. Join our in-depth conference program with 70+ technical sessions in eight tracks covering topics from new battery technologies and chemistries to BMS and thermal management.  The Battery Show. Sept. 10-12, 2019, in Novi, MI. Register for the event, hosted by Design News’ parent company Informa.