How much would you pay for a robot?

What? No links? Damn. Looks like I'll have to look them up myself. Cheers. They do look good.

Matthew

Reply to
Matthew Gunn
Loading thread data ...

Okay okay already ;) Here you go:

formatting link
formatting link

A correction, I said LPC2132, and should have said LPC2129.

For those who want to know, our $29 board I've mentioned previously will be based on the LPC2131.

Reply to
Randy M. Dumse

Eloquence is a painting of the thoughts.

Pascal (1623-1662)

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

Reply to
Randy M. Dumse

Well, better in the sense it fits the job needing to be done.

Let's take the Christophers statement and your agreement with it as a starting point:

and let's talk about that little micro in the PC's keyboard (used to be an 8041 or such, but I have no idea what it is today). Would you say the best way to do that keyboard is with a VIA motherboard? I'm betting not. There are a number of reasons a choice of a different processor inside the keyboard makes sense.

For one, the micro in the keyboard has enough I/O pins to scan the whole keyboard and talk to the PC, where another VIA motherboard wouldn't.

For another thing, the micro in the keyboard is small enough to fit in the keyboard, and the VIA motherboard isn't.

For another thing, the micro doesn't require anywhere near as much power as the VIA motherboard.

For another thing, the micro doesn't generate as much heat as the VIA motherboard.

For another thing, there's no BIOS cost associated with the micro (which is part and parcel with programming of the micro).

For another thing, there's no OS cost associated with the micro (which is part and parcel with programming of the micro).

For another thing, there's no hard disk necessary for the micro.

Now I could go on ad nosium, however, the point should be obvious, and the idea of using another PC motherboard to read the keyboard, rather than a micro more appropriate to the task isn't overkill, it's bad design.

In the same light, I am not saying, don't put a PC motherboard in your robot, there's no use for it. No. Not my point at all.

I am saying there are better micros equipped to run the wheels of your robot and its basic mobility.

So when I see you putting multiple PC motherboard in the robot _instead of_ even a single micro with hardware designed for the task, I have the same negative reaction.

Reply to
Randy M. Dumse

First of all, mere control is not robotics. A keyboard requires merely simple control.

This is not actually true as the standard PC has a prallel port which can be be used to scan a keyboard easily.

Some of the nano-ITX board may.

That is true.

Also true.

What does it matter? A small micro-ATX or ITX board is about $100 and can booth of an ethernet connection. Much cheaper than all the tools and accessories required to bring up an embedded system.

No OS cost with PC's either. Linux, FreeBSD, freeDOS, NetBSD, etc are all free.

Linux, FreeBSD, NetBSD, etc can boot of network and ROM as well as HD.

Perhaps you think so, but I disagree. The Linksys wireless router boots embedded Linux, and you can download a custom version of it.

If all you are interested is the mere control of electronic devices, use a Z80 or PIC. If you want robotics, I think that is different.

Yes, if that is their only task. A robot is more than mere motor control.

And I think you are focusing on the simplicity of electronic control of devices and issing the idea of robotics.

Reply to
mlw

And without motor control (or motion control in general) it isn't a robot. A glorified desktop with wheels with the intense realtime task of properly managing the wheels would make it a bad desktop too.

Tell you what. Why don't you go ahead and get your single-PC-mobo robot running? Have it do the same basic things I've got running on a couple of the robots you've heard about here (BeerBot and Dr. Huff's mobile platforms, for instance). Get just the fundamental robot "drive around" stuff working: reading Quadrature and making dual PID PWM, driving H-brdiges, Odometry, Navigation, Steering, Drive-to-a-point. Then tell me how much time and processing power you have left over, and if any of this motion stuff stops working when you start doing your higher level robotics stuff like stereo vision and what not.

I have my own opinion, based on real experience. Bill James' BeerBot is an interesting example. He was mentioned by Earl Bolinger in the "The best Hobbiest robot, What is it?" thread. Beerbot spent the first several years of his life as a neat looking robot, that never did much, with a 486 motherboard in his head. Bill added an IsoPod(TM) a year or two back. BeerBot became quite a success. A few months later, the motherboard came out, because it was becoming obvious, it wasn't needed.

A couple weeks ago, Bill came over, and we added line followng and speech, took out his IR rangers, which were unreliable in sunlight, and added multiple Sonar rangers. He's still just running on one $99 IsoPod(TM). (Bill is thinking about adding a TiniPod(TM) if he puts the arm and gripper in BeerBot, but as of yet, he hasn't run out of processing power or hardware interfaces with the one 'Pod.)

