Alt-BEAM Archive
Message #04758
To: "'beam@sgiblab.sgi.com'" beam@sgiblab.sgi.com
From: Wilf Rigter Wilf.Rigter@Powertech.bc.ca
Date: Mon, 21 Jun 1999 19:24:41 -0700
Subject: [alt-beam] Re: Feedback explained?
It depends on the type of core: An HC bicore with inverter thresholds "near"
+V/2 is extremely sensitive to powersupply noise near the end of each
"process" cycle. The duty cycle can change 30-50% depending on the
powersupply "noise" level. A motor under heavy load (or hitting a
mechanical stop will introduce noise on the supply and depending on the
local filtering this will more or less shorten the pulse. This feedback is
most pronounced in "balanced" Bicores where caps are identical and the
thresholds are near +V/2. Using a HCT or different timing caps or an RC
supply filter for the core will reduce sensitivity to noise and feedback.
For a more conventional feedback method one could use a motor current
sensing method with a threshold above which the pulse is cut off. This can
be used with a microcore or other control circuit and has a predictable
response.
regards
Wilf Rigter mailto:wilf.rigter@powertech.bc.ca
tel: (604)590-7493
fax: (604)590-3411
> -----Original Message-----
> From: Bruce Robinson [SMTP:Bruce_Robinson@bc.sympatico.ca]
> Sent: Monday, June 21, 1999 3:18 PM
> To: beam@sgiblab.sgi.com; Ian Bernstein
> Subject: 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