Interview w/ Trevor Blackwell from Anybots

Trevor and I have known each other for over a year now, and last Friday was the first time I got to be remotely present at the Anybots office. When I first met Trevor, the QB was already running and I got to test it out from his office – just before Yuri Milner showed up.

After close to a dozen iterations, using the newest QB was a much better experience – with the two-way video, standard and high-def video and even a HD zoom feature.  After a year of using remote presence systems, it was nice to see how Anybots have been improving their offering.

Aside from getting to test-drive the newer version of the QB (which I will post in a separate article), Trevor and I spent a good hour talking about how he got involved in being part of this RPS revolution.  What follows is a recounting of his past, present and the potential future.

Post PhD and post-Viaweb

Trevor’s story starts out at Harvard and Viaweb, the company that he and Paul Graham (of Y-Combinator fame) started and sold to Yahoo! back in 1998. When the company was sold to Yahoo!, Trevor began to grow tired of the whole “web thing” and was looking for new areas to explore. While he thought biotech was interesting, it did not play to his strengths. But robotics he saw as a potential and kept an eye out while he worked with Yahoo. Then, after leaving Yahoo! in 2001, he pursued his passion in robotics as Anybots.

Around the same time he sold his company to Yahoo!, Trevor completed his PhD thesis on Applications of Randomness in System Performance Measurement (see Paul Graham’s final ViaWeb press release announcing Trevor’s degree). From the abstract, Trevor’s work plays to the issue of adding some level of randomness to systems to ensure stability and robustness in performance control – in a way, providing enough noise to properly identify perturbations and be able to control the system with a greater understanding of its characteristics.

Trevor’s Vision

As Trevor began to pursue his interest in robotics, he began to have a vision of what we now are calling cloud computing/cloud robotics as well as maintaining people in the loop, rather than autonomous robots.

His first effort was creating a two-legged walking system called Dexter – using pneumatics for actuators, since at the time, pneumatics had a much better power/weight ratio as well as an effective cost/value characteristic. Even today, for $1000, he could purchase a solid brushless DC motor, or he could purchase 7 pneumatic vales to drive his system. Since Trevor was more about building a prototype than building  manufacturable system, he went for the two-legged pneumatic architecture. See the Dexter video from GetRobo here.

While Dexter was quite a fun mental challenge, it had very limited applications — and the only ones that could pay was in the military space.  Since he wanted to find a broader market, back to the drawing board he went.

The next iteration was the Monty, which leveraged his experience with pneumatics for the arms while creating a two-wheeled mobility system. The shift away from the two-legged system was predicated on experiences he had with Dexter where having legs was not a benefit in an office environment.  Wheels turned out to be a better solution since it could allow for physical disturbances (e.g, cords on floor, uneven surfaces) to be handled more effectively than the complexity of legs.  As seen on “How I Met Your Mother”, Monty was quite dexterous – allowing for teleoperation actions like making coffee, sorting things into bins, and kitchen “things”.

While Monty was quite a success in accomplishing a broader market opportunity, managing the remote operations required quite a complex control mechanism.  In addition, Monty would not be an easy  for the remote user and was going to be quite difficult to mass-produce. In addition, Monty was quite big and could be seen as a scary enough to be dangerous.

Anybots QA

From the Monty experience, Trevor took a captured a number of positive features – the eyes, the two-wheeled mobility system – and incorporated these features in a self-contained mobile platform.  This next version would be lighter, anthropomorphic and more easily able to engage in a conversation with people – both individually and in a group – focusing on connecting remote workers with their coworkers.. And so, the QA was born (video from GetRobo here).

The QA inherited many features from Monty – and some improvements: it was lighter (closer to 60 lbs), had a forward camera underneath the eyes (that were more decorative than functional) and a video screen that was planned to provide video of the remote person who was navigating the QA.  Once he had a few built, he went to work demonstrating it to both customers and potential clients.  He soon began to learn of new challenges.

While the QA was designed to be  anthropomorphic and less intimidating, the shape and style of QA was sometimes “too feminine” for some customers. The “rest mode”, which had the QA fold in half to come to a safe position seemed “awkward” and disconcerting. And when participants would try to talk to the pilot, they would find themselves having trouble looking at the LED screen due to its position on the “chest” of the QA.

Thus, after thousands of conversations with people during CES 2009, he and his team came back to Anybots and realized they needed another redesign.

Anybots QB

When Trevor and his team sat down after CES 2009, they pooled their thoughts and came up with a few more design directions:

