'General walker stupidity'
Phu T. Van
Hi, I'm planning a robot walker project and am frankly overwhelmed by
the options available :
1. Processor :
HC11 or PIC(16F84) ? I have access to a BotBoard and have recently
gotten the "no-parts" PIC programmer.
Well, apparently for some processor is strictly personal preference but
there is the obvious consequence of what programming language to use :
frankly, I would like to stay away from assembly because it seems that
the sine-calculations under assembly is something of a technological
miracle and major pain in the ass. But isn't it true that the HC11 has a
more diverse (read : complex) instruction set, which would be a set back
to the project in the long run ?
2. Serial communication :
Should there be 2 (or more?!?) processors involved, how would they
correlate their data input/output in a cooperative manner ? Again, pain
is not preferred. I understand that serial is one of the options. Are
there others ?
Any/all input is appreciated.
--Phu T. Van
|The HC11 has a superior instruction set(easier to use, alows more
complex operations easily), considerable slower instruction operation
speed, more and better pheripherals, is more expensive and also hard to
get hold of in DIL (dual in line)
The PIC is in my experience more "cost effective", however if you are
looking at smaller quantities then cost may not be an issue.
PIC has a huge user support base i.e. this list and maths functions
should not be a problem (if you realy need them) as Microchip have
application notes and assembler examples. Microchip development gear is
available at low cost and the MPLAB assembler/IDE is an excelent mature
Motorola do not (to my knoledge) provide any modern assemblers free with
68HC11 and the official development kits are not cheap.
Microchip have been slow to add FLASH program memory to their more
advanced products and Atmel have leapt into the gap in a flash, check
out their STK200 dev kit and AT90S8535 part, faster than motorola HC11
and PIC, lots of high speed registers and easy to use conditional jumps.
Very productive parts, assembler not as advanced as Microchip one
Microchip parts prices have lately seen some hikes, my belief is that
this is due to large customer base who are unprepared to learn new
processor instructions such as Atmel's.
"Phu T. Van" wrote:
I suggest Atmel '8535, very fast, why use two processors as they will
waste pins talking to each otherregards,
|a) Sine-calculations was never a problem if you use a simple table.
b) You should not choose a microcontroller based only in the fact that
it is easier to program. Several other variables should be considered,
as market availability, growing (hardware/software), processing power,
documentation, tech stability (bugs and surprises free).
c) Be sure that nothing is simple (except to blink a led ?), and so you
will find several problems and solutions.
d) For a robotics project, select the chip that has more possible port
pins, several "k"s of flash program memory, high processing speed
(>15MHz), UART (and/or ISP communication), and so on. Price is never an
issue (difference will be always few $).
e) as you say, "Pain" is not an option, you will find it ahead anyway.
The only way to avoid it; "ask somebody else to produce it for you".
f) Don't forget to see the AVR or 8051 family new chips.
g) Relax, smile and learn more about microcontrollers in general.
"Phu T. Van" wrote:
|I would argue for a distributed approach using many lower cost processors
rather than 1 expensive processor. For the price of one HC11 whatever
processor you could purchase a 16F84 and a number of 12C508/9 OTP's. The
8 pin PIC's (including some of the newer ones that have onboard A/D) are
perfect for motor/servo controllers, sensor controllers, communication
controllers, etc. By distributing the processing required for motor
control and whatnot to the small/cheap PIC's, the master controller
(16F84) can concentrate solely on the higher level functions of whatever
behavior you want your robot to have.
We (myself included) tend to think too much in terms of one
microprocessor doing absolutely everything which usually ends up with
extremely complex code. Whereas with the distributed approach, each
component (motor, servo, sensor) has a limited job to do that can be
coded much more simply.
Typical hobby walker robots use 2 or 3 servos, 2 touch sensors, and
possibly an IR ranging detector. Use one 12C508 to control the servos, 1
508 to monitor the touch sensors, and 1 508 to handle the IR ranging.
Use a 16F84 as the master and tie them all together with I2C and you
would have a very powerful, flexible walker.
Just my $.02 worth,
On Thu, 20 Jan 2000 09:20:33 -0500 Wagner Lipnharski <USTR.NET> wagner
> a) Sine-calculations was never a problem if you use a simple table.
> b) You should not choose a microcontroller based only in the fact
> it is easier to program. Several other variables should be
Adam Bryant (age 0x23)
Parker, CO, USA
Robotics, RC Airplanes
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
Be careful here, you'r reinventing the...dinosaur. I believe this is
how they were designed, the big Imperial walkers were so large
they needed a separate processor to run rear legs and tail, just
sent an occasional message to front brain that all was well in back,
head would look back occasionally to check status.
Alice Campbell wrote:
> Be careful here, you'r reinventing the...dinosaur. I believe this is
> how they were designed, the big Imperial walkers were so large
> they needed a separate processor to run rear legs and tail, just
> sent an occasional message to front brain that all was well in back,
> head would look back occasionally to check status.
> > I would argue for a distributed approach using many lower cost processors
> > rather than 1 expensive processor.
First, WAYYY too much quoted material on this list. Wastes bandwidth,
don't ya' know.
Second, he isn't talking about two controllers, two brains. But more
like the servo loop muscle control your own body exhibits. Spinal cord
reflex response level sub processing.
In the old cross your legs, doctor bangs under you kneecap with the
rubber mallet, he (or she) is testing your reflexes. This is a servo
loop going back only to your spinal cord, not all the way to your
brain. By banging on the tendon, he stretches the muscle. The muscle
is not supposed to be stretched like that, and the "kick" is the servo
loop response, atttempting to put the muscle (and you leg) back where it
belongs. So too, the 12c508's etc. would only be micro function
controllers, releaving the main controller of the need to waste clock
cycles on piddlin' little jobs like parking or ramping a servo.
Just as going to a Harvard archetecture frees up the data buss by
putting the program on a different one, using seperate processors frees
up the main processor to run the main program. With only ocassional
intervention to deal with servos. Kind of like interrupts, isn't it? A
simple timer running independantly, and activating an interrupt when it
times out. So the processor doesn't have to spend time, er, keeping
Russell Hedges wrote:
> Just as going to a Harvard archetecture frees up the data buss by
> putting the program on a different one, using seperate processors
> frees up the main processor to run the main program.
Unfortunately I am not totally sure that 12C508s or their ilk are
suitable. To network these processors you need communications; to save
I/O you need serial communications, so you tend to need processors with
either hardware UARTs or hardware IÓC.
"Baseline" controllers may not suffice.
Russell Hedges wrote:
Russell's typing fingers appeared to be controled via an active mid
brain, I've <<cut>> his response to Alice.
In practice "pidlin little jobs" like controling servos are highly time
intensive, the "main program" is only a part time job although it may
use significantly more code.
Control of a servo requires periodic PWM calls or dedicated hardware
PWM, acuracy requires good timing. Synchronisation of multiple servo
signals allows for minimisation of timing overhead.
"Main Programme" is subject to timing response lags of interfaced
mechanical gear and makes decisions based on gradually changing data.
In digital networks, the main advantage of distributed processors is
reduction of cabling.
Dino's mid brain may have been required to speed up pterodactyl swatting
so as to deter gouge'n'gorge feasting.
I am also working on a six legged robot.
The chassis is finished and I am starting on
the controllers, iam using a Handybaord(68hc11)
for the main brain and want to build a servo controller
capable of running 12 servo's (2 per leg), 12 ADC inputs
for position feedback of each leg and another 12 ADC
for monitoring current to each servo for detecting
jams and things like that, plus another 6 ADC for
some kind of pressure feedback from the feet, but
could maybe use the current consumption feedback
to detect feet on ground. I also want to add a
pan-n-tilt head to carry ranging sensors which
will also need an additional 2 servos and
2 ADC channels for positioning feedback.
This sounds like a lot of ADC channels but I
managed to design such a controller (not built or tested)
using 4 ADC lines and multiplexing them so
I could just have a looping program reading each ADC
inturn. The PWM signals for the servos where provided
by some 8 pin DIL chips called FT3?? something or other
by a place on the web called Ferro-tronics.com. These chips
could handle 5 servos at once and they also did a controller
chip that could handle 5 of the servo chips giving control of
25 servo's through a single serial line which went to the
master controller chip. all of this would
be controlled by a second stripped down Handyboard
with the servo controller board added as a expansion board.
The main brain would talk to the servo controller through
a SPI serial link. Phew now with all that out the way
I was wondering if anyone had any ideas on how to build
a servo controller out of a few pics networked together
to make a single controller as the stripped down
handyboard would just be sending serial data to the
servo chips and monitoring 4 ADC port which where being
1. Use 1 PIC (16F84 for ease of development, or 12Cxx for production) to
control 1 leg; 2 pins for the pulse width signals to the servos, 1(2) bidir.
pin(s) for communication with the main controller, 1 pin as an input for the
"heartbeat signal" from the main controller, and some for sensor inputs.
2. The main controller generates a fixed squarewave ("heartbeat") that
synchronizes all leg PICs; the rising edge is used by the leg PICs as the
timing signal to start the PWM pulses to the servos, at each falling edge
communication between controller and legs is performed.
The sync signal solves one problem of the low-end (leg-) PICs: servo control
and serial TX/RX are hard to do at the same time.
Communication could be done with IÓC or SPI-like ...
Having intelligent legs allows the controller to just say "put leg 3 down
until it touches ground", or even specify the desired force if you have an
analog pressure sensor with serial A/D for each leg. In a status scan (maybe
with a global address) the legs could report if the commands were executed
or what went wrong.
The name is "distributed processing", it was first used at IBM mainframe
computers 43XX family (internal subfunctions), later on spreaded with
inteligent computer terminals, today with your Internet home PC. No one
even think to use a dumb terminal (VT52 or other) at home connected to a
mainframe anymore, isn't?
Question: If you produce a multi-processor robot system, that uses 5
microcontrollers, exactly the same type, and one will be the Master
processor, it will be an ellection to decide which one will be plugged
at that socket? :)
Russell Hedges wrote:
> Second, he isn't talking about two controllers, two brains. But more
> like the servo loop muscle control your own body exhibits. Spinal cord
> reflex response level sub processing.
More... (looser matching)
- Last day of these posts
- In 2000
, 2001 only
- New search...