PID query

[richiereynolds]

Hi folks, I've made a 2 wheeled balancing bot with a ps2 controller for steering and am looking to go a bit further. It balances fine but I'd like to look into having it self calibrate and balance on slopes and am looking for some advice on that.

My angle detection is working pretty well and I'm using pid control based on the angle to control the motors.

On this arduino forum post - http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1284738418/210#223 a poster asks:

(1) in the setup, with the function calibrateSensors(); you have to put the robot (each time you switch it on) exactly in the static equilibrium position in order to evaluate zero values.
is this a little bit boring and could produce errors (if it is not perfectly perpendicular)?
If during the calibrateSensors() i'll give a tilt, the Robot will work to keep the tilt!

To which someone replies:

No No...
If you tilt the bot forward before calibrateSensors(), it will move forward and find a vertical equilibrium
This will happen only with encoder(s) implementation, look here

I've looked at the wheel encoder implementation mentioned, all it does is add P and D terms for the wheels based on position and velocity respectively. I can't understand how that would help find the point of equilibrium as the set point is never adjusted, could anyone explain? I can only see that this would encourage the robot back to it's starting position but surely it will still work to keep the set point at the non equilibrium position it started in which would immediately force it to move again to stay upright?

The other question I have is on the theory of getting the bot to balance on a slope, which I guess is in the same area, anyone have any tips?

Thanks, Richard.

[hopslink]

Good work on your robot so far!

The robot has an absolute vertical reference due to gravity available from accelerometer data. To use that it needs to be aware of any accelerations it is undergoing other than that from gravity. Gyros are used to check for rotation and encoders for wheelspeed (covering centripital and linear accelerations). Without wheelspeed encoders you would have to ensure the 'bot was still and in a known position (not necessarily upright) in order to calculate an upright zero position.

On to balancing on slopes. Using accelerometers and gyro data with sensor fusion as an input you have implemented a PID controller to maintain a desired angle lean angle via a 'motor control' output. The PID values you tune fit a linear model of your robots overall dynamic response to this 'motor control' signal. Your 'bot balances ok on the flat, the conditions you have tuned for. When it comes to a slope that model will no longer work as your motors' responses to inputs are now completely different depending on whether they are driving up or downhill. There is simply not enough flexibility in a linear model to accurately cope with the variability (nonlinearity) in the system.

With wheelspeed sensors you can implement a second PID controller that matches wheel speed output to a desired speed input for all inclines (a torque controller). Using your current PID controller's output as the desired speed input effectively removes the motors response from your current PID controller's model of the system, and makes the 'motor control' output a simple 'wheel speed control' regardless of terrain. Balancing on a slope should now work automatically (after you set your new PID values).

HTH     

[mstacho]

That's not entirely true.  The role of feedback is to account for errors in the modelling.  PID control will be fairly robust as long as the robot doesn't have significant nonlinearities (with the definition of "significant" varying from time to time and application).  The reality is that a constant incline will act like a constant disturbance force, which falls within the realm of linearity (despite the fact that such a force would be given as a nonlinear function of the incline itself).

What'll really break the PID controller are things like deadzones in the motors and damage or complex transmission mechanisms.  But as always, try it out (and prove me wrong! :-P I LOVE being proven wrong, as I get to learn so much more that way)

MIKE

[hopslink]

Yes I agree that a constant incline would present a linear disturbance force and could be compensated for (you could re-tune the PID values to make a constant incline balancing 'bot) and that feedback does allow some flexibility, so a tall, top weighted balancing bot with an extremely high quality transmission may cope with flat and some inclines. The balancing 'bot is a nonlinear system being modelled by the PID in a small fairly linear region around the upright position, so there are already inherent errors in the model (see inverted pendulum with a moving base). I suspect adding variable inclines to the mix will prove a 'parameter too far' for a single PID controller.

I was also basing my response on the fact the original poster has previously posted video of his 'bot balancing quite capably on a flat surface, and the fact he is asking about balancing on slopes suggests to me that he has tried it and been somewhat unsuccessful...

Like you I am happy to be proven wrong. 

[mstacho]

This would actually be pretty neat to try out.  I know that the inverted pendulum is the classical "nonlinear control" example, so the PID controller will probably only really work on some small subset of inclines.  My question becomes: is there a critical incline angle that will stop the PID controller from working?  If so, does it depend on any properties of the system?  which ones?

We also have to consider that most motors saturate after a while, so no matter how good your controller is, the motor can only resist so much disturbance.  I'll have to take out my old nonlinear systems book and give it a shot.

MIKE

[richiereynolds]

Thanks guys! I'm going to digest all that and give it a go soon.

For info, the motors I'm using do have quite a bit of backlash but the (I2C) motor controller has an interesting internal featue that kind of falls into the pid realm too. You can set the controller to monitor the encoders and deliver more power to try to keep the speed constant under more torque. I've been trying it on and off, with the feature on you can certainly see the 'bot achieving set point quicker but it does introduce a bit more vibration into the system. With the feature off I guess I'm seeing the physical damping effect of the motors slowing under stress and the system seems smoother.
You can also set an "acceleration rate" on these motors whch provides some interesting effects too.
I imagine I could simulate all these effects by adjusting my pid values but obviously it will produce a slightly different overall control.

Too many parameters!

Anyway, I'm off to the canaries for a week on Saturday so no more robotting for a little while!