Integrating the Physical and Computational Worlds

An agent is an abstract computer science term that means a black-box that takes a set of percepts from the environment, perfrom some "computation", and exerts a set of actions on that environment. This is an useful concept to talk about AI-like entities or just about anything (even non-AI things) in an useful theoretical framework.

Embodiment is when an agent resides inside a body of some kind within an environment. This means that the agent is part of the environment and has the restrictions and perspectives imparted by that body. Not all agents are embodied.

A robot is an example of a physically embodied agent, i.e. it does not live in a simulated world. However, we have now stepped over a line and have left the world of pure computer science, creeping into the difficult and unpleasant world of mechanics, dynamics, frictions, electronics, gases, other embodied agents, societies, uncertainty, noise, and risk.

I believe that in order to truly understand how one can live and act within a world, we need a truly integrative approach to the physical world and the transportation and processing of information. Simply calling this work "interdisciplinary" is just a marketing term that does not convey the full revolution I am proposing.

Animals and human beings have achieved a careful and articulate equilibrium between processing information and interacting with the world with naturally-formed mechanical bodies gradually created over millions of years of evolution. To understand not the details of the parts of humans and animals, but the general underlying principles of living and surviving in the world to accomplish tasks, we must derive a general theory that closely couples a theory of information with a theory of the physical world.

This might lead some of you into fuzzy philosophical questions, which I will not address here. However, one that I believe that may be answered as we continue our work is the following:

What is information? What is computation?

How are these questions related? Are they the same? What vocabularly are we missing?

I don't claim to know the answer to these questions, but I hope that as we proceed to stack the building blocks of our theory, we may gradually achieve a glimpse of these notions.

Robotic Basics

In order to create a general theory of robotics, you need to get down to simple basics of what exactly a robot is. I will ignore all the pop culture perception of robots and create my own working definition:

A robot is an autonomous machine composed of sensors and effectors that acts in the real-world to accomplish a task.

What's interesting is what this throws out as not being a robot. Sensorless mechanical arms are not included in this definition. A robot should perceive its environment some way and act on it.

Programs that run in simulated worlds are not robots. In order to classify something as a robot, it must exist in the real physical world and deal with that world's uncertainties, noise, change, lack of structure, and physical laws. Although simulations can be used in design of robots, they must always be verified in the real world.

Autonomous machines that have no tasks to accomplish are not robots (although they could be if you defined their task as "wandering aimlessly"). This is just a working definition that makes our analysis much easier if we always assume there is a goal.

Mars Rover to Land Tonight

The Opportunity mars rover lands tonight Saturday, 24th at 9pm PST. (Sunday 25th at 5am UTC)

Apparently the command center at JPL in Pasadena will be televised on C-SPAN for those of you who have cable television.

Nasa TV is also available on the web, but it will probably be very crowded around that time.

In the meantime, check out this awesome satellite picture animation of Spirit's landing zone.

Since Spirit has been having problems, there's been a slight shift in the plans. The team was originally going to split up with the experts shifting their attention to Opportunity's deployment and Spirit continuing it's exploration. However, since they still don't know what happened with Spirit, most of the experts are still working on it.

They don't want the same thing that happened to Spirit to happen to Opportunity, so it will be deployed much more slowly and wait for Spirit's diagnosis before taking much action.

Back From Modular Robotics Workshop

I just got back yesterday from Las Vegas where the IROS conference is happening. That's the "International Conference on Intelligent Robots and Systems". However, I showed up before it started and left the day it began. I attended a workshop that preceded the general conference organized by Mark Yim and his crew from the "smart matter" division at PARC.

Specifically, we got to learn how to use the Polybot modules, put them together to make certain forms and how to rapidly program them to do locomotion or other general movement. Basically, the polybots are individual modules with one degree of freedom. You can manually put these together by screwing them together and putting them into any configuration you want. After you have your desired form, you then use the software suite to program them to move.

One of the most impressive things was the record feature. Since every module adds 1 DOF to the system, and you typically use 10 or more modules to build arbitrary shapes, the system becomes very difficult to program and control! However, the record feature allows you to hold the robot in particular configurations, take a snapshot, then select the next configuration. You can then play back this series of configuration snapshots with a gradual transition between each one and create any type of locomotion you want. My colleague and I made a quadraped crawl with this feature in 10 minutes.

This workshop was a day-long event where we did a lot of exercises to practice using the system. There were a few breakdowns, of course, especially when systems are taken outside of the laboratory. In particular, the serial modules that communicate and power the Polybot arrays were frying for unknown reaons, so by the end of the day we were down to only 3 left. However, only a few individual modules malfunctioned which is an enormous accomplishment considering how notoriously difficult it is to maintain hundreds of robots and the amount of abuse we were visiting upon them with our wild and erratic locomotions.

There were two competitions during the day. The first was a race to see who could come up with the fastest locomotions. There were some very interesting attempts from people who have never had experience with modular robots. I believe the winner was a snake performing a sinusoidal gait with some passive components to keep it stable and give it better traction. My friend and I wanted to make a really ambitious configuration, so we tried to implement the rolling gait where you connect modules together in a circle. However, we quickly learned that there is too much calibration to be done to get it to work quickly and we only had 8 modules to work with whereas Yim did the rolling gait with 10.

