Newbie: getting started in robotics. uC and board questions

I have been thinking about playing around with robotics in my spare time and have been searching the net and newsgroups for information but
have become overwhelmed with all the information flying around. I want to try and build a robot that will use extensive servos (hexapod or arm type of project) that will use sensors and its own AI rather than human controller. THe current controllers I have been looking at are the OOpics and the AVRs (STK 500). I program in C/C++ and Java so those 2 looked pretty good. I took a look at the IsoPod/IsoMax stuff but don't want to have to pay that much and learn a new language just starting off. THe OOpic stuff looked good but I felt that to much of the stuff was already programmed into it and that it would take much of the nitty gritty stuff out so I wouldn't learn as much. Anyone else feel the same way? I've taken a look at avrfreaks.com and tried to grasp some of the basics of the AVR, but still seems confusing. But it seems many people are raving about these.
Any help would be greatly appreciated.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I think the STK-500 would be a solid way for you to get into microcontroller programming. I initially tried using the tutorials at avrfreaks to learn how to program AVRs - but luckily I found http://avrbeginners.net/ which is orders of magnitude better for beginners. I would reccomend that once you've written a couple programs in assembly you only then think about switching to C. Best of luck
-M Noone
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Well, you don't have to pay that much, and you won't get that much either. But since I make the IsoPod(TM) and invented IsoMax(TM) etc. you can assumed I'm biased.
These sorts of post, "which processor" are rather perenial, and usually touch off a "processor war" because we all have our own favorites. Some guys get very fond of one particular processor and stick with it, and some of us switch our favorites over the years as newer things come out.
You are more likely to find more PIC and AVR users, because they have been around since (approximately) 1990 and 1997 and many folks stick to what they start with. There will be more literature and also many examples because they have accumulated over time. (But for that matter, the 68HC11 is also a good choice with lots of robotics literature.)
You can do a considerable amount of computing with a PIC or an AVR, (or HC11) but you usually have to resort to assembly level programming with interrupt driven programming to get the very most out of them.
On the other hand, since you might want to stick with what you start with, it would make sense for a beginner to go with something more modern, with more capacity and more future growth potential. I'm very impressed with the ARM lately. Our ARM boards are running neck and neck with our 'PODs and there are many ARM chips running even faster, hundreds of MHz. Philips announced last week a series of ARM chips that sell for $1.47 in 10K quantity. That's pretty amazing: a 32-bit processor with big memory under two bucks. I don't know of anything else out there that can compete with so much bang for the buck.
I think if I were starting out today, and could only do one, I'd go ARM.
--
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 <snip>

I've started using PIC and mikropascal a year ago and I'm very happy with it. But the ARM keeps drawing my attention. I have a dev board with a philips LPC2*** that I'm trying to get me motivated to do something with it. The only disadvantage I see with ARMS (and please correct me if I'm wrong) is that packages are too small and SMD only... in order to do a quick and dirty prototype you'd need to have an adapter board or something similar.
Padu
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Back in the early 90's I was working for the USAF keeping track of utility purchases and resale at a couple of thousand sites in the Dakotas and surrounding states (missile sites, bombing ranges, ect). This was around the time that 486's were coming out. I was handling all of this on a Zenith 100 which was a partially compatible 286 machine. It got the job done.
The point of this is that you don't need the latest technology to get the work done. PIC's and AVR's are cheep. There are lost of examples out there describing how to use them. There are plenty of different programmers and programming languages available for them. At some point I'll need to use a POD or an ARM7 because I can't do it any other way, but for now, I am making entire robots for less than the cost of a TinyPOD.
Randy, you make a great product and it can be used fairly easily by a beginner, but for a beginner to use a POD to run a line follower or a sumo bot is sort'a like using a Humvee instead of a bike to deliver papers in your neighborhood - overkill. On the other hand, a Humvee is great for desert recon where a bicycle would fail miserably just like your POD's can easily handle some very complex problems that take multiple PIC's and incredible programming finesse to even attempt. The right tool for the job.
Eventually, DSP's and ARM7's will be so cheep that they will be used for every little project, but PIC's have at least a good five years left and AVR's at least a decade. By then, the early adopters will have plenty of code examples and a broad choice of highly efficient free compilers for upper level languages that working with them will be easy even if you spend the last decade working with the old tech.
Paul Pawelski Randy M. Dumse wrote: ...

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

