Session 6

Date: 11/06 2014

Duration of activity: 10.15 - 14.30

Group members participating: Pætur Askildsen, Christian Jegstrup Hansen, Søren Gregersen, Søren Ditlev and Alexander Rasmussen

Goal

Solve gyro drift problems, or get closer to that goal
Implement bluetooth-enabled connection for car on the top of the tube for fine-tuning the PID constants.
Work on the accelerometer to understand it better and to use it as a long term parameter to avoid drift

Plan

To solve the gyro drift problem modification on the raw gyro data is needed. In this session we seek understand what causes the gyroscope to drift and find solutions online which can help us combat this problem.

In lesson 5 in the course, we were to constructed a self balancing robot - segway. In that lesson we implemented a Bluetooth controller to fine-tune the parameters of the PID controller on-the-fly. In lesson 5 it proved to be a very useful feature to have, so we plan to go back and look at our lesson 5 implementation of the Bluetooth connection transfer it to our car on the tube.

Results

Choice of parameters on-the-fly

We rewrote our bluetooth-enabled PID constant fine tuning program from lesson 5 - Self-Balancing Robot [1] to be used to change the parameters which we needed in our TubeBalancing car program. The reason for using this method is, as lesson 5 put it:

During the development of a balancing robot a lot of adjustment of constants is needed. This can be done by editing the Java source code, compile and transfer it to the NXT before the next trial. To speed up this trial and error process a wireless communication could be established between PC and NXT so the constants of the program can be changed on-the-fly. [2].

We rewrote the PCcarController.java GUI LeJOS PC program to match our context, and the same with the BTcontrolledCar.java LeJOS NXT program. The programs can be found from our blog site.

Accelerometer and gyroscope deficiencies

While Pætur, Christian and Søren D are working on the PID-controller, the balancing robot and trying to handle the drift from the gyroscope, Alex and Søren G are trying to solve the drifting problems using an accelerometer for the long term calculations on the orientation.

The problem with the gyroscope drift seems to arrive when the system has been running for several seconds. In the beginning of each run when the gyroscope has been calibrated, there seems to be no problem, and the car balances nicely on top of the tube. But already after 5-7 seconds after the launch, the gyroscope starts to drift, meaning that its offset is displaced a few degrees to the side. This means that the point that the car is trying to adjust to is continuously moving more and more to one side, resulting in the car’s eventual fall off the tube, even though it is actually still close to the reference point.

Figure 1: Rough and non-measured illustration of the drift of the gyroscope

We looked for different solutions on the drifting problem online, and found one, suggesting that an accelerometer is implemented to help the system knowing where the actual reference point is located. As accelerometer measures all forces working on the object it is very apt at detecting small changes, however because the accelerometer is so sensitive, very small disturbances may affect the system, this makes the accelerometer unsuitable for very precise systems (like our tube balancing robot). The gyroscope on the other hand, is very good at obtaining an accurate measurement that is not susceptible to external forces, but from another deficiency instead - drift. Drift is unavoidable because of how you determine angles with gyroscope data. This is done by obtaining angular velocity dec/sec form the gyro and then integrating this term by multiplying it with the measurement frequency. The result of that piece of math is a angle in degrees. By subtracting this angle from the last known angle of the system, you know how much the system have moved. The actual drift will be caused by the inaccuracy of the gyro measurements and because we can not make contentious calculation of the gyro position but are limited to the code loop time. Therefore, over time, the gyroscope will drift slowly away from the reference point as shown in figure 1.

Complementary filter using Gyrometer and Accelerometer

The basic idea behind the complementary filter is to combine the strengths of the gyroscope and accelerometer respectively to produce a value that is both responsive, accurate and does not drift. In theory this is done by making the gyro measurements responsible for the short term changes to ensure high accuracy, and use the accelerometer for the long term changes to prevent drift.

Figure 2: Complementary Filter

As shown in figure 2 [5], the complementary filter is composed of two filters. A high-pass filter concerning the gyro and low-pass filter concerning the accelerometer. The high-pass filter uses the angle previously calculated by the whole complementary filter algorithm, and adds the angle currently obtained by the gyro. This value is heavily weighted (0.98) to give it a to give it a lot of influence in the the short term. The low-pass portion of the complementary filter uses the accelerometer data weight it very lowly (0.02) so that it does only have a very low immediate influence. However since the low-pass portion is added to rest of the algorithm it will have a significant influence over time as shown below [5]:

Figure 3: The weight of the accelerometer and gyro

As seen in the statement above. The gyro will have the most influence in measurement under half second ago, but the gyro will have be the most influential in anything above. This value can of course be tweaked to give the gyro or the accelerometer more influence.

Figure 4: Complementary filter readings

As shown by the graph above [6]. The accelerometer data(blue) is very jumpy, whereas the more accurate gyro data (red) drifts over time. However the complementary filter data(green) is stable and does not drift. This is in essence what we hope to achieve by implementing a complementary filter.

Skrive noget om, hvordan vi har udregnet de forskellige faktorer, samt code-snippets.

The formula for the complementary filter looks like this:

angle = 0.98 (angle + gyrData dt)+0.02(accData)

The angle is calculated from a the gyroscope and accelerometer data which weighs respectively 98 % and 2 %.

The gyrData constant is the angular velocity from the gyroscope, measured in degress pr second, and can be found with the method getAngularVelocity() already a part of the class GyroSensor(). The dt constant is the sample period for the system. We have a sample rate of 100 Hz which gives a sample period of 0,01 second. By integrating it with the dt constant we get the angle of the gyroscope at time t.

Working with the Accelerometer

The initial plan was to make a vector comprised of the x- and y-axis of the accelerometer, since we do not use the z-axis we just plainly omitted it. By taking the absolute value axis and adding them to one another we were able to find a unified number that should best represent the car's movement on the tube.

Figure 5: Movement vector

Figure 6: The different axes on the Hitechnics Accelerometer [4].

Figure 7: The axes for the HiTechnics accelerometer seen on our car.

Conclusion

In this session we were able to gain an understanding of the complementary filter, which we can hopefully implement in the future to reduce or remove drift. We have made a movement vector by combining the x- and y-axis of the accelerometer, which we plan to use in the complementary filter. However we are not sure if it is possible to use a combined axis vector, this we will have to test in an upcoming session.