[Edu-sig] The Educational Robotics Platform

[Morris, Steve]

Kirby Urner wrote:
 > I wonder if it's cheating for a robot to have its "brains" in the
 > PC, with some kind of wireless connection to the servos.  Perhaps
 > that's not any more cost effective.  
 > 
 > Wireless ethernet has certainly come down in price.

Acually I missed your point the first time I read this so here is a better
answer.

Big brains in a host PC coupled with low level hands on the bits
sensor/actuator control in the robot is a common model for robotics software
development. Additionally a modern robot often has multiple computers on the
robot connected with some kind of local area network. It is common for
vision to be in one computer, looking at video data and extracting landmarks
and object detail which then gets passed to some high level brain that makes
decisions based on this info. Sometimes complicated details of the leg
control of walking process (for legged robots) are delegated to a separate
computer which is given high level objectives by the big brain.

You still require a minimum threshold of compute power in the robot. (It has
to be able to understand Ethernet for example.) Ethernet is also too slow
for detailed control of the low level bits and bytes of sensors and
actuators. This minimum level of compute power sets the low level price bar.
Infrared is interesting because it can carry simple serial port data which
makes it REALLY cheap. You just use standard TV remote IR parts and almost
every embedded micro has a serial port built in. However infrared is even
slower than Ethernet.

To give you an idea, the inner loop of the LEGO RCX is some small number of
thousandths of a second (I don't remember exactly but 2 milliseconds rings a
bell.) Not much needs to be done in that inner loop but delays caused by
other code will break the robot. The minimum low cost robotics processor is
one that can do a couple of simple things every couple of milliseconds but
also handle the high level decision making in the background. This low level
stuff should be completely hidden from the programmer (in timer interrupt
handlers etc) but the capability is necessary for the low level robot driver
stuff. It is this mix of extremely frequent but low load processing
responsiveness balanced with slower but more powerful and time consuming
high level computation that defines the real-time programming problem. (That
and the problem of many things happening in parallel.) It is this mix that
Windows and out of the box Linux can't handle.

The summary answer to your question is that high level processing that a
host PC could do is not the hard part so offloading it doesn't save much if
any money.

On the other hand since a host CPU is often available (that's where you
write the code) it is a valuable tool to increase what you can do with the
robot. Using that host in conjunction with a remote link to the robot only
increases the possibilities. It just doesn't solve the low cost minimum
useful robotics platform problem.