Philips just announced a few new lower priced arm7 chips LPC2101 (8KB flash, 2KB SRAM) LPC2102 (16KB flash, 4KB SRAM) LPC2103 (32KB flash, 8KB SRAM)
see very bottom for announcement text
http://www.standardics.philips.com/products/lpc2000/pdf/lpc2101_2102_2103.pdf app notes
http://www.standardics.philips.com/support/appnotes/microcontrollers/all/?scope=LPC2103&items 254,10256,10331,10356,10369,10381
http://www.standardics.philips.com/products/lpc2000 /
Which are going to be cheaper than pics , may take a while for pricing to trickle down for small quantities.
70MHz , 17MHz IO speed , 2 uarts , 10 bit adc ,2 timers up to 32 5v tolerant inputs , on chip oscillator
Big bonus is plcc 44 , aimmed at replacing the plcc44 8051 and pic plcc44 chips.
Seems plcc44 will be available some time after the tqfp.
Gcc for arm7 is already fairly easy to use.
Make files can be a a pain to learn.
These tell you how to set it up with the free eclipse ide see http://www.newmicros.com/download/appnotes/ARM/TiniARM_Dev_Eclipse.pdf http://www.newmicros.com/store/product_manual/GNUARM/GNUfiles.zip
and http://www.sparkfun.com/tutorial/ARM/ARM_Cross_Development_with_Eclipse.pdf http://www.sparkfun.com/tutorial/ARM/sample_programs.zip
Can use the demo version of Keils ide + armgcc or their compiler. GCC isn't restricted in any way only Keils debugger only supports programs up to 16KB http://www.keil.com/arm / http://www.keil.com/demo/limits.htm http://www.keil.com/demo/eval/arm.htm
Same with the Kickstart versions of IAR's arm tools for the lpc2xxx chips http://www.iar.com/index.php?show &461_ENG&&page_anchor=http://www.iar.com/p26461/p26461_eng.php
Alex
Philips today announced the 3 newest members of the LPC2000 family, the LPC2101, LPC2102 and LPC2103.
Built on 0.16um flash process, with 128-bit wide access, the trio operate up to 70HMz, 63 MIPs, making them the fastest Flash ARM7TDMI- S-based microcontrollers on the market. In addition, the new LPC210x members feature Fast I/O capability allowing bit-toggling operation of 17.5MHz, more than 4 times faster than other competing ARM microcontrollers. At the same time, these MCUs incorporate innovative power management features that allow deep power down current consumption, with the real-time clock running, to be less than 10uA.
LPC2101 (8KB flash, 2KB SRAM), LPC2102 (16KB flash, 4KB SRAM), and LPC2103 (32KB flash, 8KB SRAM) will be available starting November 2005. The per unit Manufacturer Suggested Retail Price in quantities of 10,000 are USD $1.47, $1.85, and $2.20 respectively. Packages are available in 7mm x 7mm TQFP-48 and PLCC-44. These new devices are specified at an operating temperature range of -40C to +85C.
For more details, go to: http://www.standardics.philips.com/news/lpc210x/
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Quite honestly, I can't imagine what you guys can be building. At the same time, I haven't a clue what I would do with a LQFP64 package. 18 pin thru hole DIPs is much closer to what I can make use of. Small qty chip prices aren't that far apart between PICs and the ARM, but what do you prototype on? Am I the only one without a wave solder station at home, or do you guys just buy the $200 dev kits?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Really? Not to be contrary, but, I find I can tax out a processor pretty completely these days. Let me give you a brief accounting of my very recent efforts...
At the moment I'm in the 18 servo hexapod walker code, trying to figure out how to start a gait from standing, and return to standing from walking smoothly.
I'm also trying to figure how I can make the walker turn smoothly around a point. I thought I had a simple understanding of it based on Ackerman steering, but I was going at it a little too simplisticly. I was already doing quite a bit of trig to stretch the key pattern to fit the desired direction of the body. So now I realize I need a ton more trig functions to figure how to angle the legs, not just the stroke, relative to the commanded turning point.
I've found I can do gaits and walking pretty well. The turning is starting to stress my 80MHz DSP. I figure it's my fault because there has to be a simpler algorythm for what I'm trying to do. I am doing too many calculations per second.
In the mean time, I've set aside the Robomagellan Tank project I was working on. There I had two channels of PID control of the motors with Odometry, Navigation, Drive to a point, and GPS monitoring all running on one processor. I have yet to integrate in the CMUCam color tracking works. I'm not going to make it to the contests this year though, due to some health set backs.
A couple weeks ago, I got a 115200 baud radio link going for them with the SparkFun bluetooth interface. Nice to have your robot operating autonomously, and still have an interactive data channel to be able to gather data, and tweak values while it is on the move.
Can a PIC even bit bang a UART at 115200, and have any significant amount of cycles left over to do something useful? I'm rather doubtful, and I don't think they have UARTs that run that high, either. So using one of those processors would likely mean my data channel would be limited to much lower rates.Tragic? Maybe not. But what does it do to my productivity? What is my time worth. Are my tools enabling me, or hindering me?
My point is, I'm trying to push the envelope on robotics, and PIC's and AVR's are not well suited to play there. Even the wonderful processors with 20x performance I'm using are stressed there. And they have hardware support built in to handle tough motion control issues (without any processor intervention!) that lesser processors have to bit band to have at all.
So I know the future of robotics is not with the processors of the previous decades. And the future of robotics isn't with the processors of today, either.
Perhaps the next generation of processors will start to do what we really need done. Since it looks to me, the ARM has a clear path of non-obsolesence for a generation or two to come, that's why I wouldn't bother with lesser processors today, but if I could only learn one, I'd learn the ARM.

