DPRG
DPRG List  



[DPRG] Balancing robot difficulties

Subject: [DPRG] Balancing robot difficulties
From: Triffid Hunter triffid_hunter at funkmunch.net
Date: Mon Jul 2 16:35:23 CDT 2007

On Mon, 2 Jul 2007, Luke Steele wrote:

>
> Hello,
>
> A while back I came across Trevor
> Blackwell's DIY segway efforts, and through his site David Anderson's
> nbot., and I was immediately gripped by the urge to build my own
> balancing robot. But I've run into some difficulties, and I'm hoping someone reading this will be able to help...
>
> My initial prototype consisted of a
> sheet of wood with a potentiometer-based tilt sensor. Two Futaba
> servos modified for continuous rotation and bolted on provided
> movement, and variable speed was achieved by PWMing the servos close
> to their null value. Surprisingly (in hindsight) I was able to
> quickly get this set up balancing pretty successfully. But the
> limited speed of the servos meant it couldn't recover from anything
> more than a gentle disturbance - me prodding it - and driving speed
> was very low. So the next step was to upgrade to more powerful DC
> motors. Currently I'm using two Tamiya gearbox motors, which
> according to the specs do ~200 rpm unloaded at 7.2 V (I'm giving them
> ~8V). These are powered through two Bob Blick designed H-bridges
> (www.bobblick.com/techref/projects/hbridge/hbridge.html),
> which are PWMed from my microprocessor, a pic16f877A running at
> 20Mhz. Motor speed is detected using two Hamamatsu encoders (using
> the setup described at
> www.geology.smu.edu/~dpa-www/robo/Encoder/pitt_html/encoders.html),
> and controlled by a PD loop using code also modeled after David
> Anderson's.
>
>
> So what's the problem? Although it does
> balance, it does so in quite an agitated fashion, making small but
> rapid oscillations around the balancing point. And it has great
> difficulty in recovering from outside disturbances (me pushing it).
> This is in great contrast to the my first servo-based robot, which
> balanced very convincingly, within the speed limitations of the
> servos.
>
> Here's Flash movie of the original
> servo robot: www.allthatjazzagency.co.uk/robot/18-04-06_2312.swf
> (Sorry, it was shot in portrait on my mobile, so you'll have to turn
> you head to view it)
>
> And here's the new robot:
> www.allthatjazzagency.co.uk/robot/balance.swf
>
> I've also got a plot of the motor
> controller behaviour here: allthatjazzagency.co.uk/robot/motorcontrollerplot.gif
>
> I've got a few ideas about where the
> problem(s) lie, but I don't know which is the real culprit. And I've
> got about as far as I can in addressing the individual problems.
> Anyway, here are my ideas:
>
> Backlash in the
> 	gearbox/transmission. When unpowered the motor shaft is free to
> 	rotate 2 or 3 degrees. This is really noticeable if I hold one of
> 	the wheels stationary while moving the robot to and fro. This is
> 	also the most apparent difference between the current and the old
> 	version, where the servos exhibited almost no backlash (a fraction
> 	of a degree at most). Are the motors I'm using simply inappropriate
> 	to the task, or is there a means of overcoming the backlash?
> 	Some short-coming of my motor
> 	control. From the graphs I've plotted of requested versus actual
> 	motor speed it seems to me that this is working reasonably well, but
> 	I don't really have a basis for comparison, so it may be that this
> 	is a contributing factor. The Blick H-bridges are in 'floating' as
> 	opposed to 'locked rotor' mode — I don't know the difference
> 	between these modes in practical terms, or whether it's relevant.
> 	Incidentally, both the motor control and balance PD loops are
> 	running at 40Hz.
>
> 	Poorly calibrated PD loop: I'd
> 	guess this isn't the explanation, simply because I've spent a lot of
> 	time playing with my proportional and derivative constants, and it
> 	the robot's balancing behaviour never gets beyond what I've
> 	described. Furthermore I found it quite easy to get the PD loop for
> 	the servo based robot to produce balancing behaviour. Oh yes, it's a PD loop not a PID loop.
>
>
> I'd really appreciate any input or
> advice into how to proceed. If anyone want any more info about any
> aspect of the setup please let me know.
>
> Thanks in advance.
>
> Luke Steele

how about perturbed oscillation (pendulum action) from your mechanical 
gravity sensor? perhaps investigate using an LC network to remove its 
natural frequency - parallel LC impedance drops to zero at resonance and 
series LC impedance goes to infinity, see 
http://www.allaboutcircuits.com/vol_2/chpt_6/2.html and next page too.

what's the relationship between your mechanical sensor's natural frequency 
and the robot's natural frequency? If you insist on using such a sensor, 
I expect it would be best for the two frequencies to be as far as possible 
from any harmonics of each other to prevent resonance effects.

what's the relationship between your mechanical sensor's natural frequency 
and your update loop? will you get aliasing (update loop > nyquist), and 
what effects would that have on your control function?

using an accelerometer would probably work better - gravity manifests as 
acceleration after all ;)

what is your PD loop controlling - motor speed, motor position, robot 
angle from vertical or robot speed?

I'd suggest using locked antiphase for your h-bridges. This mode drives 
the motor in all 4 quadrants which means you automatically get either 
acceleration or braking towards the requested speed - coasting occurs 
when the motor's back emf is equal to the pwm's average voltage.

More information about the DPRG mailing list