2 ms·

Is the basic idea for third world operators to cheaply run humanoid fronts? How will you deal with lag in places of the world where internet might not be fast

Is the basic idea for third world operators to cheaply run humanoid fronts? How will you deal with lag in places of the world where internet might not be fast enough but wages are cheap enough? Or, are you planning on going into dangerous services, and replace a human? How are you planning on making the bot rugged? Also, exactly how many pixels do you expect to ship? Deployed robots in Iraq send a highly compressed 320x240 color stream -- maybe two. There is an awesome system by Chatten Associates that might be relevant to Anybots. They have a fast pan-tilt camera with analog broadcast to minimize latency to a tele-operator. The operator has a head mounted display with gyros, and here is the kicker: the gyros control the pan-tilt. This means that the camera looks where the human is looking. It's amazingly immersive. Even a small field of view camera works well. http://www.chattenassociates.com/docs/bob.html http://www.chattenassociates.com/docs/bob.html Network latency is an even bigger problem with this kind of system. Operators vomit with lag greater than ~150ms.

ecuzzillo 19y ago
On lag: I would imagine that the first teleoperation centers would come from places where sufficient internet connectivity was already in place, and then as the market grew, it would become profitable for service companies to create internet infrastructure in places where wages are lower. Yes, we envision the first applications being dangerous services. The idea is, at any given time, for any given task, there is a ratio of how long it takes a teleoperated robot to do the task to how long it would take a human. Currently this ratio is maybe 10:1, and a good part of the work in the next couple of years will be reducing that ratio. It's likely to be cost-effective, though, to send robots to dangerous places even when the ratio is high; then, as the ratio nears 1:1, it becomes reasonable to use such robots for household tasks. Then, as we develop autonomy for individual tasks, the ratio will start to go below 1, because an operator can set a robot on one task, switch robots, set a second robot on a task, etc. We haven't really looked into ruggedizing the thing, partly because Anybots eventually wants to mostly be in the software end of the industry, rather than manufacturing hardware. The point of the prototypes is to provide a platform to prove the quality of the software, and then find manufacturing partners to help make the robots bulletproof and production-ready. Number of pixels is similarly up in the air, depending on how many we think are necessary to accomplish a given task. Monty's current setup has an array of fixed, cheap cameras, because it's easier to just have a whole bunch of cameras than to have a complicated expensive pan-tilt operation with one camera. One way of reducing the required bandwidth would be to create an option just to ship a user-selected region of the panorama, the one relevant to the current task. For navigation, maybe we could downsample the panorama to provide a wide-angle view of the scene. (The above is all speculation, by the way.) I'm not totally sure I agree that latency is so terrible. Currently, our operators mostly move the arms pretty slowly, to avoid nonintuitive dynamic effects of pneumatic actuators. I would imagine that if you had to move your arm and wait a fraction of the second for the visual feedback, it wouldn't be so terrible. It would slow things down, but I don't think it would kill you.

ecuzzillo 19y ago

On lag: I would imagine that the first teleoperation centers would come from places where sufficient internet connectivity was already in place, and then as the market grew, it would become profitable for service companies to create internet infrastructure in places where wages are lower. Yes, we envision the first applications being dangerous services. The idea is, at any given time, for any given task, there is a ratio of how long it takes a teleoperated robot to do the task to how long it would take a human. Currently this ratio is maybe 10:1, and a good part of the work in the next couple of years will be reducing that ratio. It's likely to be cost-effective, though, to send robots to dangerous places even when the ratio is high; then, as the ratio nears 1:1, it becomes reasonable to use such robots for household tasks. Then, as we develop autonomy for individual tasks, the ratio will start to go below 1, because an operator can set a robot on one task, switch robots, set a second robot on a task, etc. We haven't really looked into ruggedizing the thing, partly because Anybots eventually wants to mostly be in the software end of the industry, rather than manufacturing hardware. The point of the prototypes is to provide a platform to prove the quality of the software, and then find manufacturing partners to help make the robots bulletproof and production-ready. Number of pixels is similarly up in the air, depending on how many we think are necessary to accomplish a given task. Monty's current setup has an array of fixed, cheap cameras, because it's easier to just have a whole bunch of cameras than to have a complicated expensive pan-tilt operation with one camera. One way of reducing the required bandwidth would be to create an option just to ship a user-selected region of the panorama, the one relevant to the current task. For navigation, maybe we could downsample the panorama to provide a wide-angle view of the scene. (The above is all speculation, by the way.) I'm not totally sure I agree that latency is so terrible. Currently, our operators mostly move the arms pretty slowly, to avoid nonintuitive dynamic effects of pneumatic actuators. I would imagine that if you had to move your arm and wait a fraction of the second for the visual feedback, it wouldn't be so terrible. It would slow things down, but I don't think it would kill you.