No, most don't have a wavesolder machine at home. I don't. In fact, what you'd need to do this SMT really is an IR oven anyway. No, most don't have those capabilities, so they buy the development kits.
But that's rather my point. My company will sell you a development kit for a LPC2131 for $29. It has all the hard stuff (multilayer, LED's Xtal, RS-232, power conversion) done. You just hook up to .1" pins. And if you find you run out of RAM or Flash (8K/32K), good news, we have a whole line that fits in that same board format, with up to 64K of RAM on one type board, and up to 512K of Flash on another. BTW, I see the DKits on these higher end units are less than $100. While I may have the low price point with our $29 board, I assure you, I am not the only vendor out there selling development kits for ARM's in this ball park.
So, back to the original poster's quandray, I don't know any other processor, than the ARM's, where you can buy one for less than $2 and buy another with the same base core that will challenge the computing ability of the best PDA's. ARM has just taken a unique place in computing history that no other processor has ever attained.
--
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"

This thread is being very instructive to me, it is closely related to the poll I posted earlier too.
Although I still think there will be plenty of live left for PICs, Atmels and other MCU's, for harder stuff I know it must be ARMs, DSPs or something better that could come up in the next few years.
So, knowing that there are kits and adapter boards available, I still want to be able to solder the IC to a board of mine. Is it still possible (note that I'm not asking if it's easy) to make my own board (photosensitive) at home and hand solder one of those little chips?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 5 Oct 2005 13:12:08 -0700, the renowned "Padu"

The LPC chips come in a 0.5mm pitch QFP. Personally, I have no fear of soldering small quantities by hand onto commerical-quality boards.
I am not so sure about using a home-made board-- you're talking roughly the equivalent of 8 mil lines and spaces, which is fairly fine. It should be possible with photosensitive (preferably heat- laminated photoresist), probably not with toner transfer.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
snipped-for-privacy@interlog.com Info for manufacturers: http://www.trexon.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
(115 kbaud? I think they do. USB works too well and too easily to bother.)

