Searching \ for 'PIC Networking ideas ?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'PIC Networking ideas ?'.

Truncated match.
PICList Thread
'PIC Networking ideas ?'
2000\03\01@060317 by Russell Farnhill

flavicon
face
Hi all,

I want to build a 12 channel R/C Servo controller for a
six legged hexapod robot.

The controller needs to have positional feedback using
potentiometers, and current monitoring feedback to detect
obstacles and jams etc. The controller must be able to receive
commands from a master controller that deals with higher level
functions and also be able to send back information on the state
and position of each leg.

Each leg needs:
2 PWM signals for servos.
2 ADC channels for position feed back (Swing/Lift).
2 ADC channels for monitoring current e.g. jammed leg, obstacle, etc.

I thought of using one pic or micro controller to do the whole thing,
but maybe a modular approach would be better and have a pic controller
for each leg and network them all together. I was also thinking of having
a master supervisor pic that handles all the network traffic commands/info
from the main controller to the leg pic modules.

Also the controller would need some scope for future expansion as each leg
has currently got 2 servos giving a leg two degrees of freedom vert/horz,
but
I would like the option to add a third servo to each leg bringing the total
to 18 servos, This is why I thought a modular approach would be better.

My questions are:

Is this type of networking possible,easy,hard ?

What type of pic(s) would be suitable for the job of leg controller
and master controller ?

Does the whole architecture sound ok or is there better ways of
doing this ?


Cheers,

Russell.

2000\03\02@053547 by paulb

flavicon
face
Russell Farnhill wrote:

> The controller needs to have positional feedback using potentiometers,
> and current monitoring feedback to detect obstacles and jams etc.

 This sounds like duplication to me.  While it is nice to have current
feedback, surely an overload situation is detected when you command a
given movement and the positional feedback indicates it has not been
achieved in a reasonable time?

 If in fact you are using servos, these *already* have positional
feedback.  You could alternately use current monitoring and not position
indication and simply say that if the current is not excessive, the
servo *must* be in the position to which it was commanded.

 Three levels of current detection would probably suffice - stopped, in
motion, and blocked.  There are time sequences to be considered - it is
OK if the motor briefly flashes a "blocked" pulse as it starts, as long
as this settles.  Similarly it should stop sooner or later.

 Finally - I have some BG Micro servo assemblies - potentiometer, motor
but no logic.  Could be controlled by an H-bridge and one ADC channel.
Two PWM steps should suffice.  If you know how hard you are driving the
motor, its load is deduced from its rate of position change; if you are
driving it and it isn't moving at all, then it's obviously blocked.
There is the option to briefly power it up to full; if it still doesn't
move, then shut down.

 All-in-all, I think three control ports per FOM is something of a
luxury.  In fact, you have to decide how you *will* use the reduplicated
functions.  If for example, you are driving for a certain position as
indicated by the position sensors, how do you know what value to command
the servo so that it moves to that position, and only to that position?

> The controller must be able to receive commands from a master
> controller that deals with higher level functions and also be able to
> send back information on the state and position of each leg.

> I thought of using one pic or micro controller to do the whole thing,
> but maybe a modular approach would be better and have a pic controller
> for each leg and network them all together.

 By what protocol?  IÓC?  Serial bytes (as RS-232 but using 5V bus)?
SPI?  You may well use a lot of processing power of a small chip just to
perform the communication protocol - that is my biggest concern about
"distributed processing".

> I was also thinking of having a master supervisor pic that handles all
> the network traffic commands/info from the main controller to the leg
> pic modules.

 Elucidate?

> Also the controller would need some scope for future expansion as each
> leg has currently got 2 servos giving a leg two degrees of freedom
> vert/horz, but I would like the option to add a third servo to each
> leg bringing the total to 18 servos, This is why I thought a modular
> approach would be better.

 It does sound neat, and could for example use a serial (UART) bus,
split into "up" and "down" paths with leg controllers answering to polls
from the master.

 Consider also "segments" where a PIC controls two opposite legs, so