BeerBot is actually a money-making robot, driving around in fleamarket crowds and drawing customers into the shop he's working for, carrying a large ad on his head, and telling the people "Follow me, I'm on my way to...". It also senses people in its way, and stops and suggests they move iin a series of escalating requests, which is most comical.

Now, if Bill wants to do serious vision, I might suggest he get a PC and make it a peripheral to his 'Pod, or not.

So clearly, you and I have entirely different design philosophies on the correct approach. But the main difference is, not trying to be snide here, just factual... I've got something running. When you get to a comparable point, we might talk again.

Reply to
Randy M. Dumse

Okay, that might be a reaonable definition. But this definition is broad so it can include Realtime dedicated OS's. Does Linux fit the definition of Realtime dedicated OS's? (I know Linux is supposed to be a much better real time OS than Windoze.)

I usually write the whole system, or write my own OS, so I don't know much about commercial OS's. Can you show me where in the standard Linux, one that might come on the VIA Mini-ITX, where the Quadrature Decoder input is? If it doesn't have one, has it met the definition about managing the I/O? or does this show it is not a suitable embedded real time OS? Now, I'm not asking if it can be modified, I'm sure it can, but does it come ready to do the task?

Reply to
Randy M. Dumse

A Many of the stand-alone internet routers from Linksys, buffalo, and I believe netgear use Linux.

In fact, there are a number of projects that allow you to replace the firmware of your cheap device.

Think about that.

Conceptually speaking, a wheel/scroll mouse has three quadrature encoders and a number of switches. That's pretty cool I/O.

You are focused on the minute details of mere electronic control, and not the "purposeful" control of robotics.

The term "real time" is so subjective. Any use of the term is useless without a set of criteria that needs to be met, like interupt response within some number of ms (or micro seconds), stuff like that.

Well, "ready to do the task," depending on your requirements of "real time," Linux can do it, not only that, there are more "real time" centric versions of the Linux kernel.

Reply to
mlw

Obviously motor control is vital, it is one of those things that must work correctly. No one ever said differently. I said it wasn't enough, not that it wasn't important.

In the process.

Do you differentiate between PC104 and nano-ITX? I see them as basically the same type of devices.

I have actually done this before, in 1984. Using a Z80. My goal is to create a 21st century version.

If I need to add more computing power, the architecture provides for that. Not an issue.

As do I, and we disagree.

I am not privvy to his thought process so I can't say for sure what this means.

No one has said that you "can't" do something with this or that system, I've done some great stuff with Z80, 8080, 6502, and 1802 in the past, having done that, it is a pain. Using a real OS with real infrastructure is *much* easier and maybe even cheaper.

You use the example of an IsoPod. You do know it is more expensive to use an IsoPod than a micro-ITX board, right?

A micro ITX board with 12V ATX power supply is about $140, add $30 for memory and it costs $170. There is *nothing* else to buy. You can net boot it into Linux, FreeBSD, or NetBSD. Linux has assemblers, C/C++ compilers, and everything else.

Your IsoPod costs about $100, you have to pay a license fee for IsoMax $20. You have to buy a power supply. You need to buy a development system.

At the end, you still have to buy I/O peripheral cards. I bought a I/O card for my mini-ATX board.

The advantages I have are: Build in sound, free speech synthesizer software. Built in IDE interface should I want it. USB, PS/2 mouse and keyboard, parallel port, RS-232 serial port, ethernet, TV output, VGA output.

I have a HUGE amount of software available for free, speech recognition, motor control, prallel processing code, and on and on. Networked graphical API (X Window System).

What does the isopod have? How much would you have to pay?

At this moment, my robot is at the point where it boots and moves. I can control the motors via desktop system. My target is sub-$500, so I am trying to design the system cheaply and that takes more time.

Reply to
mlw

recognition,

graphical

Please provide URLs for free speech recognition software (source code?) and motor control (PID source code?)

Thanks!

Rich

Reply to
aiiadict
[...]

What have you got running? I visited your site. What would be neat would be a download book called "How to build your own working Robot using an isoPod". The only complete book I have is based on the 8085 using 8155s for i/o and memory and it was printed in 1979!

Are you going to share the technical details and its progress on a website?

At the moment I have a clunky laptop sitting on top of my robot base. The parallel port is all I have for i/o to control the motors and read the bumber switches and two usb web cams for visual input.

John Casey

Reply to
JGCASEY

