hardware geeks and software geeks?

And have separate newsgroups too.

Mitch

Reply to
Mitch Berkson
Loading thread data ...

Now that's funny.

Actually we don't need different news groups, but the microcontroller guys need theropy. They remind me of guys who drive hopped up japanise cars. OK, sure you *can* get a few hundred horse out of a 4 cylinder engine, but it takes a lot of work and nitrous. A bored out chevy small block with a good set of heads and fuel injection, will easily produce 400 horse.

All I've ever said is that I don't want to use them and they are limited. Both statements inarguable, and what followed continues to confound me. Touchy people.

Reply to
mlw

Micro's are neat because they are understable by a single mind, in a lifetime. You can optimize your own assembly. You can know exactly what is going on with all of micro all the time. Register states, reads, writes, status bytes, absolute max interrupt handling code latency are all available to the programmer. Brute force (in the form of CPU MHZ) coding will get things done, but you might not understand exactly what is going on inside.

It is a preference for me to know exactly what a machine is doing. My mind wants to know everything that is going on, and to understand it.

Some people just enjoy programming. The ability to make a processor/computer do something.

If you want to relate it to a car: Your 2005 vehicle breaks down. You cannot find the problem because there are undocumented black boxes, a computer which is undocumented, the schematic of the car is unavailable.

Your 1970 vehicle breaks down. You have a full schematic and can trace what is going on.

I enjoy programming both. A modern PC has microcontrollers built into it. It allows CPU to execute applications and OS instead of counting ms and watching address/data lines. Example: serial and USB port buffer, IDE drive, graphics card, etc....

The PC wouldn't even operate if it had to execute instructions to directly control IDE drive (turn H bridge on. disc spins. read encoder. too fast. slow PWM. too slow. increase PWM. too fast. move head, read encoder. too far. hey supposed to be reading parallel port. go read parallel port. now drive speed is too slow. Head needs to be moved. but USB needs to be checked if there is data on line. oops mouse could have moved so go read it. IDE drive #2 that is being written to needs to have head moved. check it's speed. You cannot achieve parallel hardware operation with a standard PC without each hardware device having its own microcontroller (or buffer, which is a very simple, single purpose micro)

you have too many things going on to get them done with 1 CPU.

Rich

Reply to
aiiadict

You're being revisionist. What the "microcontroller guys" said was they prefer to use them as subcontrollers for PC-based robots (the use of microcontrollers in smaller robots has not been raised). That is *their* equally inarguable design preference, for which they've backed up with their own experiences. That experience may be different from yours.

If you're confounded by anything, might I suggest it is your habit of challenging someone else's preferences, when you feel your own preferences are not subject to discussion.

-- Gordon

Reply to
Gordon McComb

You nailed it on the head, Rich. These choices are preferences, for any number of reasons. MLW started this thread with a presumptuous statement about "hardware geeks" -- "The guys that would do their robot with many small PICS tend to be hardware geeks that don't like software all the much." Does this mean software geeks don't like hardware? He doesn't say.

Not everyone understands that for 99.9% of people here, robotics is a hobby, not a business. So it's all about preferences and choice and personal enjoyment. That means diversity in ideas and approach. But now we're being pigeonholed into some kind of partisan mindset, like the so many OS wars crap that dominate the newsgroups. Sad.

-- Gordon

Reply to
Gordon McComb

An interesting question came to my mind: how could someone design a robot that must interface to at least a dozen of sensors and actuators be exclusively PC-based?

Imagine this list of sensors:

- 2 GPS chips speaking CMOS serial

- 3 Gyros (X-Y-Z) speaking I2C

- 4 servos (steering, velocity, camera pan, camera tilt) speaking PWM

- Wheel encoder speaking whatever

- Sonar array speaking I2C

- Temperature sensors speaking 1-wire

- LADAR speaking whatever

In my opinion, it is much easier and conceptually clean to have the PC (or any other computing unit with enough power to do processing... could be a mini-itx or a rack of dual xeons communicating through ATM) communicating with the "sensorial system" being the master of a bus (I2C, RS485) and each sensor node to have a microcontroller that guarantees the language spoken between the master and slaves is the same.

In this case, the mcus are here to simplify, right?

At least, that's what I think it's the right solution for this problem, but I'm always open to new ideas.

"Eu prefiro ser uma metamorfose ambulante, do que ter aquela velha opiniao formada sobre tudo" Raul Seixas, great brazilian singer and prophet

Padu

Reply to
Padu

This is a very interesting position. It reminds me of the classic physics vs paricle physics debate, and Einstien's quote "God does not roll dice." How much predictability is there? How much do you need?

