I think it will depend on the robot's applicaiton (and consequently number
and type of sensors), but in general I agree with you. For instance,
outdoors mobile robots heavily depend on vision system. With not enough
computing power, you get very limited on the types of approaches you can use
to do image processing. But in the other hand, if the robot doesn't have the
I/O power to make the necessary data come to the "brain", then computing
power is worthless.
A few ms latency is hardly noticable to most hardware. A V8 running at 5000
RPM is one event every 3.75 ms (one per cylinder every other rotation (4
stroke)). With the right OS, a PC could handle that with a printer port.
I can't speak for Randy, but my argument is not that computing power is
unimportant -- I think it should be obvious that this will ALWAYS depend
on the application.
My argument is that computing power isn't a compelling selling point for
a general purpose robotics platform, nor should it be a first-order
design consideration. Provided you have the space, means to power it,
and a way to communicate with the other subsystems on board, the choice
of a top-level controller should really rest with the consumer.
Thus endeth my two shekels-worth.
(Replies: cleanse my address of the Mark of the Beast!)
I guess that depends on your definition of robotics too. A lot of people
have a lot of definitions.
Originally, my first "How much would you pay..." post put forth a PC type
computer on the robot. The irony about this discussion was that the choice
of the PC type computer was not the original drive. This was completely
The thrust of the point I've been trying to make is that infrastructure is
important. Many embedded or otherwise simpler systems don't have the
infrastructure that a PC type system does. At $99 for a micro-itx board,
they are truely hard to beat, but more importantly, the off the shelf stuff
you can use is simply astounding.
I've done many sides of the work. I've done the ROM code on embedded
computers and I've done high end applications software, and more or less
everthing in between on many platforms.
For me, the convenience of all the things that come with a unix variant make
development and testing so much easier. When you add to the fact the
software is free (FreeBSD, NetBSD, and Linux), a PC infrastructure is a
hard reality to avoid.
It seems you have a lot to offer. When will you
have your first Linux based robot up and running?
There is nothing better, I would suggest, than
an actual demonstration of the importance of i/o
vs computing power in actual robots.
As everyone else has said, it depends.
Little robot that runs around and tries to avoid things etc then IO for
lots of sensors is great. I am more interested in robot software (in
particular vision systems) so processing horsepower is a major
consideration for me; IO is less important as I need only 3, maybe 2 IO
channels - something to talk to whatever is controlling the motors etc,
something to give the CPU the input from the camera/s and possibly 1
back to a workstation for telepresence.
I think the problem has to be defined. For a specific designed robot
with a specific purpose you need as many I/O lines as you need, and you
need as much processing power as you need. No more. It is design
specific and each case has its own merits. Once you get into a
multi-purpose, almost robotics trainer base style robot, then I think
processing power is the most important. A high power PC will be able to
communicate with other modules you make by a serial bus or ethernet or
whatever you can manage. Although there are not many I/O pins as such
there is plenty of room for inputs and outputs in the form of
communication. Again, though, if you have a specific design then design
"Smarter" robots will *require* more computing
power and larger memories. That's just a physical
reality. We don't have all those extra neurons
for the fun of it and yet our I/O is on a par
with some of the simpler organisms.
It is not a matter of opinion. For a given task
and a given algorithm there is a minimum requirement
in terms of computing power and memory capacity.
There is also a minimum i/o required but as the
system becomes "smarter" the improvements have to
be in computing power.
Asking my opinion is *always* dangerous. :)
For most specific-purpose robots I've seen and built I prefer
However, for general purpose experimental robots I prefer
using a full-scale Linux motherboard. I prefer to have
enough computing power and memory for my experiments that
I don't have to worry about it.
D. Jay Newman
On Wed, Mar 23, 2005 at 10:51:23AM -0500, mlw wrote:
As others have said, I think the intelligent answer is that "it
depends." For an example of a successful platform that is light on
I/O (in the sense that others have beaten you up about), see the ER1:
Here you have the "laptop on wheels with a web cam." Their core
technology is not the robot, though, its the vision processing
software which they license. And from what I hear, it is very
impressive. The robot is just a thing to show off their software.
Another, not yet proven, is White Box:
I don't know about these guys. They either like announcing things way
early, or they've had some serious trouble getting their act together.
This product has been vaporware for a couple of years, it seems. They
keep saying it's coming RSN.
However, I think most folks will agree that this does not have to be
an either/or decision. Any robot needs a base, and typically we are
referring to a mobile base. Minimally you've got some form of
locomotion (wheels, legs, propellers, etc), some sort of motion
feedback sensing, and some sort of environmental sensing (IR, SONAR,
etc, for detecting obstacles). Almost every robot that we are talking
about here has these.
Regardless of anything else, you need to control the base. You need
to drive the motors using PWM to an h-bridge or high level commands to
a smart h-bridge. You need one for each drive motor, and you need two
I/O lines to drive each bridge (assuming direct h-bridge). One of
those needs to be a hardware PWM line, unless you use a smart serial
h-bridge in which case you need a serial port or whatever interface it
requires. You need controller inputs to read your motion feedback.
If using quadrature encoders, you need two inputs per motor. At least
one of those should be an "interrupt" input (preferably both), i.e.,
not a general purpose input, but one that can generate an interrupt to
your processor so you get fast response time. So if you have 4 drive
motors, you need 4 h-bridges, each using 2 I/O lines or 8 output
lines. 4 of those should ideally be hardware PWM capable for good
h-bridge control. You also need your 8 inputs for sensing quadrature
feedback, at least 4 of which should be interrupt lines.
So there you have 16 I/O lines, some with special requirements, and we
haven't even gotten to obstacle detection yet. So as you can see,
even a simple robot has some pretty demanding I/O needs.
A lot of controllers that are available can handle this just fine, and
then some. My own, MAVRIC boards, included which have over 50 I/O
lines, with all the PWM and interrupt I/O typical robots need - this
is what they are designed for. Also, a board like my MAVRIC typically
has plenty of horsepower to do all the low level control, in addition
to significant high level logic. So for most robotics applications, a
board like my MAVRIC-IIB is all anyone would need.
But what if you want to do intensive vision processing? Ok, that's
not really appropriate for an 8-bit processor - not saying you can't
do it, but it's probably not the first tool I'd reach for.
So lets say you want to do that. That doesn't mean you can punt on
the low level control of the base - you still need to do that. So the
smart thing to do here is to use the right tool for the job. Use
something like a MAVRIC-IIB for controlling the base - let it control
the motors, keep track of position using encoder and other feedback;
let it watch for obstacles and steer change steering as needed, still
keeping track of position using odometry. Heck, let it pan/tilt your
cameras that feed into your video processing board.
Partition the problem into components that make sense - you don't have
to do everything on one piece of hardware. Distribute it, but keep
the data inputs close to the processor that crunches it the most. You
don't want to be passing massive amounts of data between your logical
components. It's fine for your high level vision board to tell your
MAVRIC to "turn 30 degrees, go 2 meters at 20 cps, stop", all the
while expecting the controller to carry out those actions and at the
same time making significant decisions on its own based on sensor
input - i.e., it may come back with an message saying it couldn't
complete that because something is in the way. But as a general rule
of thumb, you don't want to start passing high bandwidth sensor data
in either direction. This takes some design and engineering to make
your layering correct and consistent. When you get it right, you know
it - everything clicks into place. When you don't, you suspect it -
you end up making "work arounds" and hacks to do things that should be
simple. When that happens, you should consider design changes.
So the short answer is - you need both, both are important. Some
controllers such as my MAVRIC-IIB can provide both, to a large degree.
Where it can't, you can add additional compute power, or I/O as needed
(not likely). It is designed to work alone or in conjunction with
So while a high end controller can serve both functions, I/O,
computation, and logic, rarely will a single PC motherboard be able to
serve your I/O needs. So you can, in many cases, kill two birds with
one stone by using a high end controller, something like a MAVRIC-IIB
or similar. But rarely can you get by with desktop class hardware
serving as the I/O system on a robot.
BDMICRO - ATmega128 Based MAVRIC Controllers
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.