The Real Model

After actually building the model, the real parameters had to be determined.

It was suspended so that it acts as a pendulum to measure the angular inertia. The gyroscope sensor attached to the robot continually fed the angle via blue tooth to my pc. In this way, the period was accurately determined. The angular inertia of the wheels was calculated based on a disk.

The motor constants were quite easy as well. The power (current and voltage) was measured under both no load and full (stall load).

torque = (stall power - no load power) / no load rotation
Km = torque / current
Km = 0.3745
Ke = volts / no load rotation
Ke = 0.5033

Mp = 0.666
Mw = 0.03
l = 0.097
r = 0.022
Ip = 0.0031
Iw = 0.00001363
R = 4.6

After plugging in the "real" values, multiple issues were found. To be more real world, a starting current is needed - the motor does not start turning until ~1.6V is applied and naturally, gravity and angular momentum also comes into play. The real world Ke and Km values are much larger than an earlier post due to the 1:48 gear ratio. The maximum volts also needed to be capped. 

More importantly, the dual PID controllers didn't really work that well if the starting angle and/or speed was not zero. It would seem to correct the angle and then stop at a low speed and stay there - the voltage shows this...

To correct this, a further pid controller was added ...

Note in both graphs the angle is accentuated. The first 0.4 (20 units) seconds represents the robot being pushed over after being already put at a speed and at an angle.

PID Controller

At uni, I did study fuzzy controllers and after a bit of searching I found my text book and lecture notes. However, fuzzy controllers suffer a bit from tuning. I experimented a bit, read a bit and did all those sorts of things until I kind of kept on stumbling on the internet phrases like "fuzzy controllers are a good option when standard controller don't work well". Hmm, look, these PID controllers look simpler and easier. Again lots of reading, experimenting etc, and then I discovered that in my situation I should break down the problem into two control problems. The first controller should focus on keeping it upright and then the second setting the speed.

First Controller - Keeping it Upright

In this controller the error term is angle speed with the objective of finding the best values that minimise energy and that the angle stays between -0.5 and 0.5 radians over a period of time. In effect this drives the solution to be making the angle as close to 0 as possible.

Using a "sophisticated" technique of iterating through a large number of permutations, I found the best co-efficient values were Kp = -64.9 Kd = 0, Ki = -846.3. The Kd = 0 is interesting because it seems controlling is not based at all on current angle acceleration. Hmm, I can't think with total confidence why this is. The only thing I can visualise is acceleration at different angle positions and speeds. Say would the controller do anything different if the acceleration is -ve or +ve when the angle is 0.5 and speed is -10 rad/s. I'm thinking from an energy point of view, maybe not.

Second Controller - Setting the Speed Point

In this controller the error term is speed with the objective of finding the best values that minimise speed over a period of time.

Again, using a "sophisticated" technique of iterating through a large number of permutations, I found the best co-efficient values were Kp = -434.5, Kd = 337.4, Ki = 0.0. The Ki = 0.0 is interesting because obviously the speed of the robot has nothing to do with its position and that makes sense.

Graph

The controller seems to work well, you can see that the angle and speed goes to zero.

You can see the robot is driven up until the blue line makes a sharp turn upwards.