Have you looked at a "roomba?" It isn't actually a vacuum cleaner. It is a
When thinking about a product, one needs to consider "performance," or more
specifically the ability to live up to some expectation. The roomba is a
joke, its a pretty pisspoor robot. Its nothing more than a Mattel BigTrack
with a brush.
The robot I am considering building will be a "real" robotics platform.
Ample computing power, usable payload, on-board networking, wireless
networking, remote control, etc.
Things like mapping a room might be a good application in an examples
directory, just as remote controlled rover mode would be, but the real
purpose of the system will be serious robotics study.
My hope would be that it would be inexpensive enough for almost anyone
interested in robots to buy.
Everyone who started building or conceiving a robot think to set up a
production and sell them to make big money.
I had same thoughts, but not longer than a flash of light :-)
The robot must be smarter than commercial, but much cheaper.
It has to carry much more payload, but be cheaper again.
I think that best way to succeed in this hobby is to make it a business.
One need to open a company or bring together several professionals who
agree to spend their time after work. This will take years to become
on the market. At least one need some time to make a team and define
I guess this would take one year until a prototype is ready, not even
talking about software.
I do not think that robotics companies going to wait until the prototype
becomes a product.
Please do not take it personally, just ...
I would find people around who have same ideas and start doing something.
Unfortunately I could not find anybody in MA (might searched not too long).
Sorry that I did not do robots and take advantage living in CA a few years
The only place where one can find people who share your ideas in every
A real robotics platform? I must be missing the "real" part of it.
Computing power does not a robot make. Usable payload without a purpose,
is not useful. On-board networking at the PC level has little to do with
robotics. Wireless networking has nothing to do with robotics. Remote
control means what you are describing is not be a robot at all, but a
glorified RC toy.
A laptop (or motherboard) with wheels is still just a laptop. It has the
disadvantage of being able to move out of reach. A wireless network will
make it a laptop out of reach, that you can radio reach, remotely. That
doesn't make it a real robot either.
Putting in computing power to run an Operating System does not a robot
make. An Operating System is a HMI, a Human-Machine Interface. A robot
doesn't need a HMI, unless it needs a human to run it, which again makes
it an RC toy. A laptop with an OS and a remote control is still an RC
toy with a very very expensive wireless link.
As someone else said, the best robots don't have operating systems at
all. What Operating System does your washing machine run? None. Yet, it
is a very popular electromechanical system with very little computing
power, yet does a very useful funtion. What Operating System does your
dish washer run? None. Yet, it is a very popular electromechanical
system with very little computing power, yet does a very useful funtion.
What Operating System does your toaster run? None. Yet, it is a very
popular electromechanical system with virtually no computing power, yet
does a very useful funtion. What Operating System does your toilet run?
None. Yet, it is a very popular hydromechanical system with no computing
power, yet does a very useful funtion.
Then, all the things it takes to make a basic robot (as opposed to a
laptop with wheels) are missing in your description. Analog outputs for
the wheels don't make a control loop. You need quadrature feedback to
accomplish real wheel control to do Odometry, to do Navigation, let
along steering to drive in a straight line. You need current sense to
know if your wheels are stalled. You need various rangers (sonar or IR)
to be able to do avoidance. You need bump switches at an absolute
minimum. Those are the sort of things that make a "real robotics
Roomba has most of those features. Seems what you describe is less of a
robot than the Roomba. By comparison Roomba is an almost brainless
robot, sans OS, ...but!... Roomba is a robot with a purpose. Any robot
with a purpose will outsell any robot without a purpose.
I don't want to sound too critical, but I am amazed of late at what
people think a robot needs. To try to explain my reaction, I'd have the
same response if someone told me they were building a new automobile,
and they showed it to me, and sure enough, it had four wheels and a
motor, but no steering wheel, no seats, no brakes, no bumper, but had a
really fast laptop, instead, running Linux. Want to go for a ride?
Sorry, that's not a car. I have the same reaction to this laptop with
wheels. So far, that's not a robot.
I'll second this. A robot is absolutely NOT a PC on wheels. It's amazing
how the first thing folks think of when building a robot is what kind of
motherboard they'll need and what kind of OS, networking, etc.
The fact is that these are probably tertiary considerations at best for
most real robots -- and OS should be even farther down the list.
Mobilty, sensing, and general mechanical and electrical robustness
should be first-order concerns. The Roomba, by the way, excels in the
As far as computing power goes, lots of I/O is far more important than
the ability to crunch numbers for most robotics applications. The latter
need not even be done on board the robot itself. Any sizeable platform
should have a massive amount of analog and digital I/O. Microcontrollers
tend to have this in spades. Personally, I use one or mutiple networked
microcontrollers (which are using no OS at all), possibly speaking to a
local, more traditional SBC if I need or want computing power on board
the robot. The SBC may be absent entirely, however, and any required
computing done remotely.
I think the "PC-First" mentality tends to pop up a lot with software
guys (and there's no disrespect intended here, as I'm one of them) who
get into building robots for the first time. This is, however,
definitely putting the cart before the horse, at least in most cases.
(Replies: cleanse my address of the Mark of the Beast!)
I think this position is a bit naive. A computer is nothing but a tool. A
robot, particularly a mobile robot, is an application. Saying a computer on
wheels is not a robot, is like saying a motor on wheels is not a truck.
While these statements are true in a very strict sense, you are not being
intellectually honest because while a motor on wheels is not a car, a motor
on wheels is the base of a type of car.
The robot described is a usable platform.
The "roomba" is nothing more than a toy with a rug brush.
I'm not sure how this paragraph affects this discussion.
I am not actually doing this for the first time. I built my first robot in
the late 1970s with a Mattel BigTrack and a COSMAC 1802 ELF computer. The
system could roam around the room and make the outline of the wall and
display it on a TV screen. (The ELF had a built in video controller that
used RAM for the display buffer, I simply used the display buffer format
for an internal map.)
I subsequently worked at "Denning Mobile Robotics" and have been watching
the industry since. You may not agree with my conclusions, and that is
fine, but they are not simply the result of being a first time software
The ideas behind this platform have been seriously considered:
(1) Cost is a big factor, unless you have a company or a government grant,
you are paying for this on your own.
(2) Software development compatibility, I didn't think any special skills or
tools (device programmers, special languages or environments) should be
(3) COTS Like it or not, COTS (consumer off the shelf) has been proved
economical and practical at reducing cost an increasing value.
In short, the platform described at the top post is sufficient to start your
robotics project. It has all the things you'll scratch your head thinking
about how to build before you can actually start playing with navigation,
motor control, vision, and spacial dead-reconing. Everyone struggles with
the initial design of their system. Which motors, how to build the
platform, motor encoders, power supplies, etc.
On top of all that, there are no other things to buy. Everything else is
included, OS, compilers, debugging tools, and virtually any other software
you would need as well as device support for peripherals.
If you find your vision algorithm needs more processing power, just add a
computer and if you wrote your system with the supplied MPI utilities, it
will automatically use the extra computing power. How cool is that?
No -- I'm deliberatly overstating to make a point. Of course a PC on
wheels can be legitimately termed a "robot" (so could an RC toy). My
point is that for me -- and you DID request feedback -- the operating
system and OS is the absolutely least important bit that (and I may not
have made this clear) that would be WORTH PAYING FOR. I'd also contend
that it's the least important part of a working design. OK -- more
important than paint job.
Yes -- but you've requested feedback on how useful.
Re-read it -- I'm more concerned about I/O on a general platform than
the particular high-level computing hardware used. The latter is
commodity item, the former might actually be worth paying for.
Really I shouldn't assume anything about your background -- my
apologies. However, based on some of your comments ("all computers have
an OS of SOME kind) you DO seem to have been out of the game for a while
-- in particular as regards the use of micros (which isn't all that new).
On another note, I remember the original PE article on the COSMAC ELF
-- I believe the original dispaly was actually a 2 digit segmented hex
display (with a single hex keypad for input), no? The video controller
muist have come much later. That's right -- I'm a geezer too.
Compatability with what? Currently there is no standard platform,
although Player/Stage is relatively popular (which is one decent reason
to support Linux and some form of wireless networking). Do you plan on
developing your own tools?
I wouldn't dispute this, but it doesn't change the fact that your system
needs to have more than a fast CPU and wireless networking as it's
central selling point. I'll try to point some stuff out that MIGHT make
for a more interesting product at the end of this post.
It sounds vision-centric (not in and of itself a bad thing), but lacking
in other areas. Not only do you have competition in this arena, it
doesn't seem like a very compelling platform (at least to me).
Here are a few features that I think would make your platform a little
Obviously, start with a decent base and drive train. Bear in mind that
noise can become an issue here.
Add in standard some reasonable motion control. The controller should be
able to both read the quadrature encoders AND do current sensing. Some
people would like programmable acceleration profiles for the motors (not
a big deal for me). My controllers generally support the ability to
compute x, y and theta on the fly, with the ability for an external
process to update those as necessary based on sensor data. I have found
this to be quite useful. The ability of the controller to maintain at
least a straight line via some kind of proportional control (without
external intervention) is a must. This can easily be done with a $9.00
microcontroller (far less in OTP versions and OEM quantities).
Come up with an internal bus that is easy to interface to. The motor
controller would use this to talk to whatever controller is used at the
top end, but it should be easy for a third party to interface to. I use
a bus that supports just I2C for communications between modules and
power, but there are other choices. There should be easy physical access
to the bus and mount points for additional hardware.
If you do this, not only can you offer easy upgrades (servo controllers,
additional sensors), but the system becomes MUCH more open for
experimenters. You seem to have a "software first" bias in your current
design, which IMHO is a mistake.
Use a material for the robot that is relatively easy to work, should
someone wish to, say, mount additional sensors or other hardware.
A real plus would be good obstacle detection. By this I don't just mean
a lower skirt bumper. Ideally the robot should be able to detect a
collision along the length of it's skin. This can be as simple as having
the panels that comprise the outside of the robot coupled to bump
detection switches, and mounted so that when depressed, they issue a
signal. Personally, I would only need to distinguish between left-front,
right-front, left rear and right rear contact. If these panels are also
easy to remove to get at the inside of the robot, and easy to drill, I
think you'd have a real winner.
Provide an interface for a top-level controller (which could be anything
from a linux SBC to another microcontroller) to talk to the devices on
your internal bus. Sell the platform with or without and SBC and
software, or provide the software for free and let your customer choose
the SBC. The SBC may be intolerably obsolete within a year or two from
purchase anyway, making easy, customer upgradability important.
Offer the same kind of product in a weather resistant model. I don't
mean something that can be left out in a rainstorm, but a robust
platform that can deal with humidity and a wide range of operating
temperatures. Now THAT would really pique my interest.
Hope that helps -- tAfkaks.
(Replies: cleanse my address of the Mark of the Beast!)
No, I agree with your original point. A PC on wheels is not a robot, but it
can be the foundation for one.
Actually I diagree with you. The OS can make a huge difference. A lot of the
tools one needs to accomplish various functionality are present in a good
A good OS provides all the background management that supports your project
without actually being important to it. Think about a word processor. To a
writer, the OS means nothing, they only care about the word processor (if
at all). The OS, however, is VERY important as it provides many of the
ancilary things that make the word processor function, like file
managemnet, memory, printing, display, etc. etc.
No, not actually, how much you would pay. Granted that there is some
conceptual overlap, but not technically the same thing.
Just a note, even embedded controllers have software that provide features
like communication, this is -- maybe primitive -- but still an OS or OS
No, an "OS" need to be huge, virtually all systems have an OS of some
It was in BYTE and it was a three part article. The third installment showed
how to use the 1861 video controller chip.
I would use Linux and construct a basic frameword built on MPI and a few
other technologies. If you write modular functions, they would just run on
any processor that had the CPU time.
Another couple reasons for Linux is stability and flexability. Cost also
works as well.
Vision is the the thing that popped in my mind when I was writing. Geez,
ultrasonic mapping, path planning, dead reckoning, motor control, the list
Yes, energy efficient and fairly quiet.
Current sensing is something that isn't nessisary. You can calculate power
use by RPM of the wheels and PWM ratio output.
You actually need thus.
[Snip motion control]
It will have motion control as indicated in the OP.
It will have 24 digital I/O bits, 2 analog outputs, and 2 analog outputs.
(actually 4 but two are used for the motor control) These operate off I2C,
and the parallel port will be mostly available as well as USB and serial.
Actually, I was looking at some LEGO Mindstorms sensors and motors, and
thinking of designing a interface for them.
I don't think I have a "software first" bias at all, but it is a fact that
simple and cheap hardware can do more and be more flexable controlled by a
computer than expensive hardware that is not. That is a reality, nothing
Aluminum and plexy. Few "curves" mostly flat edges.
That is interesting.
No, I think the computer and OS is integral. Computer 0 in the cluster would
be the base and control the motors and the the main I/O system. IMHO Single
board computers are a pain to work with.
A weather hardened robot is an interesting idea. It adds some challenges.
No. With all due respect, you'll likely want to do some reading prior to
It was PE as it turns out (you're right about the grahics chip, though).
A walk down memory lane:
If you're going Linux, you should look at some of the work which has
already been done in this area. Check the Player/Stage project at least.
Current sensing is used for stall detection. Checking the encoders alone
is inadequate for a real-world design -- in a number of situations the
wheels may not even slow that much. It is possible to look at encoder
counts, check it against the current PWM duty cycle along with actual
power output from the battery and make a guess about stall conditions,
but this is unreliable, and needlessly complicated. There's a reason
motor controllers frequently include current sensing onboard.
Again, you should look at what has already been done done this area.
Honestly, even combining current sensing and encoder input is not 100%
I would consider this "I/0 poor -- particularly in the analog
department". You should at least open up the I2C bus.
Be aware that plexy has a tendency to crack when drilled (unless a
special drill bit is used) and cut. If you intend to use a material that
can be easily worked with by your end user, I'd go with a different
plastic -- I like ABS and Sintra -- but they aren't clear. Plexy can
apparently introduce static problems as well. On the other hand, plexy
domes look really cool.
I will say that I like a cylindrical form factor in a robot -- you can
almost always rotate around your own axis to get out of tight spots
without getting hung up.
A lot of challenges -- but there are no players in this commercial space
(that I know of) that aren't extremely expensive. Your current design
already has competition (although I suppose this all depends on your
(Replies: cleanse my address of the Mark of the Beast!)
I have done several embedded products based on either the Z80 or the 6502.
Every one of them had some sort of control code nessisary for operation.
Now, I'll admit that you can probably run a program in an embedded device
without anything except setting up the stack pointer and interrupt
hardware, but the point is, in modern practices, one doesn't do that.
Today, in the 21st century, we sterilize medical instruments before we
opperate (well, except for, maybe, the HMOs :-), we test automobiles for
safety, we have waiters and waitresses going into the kitchen through one
door and out through another, etc. There are common acceptable practices.
Whether you write it yourself, or you get it from someone else, it is a
common practice to separate the application code from the system code.
The system code or infrastructure can be minimal or comprehensive but, it is
I'll be damned! All this time I was remembering BYTE, but I went into my
file cabinet (I have the articles along with the data sheets and assembler
code), and it says "Popular Electronics."
It is interesting, but I think it was you who accused me of being too
software centric. That seems like it may be too much, although I am
considering some of their interface methodologies.
Why do you think the encoders are on the wheels? The encoders are on the
You are controlling the motors, not the wheels. The problem with putting
encoders on the wheels is that there is always "play" in the gearing. So,
while you can say, the wheel position will always be +- a few encoder
points, there is no accumulated error.
The play in the gear box is *really* bad for PID.
Since the encoder is on the motor, encoder frequency and PWM when plotted
against the motor's characteristics can tell you exactly how much current
the motor is using.
As I think about it, you may not even need the encoder info to calculate
current. A PWM motor amplifier is conceptually a current source. The output
current should be directly proportional to the PWM applied as long as you
don't saturate your inductors.
Detecting current in to the amplifier is a different matter, of course.
Yes, the I2C bus will be available on a set of screw connectors or plug. I'm
looking for a good standard.
Plexi is a bit brittle, you are right. I hadn't given it too much thought.
The idea for a skin was more aesthetic than anything else.
Circular robots are cool looking but very impractical. The effect you claim
for circular can be had with hexagonal or octagonal, and you still get flat
It is the competition that I find lacking. All of them have some cool
things, sure, but none of them focus on computing environment. It has been
my experience that computing power is one of the most limiting parts of
robotics. Sure, enough I/O and sensors are vital, but actually processing
that information *and* performing motor control, path planning, navigation,
etc. make for slow robots.
On top of the computers is the operating environment. A version of Linux
with tools created for modular robotic programming makes sense. Imagine a
framework, which you can choose not to use of course, that has a well
documented module specification. You declare the type of module it is and
tell the system to use it. Depending on the type of module, motor control,
vision, ultrasonic, etc. (yes it can be exapanded), it is run on the most
available CPU. The "most available" CPU need not even be on the robot. The
point is, you code neither knows nor cares where it is run.
As I said -- you've missed a number of developments in the embedded
world. Do some reading. Check into the PIC line of devices along with
the ATMEL line. Myke Predko has a number of good books ("Handbook of
Microcontrollers" comes to mind). I'm sure others around here can
recommend other books. I think you'll find that you can cut both costs
and development time for much of your hardware.
I didn't say they were. My normal approach is to mount them directly to
the armature shaft on the motor, or use motors with the encoders already
so-mounted. Doesn't make a difference, though.
Yes -- I already mentioned this (you also need to take into account the
amount of current currently available from the motor power source prior
Or you could do it the easy way, and simply use current sensing -- but
it's your design.
Done both -- and no, it can't to the same extent, though both shapes
beat square or rectangular.
Good luck with your project -- tAfkaks
(Replies: cleanse my address of the Mark of the Beast!)
PIC microcontrollers I hesitate to computers. Microprocessor, sure, but the
term "computer" as it is used these days, but OK, I'll give you the benefit
of the doubt.
I would still insist that there needs to be code to deal with the processor
and the I/O. Now, in the 21st century, common practice is to separate that
code from application code.
The battery voltage monitor (for low power shutdown should be sufficient. If
you know the make up of the battery, lead-acid, NiCAD, or NiMH and its AH
rating, the voltage is in direct relation to the available current.)
Current sensing is interesting as a topic, but the question is it's
usefulness. If the data can be calculated in a couple microseconds
(nanoseconds) from existing data, there is no need to spend milliseconds
and an I/O channel collecting it.
Buy "real" I mean something that is the base for robotics development.
Somthing designed for just that application.
All of these features which you dismiss are important at a base level for
serious work. They may not be the purpose of your project, be it robot
vision, motion control, what-ever, but most of the time these basic
features either need to be there or make your project much easier.
That is true, but it is also true that a laptop (or motherboard) "with
wheels" can be the basis of a robot, and that is sort of the point.
Here's where I'm not sure you are understanding something about computers.
EVERY computer has an OS at some level, some more comprehensive than
others. Even systems that boot off ROM have code that is focused on
managing resources and hardare without actually being directly coded for
the purpose of the application.
Using an operating system with common tools and utilities with some sort of
desktop or workstation allows for an easier development cycle. One can
compile, test, and modify code on their workstation and simply send it off
to the robot.
Obviously, you can make a basic robot using a PIC or STAMP, but having a lot
fully integrated environment does make it easier.
A purely mechanical washing machine does not, because there is no computer.
The ones with computers probably run an embedded OS in ROM.
If it has a computer it has an OS, perhaps rudimentory, but it has one.
See washing machine. Actually, my new dishwasher does have a computer in it.
My "toaster" has a small computer in it, and it probably does have a small
More to the point, my Microwave has a computer, my bread machine has a
computer, my stove, my car (has many), as does my VCR, DVD player,
Television, my telephone, the keyboard on which I am typing this message,
my cell phone, the list is endless.
Each and every device with a computer has some amount of code dedicated to
controlling the hardware and managing resource, otherwise known as an OS.
The quatrature encode must have been left off the list as an explicit item,
but the line "2 wheel oppsed drive with 3rd castor with PWM/PID motor
control" should have made it obvious.
As for using wheel motion for navigation, it is only good for rough
If you have encoders, you know when the wheels are stalled.
There are two cameras which can be used as IR sensors. There will also be
A roomba is a novalty item. It may have a purpose, but it doesn't accomplish
it very well.
I have a bit of experience in robotics. One of my jobs a long time ago was
"Denning Mobile Robotics." We were building a mobile robot security guard.
Many of the technologies we were developing then, are still being developed
today. Robot vision, motor control, etc. We worked with people like James
Crawly and Hans Morivic (sp?)
The #1 problem we had in developing our robot was the base level
functionality. We needed CPU power for analyzing data. We needed reliable
motion. Basically, the platform I proposed.
Be aware that you have chosen the most difficult kind of robot to build
-- a robot that is meant to be something for everyone. Do you expect
your users to be able to add their own electronics? How is this done
physically? In other words, how will the innards of your robot be
accessed? What kind of internal networking (if any) would be used? CAN?
I2C? RS-485? Something else? Do you have a bus design in mind? This
alone would be more important to me than the amount of computing power
available on board were I intending to add hardware.
Not neccessarily -- that depends on the project. Moreover, computing
tends to be a commodity item. If I needed onboard computing, I'd far
rather have a robot that allows me to drop in or remove whatever I need.
Should I need long run-times, I'd rather be able to use the
lowest-powered SBC that suits my needs. If I need more horsepower, THEN
I can move up. For me, any robot tied to a particular piece of PC
hardware is a non-starter.
But I think you'll find that it makes a poor basis. In particular, a
general-purpose robot needs LOTS of sensing, particularly as it gets
larger, if for nothing else than obstacle avoidance -- which is not
really as trivial as you might think in unconstrained indoor environments.
This is simply not true. The low-end, IO-rich micro controllers I
mentioned earlier do NOT use an OS (or even a bootstrap loader). Some of
the smaller versions may have 256 bytes of program ROM -- where do you
think they'd fit an OS? Even the higher controllers I typically use for
managing I/O do not use an OS. When the controller boots, user program
execution starts immediately. There are also micro controllers that _do_
actually support something at least operating system-like.
I would _strongly_ recommend you pick up a good book on embedded
But this isn't what we're talking about.
As I mentioned earlier, this is not likely, particularly in the case of
Nope -- see above.
Dead reckoning combined with sensor feedback is actually a critical
component of most navigation schemes.
Nope -- wheels *can* and *do* continue to spin in MANY stall situations.
Relying on encoders is the least reliable way to deal with a stall.
Even current sensing isn't perfect -- personally I'm also playing with
accelerometers to see if I can add some robustness to a current-sensing
What will you do about obstacles out of the camera FOV? If I'm already
doing vision processing, do I also have to track IR blobs as well? What
is the bumper coverage like?
As a floor sweeper (as someone else mentioned, it ain't a vacuum), it
seems to do a reasonable job. It is also extremely robust.
Have you looked at the Evolution robotics platform? Whitebox robotics?
Both of these basically take the PC-On-Wheels approach (although I don't
know if WhiteBox is shipping anything yet.)
(Replies: cleanse my address of the Mark of the Beast!)
Heres where I'm not sure YOU'RE understanding something about computers.
They're jsut a bunhc of transistors. Perhaps a few resistors,
capacitors, and diodes as well, but the basis for them is transistors.
Transistors are jsut switches. A modern computer is made up of billions
of switches. You dont need an operating system to tell a switch to turn
on or off. Besides, an operating system provide low level access to a
bios. The bios tells the processor how to shift the bits around inside
it to make it do what you expect of it. You could actually just hook a
bunch of switches up to a P4 and shift the bits around inside it. IT
would take days for each operation, but it could be done.
Prior to modern computers, they ahd gears and levers and such. No
operating system besides the one between the operators ears. Those
surely were still computers though.
Prior to that, most "computers" were women in the employ of the military
working out firing tables for artillery. This is where the term
computer came from. A person who computes. And that's all a modern
computer does. It adds numbers. That's it. Subtraction, division, and
multiplication all stems from binary addition and bit shifting.
I could make a calculator out of transistors. That's it. I could make
it display the desired outcome of the operation it was asked to perform
on the values I gave it. There is no software inside those transistors
telling them to turn on and off. The software is between my ears. Just
like the operators of the mechanical computers years ago.
I dont mean any of this to be offensive. I'm merely pointing out the
fact that an operating system does not make electronics do what you want
them to. The operating system is there to ease the ability for you to
tell the electronics what to do. All of these features you talk about
could be made using discrete components requiring no operating system at
all. Does that make the functionality any less effective? However, that
would require a large amount of space. In order to make this a more
reasonable and usable size, these electronics are miniaturized. In
order to access the billions of transistors in these small devices in a
reasonable amount of time, a way of interfacing is devised that allows
the speed of processing to be harnessed. This is what an operating
system does. IT doesn't run anything other than an itnerface that
allows you to access the hardware underneath.
Serious work? Serious work for a robot developer? or, serious work for a
robot to do something?
PC's are all about developers doing something. But they aren't very
useful for a robot to do something. I say PCs, laptops, motherboards
alone are very poor bases for a robot because they have no interfaces
appropriate to robotics built in. And that is my point.
Where are the quadrature inputs? Where are the PWM outputs? How fast a
PID can you run with a PC, with the operating system in your way? Where
are the timer inputs for the sonars? Where are the analog inputs for the
IR rangers? Where are the digital inputs for the bumper switches (surely
not the parallel port 'cause that's gone on most motherboards already,
or soon will be)? PC's just don't have any interfaces necessary for the
base robot. None of those applications are considered ordinary for the
So how do you get anything done? Well, you either cripple the PC trying
to make it do a task it is particularly unsuited for, or you use some
other micro to do the interfacing task, and then try to figure out how
to get it to talk to the PC.
Stamps or a PICs are actually more fit for robot interfaces, but they
are very much early1990's solutions. As you wouldn't offer a 1991 20-MHz
386SX a good solution for a PC today, neither should you consider the
state of the art 1991 micro for a good choice for a modern robot
The modern microcontrollers are marvelous! (and unfortunaely, too often
overlooked in the robotics community in my opinion). They are as far
from PICs, as the 20 MHz 386SX is from the 2.8GHz PIII.
Some modern micros are even designed specifically for motion control.
They have quadrature decoders built in. They have PWM output modules
built in. They have mult-channel A/D's. They have timer modules with a
multiplicity of operating modes. Their digital I/O have edge sensitive
interrupts. They have serial channels of multiple kinds and networking
interfaces built on chip.
They can read sonars with no additional hardware. They can read IR
Rangers with no additional hardware. They can read bumper switches with
no additional hardware. They can read line sensors with no additional
hardware. The can also read GPS's or interface to cameras. And then they
have fast CPU's with large memories which can do many, or all, these
functions in multitasking splendor with processing power left over.
You know, I just wouldn't advise banking on that speculation. I've been
around a while.
How much would I pay for a robot. I'd pay ~$200 for a Roomba. I actually
did pay that for a Roomba, and my wife loves it. I'm glad I did. It does
something useful and we're appreciative of what it does and how well it
How much would I pay for a PC based box you are describing? I wouldn't.
I own at least a dozen robots, the most expensive being ~$750 (without
electronics). But. I've got nothing like what you describe.
You've been around some, too. With your experience first at Denning
Mobile Robots, but then doing years of Windows programming since, are
you up-to-date on modern controllers and SBC's? Relying purely on PC's,
I have to wonder if you're still trying to build the robot you wanted to
have in the mid 1980's. I do think you might be able to sell some PC
based robots, 'cause others share your opinions. But to me, the PC lacks
the interfaces to be successful, and carries a host of systems programs
which will get in the way and hinder probable success.
I have a M5 Tank (cost me $50) I consider "a useful development
platform", with a board stack I'm developing (target retail price <$200)
smaller than 1.5" cube (less mounting tabs). (Actually, the first item
is in Dr. Brian Huff's M5 of UTA Autonomous Vehicle Labs currently.) It
has a modern microcontroller and two medium current H-bridges. So far it
does Dual Channel PID, Odometry, Grid Navigation, Steering, Way-point
and Drive-to-a-point, SRF-04 ranging, Obstacle Avoidance, GPS NMEA-0183
sentence reading, and target point spherical vector computation, ... so
far. (Dr. Huff has the sonar ranging and the GPS on separate processors
tied in by CAN bus.) But the stack could do all that, and still has more
processing power and hardware pins left over for additional behaviors
While there are important some conceptual differences between the two, for
the most part they are close enough to be treated as one in the realm of
robotic hobbiest or researcher.
PCs in this case, or at least computer system boards provide the standard
features currently comprising "PC infrastructure," are all about using COTS
(Consumer Off The Shelf) technology.
Why? They are powerful computing platforms with an abundance of cheap I/O
Are you kidding? They are a great base. Lots of standardized interfacing,
USB, Printer port, RS-232 port, PCI or even ISA (some still have them).
I actually have a super low cost solution for this, but short of that, there
are many peripherals for this.
Again, lots of peripherals are available.
That is an interesting question, one which can't be answered without solid
knowledge of the speed of the processor, I/O system which reads the encoder
input, the speed of the I/O system that controls the PWM controller, and
the response time of the motor.
Suffice to say, if designed right, as accurate as anyone would need.
Parallel port maybe?
No, the PC is the base system. The peripheral packages are added to it.
That's the idea of using an OS. All the interfacing is standardized.
There is no argument that a micro or pic is good for controling specific
peripherals. Hell, your keyboard has a processor in it. A robot, on the
other hand, is more than the sum of its parts.
The 20MHZ 386sx is, in a lot of ways, very similar to a 2.8 ghz P4. Granted
they've virtualized the internal processing engine, and added more
instructions, but the 386sz still supports 32bit virtual memory, the
process protection mechanisms are the same, as is interrupt and signals.
Again, robots are more than the simple digital control, and that's the point
that this debate misses.
This is a point of view that I find curious, and IMHO, fairly sad on the
frontier of robotics. Roomba is hardly an advancement or achievement. The
"Micro-mouse" contests of the 1980s (20 years ago) were far more advanced
with less processing power. Like I said, roomba is a bigtrack with a brush.
You may think its useful, and you may think of it as a robot, but I am
dubious of the former, and skeptical of the latter.
The platforms I see out there are not what I would call "robots" or "robotic
platforms." There is both a conceptual and phylosophical difference between
mere digital control of a device and artificial intelligence.
The roomba is a device with some very simple behaviors. It doesn't solve
problems. It doesn't really "know" where it is. It is easy to line up a
number of obsticals that will put it in a loop out of which it can not
escape. A "real" robot would be able to detect and correct these issues or
at least attempt to, and issue a warning or something.
If you want to build a roomba, have at it, an old Z80, 1802ELF, or even a
PIC or Basic stamp will do fine.
-- NOTE: please perform appendectomy on email address before replying
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.