New wheel

My $2 scooter wheel arrived today. It’s a MGP Aero 100mm wheel, with a beautiful part-machined hub. After 20 minutes in the lathe grinding out the flat spots and giving it a round (side-to-side) profile, it’s as good as new!

Being rigid, I expect to see in improvement in lateral loop stability when I fit this to my unicycle robot. It’s also more circular than the existing el cheapo pneumatic tire, so there might be some improvement in the forward loop stability as well – although it still has backlash and a lack of tuning to contend with 🙂

It’s alive!

Both lateral and frontal controllers are operating in unison to balance the robot and with no extra coding since last post. All I had to do was hit the ‘enable’ key via serial port term to fire up frontal balancer. Not even any additional tuning since designing the two controllers individually.

Video standing still:

..and then perturbing lateral and frontal balancers:

I’m quite chuffed at the performance. A bit is needed to stop occasional, albeit brief, oscillation of the base wheel, but I suspect this is a bandwidth issue on pendulum pitch rate and not so much an issue of fine tuning the respective controller gain.

Time for a beer.

Lateral balancer fully working

So reducing the bandwidth of the pendulum rate solved the vibration issue caused by the pneumatic tire. Funny, it was just a little dabble that went something like this:
tmp *= 5;
tmp += kal_roll_rate;
tmp /= 6;

Regardless, I have a solid tire in the making for later performance comparisons.

Not long before I get the chance to fire up both controllers and see if this thing really is a unicycle 😉

 

IWP – Matlab/Simulink

I had a request for an IWP Matlab/Simulink model, so here goes.

What I’m posting is dated October 2008, and was what I wrote to tune my IWP. I don’t remember much about it, but it looks reasonably self-explanatory.

Note that I’ve updated the Simulink model to Matlab R2011b and it appears to work. To run the simulation, first run the Matlab script.

The model should look like this:

To fill in the gaps:

• “x1dot” through to “x3dot” represents the second derivatives of pendulum angle, pendulum rate, and wheel rate, i.e. the non-linear system model.
• Feedback gain “-k” is the linear controller.
• The only transfer function block is the motor delay model. The addition of this is a bit confusing as I should have included it in the system model above. Also, the controller is not designed with this taken into account. It can be replaced with a straight-through connection since the inertia of the wheel and resulting time response completely swamps the inertia of the motor and it’s unloaded time response. I left it in for the fiddle factor (for fiddling with ;-)).
• The functions at the bottom are the PMDC motor torque to terminal voltage equation. I included this to get an idea of what kind of signal I would need to drive the real system. You’ll notice in the following graph [below] that there is a directional offset added to overcome friction preventing a small terminal voltage from turning the wheel (essentially a dead-space in the zero-velocity region). This dead-space isn’t modeled, but in real life I found implementing the bias helped the controller to keep the pendulum “on its toes”, though the effect would probably not be noticed with a larger inertial load. It also wastes power.

The output of the simulation should look something like this:

DL Links:

iwheel.m
iwheelmodel.mdl

Hope this is of use 🙂

Good to go, laterally!

On the downside, the same tuning constants refuse to work with the pneumatic wheel as the pivot point. It’s too squishy. Either I’ll have to relax the controller gains and put up with a slower response, or it’s time to get a new wheel…

Lateral balance almost working

Turns out I had reverted a change I had made earlier that would’ve solved the motor heating issue. The wheel rate feedback calculation was the culprit: program loop too fast to register a sufficient number of increments v.s. relatively inaccurate measurement of ‘time since last update’.

I also discovered the need to improve pendulum rate feedback. The problem with this was that the raw signal, providing 110 °/s sensitivity through a 10 bit A-to-D, didn’t quite cut it. I decided instead to use the 4.5x amplified signal available from the gyro, providing a raw 500 °/s sensitivity and therefore improving the digital resolution. Additional pre-filtering before Kalman filter bias removal improved performance even further.

The graphs below show, from worst to best, the gyro with…

1. 110 °/s sensitivity with no pre-filtering
2. 500 °/s sensitivity with no pre-filtering
3. 500 °/s sensitivity with simple IIR pre-filter, n=4
4. 500 °/s sensitivity with RK4 pre-filter (Ignore the cyclic motion on pendulum rate; I think I changed something else to cause this)

…on pendulum rate as interpreted by the controller:

and subsequent inertia wheel motor duty:

Clearly there is a reduction in the noise seen on motor duty. This is especially desirable about the zero-velocity point where the H-Bridge controller has to constantly change direction of a large amount of current (~12A !).

Here’s a (rather unspectacular) video:

Although I’ve integrated out the pendulum ‘zero’ angle error caused by an off-center balance point, I’ve yet to sort out the non-zero inertial wheel velocity. Also some tuning to do…

Lateral balance. Just.

It vibrates. It squeaks. The motor heats up and has significant residual spin despite integrating out the roll angle error, though clearly it’s balanced.

Quite frustrating as I’ve reused working code, almost word-for-word, from my standalone Inertia Wheel Pendulum and spent some time fiddling with gains and selectively lp-filtering inputs. Maybe it’s a hardware issue? Time to investigate…