Handling large data from gyros etc.

rjo__

The bugaboo when it comes to using MEMS gyroscopes is handling drift. There are many published ways to do it and they all seem to have the same problems and provide solutions that fall just short of being ideal. I have ideas that I would like to explore. The first idea is that there is no such thing as noise... noise is just a signal that I don't understand. I have been able to convince myself that the drift component of several different gyros is not random and doesn't seem related to temperature in the way we might expect from the data sheets.

I have come to this conclusion by doing some simple filtering of the data over long periods of time directly on a Propeller Activity Board and saving the results to a file on my computer using FDS(full duplex serial). On a Mac this means using the screen utility in the terminal and applescript to manage it all. What I would like to do is save the raw data and then use software on my Mac OS X on that data.

I tried saving the data as image data (red=rx green = ry and blue=rz) and then using filters on that... but the bit depth is a problem.

I have found a DOE package that I think will do the job... but after fiddling with it for a couple of hours can't seem to get the data in and displayed...http://visitusers.org/index.php?title=Main_Page

I have simple ascii files... any ideas about simple, open software that can do custom analysis and visualization?

Thanks

Rich

Heater.

Rich,

I have simple ascii files... any ideas about simple, open software that can do custom analysis and visualization?

Yep. You are using it as we speak. Yes, your browser.

Create a simple web page and include am HTML5 canvas tag on it.
Add some javascript to load that data and draw whatever you like into the canvas area from it.

Dave Hein

You can clip the data to 8 bits or use something like a log function to reduce it from a larger number of bits to 8. That way you can convert your data to 8-bit image pixels.

However, I do have a problem with your premise that there is no such thing as noise. You may want to read a textbook or two on the subject of noise before you make such a bold claim. Also, you state that drift doesn't seem related to temperature, even though it is well known that temperature is one of the major contributors to drift. Of course, there are other contributors, which is why you may have reached the false conclusion that that drift is not related to temperature in the way you might expect.

Heater.

rjo__
You are wrong about noise, and drift and temperature.

Never mind the data sheets. This calls for an experiment:)

Bolt your gyro down to something immovable.
Start recording the values that come out of it.
Measure the temperature at the same time.

If you can keep the temp stable you will see noise and perhaps some drift that is not temperature dependent.
From your measurements you can decide if the noise and or drift is important to your application.

Being able to vary temperature over time and measure drift will tell you if temp stability is important to you.

rjo__

Dave,

Thanks

After I read your response, I took a shower... and while in the shower, it occurred to me that I can store the data at full bit depth and then parse that file to make several files to process as images. Each channel would end up as a 16/32 bit image... which could then be massaged using imaging tools. And it would also allow for multi-dimensional correlation analysis, which I find to be fascinating.

Noise does exists as a perturbation. But by starting with the null hypothesis, I hope to eliminate everything that is not completely random.

In this case, most of the noise is far from random:) So, I am wondering if, for a specific, individual sensor, it might be possible to develop a stochastic method to greatly eliminate it.

Simply by using large scale normalization, I have been able to reduce the noise at rest to less than a degree in 20 minutes... but it varies, sometimes it is 20 minutes...
sometimes it isn't. Normally, one looks for correlations among the various differentials, but it might be true, here, that what we should be looking at are periods when the various differentials are near zero.... and then seeing if we can find a stochastic relationship between them. If I could find a pattern that indicated that the normalization was becoming inaccurate, that might be enough. If I can find a pattern that indicates that the period of normalization is adequate, that might be enough. I am also interested in seeing whether the period of normalization relates to the final results.

Rather than coding each experiment and doing it on the Propeller and waiting several hours for each result, I want to collect data sets and then perform experiments on them. Much quicker:)

Most of the time, what I find is that the experts are exactly correct. Occasionally, they aren't.

At any rate, your comments have help me over the first hurdle. I'll try to post some of the experiments. Experimenter bias is a major concern:) So, your comments are
greatly appreciated.

Thanks

Rich

rjo__

Heater,

I have mostly looked at the l3g4200d so far. Just got my MPU6050. The experiment that I have done the most is with a stationary sensor, taped to my desk. I use the average of a variable number of initial readings(in a range between 10,000 ->100,000 data points)and and then subtract that average value from the raw readings... that resulting value is then summed with a running total and converted into an angle of deviation. I am doing it all with integer math, correcting for the fractional part periodically.

The temperature data is only 8 bits. I have not been controlling or recording the ambient temperature. With the L3G, I think the sensor temperature reading represents the difference between sensor temperature and ambient temperature... that might be where I have gotten it wrong. What is true is that, in this experiment, the sensor temperature reading does not appear to directly correlate with the average gyro signal (at rest )or with the rate of change in output values. I have just been eyeballing a massive amount of data, so I could easily be wrong on this, or I might have to consider ambient temperature and pressure in the mix.



