Why telepresence robots failed (and how bad UX killed it)

This article summarizes an episode of Automated Podcast’s video series featuring University of Massachusetts Lowell professor Holly Yanco.

Photo credit: X Square Robot

For decades, the robotics industry has been trying to create robots that can think for themselves. But Holly Yanco, a professor at the University of Massachusetts, argues this goal is not the right one. Instead, she believes the real goal should be to build “super capable” machines, not thinking ones. This shift in perspective explains why many robot projects fail. People don’t trust them because they promise a vague idea of artificial intelligence instead of being reliable.

The expected help that never came

Telepresence robots, devices that enable a user to maintain a virtual presence in a remote location, were expected to become popular during the Covid-19 pandemic. With offices empty and travel banned, the situation seemed ideal for a technology that promised to give people a physical presence from far away. It was a chance to prove they were useful.

But the growth never happened
Yanco says, “After Covid, what we saw is that [telepresence] just didn’t really find its niche. We all went into Zoom. There was no point to have a robot in a place when nobody was in those places.”

A reality check for telepresence
The shift toward remote work showed a problem with the robots’ main purpose. The situation that should have supported them instead reduced their usefulness.

Yanco explains, “That was a strong indicator against telepresence robots, which was kind of unfortunate because it felt like the field was moving along. And with Covid, it just wasn’t a use case for them.”

Real progress comes from failure

To build more reliable systems, Yanco’s method is unusual. Instead of focusing only on what a robot can do, she spends as much time discovering what it can’t do.

The art of breaking your own work
Yanco notes, “I kind of have this dual side of my world of thinking about how do we build better robots, and then how do I break them. If we can’t find where the failure points are in the lab, we’re going to find out where they are once we deploy them.”

The Bay Area is not the real world
Running a machine for thousands of hours means little if the test conditions don’t reflect real life.

Yanco argues, “When Google first came out with their automated car, they would say, ‘We drove X hundred thousand miles.’ That’s great. But if they’re doing most of their driving in the Bay Area, that’s very different from driving in New England.”

A plan for building capable robots

Yanco’s method is about building systems people can depend on. The goal is to find and share what a robot can do in the real world, not what it might do on its own.

• Capture: Find weaknesses by testing in difficult, not perfect, places. A robot that works in one city may not work in another.
• Cluster: Group these problems into tests you can run again and again. This helps compare different robots and find exact reasons for failure.
• Prioritize:  Find every problem in the lab. This is better than driving for thousands of miles in easy conditions.
• Prototype: Build and test to learn a system’s limits. This helps people trust the robot because they know what to expect, instead of just hoping it works on its own.

Redefining the end goal
The industry’s focus on the word “autonomy” confuses engineers and customers. A better goal is capability, meaning a robot can be trusted to do a specific job.

Simplicity prevents future problems

How bad user experience killed a product