Newbie: getting started in robotics. uC and board questions

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.
Reply to
Randy M. Dumse
Loading thread data ...
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
formatting link
Reply to
D. Jay Newman
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.
Reply to
Randy M. Dumse
Oh, I can't remember the last time I updated on this. So forgive me if something is repetitious.
I talked my Alma Mater into having a class this spring on intro to robotics, where they are building Mark III Mini Sumos with our PlugaPod(TM) and our Mini Sumo Adapter board. We'd originally wanted to use the PlugaARM(TM) for the processor. But they weren't ready. So we shipped them half a dozen with PlugaPod(TM)s to get them going. Since then, I've been working on this project as if it were a PlugaPod(TM) project. (I'm trying to help write the curriculum now)
A few weeks ago, 15yo James Koffeman, who participated in its programming effort with me, took the unit you see on the web site into the DPRG Table Top contest, and took 1st place in Mini Sumo and 2nd place in line following.
In the mean time, the PlugaARM became available in two forms, one the original Pluga2129, and the other the Pluga2138. I really should go back and review if the signals on these ARM based boards align with the Mini Sumo Adapter board. I'm fairly sure one or both of them will, but since the engineer who was working this job left for a position with home land security, some of the continuity was lost, and I guess it is up to me to go back and be sure everyting "lines up" signal wise, so you have A/D's where you need them, and PWM where you need them, etc.
Alex, if you're interested (and there's not a conflict of interest for you to do so), we'd trade you these boards for a check out and a sample program for basic line following and Mini Sumo operation. Contact me by email if you want to arrange something like that, which I think could be a win win for both parties.
Reply to
Randy M. Dumse
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.
formatting link
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
formatting link
Reply to
dan michaels
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
formatting link
Reply to
D. Jay Newman
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
formatting link
Reply to
dan michaels
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.
Reply to
Pat Farrell

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.