Thanks,

Rich

rjo__

Not that this isn't all as clear as mud;)

This data set shows the result of sequentially averaging 10000 measurements of the L3G4200d at rest, repeating the measurement 1468 times over about 21 hours, with each temperature reading made at the end of each averaging period... about once every 51 seconds.

The format is cx is the whole part of the x error, dcx is the fractional component. So, for dx=-1 dcx=-6000 the average output over 10000 readings is -1.6000.
Same for cy&dcy and cz&dcz.

Rich

Duane Degn

Rich,

Remember you're on a rotating Earth. Apparently you don't live at one of the poles or you'd get a drift of one degree every four minutes. Your one degree per 20 minutes could be from the Earth's rotation.

rjo__

Duane,

Good point

I know that the earth is rotating... but where does it show up in my data?

In this data set, I kept the gyro busy collecting data for a while doing averaging as above.
Then I accepted the last error measurements and proceeded to see what error it would produce in my data.
The actual data follows the keep busy section and has timer measurements.

If you look down to the twenty minute mark you see this:

260200RAWx=1 X=-38 E_X=-8 E_Y=11 E_Z=-2 t=12 timer=00:20:00.2
The format is as follows

260200 is the sample number
RAWx is the reading on the X axis=1
the correct reading is X=-38
E_X is the summed angle measurement on X =-8 degrees.
E_Y is the accumulated angle measurement on Y =11 degrees and
E_Z is the angle measurement on z=-2 degrees.
The temperature is t=12 12 degrees.
The timer is reading 20minutes and 2 seconds

Rich

Dave Hein

Is your data the filtered output of the gyro, or the integrated values? The gyro outputs angular velocity, and not the angle. You have to integrate the gyro output to get an angle value. Gyro drift usually refers to the drift in the integrated angle value, and not the drift in the raw output value. Angle drift is caused by a change in the value that represents a zero angular velocity. I plotted your x and temp values, and there does seem to be a correlation. The x value is approximately (13 - temp)*5 + 37, which I show in the plot as f(t) in green.

Mark_T

You don't care about drift in a stationary gyro, that's always going to be the smallest drift amount.

The drift when its moving is far more important, since that's what the gyro is for, compensating for rotary
movement, and that's when most non-ideal properties of the device will show up most.

Just to measure drift realistically you need to mount the gyro on a turntable and turn it known amounts and compare with
the integrated output. Sampling rate, anti-aliasing filter and the number of guard-bits in the calculations will all be
factors to consider. Expect drift to go up with max angular acceleration and average angular speed.

There will be cross-talk effects between the channels so when rotating about x you'll have to monitor all three channels.

For an analog gyro you can investigate ADC resolution and noise-injection too (noise-injection reduces
the low frequency component of quantisation noise, which should reduce drift due to quantization)

rjo__

Sorry about my delay in responding. A long time ago I damaged my Propeller Board of Education and it finally died. In the process, it crashed my computer and it took me a while to sort it all out and get my stuff back together.

Dave...

Wow. Thank YOU. Your math is clearly better than my poor eyes:)

Good point. I didn't write that clearly. The data that you (very nicely) analyzed was from consecutive series of averaged raw data, uncorrected.

The data in the second series above is a progressive series of integrated values converted to angular measurements produced as follows:

Each raw measurement was first corrected by subtracting the average measurement (found as described for the first series). This value was then added to a running total, which was then converted to angular measurements and output with the time and temperature ending of that output.

The output only shows one result for each one hundred calculations.

The integrated (angular) values start with "E_". I output the rawx and corrected x only for debug logic and never removed it. The numbers might be off by a smidge because I measured the time factor for converting rate data to degrees and left it as it that was... but then I kept changed my reporting method, which takes time, which changes the method times...you know.

Mark

I need to finish this set of experiments first... BUT

I completely agree... AND it was news to me when I found it:) . What I found is that if I move my board in an even manner, my angular error stays about the same. But if I lift along an axis slowly and then drop it back quickly(but evenly), I produce errors that are well beyond the resting errors I have been measuring. So, clearly I need to mount this up on a rotary table....hmmm

This is all part of a project to build a self aware wheelchair... and I have the motors controlled with my homebuilt quadrature encoders... so it makes perfect sense to hook the two together:)

This could take a while, Grandma is leaving... so I have major doodies with my grandson.

Thanks Guys.

Rich

rjo__

here's the code