Paper Review: Astronauts Must Program Robots

This is a position paper presented at the To Boldly Go Where No Human-Robot Team has Gone Before AAAI Spring Symposium by Dr. Yim from University of Pennsylvania. A lab mate of mine had the privilege of attending this. I only get to read the paper.

Now, don’t let the title fool you. This is not a paper talking about having astronauts sitting in space coding C++. The main idea of this paper is that given the complexity and many possible unexpected events of Mars and Lunar operations, the astronauts need to construct tools (“programming robots”) from a rich set of modules to complete various tasks. Therefore, a new programming model to fit such needs is necessary. The paper defines a robot as “a machine or device that operates automatically or by remote control” and program as “to provide (a machine) with a set of coded working instructions.” Note that these are very broad definitions. We could even define a copier as a robot and specifying how many copies to create as programming.

The paper argues that in addition to robot controlled autonomy, user interfaces and data filtering also required programming, and the context for programming these should be a system modular in both hardware and software. Divide and conquer is a common approach that works well, however, the tradeoff is the granularity of modules. Astronauts are highly skilled/intelligent people. The question becomes: would sending the programming tools to them be an effective and efficient use of resources? And the problem now falls under the Human-Robot Interaction domain.

The paper also presented and effectively argued against some of the common counter arguments:

- Local teleoperation is all that is required
Paper: Some forms of autonomy are likely to be incorporated as part of the user-interface.
Lanny: Yep! I step on gas, and the car goes.

- Programming can occur remotely from ground-based engineers
Paper: Terrain interaction on Mars cannot be duplicated exactly on earth.
Lanny: Don’t forget the 20+ minutes of communication delay.

- We can send highly capable robots that can handle any contingency circumstance
Paper: that’s impossible.
Lanny: “Good morning, Dave!” (See 2001, A Space Odyssey)

- Adding programmability and versatility will reduce efficiency and robustness.
Paper: The cost of not having flexibility and versatility will likely overweigh the loss of efficiency
Lanny: Depending on the context.

The solution proposed in this paper is to use a robot system composed of mostly identical modules such as the PolyBot G2 robot shown below.

When putting multiple of these together, they can form a 4-legged robot, or a bipedal one.

During a IROS 2003 workshop, participants were challenged to make the robot using these modules that can gamble using a slot machine, and you can see the winning configuration in this video:

Gambler Robot Movie (5.4MB mpeg)

The paper concludes that assuming the complexity of Mars and Lunar habitation, maybe the level of sophistication in programming needs to be extended to a similar level of complexity.

This type of robots is also called Shape-changing or Reconfigurable Robots. And here’s a video demonstrating the rich set of functions one can create with such robots:

This paper is certainly a fun read, however, I’d also like to point out some of the drawbacks of such modular systems and other possible solutions.

One major drawback of such modular systems is that it is a homogenous system without any specialized sensors, actuators or processors, and there is either no need or too expensive to have these components on each of the modules. A heterogeneous system with small groups of homogenous components might be a better idea under most contexts. However, that also adds multiple levels of complexities to the configuration and programming.

Identifying and configuring a workable solution using these modular systems also adds more complexity to the problem and adds more workload to the astronauts (taking away time and effort from other tasks). For example, what would be a good shape of the robot for a specific task and how can such a shape be built? The configuration of modules might not be intuitive to the astronauts and while in space, it is also difficult/expensive/dangerous for them to evaluate/test the configurations with possibly unexpected consequences.

If the modular system uses a multi-agent approach for decision making, the decision process can be very difficult for the astronauts to understand. If the decision making is centralized, then extra effort is required to generate and understand communications from each individual module.

Depending on the context, a specialized robot might be more desirable (for example, a transformer robot that can turn into a Roomba vacuum cleaner and a car is cool but unnecessary). Therefore, adding a bit more flexibility to the specialized robot might be better than going completely modular.

Therefore, I think a good solution for astronauts should be a combination of human, specialized robots with added flexibility, and highly flexible robots (modular ones) as additional tools to deal with the unexpected.




"HAL: I am sorry Dave, I am afraid I can't do that."

Picture of the Day: