Tag Archives: learns
#436466 How Two Robots Learned to Grill and ...
The list of things robots can do seems to be growing by the week. They can play sports, help us explore outer space and the deep sea, take over some of our boring everyday tasks, and even assemble Ikea furniture.
Now they can add one more accomplishment to the list: grilling and serving a hot dog.
It seems like a pretty straightforward task, and as far as grilling goes, hot dogs are about as easy as it gets (along with, maybe, burgers? Hot dogs require more rotation, but it’s easier to tell when they’re done since they’re lighter in color).
Let’s paint a picture: you’re manning the grill at your family’s annual Fourth of July celebration. You’ve got a 10-pack of plump, juicy beef franks and a hungry crowd of relatives whose food-to-alcohol ratio is getting pretty skewed—they need some solid calories, pronto. What are the steps you need to take to get those franks from package to plate?
Each one needs to be placed on the grill, rotated every couple minutes for even cooking, removed from the grill when you deem it’s done, then—if you’re the kind of guy or gal who goes the extra mile—placed in a bun and dressed with ketchup, mustard, pickles, and the like before being handed over to salivating, too-loud Uncle Hector or sweet, bored Cousin Margaret.
While carrying out your grillmaster duties, you know better than to drop the hot dogs on the ground, leave them cooking on one side for too long, squeeze them to the point of breaking or bursting, and any other hot-dog-ruining amateur moves.
But for a robot, that’s a lot to figure out, especially if they have no prior knowledge of grilling hot dogs (which, well, most robots don’t).
As described in a paper published in this week’s Science Robotics, a team from Boston University programmed two robotic arms to use reinforcement learning—a branch of machine learning in which software gathers information about its environment then learns from it by replaying its experiences and incorporating rewards—to cook and serve hot dogs.
The team used a set of formulas to specify and combine tasks (“pick up hot dog and place on the grill”), meet safety requirements (“always avoid collisions”), and incorporate general prior knowledge (“you cannot pick up another hot dog if you are already holding one”).
Baxter and Jaco—as the two robots were dubbed—were trained through computer simulations. The paper’s authors emphasized their use of what they call a “formal specification language” for training the software, with the aim of generating easily-interpretable task descriptions. In reinforcement learning, they explain, being able to understand how a reward function influences an AI’s learning process is a key component in understanding the system’s behavior—but most systems lack this quality, and are thus likely to be lumped into the ‘black box’ of AI.
The robots’ decisions throughout the hot dog prep process—when to turn a hot dog, when to take it off the grill, and so on—are, the authors write, “easily interpretable from the beginning because the language is very similar to plain English.”
Besides being a step towards more explainable AI systems, Baxter and Jaco are another example of fast-food robots—following in the footsteps of their burger and pizza counterparts—that may take over some repetitive manual tasks currently performed by human workers. As robots’ capabilities improve through incremental progress like this, they’ll be able to take on additional tasks.
In a not-so-distant future, then, you just may find yourself throwing back drinks with Uncle Hector and Cousin Margaret while your robotic replacement mans the grill, churning out hot dogs that are perfectly cooked every time.
Image Credit: Image by Muhammad Ribkhan from Pixabay Continue reading
Posted in Human Robots
#436184 Why People Demanded Privacy to Confide ...
This is part four of a six-part series on the history of natural language processing.
Between 1964 and 1966, Joseph Weizenbaum, a German American computer scientist at MIT’s artificial intelligence lab, developed the first-ever chatbot [PDF].
While there were already some rudimentary digital language generators in existence—programs that could spit out somewhat coherent lines of text—Weizenbaum’s program was the first designed explicitly for interactions with humans. The user could type in some statement or set of statements in their normal language, press enter, and receive a response from the machine. As Weizenbaum explained, his program made “certain kinds of natural-language conversation between man and computer possible.”
He named the program Eliza after Eliza Doolittle, the working-class hero of George Bernard Shaw’s Pygmalion who learns how to talk with an upper-class accent. The new Eliza was written for the 36-bit IBM 7094, an early transistorized mainframe computer, in a programming language that Weizenbaum developed called MAD-SLIP.
Because computer time was a valuable resource, Eliza could only be run via a time-sharing system; the user interacted with the program remotely via an electric typewriter and printer. When the user typed in a sentence and pressed enter, a message was sent to the mainframe computer. Eliza scanned the message for the presence of a keyword and used it in a new sentence to form a response that was sent back, printed out, and read by the user.
To encourage ongoing dialogue, Weizenbaum designed Eliza to simulate the type of conversational style used by a Rogerian psychoanalyst. The program would take something the user said and reflect it back with a question, as can be seen in the example below. (Notice how the program takes keywords like “boyfriend” and “depressed” and re-uses them.)
Human: Men are all alike.
Computer: IN WHAT WAY?
Human: They're always bugging us about something or other.
Computer: CAN YOU THINK OF A SPECIFIC EXAMPLE?
Human: Well, my boyfriend made me come here.
Computer: YOUR BOYFRIEND MADE YOU COME HERE
Human: He says I'm depressed much of the time.
Computer: I AM SORRY TO HEAR YOU ARE DEPRESSED
Human: It's true. I am unhappy.
Weizenbaum chose this mode of dialogue for Eliza because it gave the impression that the computer understood what was being said without having to offer anything new to the conversation. It created the illusion of comprehension and engagement in a mere 200 lines of code.
To test Eliza’s capacity to engage an interlocutor, Weizenbaum invited students and colleagues into his office and let them chat with the machine while he looked on. He noticed, with some concern, that during their brief interactions with Eliza, many users began forming emotional attachments to the algorithm. They would open up to the machine and confess problems they were facing in their lives and relationships.
During their brief interactions with Eliza, many users began forming emotional attachments to the algorithm.
Even more surprising was that this sense of intimacy persisted even after Weizenbaum described how the machine worked and explained that it didn’t really understand anything that was being said. Weizenbaum was most troubled when his secretary, who had watched him build the program from scratch over many months, insisted that he leave the room so she could talk to Eliza in private.
For Weizenbaum, this experiment with Eliza made him question an idea that Alan Turing had proposed in 1950 about machine intelligence. In his paper, entitled “Computing Machinery and Intelligence,” Turing suggested that if a computer could conduct a convincingly human conversation in text, one could assume it was intelligent—an idea that became the basis of the famous Turing Test.
But Eliza demonstrated that convincing communication between a human and a machine could take place even if comprehension only flowed from one side: The simulation of intelligence, rather than intelligence itself, was enough to fool people. Weizenbaum called this the Eliza effect, and believed it was a type of “delusional thinking” that humanity would collectively suffer from in the digital age. This insight was a profound shock for Weizenbaum, and one that came to define his intellectual trajectory over the next decade.
The simulation of intelligence, rather than intelligence itself, was enough to fool people.
In 1976, he published Computing Power and Human Reason: From Judgment to Calculation [PDF], which offered a long meditation on why people are willing to believe that a simple machine might be able to understand their complex human emotions.
In this book, he argues that the Eliza effect signifies a broader pathology afflicting “modern man.” In a world conquered by science, technology, and capitalism, people had grown accustomed to viewing themselves as isolated cogs in a large and uncaring machine. In such a diminished social world, Weizenbaum reasoned, people had grown so desperate for connection that they put aside their reason and judgment in order to believe that a program could care about their problems.
Weizenbaum spent the rest of his life developing this humanistic critique of artificial intelligence and digital technology. His mission was to remind people that their machines were not as smart as they were often said to be. And that even though it sometimes appeared as though they could talk, they were never really listening.
This is the fourth installment of a six-part series on the history of natural language processing. Last week’s post described Andrey Markov and Claude Shannon’s painstaking efforts to create statistical models of language for text generation. Come back next Monday for part five, “In 2016, Microsoft’s Racist Chatbot Revealed the Dangers of Conversation.”
You can also check out our prior series on the untold history of AI. Continue reading
Posted in Human Robots
#436180 Bipedal Robot Cassie Cal Learns to ...
There’s no particular reason why knowing how to juggle would be a useful skill for a robot. Despite this, robots are frequently taught how to juggle things. Blind robots can juggle, humanoid robots can juggle, and even drones can juggle. Why? Because juggling is hard, man! You have to think about a bunch of different things at once, and also do a bunch of different things at once, which this particular human at least finds to be overly stressful. While juggling may not stress robots out, it does require carefully coordinated sensing and computing and actuation, which means that it’s as good a task as any (and a more entertaining task than most) for testing the capabilities of your system.
UC Berkeley’s Cassie Cal robot, which consists of two legs and what could be called a torso if you were feeling charitable, has just learned to juggle by bouncing a ball on what would be her head if she had one of those. The idea is that if Cassie can juggle while balancing at the same time, she’ll be better able to do other things that require dynamic multitasking, too. And if that doesn’t work out, she’ll still be able to join the circus.
Cassie’s juggling is assisted by an external motion capture system that tracks the location of the ball, but otherwise everything is autonomous. Cassie is able to juggle the ball by leaning forwards and backwards, left and right, and moving up and down. She does this while maintaining her own balance, which is the whole point of this research—successfully executing two dynamic behaviors that may sometimes be at odds with one another. The end goal here is not to make a better juggling robot, but rather to explore dynamic multitasking, a skill that robots will need in order to be successful in human environments.
This work is from the Hybrid Robotics Lab at UC Berkeley, led by Koushil Sreenath, and is being done by Katherine Poggensee, Albert Li, Daniel Sotsaikich, Bike Zhang, and Prasanth Kotaru.
For a bit more detail, we spoke with Albert Li via email.
Image: UC Berkeley
UC Berkeley’s Cassie Cal getting ready to juggle.
IEEE Spectrum: What would be involved in getting Cassie to juggle without relying on motion capture?
Albert Li: Our motivation for starting off with motion capture was to first address the control challenge of juggling on a biped without worrying about implementing the perception. We actually do have a ball detector working on a camera, which would mean we wouldn’t have to rely on the motion capture system. However, we need to mount the camera in a way that it would provide the best upwards field of view, and we also have develop a reliable estimator. The estimator is particularly important because when the ball gets close enough to the camera, we actually can’t track the ball and have to assume our dynamic models describe its motion accurately enough until it bounces back up.
What keeps Cassie from juggling indefinitely?
There are a few factors that affect how long Cassie can sustain a juggle. While in simulation the paddle exhibits homogeneous properties like its stiffness and damping, in reality every surface has anisotropic contact properties. So, there are parts of the paddle which may be better for juggling than others (and importantly, react differently than modeled). These differences in contact are also exacerbated due to how the paddle is cantilevered when mounted on Cassie. When the ball hits these areas, it leads to a larger than expected error in a juggle. Due to the small size of the paddle, the ball may then just hit the paddle’s edge and end the juggling run. Over a very long run, this is a likely occurrence. Additionally, some large juggling errors could cause Cassie’s feet to slip slightly, which ends up changing the stable standing position over time. Since this version of the controller assumes Cassie is stationary, this change in position eventually leads to poor juggles and failure.
Would Cassie be able to juggle while walking (or hovershoe-ing)?
Walking (and hovershoe-ing) while juggling is a far more challenging problem and is certainly a goal for future research. Some of these challenges include getting the paddle to precise poses to juggle the ball while also moving to avoid any destabilizing effects of stepping incorrectly. The number of juggles per step of walking could also vary and make the mathematics of the problem more challenging. The controller goal is also more involved. While the current goal of the juggling controller is to juggle the ball to a static apex position, with a walking juggling controller, we may instead want to hit the ball forwards and also walk forwards to bounce it, juggle the ball along a particular path, etc. Solving such challenges would be the main thrusts of the follow-up research.
Can you give an example of a practical task that would be made possible by using a controller like this?
Studying juggling means studying contact behavior and leveraging our models of it to achieve a known objective. Juggling could also be used to study predictable post-contact flight behavior. Consider the scenario where a robot is attempting to make a catch, but fails, letting the ball to bounce off of its hand, and then recovering the catch. This behavior could also be intentional: It is often easier to first execute a bounce to direct the target and then perform a subsequent action. For example, volleyball players could in principle directly hit a spiked ball back, but almost always bump the ball back up and then return it.
Even beyond this motivating example, the kinds of models we employ to get juggling working are more generally applicable to any task that involves contact, which could include tasks besides bouncing like sliding and rolling. For example, clearing space on a desk by pushing objects to the side may be preferable than individually manipulating each and every object on it.
You mention collaborative juggling or juggling multiple balls—is that something you’ve tried yet? Can you talk a bit more about what you’re working on next?
We haven’t yet started working on collaborative or multi-ball juggling, but that’s also a goal for future work. Juggling multiple balls statically is probably the most reasonable next goal, but presents additional challenges. For instance, you have to encode a notion of juggling urgency (if the second ball isn’t hit hard enough, you have less time to get the first ball up before you get back to the second one).
On the other hand, collaborative human-robot juggling requires a more advanced decision-making framework. To get robust multi-agent juggling, the robot will need to employ some sort of probabilistic model of the expected human behavior (are they likely to move somewhere? Are they trying to catch the ball high or low? Is it safe to hit the ball back?). In general, developing such human models is difficult since humans are fairly unpredictable and often don’t exhibit rational behavior. This will be a focus of future work.
[ Hybrid Robotics Lab ] Continue reading
Posted in Human Robots