Newbie: getting started in robotics. uC and board questions

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.

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.

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.

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

=====================

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

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

=====================

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.