Snubber

A comment was made about a capacitor seen across the inertia wheel motor in this post. Just so you know, that was for test purposes only; don’t go putting 100 nF across your 20 kHz MOS driver outputs!

The VHNH2SP30 driver can operate at a supply voltage of up to 16 V, though the maximum rating is 41 V. If 16 V is exceeded, the device shuts down which causes erratic behavior if ignored.

The Mabuchi RS-555PH motor I use has an armature resistance of about 1 R, so with an 11.1 V LiPo @ 0 RPM, that causes what would seem like a relatively large current for such a small ‘bot, but it’s needed for the torque. Anyhow, when the motor commutates, especially at low speeds, all the resulting stored energy gets dumped across an unloaded H-Bridge causing some large voltage transients that shut down the driver. There isn’t much voltage margin to play with so my solution was plonk a 15V TVS across the terminals.

An RC snubber compliments the TVS’s clamping ability by reducing the dV/dt. The resistor was selected to produce < 16V with maximum motor current. The capacitor was chosen quite conservatively to limit power wastage in the resistor to 1W @ 20 kHz. It should help to reduce noise that might interfere with the Bluetooth transceiver but I’ve not verified this.

remote

While I wait on a new battery and optical sensors, it’s time to work on a remote controller:

Details:

• Bluetooth (old buggy v1.1 CSR chipset),
• LED to indicate power (flashing) and successful pairing with slave module (on 100%),
• Joystick salvaged from some game console controller,
• Power switch,
• Oversized die-cast box 😉

New wheel in action

Got my new wheel installed the other day after turning up some shaft adapters for the hub. After installing it I had a play with increasing the feedback gains on the lateral balancing circuit. The bandwidth limiting for the previous pneumatic wheel is still in place but the improved performance is already noticeable. The response to disturbances is less sloppy, it holds true to 0° much better, and no limit cycles are generated despite increasing gains by 1.5x, 2x and 3x for roll angle, roll rate, and wheel rate respectively.

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 😉

 

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…

Final touches…

…before I move on to implementing the lateral balance controller.

I’ve increased the ground velocity gain to reduce the swaying evident in my previous update. I’ve also added an integrator to dynamically align the intended center of mass pitch angle with the actual center of mass to maintain an upright posture in the presence of temperature drift and changes in weight distribution (battery shift etc.), for which a simple programmed offset cannot fix.