The robots are coming… but when? (Ep 497)
If there’s one thing humanity needs right now, it’s robots. Our oceans need cleaning up, our roads need maintenance, and many restaurants and farms can’t find enough staff. We technologists better get building the benevolent robot custodians that are ultimately going to make our lives better by filling potholes and picking up our trash.
You’ve likely been hearing this same robotics keynote at conferences, promising useful automata that will walk among us, for the last 20 years or so. So how come we don’t see them anywhere in our everyday lives?
Today’s podcast episode explores why the barrier to entry for developers in the robotics industry is so steep. Our guest, Eliot Horowitz, CEO & founder at Viam and former founder and CTO at MongoDB, shares his vision for a future in which it’s just as easy for developers to create robots as it is to craft a smartphone app.
Episode notes:
Despite our long held fantasy about the future of robotics, the technology is still far from mainstream.That’s because the amount of effort needed to get hardware to do useful things at scale is…well…hard.
When Eliot started Viam, his goal was to address this challenge by creating software that supports a range of hardware builds out of the box.As the company explains – “we’re addressing these issues by building a novel robotics platform that relies on standardized building blocks rather than custom code to create, configure and control robots intuitively and quickly. We’re empowering engineers – aspiring and experienced – across industries to solve complicated automation problems with our innovative software tools.” Viam announced the release of its public beta earlier this week.
While Eliot elaborates on his vision for Viam, Ben reflects on his time covering drones for The Verge and working on robotics at DJI.
Inquisitive badge winner, Neeta, gets props for asking well-received questions on 30 separate days.
Follow Ben and Eliot on Twitter.
Tags: automation, mongodb, robotics, Viam
2 Comments
I haven’t listened to the audio, but… Oceans need cleaning by robots? So we can throw even more plastic we want in the oceans and not have to worry about it?
Once these robots collect all the plastic from the ocean, then what do we do with the piles of collected plastic? Let’s just do that right at step two, and cut out the middle procedure of throwing plastic in the ocean. Congratulations, you have just discovered why we throw plastic in the ocean. You have also just redefined the problem, and now we realize, robots aren’t the answer.
The robots are already here, and they have been for a long time. That is why we sit in a chair in front of a computer not producing food, yet we still get to eat.
Quite the opposite. I am a senior roboticist. The barrier is component cost. Solution space and software for robots is very easy and already widely available. Machine vision… piece of cake with OpenCV. Object identification and classification also easy with tensor flow and media pipe.
As cost continues to fall in robotic components the proliferation will grow as such. For instance a mid line Yaskawa DDR motor and its amplifier still runs for ~1k. This is down from 4 k, 10 or so years ago. Cameras and lenses for instance are also very expensive. An off the shelf basler or mako will run 500 for the camera and another 200 for the lens. This all means a quality robot which consists of a serial failure mode if any component does not operate to cost as little as 10k MCost for a 3 axis solution. Take for instance UR10e’s they run for 40-50k for the 6 axis and no camera. But!!! This cost map was 2-4x higher across the board for same performance 5-10 years ago and like such before that. In 5-10 years this cost mapping will break under price points that are affordable for consumers and then you will see them everywhere like iPhones.
There is a very good talk on this recently from Dr Mark Yim from the University of Pennsylvania, GRASP laboratory. Give it a look see when you get a chance.
Modularity is not the answer if the goal is to reduce cost modularity pads significant cost to get same solution as purpose built. So I think these guys are not really on the right path.