I was thinking about the fate of CMU’s Sandstorm in the 2004 DARPA Grand Challenge. After hanging up on an embankment, the robot car continued to spin its wheels, causing the rubber to burn off in a cloud of smoke and flame.
Hmmmm…for all the speed and power of that system (and it looks by most competent while driving) it couldn’t tell it was stuck. To me, this indicates that the robot is paying too much attention to the environment without checking its own internal state. The thing at issue here is sensors. Any biologist will tell you that simple animals don’t have elaborated brains – but they have a huge load of sensors. A single bacterial cell has thousands of protein-based sensors – measuring temperature, pressure, salinity, light, and chemical composition. This complex sensor array is coupled to a few simple outputs, like whether to divide, swim, tumble in space. This patternis repeated with more complex organisms – very rich sensor nets coupled with simple processes at the decision-making level and motor output level.
How would this work in a robo-car like Sandstorm? Well, I have a smoke detector above my computer which is relatively cheap and works fine. If Sandstorm had a few of these in its wheelwells it would have sensed the problems with the spinning tire and shut off the engine.
I suspect that a lot of the “stupid” behavior of mobile robots is simply due to their extremely limited sensor set. An insect has tens of thousands of sensors on its body recording a variety of stimuli (light, chemical, temperature, pressure). The very advanced QRIO robot that Sony produces probably has about 100. As the number of sensors increases we’ll see a version of “Moore’s Law” for robots – double the sensors, double the performance and apparent “intelligence.”
One could argue that this can be done in software. For example, if you program a routine that detects tires spinning without forward motion of a robot car you have de facto “sensed” a tire spinning against the ground. Fair enough. But this approach means that one has to figure out a huge number of environmental states in advance and figure out how to measure them in software using a limited sensor set.
Frankly, a smoke detector in the wheel wells seems easier.
One thing I’ve noticed about robotics work is that everyone seems to work with a small number of sensors. IR, ultrasound, laser rangefinder – we see them again and again. Nothing wrong with that. But this means that anything not easily processed by these systems in the environment has to be recognized by a software program.
The fact is, there are a huge number of sensors out there. Many are special-purpose devices designed for industrial robots and are very specific. There are sensors for heat, fire, rotary motion, proximity of metal (too close to another robo-car) windspeed using ultrasonics, temperature, humidity, strain, hydraulic pressure, ionization, low-level acoustic (detect change in standard sounds like an engine), magnetic, compass, a variety of gases like CO, O2, CO2, and biogenic gases, leak detectors, movement, radiation, micro cameras, sudden motion (airbags), moisture in oil. and more. To see examples of this go to the Direct Industry website and search for “sensors.” You’ll get a huge amount of information. A lot of these sensors are relatively small – too big for a hobby robot, but fine for a pickup truck.
I wouldn’t say that the extreme focus on robot vision for the fast 40 years is misplaced, but it is inadequate. During the 2004 Grand Challenge, Digital Auto Drive performed beautifully in termse of vision – but got stuck (lightly) on a rock. The robot sat there revving its engine but not enough to free itself. If it could “feel” the rock it could have determined its state and possibly got free. A human driver got the DAD car free in a couple of seconds becaus they could “feel” the rock themselves through the vibrations of the car transmitted to their body. They didn’t have to see the rock. Vision is not always necessary to solve problems. The right kind of sensor can pick up very specific information that can be handled as a low-level reflex rather than requiring high-level computing.
My image of an “alternative” robo car would be to cram the system with as many unique sensors as possible. Put in a few obvious low-level reflexes (e.g. tire smoke in the wheelwell tries to shut off the engine). Use a subsumption-style architecture to allow override in special cases – but do that later. Don’t worry about the complexity explosion of monitoring large number of sensors – tie them up with simple reflex circuits. The “brains” of the robo-car would normally only get the message that nothing was wrong.
I’m guessing a sensor-rich carbot would have a better chance of completing the course than a comparable system with super-vision processing and few sensors.
Finally, trying out some of these strange, alternative sensors that mobile robotics groups don’t use today might lead to some insights. Just possibly, there’ too much focus on a few well-known sensors at the expense of the others. So dig through a list of every sensor out there and try to think of creative ways to use them. If your’re a hobbyist, do the same – dump the standard IR or sonar sensors for something really different. By doing so you’ll be bringing us closer to robots that jump.