How much would you pay for a robot?



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 list. Thanks.
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.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I'm actually gonna pipe in here on MLW's side and Randy's side at the same time.
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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Andy P wrote:

    Beautiful point. I've been trying to convince people of this for     a couple of years now.

    Exactly.
    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     still.     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     roll over.     Take a look at the combat robots of you want to learn about          overcoming stress related injuries.
    Eljin
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Eljin wrote:

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 dollar one.
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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Eljin wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: 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 so:
: 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 -- snipped-for-privacy@westnet.com -- (914) 967-7816
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Christopher X. Candreva wrote:

Flash is a form of EEPROM, it just allows a broader/quicker eraser.

How's the support for a debugger? How's the memory protection? How's the process isolation?
How much does a full development system cost?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.
http://www.bdmicro.com/mavric-iib
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.
Cheers, -Brian
--
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

No. Saying that isn't right, its grossly misleading.

Incorrect.
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 H-bridges.
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.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Randy M. Dumse wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 like.)
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 16+ GPIO 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 ports!).
(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.)
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Randy M. Dumse wrote:

This explains a bit.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 them.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Randy M. Dumse wrote:

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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Eloquence is a painting of the thoughts.
Pascal (1623-1662)
http://groups.yahoo.com/group/daily-wisdom
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.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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 buss.
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 likes.
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 -- snipped-for-privacy@westnet.com -- (914) 967-7816
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Christopher X. Candreva wrote:

Argue? That is such an ugly word, I like to use "discuss."

Yup.
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 easily.

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 redesign.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: 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 : redesign.
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 it.
--
==========================================================
Chris Candreva -- snipped-for-privacy@westnet.com -- (914) 967-7816
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Christopher X. Candreva wrote:

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 computers.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.