Learned or engineered? The split over how robots should get smart
Russ Tedrake argues for rigorous thinking in the age of deep learning, Michael Littman discusses the bitter lesson, Andrej Karpathy champions Software 2.0, and Marc Raibert wants to join athletic intelligence with cognitive intelligence. Comparing them clarifies what data-driven learning has and has not yet delivered for machines that must touch the real world.
The split over whether robots should learn their skills or have them engineered is real, and narrower than the slogans suggest. All four people here use learning. They disagree about how much a person still has to understand, and about how far lessons from driving and games carry over to machines that must touch things.
Andrej Karpathy, who led AI for Tesla's Autopilot, argues that more and more of a robot's software should be learned from data. His reason: "Humans are just not very good at writing software basically." Computer vision moved from hand-designed methods to networks that learn everything, and each step worked better. At Tesla the networks gradually took over work that had been written by hand. What replaces the code is a loop. Deploy the model, find the rare cases where it struggles, establish what really happened, add those cases to the training data and retrain. He says the hard part is carrying this out, not the idea. Learning also works far better when it starts from prior knowledge instead of from nothing.
Russ Tedrake, an MIT professor who leads robotics research at the Toyota Research Institute, uses deep learning heavily and still worries about what its ease does to people. He says it "makes it easy to get things to work without thinking as critically about it." Where a well-understood method exists, such as inverting a matrix, you should not train a network to do it. His main case is contact. Touching the world changes a system abruptly, and the number of ways a hand can meet an object explodes. He wants simple models people can understand, and software that hunts for rare failures before a robot goes into anyone's kitchen.
Marc Raibert, founder of Boston Dynamics, reports from the hardware side. The most impressive robot performances so far, including most of those by his Atlas humanoid, still come from traditional control that predicts a second or two ahead. He expects the best results from combining that with learning. He also says hardware innovation is far from finished.
Michael Littman, a reinforcement learning researcher at Brown, accepts that scale and computation have beaten clever tricks. He doubts the curve runs forever, and he stresses how much human skill hides behind every learned system. A program that keeps improving at the game of Go is improving at Go and nothing else.
They agree that rare cases decide whether a robot can be trusted. They disagree on hardware. Karpathy treats each extra sensor as a liability, while Tedrake wants soft surfaces and a sense of touch. Much of the gap follows the task, since Karpathy's evidence comes from driving and Tedrake's hard problem is handling objects. No one claims a finished answer.
What to do with it: ask what kind of problem you have, since seeing with cameras has rewarded learning and planning through contact has not yet. Do not learn what is already known. Start learning from prior knowledge. Build the loop of deploying, finding failures and retraining. Hunt for rare failures on purpose and test on more than one machine. Let the body do some of the work. Be wary of extrapolating from one success, and expect a combination of methods.