Discuss: Computing power

I seem to be at odds with a number of people in this group about the importantce of computing power.

One camp says robots need I/O more than computing power. The other camp, mine, says that raw computing power is more important.

I have my reasons for why I say what I do, and I have enumerated them a couple times on this group.

What's your opinions?

Reply to
mlw
Loading thread data ...

"mlw" wrote

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.

Reply to
Padu

I feel cheap about what I'm about to say, but being bombarded with news, I can't help but make the analogy thinking about Terry Schiavo. She has reflexes, but no brain.

Reply to
mlw

Get away from the discussion and back to the robot!

Rich

Reply to
aiiadict

[with apologies]

You can always add a computer at the end of an ethernet connection. Possibly wireless.

Latency to hardware is forever.

cheers, Rich.

Reply to
Rich Walker

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.

Reply to
the Artist Formerly Known as K

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.

Reply to
Mattd

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 something specific.

Matthew

Reply to
Matthew Gunn

Unless the robot goes out of range.

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.

Reply to
mlw

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 misunderstood.

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.

Reply to
mlw

"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.

- John Casey

Reply to
JGCASEY

mlw wrote: [...]

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.

John Casey

Reply to
JGCASEY

Asking my opinion is *always* dangerous. :)

For most specific-purpose robots I've seen and built I prefer smaller processors.

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

Reply to
D. Jay Newman

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:

formatting link
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:

formatting link
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 other systems.

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.

-Brian

Reply to
Brian Dean

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.