DPRG List  

[DPRG] automate movement/position data collection. Was: Driving an H-Bridge with a switching power supply

Subject: [DPRG] automate movement/position data collection. Was: Driving an H-Bridge with a switching power supply
From: chris cbrenizer at socket.net
Date: Fri Dec 26 10:41:00 CST 2003

man, man, man, (i can feel my brain swelling because of yet another project
that gets added to my list but will never get done).

this discussion on movement/position errors, dead reckoning, battery
voltage, etc... on this list and others, sparked an idea that i gotta throw
out, to see if it's practical. (and to get it out of my head)

how complicated would a 'robot dynometer' (or is it dynameter?) have to be,
to use to gather performance characteristics that might then be compensated
for via software or the control system?

would two independant small treadmills (so you can vary the spacing for
different robots), which the robot sat on and spun via it's powered wheels,
be enough?

a computer or processor would monitor either encoders or dc motors acting as
generators, and robot motor batteries voltage.  so that performance
characteristics could be plotted, then compensated for.

i know, typically, the ones used for cars vary load, etc... but would think
a small, hobby, home made one would probably have enough inherant friction
to supply a steady load.  but would guess there's a way to figure how much
force is needed to move the robot then duplicate that load on the

but, i would wonder if sitting on two treadmills could capture enough
accurate data about turning, etc.

if it would, you'd be able to charge up the robot, set it on dyno, connect
voltage sensor wires, (maybe remote stop/go wires if you want to get fancy,
or turn left, turn right signals, etc...), then walk away, letting the
computer gather speed or encoder clicks or whatever, while the robot ran
it's batteries down...

ideally, after several cycles of this, you'd end up with a repeatable
'performance curve' that you could count on and then compensate for.

(it should also show any difference in counter rotating motors. that dilemna
of two matched motors, one which runs 'backwards' to the other as the robot
moves forward)

instead of plotting 'power', like in car tests, it would be designed to
gather movement/position data.

i don't know if there'd be any benefit to being able to change the tread
surface, like low pile carpet, simulated lineolium, or whatever...

maybe, instead of a stationary treadmill setup.  it would need to be a
'wagon or trailer' that the robot pulled.  but collecting powered wheel
encoder clicks, to compare to the wagon's actual wheel rotations to find
drive wheel slippage might be complicating it beyond the KISS principle.

...there, at least i've rambled it out of my head...sort of...

chris brenizer

----- Original Message -----
>From: "Earl Bollinger" <earlwbollinger at comcast.net>
To: <dprglist at dprg.org>
Sent: Friday, December 26, 2003 8:18 AM
Subject: RE: [DPRG] Driving an H-Bridge with a switching power supply

> I had observed problems like this before. The most obvious is when a
> robot did a 90 or 180 degree turn on a freshly charged versus a low
> battery. You would get a difference. You can readily see this in the
> small robots.
> So it does make sense to use a regulated supply to furnish voltage to a
> drive motor system. It would keep the voltage and current more constant
> during the charge life of the battery pack.
> So it looks like a good thing to do, if you can get a motor power
> regulator into your robot, is to do so.
> For a small robot I think we need to come up with a reliable sensor for
> determining whether we have done a 90 or 180degree turn.
> GPS looks promising, but the military have the accurate system. We'd
> have to at the least, use a fixed and mobile GPS receiver to determine
> positions more accurately.
> I have tried wheel encoders, but the slippage is cumulative and leads to
> error. A digital compass doesn't work well inside as all the nearby
> metal interferes with the compass, sometimes rendering it useless.
> I have been thinking that maybe a dual roller encoder with both encoders
> set at 90 degrees to each other. When the robot starts a turn, one
> roller works for a while then stops as it's skidding, then the other
> roller starts turning. Adding the combined total tick counts from the
> two rollers looks promising. This would use two wheels like those
> multi-roller wheels they sell at Acroname.com.
> Then of course maybe a simple castor wheel encoder would work.
> Outdoors, a digital compass looks much better, but the larger electric
> PM motors cause the compass to point at them. If you use a soft iron
> shield around the motors, it works for a while until the iron starts to
> get magnetized, then the compass starts pointing at the motors again.
> GPS seems to be the only practical way at the moment here. But maybe a
> castor wheel type encoder would work Ok enough. But grass, sidewalks,
> dirt, bumps, ditches, etc. all cause turn problems too.
> -----Original Message-----
> From: dprglist-admin at dprg.org [mailto:dprglist-admin at dprg.org] On Behalf
> Of David P. Anderson
> Sent: Monday, December 22, 2003 11:47 PM
> To: dprglist at dprg.org
> Subject: [DPRG] Driving an H-Bridge with a switching power supply
> Howdy
> On Using a Switching Power Supply to Drive an H_Bridge.
> One of the problems I've struggled with on the two-wheel
> balancing robot is the change in behavior as the battery
> drains.  I'm running the robot on 18 Nmh AA cells, at 1600
> mAh.  Fully charged that's about 25 volts, and fully discharged
> (at 1 volt per cell) is 18 volts.
> The robot balancing behavior is optimal at about 23 volts.
> Higher than that, it is quite "jerky", and below about 22 volts
> it is quite "loopy."   I can adjust it so that it is optimal
> in any of these ranges, but then it works poorly in the others.
> On my other non-balancing robots, this problem is solved with
> shaft encoders and a PID speed controller.  The speed controller
> increases the pulse widths to compensate for the sagging battery
> voltage, and the behaviors remain constant across the range of
> the battery.
> For the balancing robot, this has proved more problematic.
> I originally thought that I could deal with this by monitoring
> the battery voltage, which I do, and adjusting the gain or gains
> as the voltage drooped, but in practice this has proven very
> difficult to do.
> About a month ago at one of the RBNOs at the warehouse, I was
> demonstrating this behavior and the Most Excellent Brian Merritt
> suggested that this problem might better be solved in hardware,
> and thereafter gave me a pointer to a Dallas Semiconductor
> Maxim MXL1074CT  --- here's a handy reference:
> http://www.chipdocs.com/pndecoder/datasheets/MAXIM/MXL1074CT.html
> So I ordered a couple of samples and after some consultation with Brian
> and Ron Grant, made a trip to Tanners for the appropriate inductor
> and a handful of capacitors, and built a little 23 volt, 5 amp
> switching power supply.  I added three more AA cells to nBot's
> battery pack and mounted the switcher between the power switch
> and the H-Bridge.
> I've been running it for a couple of weeks now, and it works just
> dandy!  The output remains at a steady 23 volts as the pack drains
> from about 29 volts to about 25v.  I hung a 3amp load on the supply
> and watched the output on the scope, it appears to regulate down to
> within about 2.5 volts of the requested output voltage (which I can
> adjust with a 10-turn pot).  There is a little bit of ringing on
> the output waveform, but basically it's pretty clean.
> I'm now in the process of re-calibrating the robot, which is about
> 1/2 done, but so far the performance is markedly improved.   Further,
> during a two hour session of testing and calibrating, the behavior
> remains consistent throughout.  As a result, it is easier to tune
> the system, and the robot already seems more stable.
> This has made me wonder if this sort of thing might be a useful
> addition to a non-balancing robot, as well.  And if so, if the
> little switcher should just be part of the H-Bridge board to
> begin with?  (It's only something like 5 components)
> Anybody have any similar experience?  How about with industrial
> controllers?
> merry christmas,
> dpa
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://nimon.ncc.com/mailman/listinfo/dprglist
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://nimon.ncc.com/mailman/listinfo/dprglist

More information about the DPRG mailing list