> If we are asking a customer or end-user to do something they wouldn’t naturally do already we are making it harder for them to use our product…
The iRobot product line barely works without rearranging and adapting all of your furniture and floor space. It can barely get over bumps in the floor, it’s too large to clean around chairs in a dining table or shoes near a door. It needs a lot of finicky maintenance. There are a huge number of limitations. I don’t know. If this was their motto, they obviously didn’t follow it.
Here’s a tip for you: Sell the idea of a useful robot. That’s what a Roomba is. They sit around gathering dust, ironically, or create so much toil to adapt an environment to them to make them effective, you might as well just sweep yourself. An idea of a useful robot, a narrative that it is just simple enough to be real but powerful enough to be useful, is valuable.
The post mentions several times how it's both costly for adopter to add infrastructure to support robots but also how other forces can make that infra already there e.g. how it costs money to install wifi in a warehouse but handheld scanners led to wifi being in them anyway (which was great for the robots too).
This reminded me of a quote about the future of automated driving (paraphrasing):
"We currently consider the following to be distinct and very different modes of transportation:
- car
- elevator
- train
At some point, those will all converge into a vehicle that can travel on roads (like a car), with other vehicles (like a train) and bring you up to a building floor (live an elevator)."
This seemed somewhat true to me until I considered two things:
1. The smart phone did something similar with a phone, television, computer etc
2. There is a scene in the movie Minority Report that does exactly what the author of the original quote described. [0]
The combination of another convergence device AND a fictional visual of what that convergent device would like really hammered home what the future might look like.
Re. infrastructure integration: it's always a cost-benefit analysis. I've worked at a robotics company where we integrated with doors and elevators. Doors was really easy, cost almost nothing, and didn't come with any regulations. Elevators, on the other hand, was a length process, required certified elevator technicians, and cost a lot of money. On the other hand, adding a manipulator to open manual doors is very difficult and costly (per robot), but adding a button-pusher for elevator buttons is not.
Too often I've heard: why make a robot open doors with it manipulator, just install a door opener on the door!
Fits the bill here exactly: making a better robot helps you scale. Only relatively recently that robots opening doors became a reasonable thing to ask fo, but not much robots yet that do this at scale I think.
The true answer is that it is hard, and requies very carefull analysis.
Putting a “door opener” on the robot is sometimes at no extra marginal cost. (Because it already has a manipulator to fullfill its job.) Sometimes it would make the robot cost prohibitive, and the correct solution is to use automatic doors. Depends on how many doors there are and how many robots, and what kind of robot and what kind of door.
Then again even if the correct solution in a particular situation is to add door opening manipulators on the robots very likely you would only want to support a few different kinds of handles. Imagine the complications of trying to support all door handles from baroque brass levers through modern spherical knobs to dogged doors the kind you find on a warship.
This is solid advice, particularly #4 is the reason I have started building my own bots. I do have one question though, how to design the production pipeline such that it is easy to iterate on the bot design with minimal disruption?
Rapid iteration at the component level would obviously require custom components, and maybe vertical integration, which clearly conflicts with point #1 about riding existing supply chains. But you can still iterate parts of the design that you more or less "have" to customize, such as the body material, axis geometries, and dozens of other factors I can't think of off the top of my head. The collected data can both be used to improve training and as input into the design iterations.
> If we are asking a customer or end-user to do something they wouldn’t naturally do already we are making it harder for them to use our product…
The iRobot product line barely works without rearranging and adapting all of your furniture and floor space. It can barely get over bumps in the floor, it’s too large to clean around chairs in a dining table or shoes near a door. It needs a lot of finicky maintenance. There are a huge number of limitations. I don’t know. If this was their motto, they obviously didn’t follow it.
Here’s a tip for you: Sell the idea of a useful robot. That’s what a Roomba is. They sit around gathering dust, ironically, or create so much toil to adapt an environment to them to make them effective, you might as well just sweep yourself. An idea of a useful robot, a narrative that it is just simple enough to be real but powerful enough to be useful, is valuable.
The post mentions several times how it's both costly for adopter to add infrastructure to support robots but also how other forces can make that infra already there e.g. how it costs money to install wifi in a warehouse but handheld scanners led to wifi being in them anyway (which was great for the robots too).
This reminded me of a quote about the future of automated driving (paraphrasing):
"We currently consider the following to be distinct and very different modes of transportation:
- car
- elevator
- train
At some point, those will all converge into a vehicle that can travel on roads (like a car), with other vehicles (like a train) and bring you up to a building floor (live an elevator)."
This seemed somewhat true to me until I considered two things:
1. The smart phone did something similar with a phone, television, computer etc
2. There is a scene in the movie Minority Report that does exactly what the author of the original quote described. [0]
The combination of another convergence device AND a fictional visual of what that convergent device would like really hammered home what the future might look like.
0 - https://www.youtube.com/watch?v=Vrxyr1CjiSM
Re. infrastructure integration: it's always a cost-benefit analysis. I've worked at a robotics company where we integrated with doors and elevators. Doors was really easy, cost almost nothing, and didn't come with any regulations. Elevators, on the other hand, was a length process, required certified elevator technicians, and cost a lot of money. On the other hand, adding a manipulator to open manual doors is very difficult and costly (per robot), but adding a button-pusher for elevator buttons is not.
Some good advice here!
Too often I've heard: why make a robot open doors with it manipulator, just install a door opener on the door! Fits the bill here exactly: making a better robot helps you scale. Only relatively recently that robots opening doors became a reasonable thing to ask fo, but not much robots yet that do this at scale I think.
The true answer is that it is hard, and requies very carefull analysis.
Putting a “door opener” on the robot is sometimes at no extra marginal cost. (Because it already has a manipulator to fullfill its job.) Sometimes it would make the robot cost prohibitive, and the correct solution is to use automatic doors. Depends on how many doors there are and how many robots, and what kind of robot and what kind of door.
Then again even if the correct solution in a particular situation is to add door opening manipulators on the robots very likely you would only want to support a few different kinds of handles. Imagine the complications of trying to support all door handles from baroque brass levers through modern spherical knobs to dogged doors the kind you find on a warship.
This is solid advice, particularly #4 is the reason I have started building my own bots. I do have one question though, how to design the production pipeline such that it is easy to iterate on the bot design with minimal disruption?
Rapid iteration at the component level would obviously require custom components, and maybe vertical integration, which clearly conflicts with point #1 about riding existing supply chains. But you can still iterate parts of the design that you more or less "have" to customize, such as the body material, axis geometries, and dozens of other factors I can't think of off the top of my head. The collected data can both be used to improve training and as input into the design iterations.