There are some serious limits to what you can know. You can not ever guarantee there are no bugs. Even if the software is perfect, the hardware may have issues. It is best to design around things not being as you expect.

That is the a part. True.

Actually, that isn't technically true. (I'm sort of a car buff). There are code readers that can tell you what is wrong. As for the undocumented issues, there are DOT regulations, and they are working on laws to make this less of an issue.

That may be true, but just as you need a code reader with a newer vehicle, you need some tools to work on an old carborator. How would you fix an old brass float that has holes in it?

[snip]

Again, I'm not making the argument that microcontrollers are not valuable. I never have.

My position on microcontrollers, as I have tried to articulate multiple times and in multiple ways, is that as long as the functionality is well defined and constrained, then sure. Keyboards, microwaves, etc all perfect examples of where and how to use a micro.

Reply to
mlw

I agree that a microcontroller can often simplify a task, but to me, the larger issues are:

  1. isolating the specifics of hardware
  2. offering future flexibility for hardware you might not even think about today

Neither can be dismissed, but as has been discussed here, there are also personal preferences involved.

For isolating hardware, you could use software drivers alone, but these can become progressively complex as interface choices increase. With a consistent hardware interface, no matter what information the underlying machine needs or returns, it's handled by a common communications protocol, and software drivers can be kept lean and simple. This is why R/C servos are so popular for smaller robots.

The ability to plan for the future, without knowing what the future is, is a basic tenet of good engineering design. That's why *some* of us prefer using a microcontroller for handling subsystems. It's our inarguable preference to do so.

-- Gordon

Reply to
Gordon McComb

You know, I thought you had made some good arguements in this thread, even if I didn't always agree with them, but now I think you're just being a turd.

First, you completely ignore the fact that some people ENJOY working on those "hopped up japanise cars", just like some people like working with microcontrollers, some like climbing the mountain instead of driving to the top, and some prefer to make their bread instead of buying it in a store. In each case, maybe there was a faster, easier way to do the same thing, but it's the act of doing something a different way that's sometimes the goal, not the end result.

Second, how will anyone ever know if there is a better way to do something if they don't experiment. You argue that people should consider your methods, yet you completely dismiss the other side of the arguement as unreasonable and without merit. Don't be so quick to dismiss other people's choices. The most powerful computers started off as just a bunch of switches... you have to start somewhere. And sometimes the simplest answers ARE the best; not always, but sometimes.

Third, and lastly, you should always pick the right tool for the job. I think it would have been really silly if they had used a $100 computer board in a Furby (or robotic toy of your choice) when a $0.50 microcontroller worked just as well. Then again, I'd be screaming for someone's head on a platter if I found out that NASA spent millions of tax dollars to build the Mar's rover's entirely out of microcontrollers. Sometimes the job needs big tools, sometimes small... and sometimes a mix. Use what's best, and what's available to you.

For myself, I've work with computers my entire adult life. It would be very simple for me to build a robot controlled by my laptop, but for my current project I've chosen to use a microcontroller because I've never used one before. (Not to mention that I couldn't figure out how to build a tabletop sumo with a laptop strapped to the top that could move itself... although I bet no one would be able to push it out of the ring.)

WEC

Reply to
W.E.Cole

I have to agree with Gordon here.

After building a primarily PC/Linux controlled robot, my next robot will attempt to use a more heirarchical approach.

Many of the ideas for this have come out of these discussions.

I want to take a stock PC interface (USB, hopefully) and then connect that to the high-level controllers. The PC will do the planning and high-level control, but it will not be very concerned with the actual control of the sensors/actuators. For example, the PC might say "turn right" rather than give specific motor commands.

There would be several reflex layers that might affect the outcome (such as an emergency motor stop) under certain conditions; the higher level processors would be notificed and could override these reflexes if necessary.

In other words, something like a biological nervous system.

However, that's a discussion (and hopefully a book) for another time and place.

-- D. Jay Newman

formatting link

Reply to
D. Jay Newman

Rod Brooks started one, but without many hardware specifics. Of course many of his company's products use this approach.

Though his book (a collection of his papers) lack a step-by-step project, there's enough there for anyone interested in subsumption to give it a whack. It's an area where, as demonstrated by about two decades of MIT research, is ably handled -- among other ways -- by using simple individual microcontrollers.

The fact that Brooks designed Ghengis, or even COG, out of a heterogeneous collection of microcontrollers reflects his approach to robotics. With COG, far more complex than Ghengis, he supplemented the microcontrollers with QNX for real-time vision and sound analysis, and DSPs as pre-processors. I have to read anywhere that he insists it's the only way it could be done.

-- Gordon

Reply to
Gordon McComb

"Gordon McComb"