That's rather my point, as well. It's not $2 a chip to me, or even $29. It's more like $89 (Pluga21xx) to do anything useful. As the business owner, you already know that. Just the same, I don't mind spending the money where it's earned.

Alright, I'll play. Shopping from your shelves only, what do I need to get started (and be reasonably happy with 4 years from today, to match the PIC's track record)? I want to develop on my Windows or Linux box, push it to the processor, and have it act in a motor control and power management role. (Drive a few BLDC motors, some sensorless, some with Hall sensors, some with quadrature encoder; two three phase AC induction motors; read a few 10-bit or better ADC channels, monitor a handful of digital lines; converse with the controlling PC, exchanging status and command info. USB would be nice; IR or RF would be better; hardwired UART would need strongly compelling compensation.)
If you care to put together a list, add a "Buy Now!" button. I might be crazy enough to hit it. Tack on a dummy tax if you like, for doing my legwork for me.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
For what you are doing, you have the right tool. For what I am doing it would be the wrong tool. I just finished the first draft of the first article in a series that I plan to submit to Servo entitled "Beginning Robotics for $50 a month". While the first article was about necessary tools, how to solder, and things to look out for when shopping online, the second article builds a complete, programmable, expandable robot for $50. Even with the extremely good price of your $29 ARM board, I could not hit my price target if I used your board. I am using a DIP ATMega8, internal osc, simple cable programmer. It does what I need at a total price I can afford. My bots are running (well, one is half torn down so I can take pictures for the second article, but it was running before and will again) on a $5 processor with $2 worth of power conditioning. The $22 I saved compared to your board paid for motors, H bridge, and battery holders.
If I can fight my own laziness and write the entire series, I will be able to show all the basic sensor and communication interfaces with that AVR. Each month adding enough new capability to keep a novice interested in those tough early months. Beginners need cheep, simple, and easy to understand. POD's are simple and easy to understand, but they are not yet cheep. ARM's have dropped dramatically in price, but the need work with SMD makes you trade off either simple of cheep.
Like you, I got a Stewart tank waiting to become a robo-Megellan contender. If I ever get to it, I will probably need more powerful processors to make it work (although I am a sucker for distributed systems). At that point, I'll have to take a good look and see what is the right tool for the job. There is a good chance I'll place an order with you for one of those ARM boards, but there will probably be a PIC or two in there too.
Paul Pawelski
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Randy M. Dumse wrote:

But you can push the envelope by using multiple processors.
Perhaps you could handle the turning easier if you had one processor per leg handling the kinetics and sensors for that leg. And a more central processor that handles the interaction of the legs.
In the future we'll have procesors that can do more. But for now we have to work with what is available. I've seen people do wonderful things on a small PIC, and see people flub a robot with a PC.
I think that it's what we do with what we have available that counts.
For now I'm looking for a good single-leg processor. It would need to: 1. Handle motor control for three/four motors 2. Read encoders from each motor 3. Read sensors on the leg to verify pressure and position. 4. Communicate with other processors in the system.
Perhaps the Tiny-ARM can do it. I don't know. Maybe even a Tiny-Pod (I like Forth). Heck, perhaps even an AVR or PIC can do it if I tune the algorithms right.

I don't know enough about the ARMs to make an intelligent decision. They look like they have the computing power, but do they have the microcontroller peripherals, like ADC and PWM?

And you have a pinout that I would have to create a custom PCB to use. The rows of pins are too close together to fit into a breadboard. I can use your dev kit but that adds money on top of the Tiny-ARM.
Also, I would have been *much* happier had you just had TTL-level serial communications instead of RS-232. I generally prefer to communicate with other processors. If you're going for an "RS", I would have preferred RS-485. Of course, that is personal preference. -- D. Jay Newman http://enerd.ws/robots /
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Perhaps. We may yet find that to be true, but I don't know if I can fully agree, yet. I haven't yet seen a cluster of processors doing much useful that can't be better done with a few processors running at higher speeds. A more successful architecture than Van Neuman really hasn't been found. Not that I know of anyway.
Looking at the biological model, we have one brain. Now it is true, preprocessing is distributed, and some reactions are lower than brain level responses (essentially hardware responses). But still, there's one central brain, and I still think that's the model nature favors.
I've already made the argument many times that using lower level processors may not really make the real time programming easier, but actually worse. Each processor you add adds two more communications tasks.