If you're interested, I've built a working TankBot using the MiniPod...

formatting link
...which included the ultrasonic sensor turret.

The details were published in Doctor Dobb's Journal (Embedded Systems section), October 2004.

-Pete.

Reply to
Pete Gray

: Okay, that might be a reaonable definition. But this definition is broad : so it can include Realtime dedicated OS's. Does Linux fit the definition : of Realtime dedicated OS's? (I know Linux is supposed to be a much

Yes. Again though, I would not do direct quadrature in it, any more than I would monitor the mouse wheels or keyboard buttons directly.

: I usually write the whole system, or write my own OS, so I don't know : much about commercial OS's. Can you show me where in the standard Linux, : one that might come on the VIA Mini-ITX, where the Quadrature Decoder : input is? If it doesn't have one, has it met the definition about

Sure, any of the many mouse drivers included in the standard kernel. Of course, they expect the quadrature to have a dedicated controller. :-)

Recent versions of the Linux kernel have done a lot of work on real-time response, both for embeded applications and multi-media desktop use. Older versions ran into problems where a high use of IDE disks could cause mouse movement to stop, so this was an area a lot of work went in to. New kernels (2.6.x series and up) let you select tuneing either for transactional, server use or real-time response.

But again, I'm the guy who would use micros for motor control. Anything running linux I would use to co-ordinate, map, path plan, talk, etc. If only the kids would let me get back to robot building . . . :-)

-Chris

Reply to
Christopher X. Candreva

Here's a good place to start for motor stuff:

formatting link

And there are some university project on voice recognition, but I don't have any URLs at the moment.

Reply to
mlw

Yup.

Reply to
mlw

Look for Sphinx at CMU, ISIP at Mississippi State. Easiest to look up the voice recognition HOWTO at TLDP.ORG. It has a list of all the best software that is free for the download.

formatting link
is an awesome starting place for finding information on building pc based robots. Check out their links especially.

Eljin

Reply to
Eljin

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.

Reply to
Andy P

Exactly. And it isn't a PC Clone doing the mouse job either.

Yes, this is as I suspected. These OS's try to be realtime, but when it comes the to the hardcore realtime tasks, the process must be off loaded to dedicated processors. Note that both the IDE and the mouse have dedicated processors "serving" the PC, and yet the OS had to be modified to keep up with them, not the other way around. It's not that the PC can't be realtime controllers, its that their OS's get in the way.

When it comes to finesse in motion control, the programming requirement becomes extreme, and frankly out of the range of most of the old 8-bit controllers. Which explains why so many DSPs are pressed into motion control, where they've found a real niche.

Okay, (exept for that talk part) we are indeed in close agreement. Add to that list, talk on Ethernet or 802.11x etc. Although, many of those apps are going to start going to the ARM's, but may still be Linux.

Reply to
Randy M. Dumse

: to dedicated processors. Note that both the IDE and the mouse have : dedicated processors "serving" the PC, and yet the OS had to be modified

IDE does NOT have a dedicated processor, that's why it's cheap. The main CPU is doing all of the work. SCSI is where you have a dedicated processor, and the gain in performance is significant. (IE - I could copy a 4 gig file faster to an old 40mhz Sparc 2 over 10-baseT with SCSI disks faster than to a 1.6Ghz PC over 100bast-T IDE disks -- all because of disk bottleneck.

: to keep up with them, not the other way around. It's not that the PC : can't be realtime controllers, its that their OS's get in the way.

Right. Before the 2.6 kernel series, there were separate real-time Linux projects. As of 2.6, real-time was integrated into the main kernel tree, and things have gotten significantly better.

: Okay, (except for that talk part) we are indeed in close agreement. Add

Let me try to change your mind. :-) Check out the Festival and Flite (Festival-lite) project from CMU. I don't have a link handy, but a Google search find it easily enough. IF you already have a PC/Unix board running, you get free speech with higher quality then any of the dedicated chips out there. ARM support already existing.

Of course, what I really want to do is take the text-to-seach part of Festival, and right a driver to output phoneme codes for my SSI-256 chip from my Heathkit speech board, because, well, it just so sounds like a robot. :-)

: to that list, talk on Ethernet or 802.11x etc. Although, many of those : apps are going to start going to the ARM's, but may still be Linux.

The only reason I wouldn't use an ARM in my hobby would be the plentiful supply of free motherboards from retired computers.

Reply to
Christopher X. Candreva

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

Reply to
Eljin

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