While I agree with your point...
I have to wonder about this mythical $5 microprocessor. I'm beginning to
suspect they are phantoms that don't exist.
I've had folks mock my products, imply I'm price gouging, and say they
could do the same thing with a $5 micro. Hear it all the time.
Of course, that's what they say. But instead, what they do... they never
do anything. They never show anything. They never build anything. Just
another good project idea gets killed by the mythical $5 micro.
Sure, I can even get a $.70 68HC908 that could probably do better motor
control than a whole PC with an OS could do, but, it doesn't have a
program in it, and it isn't $5 once it's on a board and in a system.
Whosh! The phantom disappears again.
I think we're hurting ourselves (robotics community) by believing in the
mytical $5 microcontroller. This is an interesting enough point to me, I
think I'll start a new thread about it.
Might be a good idea about the separate thread, but in my particular
experience, $5 is about right, including a small board and external
parts. The AVR AT90S2313, while not the most powerful microcontroller in
the world, does an excellent job as a main processor for little robots,
and a subprocessor for larger robots. It's routinely available for about
$3 to $3.50. (There are others, with more I/O like the '1200, and the
Tiny and Mega lines; many are under $5 and almost all are under $10.)
While I happen to use a STK500 programming board, you can program these
from your PC with just a few wires and some resistors. I happen to like
Bascom AVR for its simplicity, which you can get for free if you're
happy with the 2K program limit (usually suffices for most subprocessing
jobs) there are all sorts of C compilers available for it, some free and
others not so free.
There is a place for every type of microcontroller architecture. I
wouldn't dream of asking a '2313 to do the things your Iso products do,
for example. Apples to oranges, IMO.
In most PC operating systems, he IOS is not used after boot.
Why would I need to?
Because if I can eliminate the $5, thats less that people need to buy.
Not at all.
Perhaps, but the sub $500 robot has a tight budget.
I haven't missed them, I disregard them.
There are number of point that seem to be missed:
The sub $500 robot costs no more tan $500 dollars to build. The only
assumptions are a networked PC.
I ave no desire to write code for an embedded system. If I can buy one that
performs a specific task, at commodity prices, like an internet router,
Basically the issue is interrupt latency -- which can be quite long and
unpredictable with a non-rtos. Note that the "Real Time" part of RTOS
means that the operating supports a deterministic interrupt latency.
There is actually at least one real-time Linux version (RTLinux). I
believe that it basically runs Linux as a seperate task, and your
time-critical tasks run as other tasks. I'm not sure to what extent (if
any) they actually have the functionality of the Linux part of the OS
However, even with an RTOS running on a mobo, you're either short on I/O
ports altogether (at least the kind useful for robotics) or are stuck
using stupid hacks to get what you need -- and you're still limited.
Moreover, we haven't even begun discussing power consumption issues,
which may or may not be a factor in a particular application.
A MUCH easier approach is to use microcontrollers or DSPs for the low
level stuff and let them talk to your motherboard, which can handle the
stuff that requires more horsepower, or which will interface with
peripherals that would otherwise be difficult or impossible to talk to.
This is what most of us have been trying to get through to mlw without
much success. There's no real dichotomy here -- if you need vision
processing, if you want to run a web server on your robot or do anything
computationally intensive, a pc mobo is ENTIRELY appropriate. It's just
a poor choice for the lower-level workaday tasks that most
general-purpose robots are likely to need to do. For the record, both of
my larger platforms are designed to support (and one does, on occasion)
small form-factor pc-type boards.
Cheers -- tAfkaks
(Replies: cleanse my address of the Mark of the Beast!)
Everyone uses "real time" as some magical statement. "Real time" is very
subjective. I would argue it is largely not needed on a general purpose
It works something like that, yes.
I'm not sure what you mean.
One I/O card and you are good to go, what's the big deal?
Probably minimal compared with motor power requirements.
Yea, that is a standard approach. Most things that connect to a PC are some
form of controller. That isn't this debate.
Not at all. I have said, over and over, that microcontrollers have their
place in well defined tasks but that I would not base a robot on one
because they are too limited. This has been taken to mean that I would
never used one anywhere. Its not true.
I have done my share of micro development and it doesn't interest me. In
this project, the sub $500, robot, it will not use any because they cost
"Real time" is not a subjective term. It has a specific meaning when
applied to operating systems and control applications. Sheesh.
I imagine you'll find out soon enough.
Unless your motors run constantly -- no, it isn't actually. It depends
greatly on the application.
And where exactly did you do this development -- ExpensiveLand? How
much do you think modern microcontrollers cost? Let me give you a hint
-- for the cost of your $50.00 I/O card, I can put together and network
six or 7 microcontrollers, each having 30 or so lines of I/O,
including 6 channels of A/D and built-in PWM hardware and pulse capture.
External part count for each MPU? Around 4. Each of thse MPUs can be
reprogrammed on the fly if desired, and have sufficient horsepower to do
a significant amount of preprocessing of raw sensor data -- I routinely
do trig on PICs.
And as Randy mentioned, this is OLD technology. There are newer MCUs and
DSPs out now that far surpass this.
(Replies: cleanse my address of the Mark of the Beast!)
Yes, "real time" has a specific meaning to specific groups, too bad they
don't all agree. To the data acquisition people, the software guys have a
different view from the hardware guys.
All I'm saying is that "real time" is subjective to your task. "real time"
updates of traffic is every 10 minutes. "real time" control of motors is
measured in milliseconds. "real time" measurement of signals can be in
There is no "one size fits all" solution that is affordable, "real time" to
your application is defined by your application.
Oh, like no project runs into its snags. Get a grip, there will be issues
around which must be developed. Using a PC over a microcontroller gives me
a larger set of tools to bring to bare on the problems.
What part of mobile isn't motors running. When it isn't running it will be
in the charger.
And how much is a vision processing system for your micros? How much is a
speech synthesis board? How much is a video display? How much and what
software exists (and how much is it) for networking protocols like ssh,
http, etc? What about storage? What about a development system?
No, Mikey is right. When it comes to OSs, "real time" has a specific
meaning. Your examples are irrelevent; none of them have anything
inherently to do with priority switching, an interrupt-driven scheduler,
task-to-task interfacing, or anything else you'd see in an RTOS.
It follows that if you're talking about addressing hardware interrupts
in real time, it's assumed flyback or latency is as fast as the system
can manage. What that time measurement is, precisely, is a matter for
the hardware, but the definition of what *needs* to happen is not up to
Whether or not a robot needs an RTOS is a matter of debate among those
who have actually done it. Regardless, experience has shown that even
with a Linux based robot, time-critical events demand more control of
the system queue. Robotics entails several of these time-critical
events. If no one ever needed to address this issue for harware, then
RTOSs would not exist, and we know that's not the case.
For a larger robot it is wise to consider either an RTOS (RTLinux, BeOS,
QNX, LynxOS, or whatever or want), or consider offloading time-sensitive
subprocesses to some other circuitry in order to free up CPU time,
enable watchdogs, and provide for fail-safes. Believe me, a robot that's
reading its hard drive while doing speech processing and doing vision
analysis, will have a hard time scheduling itself to stop the motors in
time before it hits something. (Or maybe you don't want to move the
robot during these processor-intensive periods. But that would be a
shame, given the availability of options.)
On Sat, Apr 09, 2005 at 07:29:18PM -0400, mlw wrote:
That's a marketing term used by news channels. There's nothing
real-time about this.
You are off by several orders of magnitude.
This statement is close. Real time, as the term is used in embedded
control actually is a combination of predictable or deterministic time
from when service is requested to when it is received. Better
real-time systems can even schedule conflicting real-time requests so
that they can all be satisfied. This requires pre-knowledge of the
amount of time each service handler takes so that the schedular can
interleave the jobs appropriately.
A fast computer system that _happens_ to do what it needs to do most
of the time is _not_ a real time system.
Real-time is a guranteed response time to an event that requires
service within the time window. If the response is late, you get the
wrong answer. Simple as that.
CD burning is a real time process - if you don't get data to the
burning process in time, you burn a coaster because the process cannot
be stopped and restarted once it is started. Window's systems burn
coasters all the time if the system is doing anything else, especially
things like IDE disk activity which tend to hog the CPU and busses and
by the time the CD burning process gets control back, the FIFO is
empty and you have a coaster. Unix is better due to better process
scheduling, but they are not immune. Note that this can happen on
very fast multi-GHz systems.
A real time scheduler gurantees that the job that requires service,
gets it, perhaps at the expense of other non-real time jobs or
real-time jobs that don't yet need service.
So the definition is not fuzzy or subjective. If your real-time
requirements are not met, you get the wrong answer. In terms of motor
control, the wrong answer means your motors don't behave - maybe they
While Linux, FreeBSD, *BSD, etc are better than Windows at this, they
are all time-sharing systems. These schedulers actually try to be
fair in terms of scheduling time. Processes that are CPU hogs tend to
have their priorities dynamically lowered so that they get less CPU in
order to be more fair about the scheduling with other competing
processes. Conversely with processes that perform I/O - they tend to
get their scheduling priority raised, since they typically only use
the CPU for a short amount of time and then go back to waiting on I/O.
A real time system is definitely NOT fair in terms of scheduling. It
is very unfair. Non-real-time processes may starve in order to meet
the demands of the jobs that have real-time requirements. Not fair,
But worse than that even, Unix, Windows, etc, all use virtual memory
and process data swapping. What if your "real time" process finds
itself swapped out to disk due to memory constraints. Your real-time
event comes in and your swapped out process needs to service it. Disk
access is very slow, but worse, it is unpredictable. There may be
many I/O transaction requests in the disk queue ahead of you and it
could literally be many seconds before your job gets swapped back into
memory so that it can service your "real time" event.
Like I said, a fast system that performs correctly _most_ of the time,
is not a real time system. Real time systems imply a guaranteed
response time that Unix, Windows, and other operating systems with
non-real-time schedulers just cannot make.
BDMICRO - ATmega128 Based MAVRIC Controllers
there was a motion control system out there that used an FPGA to drive
steppers. It ran under DOS, it ran under Windoze 95A. It did this by
pretending to be a disk drive... windows 98 killed it.
The real issue here that concerns me, is that there is a level of
communication that you speak at, that not everyone can absorb. This is not a
fault of your own, on the contrary, you communicated the points here with
such clarity, that I have copied this post, so that I may plagarize it
wholly or in part in a future column ;^)
It is a simple matter of understanding the fine points, and a matter of real
world experience. I think that MLW just needs to run a couple of 2 kHz PID
loops using a PS2 mouse under windows, linux, free bsd, or QNX, and see for
himself what he is up against. If he succeedes at real motion profiling and
real motor control, with enough horse power left for vision, navigation,
speech recognition, speech systhesis, etc, then more power to him, we shall
learn a lot from him in the process, I am sure.
On Sun, Apr 10, 2005 at 02:43:05AM +0000, blueeyedpop wrote:
Thanks - some of the points might be a little subtle if you are not
used to the language typically used to talk about this stuff. I
appreciate that you appreciated it :-) I guess my main point was that
the term "real time" is actually very precise, within the circles that
use the term in the way that it is being used here, and to give one
example that I think most everyone can relate to - CD burning. "Real
time traffic updates" - Puleeeaze.
I agree. I really want to see him do it without any specialized
support hardware. PC MOBO only, as he has said! I'm wondering how
he's going to generate a 20KHz PWM signal using his general purpose
I/O card, continuously, without interruption - not just for short
bursts at a time, as required to drive a simple h-bridge. Let alone
multiples of those, each at a differing duty cycle. And still be able
to do his vision processing, etc, etc. Microcontrollers have built-in
hardware to do this - just set up the facility and plug the duty cycle
into a register. Set and forget.
Heck - even R/C servos which are the dregs of motion control and if
your signal is off by just a few microseconds you get jitter. I just
don't see you having this kind of control using a PC parallel port
where system response is highly dependent on load.
Oh, nevermind. I just remembered - he's using a DAC to drive some op
amps. I'll take a good reliable h-bridge with high current MOSFETs
anyday, though. Check this one out:
Anyway, these threads remind me of a signature someone is using in
"Good judgment comes from experience, experience comes from bad
I love that! It's so true. More so for some than others :-)
I seriously hope MLW doesn't give up, though - keep at it.
Persistance in this field is key to success! You never know, maybe
the end result of all this is that he will design a 40mA Athlon based
PC motherboard with all the bells and whistles that we need for our
robots that runs on 4 AA's and make a fortune selling it to us for
BDMICRO - ATmega128 Based MAVRIC Controllers
Yup, just about sums it up.
interrupt driven I2C DAC off the parallel port to an LM12.
I think that this is the time for him to maike a new BIOS, and write an OS
Those look like 18201's on that board. Trying to make a toaster ;^)
Try 16 LM12's and you can cook a pork roast.
I know of a particular device that uses literally dozens in parallel to
control a big motor. It has a specific need to not be chopping Watts at such
a scale, and making Mr Marconi jealous.
We can do lamb. how about gyros ?
On Sun, Apr 10, 2005 at 04:54:52AM +0000, blueeyedpop wrote:
Actually those are 16 IR high current MOSFETs ganged 4 in parallel for
greater current carrying capacity. Each row of 4 is a leg of the
h-bridge. There's also a pair of high-side MOSFET drivers on there
and an ATmega32 microcontroller providing the "smarts."
It does RS232, RS485, I2C, R/C servo pulse, and simple potentiometer
control. The potentiometer can alternately be connected to the shaft
of the motor and used to make a giant "servo" where it gives position
It also does quadrature encoder input and PID control.
It's not all done yet - not quite fully functional, firmware wise, but
I've placed 4 mounting holes to mount an Athlon CPU heat sink fan over
top of the MOSFETs :-)
I torture tested it on a 20 HP E-Tek motor and it survived. Some
parts did get hot, though. But it still works :-)
BDMICRO - ATmega128 Based MAVRIC Controllers
Sure you have. Just use the OS. Make D/A pins out of the parallel port.
Make D/A pins out of the audio channel. Make D/A pins out of the video.
Any of these are possible. What's the big problem?
If you use a parallel port, Just use a 100,000 Hz interrupt, count each
time, and then along some part of 65536 of those interrupts make the pin
go hi, and the remaining make it go low. That will give you a 16-bit D/A
output that has about a 1.5 Hz update rate. Easy! right? Maybe there's
already some driver written that could do this for you.
Or how about that stereo sound channel? There's two audio outputs, and
you can probably shape those waveforms to be just what you need right?
Just assume the D/A's are there, like you suggested. Use the OS. Just
pick a couple pins on your PC, and make 'em work. No cost! Easy! You've
got them right there on your ITX mobo.
Let us know how it works out.
Can get some cheap pci expansion cards
You can buy a 1->2 or more adaptor for the mini-itx boards
then could plug a couple of these boards in.
Or other option
get a pci to 4 port usb card and buy a few embedded boards that have usb
or pci expansion and a usb adaptor and pc io board or extra paralel and
www.newmicros.com have a few
their dsp boards are brilliant for motor control
can use c , forth or isomax or asm
quite a few articles / projects on the web using a servopod or isopod
as the io for a mini-itx board
http://robots.net/article/983.html some good suggestions at the bottom of
http://www.bio-bot.com/bio-botsite/lynxmotion/ Mike who posts here a lot
is currently selling this on ebay
a single usb connection to a servo pod would let you control 26rc servos if
one very cool looking product is the biped scoutn from lynxmotion
Could also get a few of the microchip , pic18f4550's
which can do usb2 fullspeed(12Mbps), easy to program and use.
Silabs also make 8051 micros with usb ,adcs , spi and smbus on a single
Can get some cheap reasonably powered bridges
looks like they have droped the price, not bad.
for dc motor see page 6
Sub $500 huh.
There isn't a whole lot of context in this message, but I have been reading
up on your other posts.
One pattern I see in your thinking is that you appear to feel that a PC is
going to be able to do everything. That there is a cheap OS that will have
all the functionality.
You are in effect designing the mythical "killer app".
I really do not think that you need to concern yourself with OS.
PCs running Linux, QNX, Windows, DOS will all have to have specific hardware
to achieve the task of robotics. This can be on the ISA, PCI, USB, Serial or
LPT port. You will have to roll your own hardware to do this on the cheap.
If you use an internal bus, you will need device drivers deep within the OS
to demand service from the CPU on a periodic basis.
I saw that you discount microcontrollers.
A microcontroller is a micorcomputer with internal memory and specific
register based devices for performing specific tasks.
Your mouse attached to your PC likely has a Cypress microcontroller with
timers to read the quadrature coming out of your mouse encoders, or to read
the SPI or quadrature coming out of it's Agilent mouse chip, which is a very
specialized microcontroller in its own right.
The mouse is a very specialized subsystem designed for user input. We do not
run the encoder lines from it directly into our PC, we use a sub system.
The printer you have next to you is similar, with stepper motor drivers and
one or more microcontrollers to mediate its functionality. It has a buffer
of commands, and follows them. It demands time slices when the buffer is
empty, but otherwise does not place a demand on the OS.
Your hard drive is an embedded system with h-bridges, motor controls and
Industrial automation is using CANBUS and other serial busses to distribute
motor control commands in the form of PVT commands to microcontrollers which
mediate the final motion.
Automobiles use microcontrollers with a variety of serial busses including
CAN, LIN and K-Line. All working in concert, all working on their own with
Alex mentioned the IsoPod. This is but one example of a device which is a
seriously powerful robotics controller in it's own right. Even if you write
a simple shell within FORTH to accept commands from the serial line, and
wrap that around a simple PID loop, you will be a lot better off in the end.
Add a lot of analog and digital sensors, and you are in really good shape.
As a matter of note, you asked how many motors Randy's micro can control. I
have run 12 DC motors in open loop, with 1 wire PWM. You can run 6 motors
with quadrature feedback and 2 wire PWM, or 8 motors with analog feedback(16
on a servopod) and 1 wire PWM. You can run ~26 motors in locked anti-phase
open loop, or 22 closed loop with 6 on quad feedback, and 8 or 16 on analog.
Or you could add an SPI a/d and close more loops.
By trying to over simplify your system, you are making it more complicated.
Take your $1.29 D/A converter and replace it with a cheap micro that does
PWM and has a few timers for your hacked mouse feedback. If you plan things,
you will have some digital and analog lines left for other things. Then
build a good and proper PID controller that accepts serial commands with
some sensing as a bonus? Drop the mouse and add 4 reflective sensors and a
printed wheel encoder wired to an AVR, PIC, ARM, whatever will save you lots
of ulcer medicine compared to trying to close a loop through an HID call in
don't get me wrong, $500 is an admirable goal, but why not add $40 worth of
microcontrollers and save the usenet bandwidth, save yourself the ulcer meds
and rogaine to grow back the pulled out hair.
just my $0.02
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.