Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).


RoseWheel & the accelerometer

In relation with our previous post we made some further investigations on the physic underlying the accelerometer measurements.

Theoretically, it’s really easy to extract a tilt angle from an accelerometer. We just have to take the arcsin of the right axis measurement, depending on the frame used, divide by g and we get the tilt angle.

for us :  theta = arcsin(Ax/g) where :

theta = tilt angle, Ax = measurement on the x axis, g = gravitationnal constant

This solution works well while the accelerometer doesn’t translate.

If the accelerometer is translating with a non zero acceleration component, extracting a correct angle measurement becomes really tricky. As we don’t only measure the gravitationnal acceleration, but also the translating acceleration, we can’t apply directly the previous equation.

however, even without encoders, it’s mathematically possible to extract the tilt angle. As we have a 3-axis accelerometer, we can extract from the measurements of 2 well chosen axis of the accelerometers a set of 2 equations with 2 unknown variables that are the tilt angle theta and the translating acceleration x and thus it’s possible to resolve this set of equation.

In the frame of the accelerometer we have :

g*sin(theta) + x*cos(theta) = Ax          (1)

-g*cos(theta) + x*sin(theta) = Az        (2)

where, g is the gravitational constant, theta is the tilt angle, Ai is the acceleration measurement  of the accelerometer along the i axis. We gave this set of 2 equations to matlab using the solve function.

And it returned 2 solutions:

theta = -2*atan((Ax – (Ax^2 + Az^2 – g^2)^(1/2))/(Az – g))
theta = -2*atan((Ax + (Ax^2 + Az^2 – g^2)^(1/2))/(Az – g))

We tried each of theses solutions, but none of them worked. We investigate some more about it and the main problem is that, experimentally, the measurement aren’t perfect and are skewed by noise.  Thus, even if there is no tilt angle, Az isn’t perfectly equal to g. Furthermore, even if theoretically Ax² + Az² is supposed to be equal to , experimentally it’s not the case, and that leads to calculate the square root of a negative number, that isn’t a great thing in the real world.

So, our conclusion is that even if this set of 2 solutions is mathematically right, it’s not relevant in the real world and we decided not to use it.

In addition, we lied, equation (1) and (2) aren’t perfectly right, we also have to add the acceleration terms from the rotational movement of the chassis around the wheels axis. That leads to :

g*sin(theta) + l*theta_dot_dot + x*cos(theta) = Ax          (1)

-g*cos(theta) – l*(theta_dot)² +  x*sin(theta) = Az             (2)

That’s why we finally decided to put the sensorboard as close as possible from the wheels axis so that l is small as possible. That hopefully able us to neglect this two terms.

Anyway, we think that a proper set of coefficients for the measurement noise and the process noise in the Kalman filter will be sufficient to correct those problems.

To be continued.

RoseWheel : CAN & Kalman

Today, we finished and/or improved some of the micro tasks we assigned to each other at the beginning of this week.

We tested a lighter version of the Kalman Filter that will be used in RoseWheel on the testbench we made a few weeks earlier. We used a light version because the full one needed to know the state equations of the system to be accurate. As we didn’t want to loose time trying to find out the state equations of the testbench (even if they are really similar to the ones of RoseWheel), we decided to test a version that was only able to track the drift of the gyroscope and make some minor corrections on the signal from the accelerometer during x axis translation. The light Kalman filter worked well and did what we expected, he tracked the drift and thus corrected the gyroscope noise and also filtered the signal from the accelerometer thanks to the sensor fusion.

During the experiments, we could observe that the noise from both the accelerometer and the gyroscope weren’t as high as we expected, that is a good news. However, even if the drift problem is correct by the Kalman filter, the measurements from the accelerometer are still not accurate during movements because of the noise induced by the other accelerations components. These other acceleration components are only dependents on the angle and its derivatives. We thought of a way to subtract those noisy components at each step by using the estimation of this values at the previous step. We will test it tomorrow on the testbench if we have time to do it.

We also finished the implementation of the CAN drivers and we tested it on our laboratory boards as we didn’t receive yet our mainboard. The tests were satisfaying. But as at the time we performed the tests we hadn’t decided yet the final version of the CAN protocol we were going to use for the communication between our 3 board (mainboard, sensorboard, HI board ), we didn’t use any filters. Hopefully tomorrow we will be able to test the CAN protocol as we will receive our mainboard.


RoseWheel : accelerometer done and progress update

One of our PSSC was to have a functionnal accelerometer for last monday. Despite the fact we didn’t post that day, we did have a working implementation and we were able to compute the inclination angle using the normalized 3D acceleration vector. We did this only with interruptions and without any kind of polling. The code was actually already working at our last demo. But in the meantime we’ve made some improvements that deserve to be described here. We used to detect rising edge of the accelero’s RDY pin to update the values. The rate at which values are calculated depends on the decimation factor chosen. According to the datasheet it spans from 40 Hz to 2560 Hz (with only 4 different values) and because of the fact we need 200 values per second we chose a decimation factor of 32 that enabled us to refresh values at a rate of 400Hz (closest value). Using interruptions at rising edge of RDY pin and then requesting the values from the device using SPI bus protocol was a bit demanding for the processor at this rate. We have therefore chosen not to use the RDY pin to be able to choose more precisely our rate of update. Some changes have also been made on the number of bytes used to represent data and a global coordinate system has been defined for both accelerometer and gyroscope.


Video of our sensorboard displaying the inclination angle using a color led.

Today we also assembled the mechanics of the Zzaag project. We could even try to ride it using the board shipped with. Here is a picture of what it looks like:

Mechanics of th Zzagg project

Mechanics of th Zzagg project

We had the time to begin the drivers for our hypothetical encoders (we are not sure to be able to set them on the mechanics) and we will be able to finish them tomorrow to be able to validate another PSSC.

At this point we have several pieces of software that wait to be integrated in our boards softs. The integration of the sensorboard has been started. In the main task an infinite loop wakes up every 5ms (200Hz). We retrieve the values of the accelerometer and the gyroscope that are updated separately in independant tasks. Then we need to give these values to the kalman filter for the final angle to be computed getting rid of the noise. But the kalman filter needs to estimate the next state before correcting the given values. We then need to receive the current values of the commands applied to the motors sent on the CAN bus by the main board. Finally we broadcast the computed angle and angular velocity on the CAN bus.