Newbie: getting started in robotics. uC and board questions

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

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
Caution: Objects in mirror are more confused than they appear.

"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

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:
...

[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 -40°C to +85°C.


For more details, go to:
http://www.standardics.philips.com/news/lpc210x/  

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?

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
Caution: Objects in mirror are more confused than they appear.

"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?

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"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

(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.

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

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/

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
Caution: Objects in mirror are more confused than they appear.

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/

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
Caution: Objects in mirror are more confused than they appear.

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/

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
=====================

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

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
=====================