Calibrating the Kalman Filter Values

The Kalman Filter values from here work, but I think I can make it more responsive. The Lego motor has a optical sensor to track the rotation of the motor, so I have set up a simple program to compare the difference between the angle from the Kalman filter and the angle suggested by the optical sensor.

I really need to upgrade to the latest TI development board simply because it has a hardware quadrature decoder. I not 100% convinced that my software solution does not miss things. 

Kind of balancing

The robot is kind of balancing...

Really just using wild guesses for the PID parameters. The ones from my simulation don't work too well. The robot could be improved by having bigger wheels and higher angular inertia. An attempt was made to isolate the vibration of the motors from the body by using rubber mounts. The accelerometer was also mounted on a foam pad on a chunk of metal which in attached to the wooden chassis. In theory the miss match of materials with different acoustic properties would cause the vibration to be reflected. In practise, given the size, it probably would only impact higher frequency mechanical vibration.

Another vid...

First Run

Well it kind of worked. The biggest issue is the vibration that the accelerometer/gyroscope gets subjected to. It even managed to oscillate on the spot once, of course this was not caught on camera. My next step is to redesign an mount the sensor close to the centre of gravity and some how vibration isolated. 

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.

Bluetooth and the Physical Model

Being a mobile robot, radio communication is essential for both control and debug. 

It took me ages to integrate it (~ 4 hours). My first problem was not knowing about the protection for the non mask-able interrupt pin that is shared with the tx line for uart 2. The second was actually pairing the Bluetooth with my PC. I could pair, but it would immediately go offline. I did not realise that it would actually only pair correctly once I had opened the comm port. It did not help that there were a few weird errors in the windows event log either.

The model it self  has a training sled and is very top heavy, especially when the batteries are added. Essentially components have just been screwed onto a block of timber. The pcb on the bottom is the dc motor driver. It has a 5v dc regulator output so the logic components can either be powered from the usb jtag or battery with a flick of a switch.

The batteries will be NiMh and currently only 8 of 10 the battery slots will be used. The Lego motors will be powered by 9.6V! All good.

Kalman Filter

Kalman Filter

The Kalman filter is pretty straight forward filter that seeks to turn noisy measurements into not so noisy measurements. It does so by combining the observed measurement with a predicted measurement.

The blue line is the raw gyroscope measurement of the X axis. The red line is the Kalman filtered version.

This was just the sensor sitting on my bench, so the prediction model is trivial. That is the predicted gyroscope value is the previous gyroscope value.

Once the gyroscope is mounted on the robot the model will be based upon the model described in earlier post.

Stellaris and Gyroscopic Sensor

I've kind of settled on the Stellaris simply because of its 5 Volt tolerant pins.

A fair bit of effort was spent into integrating the gyroscopic sensor to the Stellaris. The problem ended up being the drive current from the micro controller was too low and was intermittently failing (i.e. the sensor was either not getting the command or getting the wrong one). On the Stellaris, you can set the drive current. The default was 2mA. 4mA seemed to work fine. So I am using 8mA to be sure to be sure.

Beaglebone with Accelerometer and Gyro

Beaglebone and I2C sensor.

The micro controller board below is called a Beaglebone. It has a very powerful arm chip running at 700Mhz. It is similar to the Raspberry Pi. The Stellaris launchpad is just 16Mhz (I think). Anyway in this small project a $6 i2c gyro and accelerometer was hooked up. The full blown SYS/BIOS was used. Linux could have been used, but the main issue there was the code size. The code size is important as it takes forever (~5 minutes) to download something the size of Linux with the slow built in jtag debugger.

SYS/BIOS is not officially supported on the Beaglebone. However, it was made to work using TI's own industrial SDK.

The output of the sensor makes its way through the Beaglebone, through a (usb) comm port to my PC to be displayed in a simple app written in C# in real time. Louka had a lot of fun hitting the table and making the graph bounce.