I've read a book from one of his students that now works for iRobot and I believe is the creator of Roomba. The guy uses an architecture inspired on the subsumption but more grounded to practical problems such as sensors that give you false information, wheels that slip and so on. There are a couple of practical examples throughout the book, and some very good practical advices.

Info on the book:

Robot Programming : A Practical Guide to Behavior-Based Robotics by Joe Jones, Daniel Roth ISBN: 0071427783

They also have a website with a robot simulator

formatting link
Padu

Reply to
Padu

Not "just as well" but far better. How long would furby's batteries last if it was running a P3 at 500 mhz, plus memory controller, video controller, IO controller, etc.. and all those other things it would never use.

MLW, when you say "microcontroller guys" you make it sound like a cult. The only microcontroller guys are the ones who design them. Just because some guy used one once in some design where it was prudent doesn't mean he's obsessive and irrational about them.

Reply to
Mark Haase

Yes, this is correct. Joe Jones is one of the lead developers of Roomba. I left out Roomba because its single microcontroller is not slaved to a PC, which is the subject of the discussion these many weeks. It's more of an elaborate LEGO RCX. (In fact, quite a number of folks have replaced the non-reprogrammable controller in the Roomba with another MCU, like Javelin or even a Basic Stamp.)

That said, it is certainly a testament of the power of a little 8-bit MCU with 256 bytes of memory. It's arguably the most successful utilitarian robot design yet. I am not aware of any other robot, that wasn't basically a child's toy, that's sold 1+ million units.

Jones' earlier book, Mobile Robots, also includes some practical behavior-based projects and code.

-- Gordon

Reply to
Gordon McComb

Like the old computers. A thin hardware manual and you could understand it all in an afternoon.

[...]

Getting things done at a price you can afford is what it is all about. There are jobs best done with a shovel and other jobs best done with a back digger.

[...]

Understanding how a piece of software works is no different than understanding how a piece of hardware works. Software is flexible but slow. If the software is really useful we embody it in hardware. Thus graphics algorithms are implemented in graphics chips. Same with sound, video, controllers of various types...

I don't have the means to embody some of the lower level visual processing algorithms in silicon, although those that do have the means are doing just that, so I need a fast cpu with lots of memory to do the job instead.

[...]

And *enjoy* is what it is all about.

Mlw enjoys using software to solve a problem, even if others see a hardware solution as a better option.

[...]

So you add another cpu :)

John

Reply to
JGCASEY

True.

Stereotype or categorize?

Of course not.

Of course not, and that is sort of my point.

What's the line between someone talking too much, and the USA problem of limited attention span? I'm all about free speech and really believe that if you don't like something, don't read. Critisizing someone for speaking is never helpful.

The subject is a rich one. There are tons of interesting design issues. The choice between using a microcontroller and a PC with an OS, and which OS, is something that could be the subject of many many papers. There is no lack analysis that can be done.

Reply to
mlw

Now its you who are doing the silly attacks based soley on nationality.

Many of us here are from the USA, and some of us have an actual attention span. Please restrict your attacks to individuals rather than stereotyping entire nations.

And while I agree with free speech, disallowing criticism is also against free speech.

-- D. Jay Newman

formatting link

Reply to
D. Jay Newman

D. Jay Newman wrote: [snip]

[snip]

I agree. And I'd also like to add... Oooh loook -- a SHINY thing! What were we talking about? Where am I?

Will there be cake later?

Reply to
The Artist Formerly Known as K

Oooh so pretty.

I think we were talking about robots and how to build them,

Let's forget about that.

shiny.

mmmmmmmm.

Rich

Reply to
aiiadict

Oh come on now. I'm from freak'n Boston, MA USA. Born here, raised here, and gosh darn it, I even pay taxes here.

Jeez, dude, have you looked at your country? Do you have *any* children in public schools?

The mere fact that creationism and/or "intelligent design" is even a debate over evolution in this country should scare any one with an intellect or an attention span out of their wits.

Sorry, I don't want this conversation to get political, and this is also a digression which proves my point.

This is one of those arguments that suck. To have "free speech" people have to respect free speech. Critisizing someone's free speech, not what they said, but that they said it at all, may be an excersize in your free speech, but it is also an intimidation and form of censure. Using your freedom to make someone else's freedom more difficult.

"I may not agree with what you say, but I'll defend to the death your right to say it" Voltaire

My favorite author, Douglas Adams, wote this and it is a great wording for what I want to say:

"To be frank, it sometimes seems that the American idea of freedom has more to do with my freedom to do what I want than your freedom to do what you want."

If you believe in freedom, it means you believe in other's freedom just as much as your own. If not, you're not really interested in freedom, are you?

Reply to
mlw

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.