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.