you have four PICs rather than seven.  Is one PIC16F87x cheaper than
two 16F84s (plus ADCs)?

> Is this type of networking possible,easy,hard ?

 I suspect the high-level part (movement command language) is
relatively easy, the low-level (simultaneous communication *and* servo
pulse generation) part, tricky.

> What type of pic(s) would be suitable for the job of leg controller
> and master controller ?

 Preferably ones with UARTs and/ or PWM hardware and ADC inputs if you
really want position sensing.  Like a PIC16F87x.

> Does the whole architecture sound ok or is there better ways of
> doing this ?

 Sounds like fun.  I'd think the simplest way to start would be either
the BG Micro servo core with H-bridges and DAC, or standard servos with
quad comparators (LM324 variant) registering a servo current threshold
or perhaps two thresholds.
--
 Cheers,
       Paul B.

2000\03\02@075038 by Russell Farnhill

flavicon
face
Hi Paul,

Thanks for the reply !

I have alaborated on a few points.


>   If in fact you are using servos, these *already* have positional
> feedback.  You could alternately use current monitoring and
> not position
> indication and simply say that if the current is not excessive, the
> servo *must* be in the position to which it was commanded.

I am using HI-Tech R/C servos and was thinking of tapping the position from
the
internal pot inside the unit. I think just current feedback will probably be
enough as you point out..

> > The controller must be able to receive commands from a master
> > controller that deals with higher level functions and also
> be able to
> > send back information on the state and position of each leg.

The master controller is a HANDYBOARD (68HC11 with 32K Ram) which
I built some time ago. Comms would preferably be TTL Serial line.

{Quote hidden}

Not sure on what protocol to use but something simple to program and
impliment
as I am only just starting out on PIC's

>
> > I was also thinking of having a master supervisor pic that
> handles all
> > the network traffic commands/info from the main controller
> to the leg
> > pic modules.
>
>   Elucidate?

Some kind of middle man pic which sits inbetween the pic leg modules and the
main
controller (HANDYBOARD). So the handyboard can say move forward 10 steps and
the middle
man can dish out all the relevent commands and step sequences to the leg
modules. This
would save the handy board having to send separate comands to each leg
module, well
thats the idea anyway.

{Quote hidden}

What do you mean by "up" n "down" paths ?

>
>   Consider also "segments" where a PIC controls two opposite legs, so
> you have four PICs rather than seven.  Is one PIC16F87x cheaper than
> two 16F84s (plus ADCs)?

I was guessing on one pic per leg as I was not sure if one pic could handle
the timing
of more than 2 PWM signal for each leg, but it would be nice to control to
legs with one
pic.

{Quote hidden}

Are the comparitors replacing ADC for current sensing ?
I thought ADC would be easier to calibrate in software rather than a
external hardware solution ?

> --
>   Cheers,
>         Paul B.
>

Thanks,

Russ.

2000\03\03@100954 by Jeffrey D Spears

flavicon
face
Hi Russell;
Funny you should mention all this--sitting here on the scratchpad
next to me is a quick little 'proof-of-concept' doodle of what
you are talking about.

At first I was thinking that a 12C6xx on each pin communicating
with a central cpu (16f876 on my drawing) via i2c. External
sensors (bumpers/IR/ultrasonics etc) communicate directly with
the 876. Without working out the details, it seems that 400Khz
I2C ought to work well for this type of application.

Am new to R/C servos. The information I see calls for a pulse
that ranges from 1ms to 2ms proportional to the desired
position every 10 to 20ms. When I think of using PWM's for
this, the every 10 to 20ms gets in the way. If you set the
PWM period to say 20ms, and then want to vary the duty cycle
to provide 1 to 2ms, the resolution seems to get pretty small.
On the other hand, if the PWM period were set to 2ms, then
the duty cycle could be varied between 50 and 100percent
with much better resolution--but how to seperate those
pulses by 10 to 20ms? Do you see the stumble here?

