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