• Portability was key – even tough the QA was close to 60 pounds, it required a large crate to deliver it from place to place and became more of a hassle to change locations since now it required a carrying case that was larger than the system.
• Needs a sturdy exoskeleton/infrastructure – while the QA was designed to be an elegant device, unfortunately the design turned out to be quite fragile. The plastic shell could not handle the normal bumps and dings of operation and could hamper normal operation.
• Different use case from video conferencing – when using the QA, it quickly became obvious that it was not a simple substitute for video conferencing (VC). VC is great for groups of people meeting in different locations and sitting to work together – one-to-one with lots of eye-contact. But with the QA, pilots were touring the office instead of sitting, conversations were more about focusing on a problem/whiteboard/part than on looking at each other.

Thus, the pivot for the QB began.

In designing the QB, a number of lessons were applied:

• Finding the balance on making it look to humanoid – while the curvy stand on the QA was excellent in cooling the CPU of the system, it seemed to cause consternation. Thus the QB would be more functional and accessible than the QA
• Better speed – in using the QA, the need for the pilot to move at an effective walking pace was important – no one wanted to be dragging the speed of the other conversationalists down.
• Obstacle avoidance – since navigation within a QA could be a challenging act while trying to have a conversation at the same time, an effective obstacle avoidance system should be invisible to the pilot and give them a sense of confidence in using the system. Reducing the cognitive load was key.
• Manufacturability – while making a single prototype is tough, making a manufacturable system is even tougher.
• Study but soft – ability to handle bumps and falls were also key to ensuring robustness of the system.

As the QB began to take shape, the team has been field testing the QB to learn from real-world experiences.  Today, the QBs that are going to customers are in their tenth or eleventh version – based primarily on the manufacturing and user experiences that support the QB.  Experiences like:

• Transporting the QB in the back of a car/in the trunk is a lot harder on the system than normal use – so improvements in the physical infrastructure have been made
• Customers really wanted to see the pilot, so two-way video has been implemented and supports HD-like video quality from the QB to the pilot.
• Customers were not as happy with the audio quality of the QB, so significant improvements have been made to improve the intelligibility of the pilot.

Today, Anybots is shipping out every new QB they complete to customers – and more orders are coming.  With the QB with customers and in the wild, Trevor and his team are learning how effective these remote presence systems can be.

Manufacturing Use Case: A Door, not a Window

In building their QBs, Anybots has been working with a contract manufacturer who is about fifteen minutes away from the Anybots HQ. Before having any QBs to use in both locations, the team would visit the manufacturing line once a week. While the time to drive to the manufacturing line was not long (e.g., 15 minutes), the team would only visit once a week, twice if necessary.  It seemed that the cognitive load for the interruption of work or having to drive to the location was enough of a deterrent to slow the progress in addressing various manufacturing issues.

But once the line and Anybots had enough QBs in to support both locations, each team would use the QBs to connect and work together on a daily basis – where the Anybots engineers could go with the manufacturing staff on the line via the QB and discuss the problem directly at the problem site.

When Anybots needed to discuss a change to the manufacturing process in their office, the line staff could easily log into a local QB and participate in the meeting without leaving their place of work.  Once the changes were agreed to, the staff would apply the changes immediately.

Interestingly enough, the biggest problem Anybots has in manufacturing has to do with a single partner – and they currently do not have a QB…yet.

When Trevor told me this story, it sounded like a page out of the Agile Software Development Process, the ability to have the business owner at the point of production to answer questions when they arise has improved the performance with very little cost and process load. By having the engineers using the QB, they have a door that they can engage from, rather tan a window as most video conferencing solutions would provide.

Will RPSes dehumanize us?

When we spoke about where the QBs could be applied, he suggested that in the world to come, all of the people on the top floor of the TV show The Office could easily be replaced by the QBs – where the staff could stay at home and not come to work. Then everyone in the top floor would interact via QBs versus in-person.

I asked him didn’t he think that could be somewhat dehumanizing – all of us having to interact though our QBs. He suggested that it would be more humanizing since now we would not have to go through the grueling effort of commuting, we could spend more time with our families, and be in an environment that we create for ourselves instead of the fluorescent sterile work spaces we trudge our way to. And from that point-of-view, I would have to agree.

What’s next?

As I spoke with Trevor, I noted a change from the first time we spoke.  When we first played with the QB in the Anybots office, Trevor was talking more about the technology and the features within.  On Friday, he was speaking more from the point-of-view of the QB users – more concerned about their needs and how the QB could address them.

He remarked that when he was building robots in the past (and the current QB), he had been quite head-down in the engineering – working to achieve the features that he wanted. But since the turn of last year, he has spent more time simply talking with customers and listening to their needs – which will drive the future development of the QB.

I asked what’s next in this space – and he commented that we were a long way from achieving having as many robots in the world as there are people. So, instead of predicting, he is focused on listening. He knows how to make robots in Silicon Valley; his customers know their business. He just wants to help them succeed.

Next post – a video montage and feedback on using the newest version of the QB.