Realizing this, we quickly reconfigured the modules to implement a lazy biped that uses his two feet to push himself and rests and slides on a pair of crutches. Unfortunately this didn't work out very well since we couldn't get effective forward motion. Finally, we decided on the quadraped which took about 20 minutes to assemble. We were late in finishing the design, but I think people thought we had the second-most ingenious design. The most innovative design was a robot doing somersaults that one of my other colleagues designed who was inspired by one of the locomotions he saw in Karl Sim's work.

The final competition, following the theme of Las Vegas, was to design a robot that would approach a slot machine, put a coin in the slot, pull the lever, and catch the coins that popped out with a cup. This was not an autonomous requirement since we could control the robot serially from a laptop. We split into two teams and spent about 3 hours working on the problem. In fact we went over our allotted time by an hour.

My team was fairly successful. We realized that these modules are really good at implementing caterpillar gaits, but the gaits by themselves are very unstable and incapable of changing direction. We decided to implement two caterpillars in parallel to each other, connect them together by a beam, and attach a robotic arm to the beam. The result was a crazy robot that was able to move around and turn in place using four snake appendages, and a robotic arm that was used to manipulate the slot machine. To my knowledge, no one has ever come up with a design quite like this. I'm quite proud of our innovative design and the fact that we were able to put the coin in the slot and push the lever. Sadly, we were unable to catch the coins since the time-to-response to move the cup in position was too short for successful teleoperation. I should know since I was the one at the controls!

The other team was not so successful. They tried to build a very long and large robotic arm and do recorded motion to interact with the slot machine. However, there were so many DOF (approx. 20) and the motor dead-reckoning was not accurate enough that the errors quickly added up and was unable to reach the correct positions. Implementing manual interface would be impractical in the amount of time allotted, so they reverted to a simpler design. However, the team began to disintegrate by this time, and they were unable to make a successful showing during their demonstration.

All in all, I really enjoyed this workshop. Mark has promised to send us all the videos he took of the workshop, so hopefully I should have some videos to link to that show our crazy snake monster. You'll be able to see our coin-slot operation in action with me at the controls

In the meantime, I encourage you to browse the videos of Polybot in action.

Also, comment on this story here over at Frontier Files.

On Genetic Methods of Robot Design

In class today, we discussed the general method of solving problems using genetic algorithms which are loosely derived from the concept of natural selection in evolution. The idea is that you create a population of "genes" which serve as the basic building block in which you operate. These genes are interpreted in some way to attempt to solve a problem. Then you apply a fitness function to evaluate how well it solved the problem. Based on the fitness value, you apply a selection process for the fittest of your population of genes, do cross-over operations and mutations akin to the natural process of reproduction, and create a new generation of genes to form solutions. Then repeat ad infinitum.

One of the general drawbacks to this approach is that we have a very poor understanding of the dynamics of the system. There are lots of attempts to produce directed evolution to converge on a solution, but the fundamental drawback is that you must describe how the genes are interpreted to represent a solution, devise a suitable fitness function to weed out the underperforming solutions, do parameter tuning to balance your reproduction and mutation rates, and provide lots of computational resources and time.

That last one is a huge drawback. Natural evolution has operated on the order of millions of years and it has only produced sub-optimal solutions (humans, flora and fauna) to the problem of survival. Consumption of resources is also a big problem since if you want to find useable solutions in a reasonable amount of time, you want to have very large populations. If you want these solutions to work in the physical world, you need to provide physical resources in which to test it.

We mainly looked at these problems with respect to their applications to robotics. There have been stunning successes in the application of genetic methods to purely software worlds, but these don't transfer very well to physically realized systems such as robotics. So the question is, how can we model the real-world closely enough so we can evolve our robotic systems in simulation, or how can we closely couple the physical world and marshall the resources necessary to evolve physical solutions that are guaranteed to be a) applicable to the real world and b) tractible in time and cost.

The former may be more practical but the latter is more interesting. The basic idea is that you are simultaneously producing mechanical designs with sets of actuators and sensors and the control system that drives it in its interactions with the world. Then you are applying a fitness function on it to determine its level of "goodness" and mixing it with other solutions to come up with similar but different candidates that hopefully extend whatever general strategy that the parents had devised.

The question is, how far do you go in the allowed variance of the physical design and how do you facilitate the rapid fabrication and testing during the evolution of many generations of solutions?

One of the key features of artificial designs is that they require a huge industrial infrastructure to be produced. You need manufacturing plants, special materials and the factories to produce them, harvest of natural resources, swarms of engineers and factory workers, sophisticated operation methodologies, information management, etc. Can you really line these up in a row and start tweaking the parameters to come up with different materials, different designs, unique applications of existing technologies, and unforseen optimizations in production?

What would be really neat is to come up with a "backyard industrial complex" in which you can control and tweak the whole process from basic materials to final design and somehow integrate this into an automatic guess-and-check system to facilitate computational genetic methods to come up with new and interesting solutions to a posed task. Perhaps this could be made a little easier by restricting ourselves to reusable parts that can be assembled and disassembled without the costly waste of resources. Something akin to Legos would suffice, but we'd still need a way to assemble the test design rapidly enough to make the process worth doing.

Just thinking out loud here.

To see some previous research relevant to genetic methods in robotics, see Karl Sims or Jordan Pollack.

Jacob Everist