Perhaps. Others have suggested that too. At the moment, I'm trying to pack a single processor out as far as I can. So far it seems there are body issues, and leg issues. The body issues need to be figured by the central processor. For instance, the angles the stride each leg makes depends on its body-relative position to the turning point. If each leg was allowed to select its own turning point... well... I think the absurdity is strained but obvious.
So there are levels of information that dictate (to my way of thinking) the level of processing they should be done at.
On the other hand, things like motor control, such as what goes on in the RC Servo electronics, if you want to go to that level, yes I can see a processor dedicated to that.
But really, the beauty of software is it can be used to simulate hardware, but with much much greater latency. If you can tolerate the latency, the processor can be useful. However, I think we spend far to much processing power on what should be done in hardware.
Take, for example, quadrature decoders. The reason I favor our Pod's for motion control (among other reasons) is they have hardware decoders. There just aren't many processors that have built in hardware quadrature decoders. The Pod's hardware can go up to 40 MHz without skipping a beat. The faster the quadrature lines come, the finer your control. You can certainly make a quadrature decoder out of a PIC. How fast can your encoder go though? The PIC is maxed out at something like a few hundred KHz of quadratre capture, and there's still the issue of how do you get the info out (serially?), and whether getting the data out causes its useful reading speed to be compromised. And then too, what is the latency of the encoder reading once you've got it out?
In the Pod the decoder is just a memory access, and perfect results. It is very hard to compete with hardware and get to the peak of system performance.

Because of the need for three motors, and the TiniPod(TM) can do quadrature-in on three channels and complementary PWM out on three channels, the hardware issue would decide the choice for me. I personally wouldn't try to use an ARM for that if a Pod were available. If it was truly 4 motors, I'd go to a more advanced Pod.
Because the DSP was designed with motion control in mind, I really don't have a second choice.
Yes, you could possibly use a AVR or PIC. Probably only doing one motor at a time, from the examples I've seen. You have to ask, at what level will the performance turn out? Could I have gotten more performance if I chose 4 PIC's or AVR's, or would it be better with a single Pod. Because of the special purpose hardware in the Pod, I'd have to say yes.

Computing power, yes, I'm pleased. A/D and PWM, well, look carefully. From us, the TiniARM(TM) doesn't have A/D and the PWM pins were not all brought out. Of course, we have a much better choice if you want motion control in the Pod's and we have the PlugaARM(TM) with lots of A/D.
I'll tell you the worst thing I've seen so far about the ARMs, that is their I/O is slow. But Philips is on it, and these latest ARM's are getting better.

I don't see why you assume you would have to create a custom PCB to use our boards. We do provide a layout to accept our PlugaXXX board formats for people who want to make their own 2 layer boards. But that doesn't mean you have to make a board to use a TiniXXX or PlugaXXX.

The pins are .1" dual row, which is the spacing of most breadboards.
Do you mean the white "push-in" Solderless Breadboards? The kind a Stamp can strattle and have two rows of pins on either side? Okay, you'd need an adapter to take our pins and spread them out far enough to strattle the white prototyping boards. No problem, we've got them, if that's the way you want to use it.

Yes, but you can wire directly to the pins, or you can even put it in a prototype board and wire wrap to its pins, or you can get a .1" dual in line 24-pin socket and wire to that.

Well, go ahead and be much happier. The TTL level serial is there. All our TiniARM(TM)'s, TiniPod(TM)'s, PlugaARM(TM)'s PlugaPod(TM)'s have a three pin TTL level connection to their primary serial ports at the front board edge.
--
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:

I don't know. Most microcontrollers use the Harvard architecture and that seems to work well.

