Alt-BEAM Archive

Message #04740



To: beam@sgiblab.sgi.com, Ian Bernstein ian@beam-online.com
From: Bruce Robinson Bruce_Robinson@bc.sympatico.ca
Date: Mon, 21 Jun 1999 15:18:06 -0700
Subject: [alt-beam] Re: Feedback explained?


Ian Bernstein wrote:
>
> I know this is probably old news for some of you but I was just writing
> an e-mail to someone and suddenly started to understand motor feedback
> and how the walker can adapt....
>
> What happens if the motor encounters resistance is the voltage drops (?)
> and the .22 caps charge differently.

I've come across the feedback concept a number of times while wandering
the BEAM landscape, Ian. I've seen a similar suggestion to yours in a
few places -- motor slows down, current increases, supply voltage drops,
and the cap charges more quickly.

After a lot of reflection, I think this kind of feeback is bogus. (Boy,
am I asking to get dumped on for that remark!) The thing is, for a
74HC14 (and for most basic CMOS chips), the trigger threshold is
approximately proportional to the supply voltage. And in one of the
Stills/Tilden papers, I came across the formula for the time delay -

T = R x C x ln(Vmax / Vth)

R = resistance (ohms)
C = capacitance (farads)
Vmax = maximum voltage (e.g. supply voltage)
Vth = threshold voltage
T = time (seconds)
and finally, ln is the symbol for natural logarithm

So if Vth is approximately proportional to Vmax, then ln(Vmax / Vth) is
a constant, and the only thing that will affect the delay is R and C.

Personally, I think the apparent feedback effect is electro-mechanical.
From the mechanical side:

Power = Speed x Torque

Well, torque is the rotational equivalent of force. So when a walker
runs into some kind of resistance it tries to deliver more torque. Given
a more-or-less constant source of power, the only way to get more torque
is for the motor to slow down. Slower speed means less distance
travelled before the Nv times out.

There's a great subject to discuss with Mark this summer! It'll probably
get discussed on this list very shortly, too. Fire away, folks.

> Well I wonder if there's a was to 'amplify' the motor feedback so if a
> leg gets stuck it will drastically change the circuit?

Ahh, now this is the really intersting topic. Rather than relying on
some kind of questionable inherent feeback, let's find a way to CREATE
feedback that we can direct (and play with). I've not done mcuh in this
regard (heck, I haven't even got a functioning walker yet), but I have
mentally kicked around some crude ideas, such as:

For your walking motion, have a delay that is too long, then use
limiting contacts on the legs to kill the leg-moving process after a
full step. If your walker gets partly stuck, the leg will still try to
go through its full motion. But if it's REALLY stuck, the Nv delay will
eventually time out (giving up, in effect).

Or, run two Nv's in parallel: One has the delay you would expect if
the leg were moving normally, but doesn't control a leg motor; The other
has a long delay as above, and drives the leg. If the "normal" delay
times out before the leg has finished moving, have it alter the leg
driving circuit in some way. A 74HC139, for example, would tell you if
the leg was taking longer than expected to move, or had finished sooner
than expected. You get a different output signal for each condition, so
you could do completely different things depending on the circumstances:
play with an H-bridge bias, perhaps, or fool with the Nv delay, or even
alter the delay of a different Nv.

Or how about switching into a "kicking mode". If a leg seems to be
stuck, run a bicore (say) for a short interval that moves the leg
quickly back and forth over a small distance. Kind of like shaking your
foot when it gets caught in the underbrush.

This is the kind of direction I'm heading in -- try out different
feedback ideas, possibly at the expense of circuit complexity; if an
idea shows promise after it's been built, wave the circuit in front of
Wilf or Steve (or Mark T) and watch them pounce on it -- no doubt
reducing the component count by 50% or so.

Have fun with this, Ian (and anyone else).

Take care,
Bruce

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/alt-beam
http://www.egroups.com - Simplifying group communications



Home