Therefore I figured that some little pics set up with timers and
interrupts could generate the desired signals fairly easily. The
documentation on the lynxmotion web-page says that two micro's
are generally used in this application.
What say you?

I have not considered using feedback pots or shaft encoders
since the servos handle the position feedback internally.

Have not ordered a Hexapod yet--still contemplating the idea.
Do you have one? Is it worth the price?

If I decide to purchase one, care to work together via the net?
Sometimes it is very nice having another to politely argue with over
issues that arrise.

I am an EE student on spring break. Will not have time to fool around
with fun things until end of April when school gets out.

ok..jef

On Wed, 1 Mar 2000, Russell Farnhill wrote:

{Quote hidden}

Jeffrey D. Spears
University of Michigan
College of Engineering

``Double-E, can't spell gEEk without it!''
                       -Captain Gerald M. Bloomfield II, USMC
                        (my brother)

2000\03\17@070704 by paulb

flavicon
face
Russell Farnhill wrote (some while ago - I realise):

> The master controller is a HANDYBOARD (68HC11 with 32K Ram) which
> I built some time ago.  Comms would preferably be TTL Serial line.

 The overall problem is in regard to having a *basic* PIC receive
serial data and generate pulses in software at the same time.  It just
doesn't add up.  If you have a UART, even without buffering, things get
much easier.  But... a solution is suggested.

> Not sure on what protocol to use but something simple to program and
> impliment as I am only just starting out on PIC's

 Serial comms will do, on an open-collector bus.

> Some kind of middle man pic which sits inbetween the pic leg modules
> and the main controller (HANDYBOARD).  So the handyboard can say move
> forward 10 steps and the middle man can dish out all the relevent
> commands and step sequences to the leg modules.  This would save the
> handy board having to send separate comands to each leg module, well
> thats the idea anyway.

 But it may not then have much left to do!  Otherwise, fair enough.

> What do you mean by "up" n "down" paths ?

 Generally, you have a path from master to slaves, and one from slaves
to master, the latter is always open-collector so any slave may drive
it.  However, you can use a single open-collector bus for both
directions.

 I would visualise a protocol where commands were sent in ten-character
(fixed-length, as will be seen) packets at 9600 baud (or 10 kbaud, or
9766 baud if that suits your crystals better) occupying 10 ms each.  In
the following 8 or 10 ms, the slave PICs would issue a 1 to 2 ms pulse
to each of three servos, or perhaps command packets could be six
characters followed by pulses to six servos with two legs per PIC.

 In either case, the PIC would recognise the end of the command stream
by a convention, and proceed to issue the pulses safe in the "knowledge"
that no more commands would be issued until it was ready again.

 If an answer was requested from a slave, this would be sent in the
next communication "slot" and all other PICs would use this instead as
the prompt for the next round of pulses.  Overall, this cycle would be
20 ms or shorter, the nominal PRR for the servos.

> I was guessing on one pic per leg as I was not sure if one pic could
> handle the timing of more than 2 PWM signal for each leg, but it would
> be nice to control two legs with one pic.

 It's more a matter of the above timing.  Most implementations of a PIC
(serial) servo controller seem to target about 8 servos maximum.

> Are the comparitors replacing ADC for current sensing?

 Yes.

> I thought ADC would be easier to calibrate in software rather than a
> external hardware solution ?

 Maybe, but 16F84s don't have them, and they're easiest to use.  If you
use an ADC, you still have to amplify the current shunt so it's either a
quad op-amp or a quad comparator.  I should have thought that for a
given servo unit, calibration would be a "test once and copy" matter for
detection of servo jam/ endstop detection, and the possible extension to
two bits for "easy/ difficult" motion, likewise.

 Anyway, there's my suggestion; a six- to ten-character packet protocol
should be oodles to implement a network with up to 8 or 16 slaves,
command/ poll and 16 or 8 alternate commands, all the foregoing coded by
the first character, the others being arguments.  What think ye?
--
 Cheers,
       Paul B.

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...