However, our brain has several major parts.
Also, some reflexes don't get as far as the brain before coming into play.

If the network of processors is designed poorly, communications overhead can kill you.
However, using the biological analogy again, our brain is more interconnected than anything we've built on purpose. And the brain *works*.

...
I can understand and even agree with that point of view occasionally.
However, I'm a software and mechanics guy. I prefer to use a processor than to use actual electronics for the most part.

You can buy chips just for this purpose also. However, I do like the Pods.

That's why I like using a single processor for closed-loop control: the same processor reads the encoder and produces the PWM.

This is nice, I'll admit.

...
The Pod can do three quad's and three PWM? Great! I'll have to try this.

There aren't any boards I've seen that use your pinout. Which is nasty because they Tiny-Things put a lot of computing power in a little space.

Yes, I mean solderless breadboards. I *hate* point-to-point wiring.
And I didn't see these adaptors on your site.

Yes! I kept seeing RS-232 in the docs and that just threw me.
One other thing: is there a way to power the Tiny-Pod from +5V or less? It's a pet peeve of mine that everything now has to have a voltage regulator on it when I already have a +5V regulated supply voltage.
I don't mean to sound like I'm picking on the Pods. I *like* them. I even like programming in Forth. I prefer Java, but Forth was one of the first computer languages I became proficient in so it holds a place in my heart. -- D. Jay Newman http://enerd.ws/robots /
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Yes, the TiniPod(TM) and PlugaPod(TM) can do three channels of quadrature input. One hardware quad, and four timer lines are brought out for that purpose (timers have mode that they can do quadrature as well). There are six PWM outputs.
The IsoPod(TM) can do 6 channels of quadrature in, using its two hardware quadrature decoders, and again, the timers can also be used as quadrature counters. It has 12 PWM outputs.
The ServoPod(TM) has all that, plus with double the A/Ds. So with16 12-bit A/D's it can do closed loop control on 16 analog motors with pots for position feedback. (Like RC Servos do.) (This time 4 timers are used to generate PWM. Gotta love those timers on the DSPs. They have to be the neatest timers I've ever used on a micro. Very flexible with many functions and modes.)

We follow the stamp pinout almost exactly, except instead of being .6" wide, we're .1" wide. But the power is in the same place, the serial in the same place, the reset in the same place... and 16 port pins below those. Of course our pins a less "general" purpose. We tried to route out the signals with the most hardware functions.

No, but we've got them. I'll ask LC to add them to the web site.

Well, good news and bad news. Yes you can feed the board with 5V. But it will regulate it down anyway, because it is 3.3V only internally. But yes, you can feed either rail, or the unregulated Vin, and it will work.
--
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:

Well, there goes my last major objection. :)
I'll think about using the Tiny-Pods as leg controllers for my next bot. -- D. Jay Newman http://enerd.ws/robots /
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Randy M. Dumse wrote:

This is very much of a misrepresentation, I think. We have one brain, but it has literally 100's of subsystems or modules, which are "specialized" for different tasks. This is a result of evolution, not prior planning. Neural modules were built on top of modules on top of other modules over the past 500MY of evolution. The brain doesn't have one generic computer which simply runs a lot of subroutines. It has a lot of specialized computers for different tasks. You can cut these out, one by one, and you lose the functionality associated with that module [cf, what happens after strokes, brain lesions, etc]. There are separate subsystems for vision, speech, motor activities, on and on. You can make the argument that you can do in software what the brain does in hardware, but that isn't really how the nature, viz-a-viz the brain, actually solved the problem.
However, regards the inter-communications problem, this is a tough issue. The white matter of the brain consumes a lot more volume than the grey matter, and the white matter is the billions of nerve fibers which interconnect the 100s of different modules. Fact of life is, it does take a lot of intercomms to coordinate all those separate modules containing 100B or so neurons.
================ That being said, I'll reiterate what I said in the other post on this thread. It seems to make a lot of sense to use separate hardware devices for different "major" functions. IE, it makes much more sense to have a different computer to perform vision than used for say motor or planning activities. The advantage of this route is that you can scrap or upgrade the main computer, but keep the vision processing hardware-software subsystem intact. Why start all over with new hardware interfacing issues, and possibly having to rewrite much of the software for vision processing, simply because you want a more powerful computer for planning, learning+memory, etc.
This is essentially how nature solved the problem, too. To get better vision, it essentially evolved new and separate vision-processing modules on top of older ones. Frogs, for instance, have an optic tectum, plus 1 or 2 areas nearby, for processing vision. Higher vertebrates, like mammals, still have the analog of the tectum [ie, the superior colliculus] in fact still functioning, but have added an additional 30 or so modules in the cortex, which are each specialized for processing different aspects of visual input.
I can see why you're arguing in favor of using a more powerful computer for a robot than a limited PIC or AVR, but step back for one minute at look up at the "next" level. You have to realize that any DSP-based system like an isopod also has significant limitations, when it comes to executing "all" of the processing needed for, say, true AI. For this, you needs scads of memory store, and billions of processor cycles, and need to integrate dozens of different I/O and sensor systems, requiring a lot more than is available on any small DSP-based board. IOW, the isopod is nice in terms of its power compared to PICs/etc, but go up one more level, and its best role becomes that of a co-processor for a more general processor. So, you're still stuck. It's fine for a small robot with limited functionality, but not for a more general system.
============= But, this has gotten far beyond "Newbie: getting started in robotics ...".
In fact, my suggestion for someone in that situation is to start with something very easy to get up and running, and for cheap, like a Basic Stamp or OOPic processor, and a Boebot or MarkIII base, and to use this processor/platform a "step" along the learning curve.
There are many many issues involved in getting even a simple robot to work - mechanics/hardware, motors/locomotion, sensors, basic electronics, hardware-software interfacing, logical programming, on and on. There are many places in this list that trip up beginners, because a robot is really a "system", not just a bunch of parts. Once a beginner gets a simple bot to go, then they can use the knowledge gained in accomplishing this to take the next step, which will invariably involve more power, more parts, and more money.
have fun, - dan michaels www.oricomtech.com ====================
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
dan michaels wrote:

There is a serious group who if medical researchers who think humans may have a sub-brain or second, specialized one, in the digestive system. No solid proof one way or the other.

True in wetware and software.

Plus, multi-programming realtime system is hard. KISS makes sense.

And into serious software engineering and other fun topics.
--
Pat



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

Oh yes they can and they do. You might not have caught it on yahoo seattle-robotics forum, but Lyle.C was actually using my PIC-based MSCC20 servo controller on his walker prior to switching over to your servopod.
http://www.its.caltech.edu/~lyle/walker.html
However, he was doing things with the MSCC20 that it was never really meant to do. First off, running at 115.2 [which is built into the chip], but he was streaming data through it from his 400MHz XScale Gumstix Processor. So, controlling multiple servos at 1-usec resolution, plus streaming data constantly through at 115.2. The only real trouble he had was that 2 of his digital servos were being used with low deadband settings, and they were jittering too much. In fact, had he ever told me what he was trying to do, I could probably have fixed his problem, a couple of different ways - first off would have been to switch off the automatic velocity ramping, which takes large #cycles to compute, and which was interfering with his attempts at real-time closed-loop control, and secondly to fiddle with how the UART control was handled. Too bad he never told me what he was trying to do. I could have saved him some money.

This is another issue, besides what was mentioned above, and I do agree with you here. PICs and AVRs are ultimately limited, the worst problem being the limited amount of usable RAM, but as you know, we have a fundamentally different idea regards trying to do "everything" with one processor. I still think going the co-processor route makes more sense - *especially* when it comes to upgradeability [ie, why start completely over from scratch with each new cpu?]. And this is what Lyle did anyways. He ended up using the servopod as a servo-coprocessor for the Gumstix, which was being used to calculate real-time closed-loop PID for 12 leg joints.
- dan michaels www.oricomtech.com ====================
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.