John, that's a pretty interesting suggestion. I've got several "write a
book" entries on my big life todo list. I'll add your suggestion to that
If you go to our Downloads page from the top buttons, and then to the
'Pod Downloads page, you'll find Appnotes -Example Programs with many
robotics interfaces. Code for the Mark III which was several times
champion MiniSumo at DPRG is there, code for Lynxmotion L5, L6 with
inverse kinematics, hex walker H3 18 servo example code, and dual PID
example code which was the origin of BeerBot's code.
Randy M. Dumse
Caution: Objects in mirror are more confused than they appear.
I'm actually gonna pipe in here on MLW's side and Randy's side at the
As far as micro vs pc...well...they're used for different tasks.
The human brain even has different parts for different functions. The
medula oblongata does the low level stuff. It lets our ancilarry
peripherals run without the need for the rest of our major lobes and
corticies to do the prrocessing. Think of it as a micro. Memory,
speech, etc is different. Yes, it can be put to the task of a micro if
you want, but you will lack the higher functions.
Of course, all this can be solved by using a dsp or two, and a plc or
two, but that's neither here nor there.
from a speech and advanced visual output stance, you cant beat the mobo.
but from a movement autonomy pointt of view, you cant beat a micro.
As far as I/O, I could build and code a 2 sq inch board that has lcd
out, I2C, RS232, Parallel, CAN, SPI, 1 wire, RS485, 8 analog inputs, and
~30 left over digital I/O's in aout an hour with 4 chips at most, and
only consuming ~ 1 amp or less from a 5 volt source. So using that as
an excuse for a pc mobo really isn't a valid argument.
However having the options as to what to do with that data IS. There
really isn't anything that can be done with a micro...but pc's have
thier place as well.
I wouldn't base the robot off of a mobo as it's core, plain and simple.
I would use micro's for the I/O (you can get literally thousands of
I/O of any sort you want with just one or two micros). Let the customer
then decide how to process the I/O, but have all of the needed fittings
for dropping in an itx mobo if they so choose. Or make it an option
package. Start with nothing but a bare chassis with rudimentary drive
circuitry and tons of I/O, and let them order to suit. Youd sell alot
more this way.
One more thing about micros vs a pc...make a nice stout chassis, and
then wait until theres lotsa action going on with the hadd and other
things on the pc...then take a 40 pound sldge and blast that mofo across
the room and into a brick wall. Think those hdd's are going to survive
with all data intact? A micro would.
Beautiful point. I've been trying to convince people of this for a
couple of years now.
This is where we need bigger better faster cheaper flash drives,
or something even better.
A real robot will have to survive in the real world, especially
a humanoid where it's constantly moving even when standing
There have been a few successful hard drive based mobile robots,
but those usually never made it out of the lab or off the factory
floor where it always had a nice smooth floor to
Take a look at the combat robots of you want to learn about
overcoming stress related injuries.
Well...there is ALOT of technology out there that is uber friggin fast
and solid state. Problem is, you coudln't even imagine it for a sub
$500k system. And that's jsut the storage.
I've had the opportunity to specify ruggedized storage for a customer
once. Basically they had a choice of fiber interfaced static ram drives
(about $10k per gig) which are fast enough to make your head spin, and
completely bombproof (almost literally!), or a ruggedized SCSI, which
falls into the category of about $4-$5 thousand per gig. The scsi is
cheaper, but not as bomb proof. IT will take a licking though. It
would actually survive my above mentioned sledgehammer test. IT's what
was origionally used on surveillance jets with digital camreas in the
late 80's early 90's, before the wide scale move to solid state.
You can get flash cards on the order of a few gigs now. And with an IDE
interface (which there are 2 channels of two, so technically 4) you can
get to about 8 gigs max. and it would be rugged. It's only writeable a
finite number of times however, and again, is expensive. a 1000 dollar
robot could ont be based off of something like this, let alone a 500
a promising new technology is comming from fujitsu called F-Ram. It's
not an eeprom based technology, so it's not a finite write type
technology, but it is static. It's also gads faster than any eeprom
based tech like flash. At the moment, it is NOT cheap. 256 bits run
about $6 US. but it's an emerging technology, and as with anyhitng,
costs will drop. As far as I believe, this will be the future of solid
state non optical storage.
There is also holographic laser-dye storage. That's actually NOT that
expensive, but it's not that fast either. The beauty of it though is
that it stores data in 3 dimensions throughout the medium it's being
stored in. Think of a cd rom (which is really only a thousandth of an
inch if not less thick) stacked one on top of another, and being able to
access any layer at any time. Hyper dense storage...but..it's slow.
Damn slow relative to other technologies. Being optically based and
technically solid state, it is rugged though. For jsut plain reading,
it would be an excellent way to go, especially for packing huge amounts
of program into a very small space (like a robot!) but for a read write
situation, it would end up being like the old tape drives for the commodore.
For some reason that is unclear to me, Randy has been making arguments that
PC main board is somehow exclusive of using a PIC or small embedded
processor. While I no longer have any real desire to code for that sort of
design, it doesn't mean I wouldn't use one for a very specific purpose.
IMHO small embedded system do not make for very flexable designs. They are
difficult to write for, difficult to test, and difficult to load programs
on (relative to a PC design, of course.) With a PC, you can Network boot or
even use CDROM. A couple sticks of RAM and wireless ethernet can make for a
very rugged and cheap device.
The embedded boards are a pain. Programming EEPROMS or EPROMS, reviving
"bricks" that got programmed wrong. Mostly it is a lack of available code.
I am totally spoiled with Linux. (You could use FreeBSD or NetBSD if you
like), I can really focus on what the robot should do, not how to go about
getting to the point where I can start focsing on what it should do.
A good OS infrastructure on a PC provides you will so many things that you
would love to have but have neither time nor expertise or your embedded
system lacks the capacity to do.
See, I would. The PC, using your analogy, should be the brain. Small
specialized systems should perform functions ass nessisary.
: IMHO small embedded system do not make for very flexable designs. They are
: difficult to write for, difficult to test, and difficult to load programs
: on (relative to a PC design, of course.) With a PC, you can Network boot or
Well, IMHO this is just completely wrong. However I can see why you might think
: The embedded boards are a pain. Programming EEPROMS or EPROMS, reviving
EEPROMS are so last-century :-) With Flash and in-system programming,
testing new code on the micro is not significanly harder then testing PC
code. On the AVR it's the same gcc toolchain.
Chris Candreva -- email@example.com -- (914) 967-7816
On Sun, Mar 27, 2005 at 12:14:38PM -0500, mlw wrote:
Excellent. Use avarice + gdb + JTAG programmer/debugger. Set and
take breakpoints, watchpoints, dump display, examine the stack, call
functions, modify memory - all from the familiar gdb interface.
Not really relevant with a microcontroller.
MAVRIC-IIB is $99. ECROS Tech JTAG ICE-Cube is $40. GCC + avr-libc +
avarice + avrdude = full development environment = $0.
So ... about $140 If you pamper yourself and go for the screw
terminals on the MAVRIC-IIB, then it's a little more.
Also, with the open source tool set, we support a multiplatform
environment - Windows, Linux, FreeBSD, and MacOS X.
And yes, the MAVRIC-IIB does motor control, quadrature encoder inputs,
analog to digital converter inputs, dual level shifted serial ports,
RS485 network port, 6 R/C servo headers, 128K FLASH program space, 4K
SRAM (expandable to 128K), I2C, SPI, all that - a real Cadillac. $99
Power consumption? 40 mA - run it for many hours (or days) on 4 AA's :-)
It needs only 5.5V in but can handle up to 24V.
BDMICRO - ATmega128 Based MAVRIC Controllers
Let me make it clear:
We started with your robot. It as only a PC main board. That's the way
you made it. That's not the way it might be, but that's the way it is.
So that's why I've been making arguments about PC main boards exclusive
of embedded processors.
No. Saying that isn't right, its grossly misleading.
The IsoPod(TM) is $99. It comes with IsoMax(TM) installed.
Get the IsoPod(TM) V2, wall transformer, serial cable as Quick_Kit_V2
for $114. You're ready to go.
Power supply is not much of an issue. You can power it with 4AA's if you
wish. Or a 6V lantern battery. It has its own regulators on board. Or a
7.2 rechargable pack and drive your motors too (as long as they don't
spike the batteries down too low).
It is its own development system, less the human interface side, which
amounts to a serial cable and the desktop or laptop you already have.
Use it for an editor and terminal. (I noticed you didn't include the
cost of a monitor screen or keyboard or wireless in your tally. It was
assumed available) We provide the integrated edit/comm software without
charge. The IsoPod(TM) is interactive and you send it source, and it
compiles your program as you go. It has a multitasking capability, and
you can actually run programs and do additional programming or do
queries to the system at the same time.
I really don't think you have a concept of how powerful these boards are
compared to the PIC's and Z80's, etc., you used 20 years ago.
What happened to "There is *nothing* else to buy"?
No you don't need to buy I/O peripheral cards for the IsoPod(TM) and
that is largely my point. With IsoPod(TM) there really is *nothing* else
to buy in the way of peripheral cards. You can buy other sensors, etc.,
but the IsoPod(TM) is sufficient in itself for everything up to the
The IsoPod(TM) is ready to read two channels quadrature encoders in
internal hardware, generate PWM for H-bridges in internal hardware, has
timers to read Sonars in internal hardware, or can directly drive upto
26 RC Servos with those PWM+TImer lines, has A/D's to read IR Rangersin
internal hardware, 16+ GPIO to sense bump switches, networking via
CANbus, serial ports to other devices like CMUcam's, or voice
synthesizers, or GPS, and SPI for SD memory interfaces if desired.
But the important point here, I think, is the IsoPod(TM) has the real
world motion control features built into its hardware, where a PC mobo
doesn't have them, and those interfaces have to be kludged up.
The modern microcontrollers are marvelous! (and unfortunaely, too often
Could you give me a few examples of these micro's?
I have used PIC's a little bit but did not realise you could get micros
with all that built in. I was tossing up whether to use micros or a PC
mobo, thinking that micros were a bit limited.
I do like the modular approach though if you are experimenting and
trying new things, it kind of makes sense to have a "universal base" and
plug on different modules. As long as all modules are designed to
communicate with the same protocols.
Matthew, two micros I am particularly focused on these days are
1) DSP56F805's and family
2) LPC2106 and family
(Commercial Disclosure: If you didn't know, we, NMI, sell boards based
on these chips. It's hard to separate my commercial life from my
personal hobbies because they overlap. I make, or have made, things I
The DSP56F805's are a 80MHz 16-bit DSP based processor especially
designed for motion control projects. The internal bus is 40MHz and you
get near 40 MIPs. (So it's about 20x the PICs)
Great thing about the DSP56F805's is the hardware provided:
2 quadrature port inputs.
12 PWM outputs
8 12-bit A/D's
14 timer pins and 16 timers
All the timers can be multimode and (for instance) generate PWM, so you
can directly control 26 RC Servos in hardware. No need for SSR's.
Or the timers can be more quadrature inputs. I've written an app that
read 6 channels of quadrature input for position, and used the other
timers for pulling velocity off those inputs at the same time.
You can hook a timer to a SRF04 sonar, pulse the sonar, and come back at
your leisure and see when the echo pulse arrived because it will capture
and store the time for you.
As I say, I'm pretty amazed with these controllers, they make robotics
much easier, because there's no processor overhead to run these timer
and PWM features. It's all done by the hardware. Set and forget.
On the down side, they have CAN and SPI, but no I2C interface (although
it can be bit banged without too mcuh difficulty). These take
considerable current ~200mAs (but it's still small compared to a PC).
Program space seems sufficient (64K Flash) but RAM is rather limited.
(4K RAM). The choices of languages and development support are rather
limited. Code Warrior is a professionally priced C environment from
Motorola, which often manifests the most amaturish mistakes.
Newer versions are coming out with even more memory and faster operation
(56F8365: 120MHz, 512K Flash and 32K RAM, 16 12-bit A/Ds),
The LPC2106 are a 60MHz 32-bit ARM7 based processor. They seem to run
about neck and neck with the DSP's, but have larger memory (64K RAM 128K
Flash). They have less motor control features, they do have PWMs. No
A/D's (but others in the family, ie the LPC2132s, do, but less RAM).
They have I2C but no CAN (but others in the family do).
These are lower operating current, less than 100mAs, and less I/O
intensive. The appeal of these seem to me to be having enough memory to
do some mapping, and the ubiquitous ARM core, with all the development
support you could wish for, and then some. GCC being available. And
there is no doubt ARMs will be around a while, with a new generation of
200MHz (and higher!) devices just coming out now (some with USB host
(A new version in this family is coming out that is extremely low price,
competes with low-to-mid end PICs) and we hope to offer a $29 board
based on it soon.)
Boy, you aren't much fun to talk to.
Isn't this thread about your wanting us to do your commercial research
for you, establish pricing, so you can decide if your in business or
not? And when a guy with 25 years business experience, and another 15
years electronics experience, tries to tell you the best of what they've
learned, when it doesn't agree with what you've already done, you
"besmirch" :-) reaching a bit in to that thesaurus aren't you? Has anyone
really "besmirched" anyone since the late 1800s?
I'm having a duh! moment, my comment "This explains a bit," was not intended
to be to "besmirch" your motives. I'm sorry if you took it that way.
It was mean more as an understanding of your perspective. We are all most
comfortable with what we are most familiar.
I'm truly sorry if you were hurt by my post.
Eloquence is a painting of the thoughts.
Today's "wisdom" email.
No, I didn't use a thesaurus, I actually talk like that sometimes. The
other candidate word was smear, but I thought besmirched was probably
the more accurate and less poignant.
Okay, explanation of your motives noted.
With the amount of arguing going on, it really looks like you are talking
alternately about completely different things, and the same thing without
even knowing it.
Do you guys realize that PC's have MCUs and DSPs all over the place -- in
network cards, video adaptors, SCSI controllers, etc ? Hell, the mouse and
keyboard each have a dedicated controller -- the CPU isn't polling the
encoder wheels and individual keystrokes directly. There is a dedicated
controller summarizing the information and passing it along the PS/2 or USB
The two platforms are not mutually exclusive. Just about every device
connected to the PC has a dedicated microcontroller or DSP of some kind.
Yes, trying to do quadrature and actual control of hardware DIRECTLY from
the PC not the optimal way to do it. You can program something like an AVR
easily to do it all in real-time, or use one of the dedicated board Randy
But at the next level up, hooking these micros up to a PC then provides an
easy to to co-ordinate all the low-level tasks. All of the research papers
I've read on sonar mapping, image recognition, etc uses this approach.
So you are BOTH right. :-) Each has it's place in the process.
I definitely agree with one of Randy's original statements: Deciding on the
motherboard first is putting the cart before the horse. Build your base and
power supply first. Then get some controller working that controls your main
wheels. By the time you finish this, I guarantee you another generation or
two of PC hardware will have passed, and you will probably have a faster
hand-me-down motherboard than the one you would have bought at the outset.
If you have kids -- make that four generations.
Chris Candreva -- firstname.lastname@example.org -- (914) 967-7816
Argue? That is such an ugly word, I like to use "discuss."
I have made this point repeatedly, not in so many words, of course.
maybe true, however, a PC and OS which has a proper interrupt servicing
infrastructure and buffering counter/timer interface circuitry can do this
I think we are debating the relative merits of the approach. You are
basically describing the robot I proposed.
I think this is flawed. The *reason* you decide on the computer system first
is to capitalize on standards. You purchase standardized equipment at
commodity proces -- PC motherboards, and you can upgrade the robot without
: I think this is flawed. The *reason* you decide on the computer system first
: is to capitalize on standards. You purchase standardized equipment at
: commodity proces -- PC motherboards, and you can upgrade the robot without
But that's the reason you don't have to buy it first ! Design your motor
controller with any standard bus you want -- PCI, rs232, usb, CAN, and it
doesn't matter with motherboard you ever choose to use, upgrade, etc.
If you buy the motherboard before building the rest of the bot, the
motherboard will be obsolete in it's unopened box before you ever get to use
Chris Candreva -- email@example.com -- (914) 967-7816
But.... you have to decide *which* type of computer first. Whther it is a
Tyan, EPIA, etc who cares? It is the decision on the "type" of computer
more importanly the the specific computer.
Now, with many embedded system, the type is the specific computer. With the
"PC on wheels" metaphor, you get to choose from a number of specific
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.