L3G4200D Gyroscope and EEPROM

MoZak18

Hello,

I am trying to run the L3G4200D gyroscope's example code off the Parallax site from EEPROM (24LC256), but I am having a problem. Reading from RAM is fine, but when I power it up to read the code off the EEPROM, the values for all 3 axes start out at some non zero values. I think I need to do something along the lines of flushing the registers, but I am not a seasoned programmer. Any help would be greatly appreciated.

Thanks

L3G4200D_Example_code.spin

Mike Green

"the values for ... non zero values"

Is that a problem?

Since the gyroscope is connected to I/O pins 24 & 25, I can't see why running the program from RAM vs copying it from EEPROM to RAM, then running it would make any difference other than a longer time from power on to first use of the gyroscope. Unless you need for the values for the 3 axes to start off at zero for some reason, I can't see why you'd need to do something special to the registers.

How about throwing away the first or first few readings?

MoZak18

@Mike Green

I think you misunderstood, it's not just the first or first few readings that are skewed (i've seen that with some sensors and I'm ok with it), they're all pegged at fixed values that are all the same. Now, what's not so bad is that these values are essentially the new "zeroes" and if you rotate the gyro they will change with reference to those values....but for this project I need to keep track of the rotation of a balloon package for an extended period of time, and during that time power may be lost and come back on (batteries getting cold and warming up through the atmosphere) so I need the values to always be with reference to zero, otherwise I will have to sift through tens of thousands of lines of data in Excel to find where the rotation is with reference to zero and where it is with reference to those values. I have tried applying a "correction factor" in the code to accomodate for this, but I am sure there is a simpler way to clear a few registers upon starting each time.

If you are able to run the code from RAM and EEPROM with this sensor you will see what I am talking about.

Thanks

Mike Green

The first time I ran it from RAM, I got non-zero values. When I ran it from EEPROM, I got zeroes. When I repeated both after powering down, I got zeroes in both cases. I don't know this gyroscope enough to suggest what you could do to reset it. Be patient. Someone more knowledgable will chime in. If not, give Parallax Tech Support a call.

ratronic

Edit: see next post

ratronic

After trying to duplicate your problem I saw it when loading to ram from the computer. I put in a small delay in the Calibrate method to fix it. So here is your fixed code and also code that keeps somewhat track of the current gyro orientation. Also a gyro by itself will not be able to track the current balloon orientation.

MoZak18

Ratronic,

Other sensors on board this balloon include a pressure sensor (the Parallax 29124 altimeter module), multiple temperature sensors, a magnetometer (the HMC5883L), and an accelerometer (the Hitachi H48C). I'll be using the accelerometer to measure bank and roll angle of the package, and the gyro to determine the yaw rate (since weather balloon packages tend to rotate or "spin" quite a bit). All of this data will be written to a micro SD card. When you say "a gyro by itself will not be able to track the current balloon orientation" are you just talking about not using it in conjunction with an accelerometer, or are you saying it won't be able to consistently measure roll/pitch/yaw rates over time with reference to zero? I'll be in the lab again in the morning to try out the code. Thank you very much for taking the time to look over the code and modify it.

ratronic

In the second piece of code I posted it returns the orientation by constantly adding the readings, and error will keep the gyro a drift one way or the other after time. But you could use the readings from the HMC5883L to correct it. I am following along Jason Dorie's QuadX code as I think he is getting ready to try to implement a magnetometer to help with his quadcopter orientation. Have fun with your project!

MoZak18

I am only using the HMC5883L for raw data, that is, to measure the terrestrial magnetic field strength (see how it decreases with altitude). I wanted to write heading data to the SD card also, but it proved to be quite troublesome from the example code provided, and since heading isn't very relevant for a weather balloon I decided not to waste time on it. I forgot to mention that a GPS receiver will be on board as well to write position and time to the SD card as well as to re transmit that data on 248 MHz so we can track it.

When you say it returns the orientation, what do you mean? Also, how bad do you think the error will be over time for an application such as this? Is this error just concerning the Earth's rotation? Also considering that this sensor is a rate gyro, doesn't that in a way make it immune to such errors? As I understand, a free space gyro utilizing rigidity would be prone to drift, and the severity would depend on it's latitude, but I thought this wasn't the case for a rate gyro.

Also, let me know if you want to see the code for this project if you're interested. It's quite a bit for my taste, I will probably end up with 21 files.

ratronic

If you need a earth reference for yaw orientation the gyro by itself will drift over time. Try the code I posted and you will see that when you move the gyro around it keeps a pretty good lock on the current atttitude (orientation) when it's still but error will creep in after awhile of moving it. I am not to much into balloons but I know there are other people here that are and might be interested in your code.

MoZak18

Ratronic,

Your code almost works perfectly, but there is still a small error. I have tried to attach the Excel data output files from the SD card, but apparently you can't attach Excel files on this forum? Instead I will just try to explain to you what's happening. Whenever I load the code to RAM, it works fine as it always has; when I keep the gyro still, all the values are zero. But when I load it to EEPROM, turn it off, then power it back up, I get zeroes for the Y and Z axes but nonzero values for the X axis. This is better than before where I would get fixed values for all 3 axes (if I remember it was 22 for Z, 4 for Y, and -5 for X). There is a pattern though, instead of being a fixed value, the values for the X axis count down, starting at 0 and incrementing by about -1 every 3 or 4 iterations....so it counts down 0,-1,-1,-1,-2,-2,-2,-3,-3,-3,-3, etc. for example.

Attached I have two files (and a few other objects that they call); one is my main (main.spin) and the other is the gyro sensor file (gyro_sensor_mod.spin). The gyro sensor file is your file with a few modifications. One modification is that it writes data to an SD card instead of the serial terminal. The other modification is that I have an error check function that sees if the values are nonzero (note that although this was working for me before, it for some reason doesn't detect the error on the X axis any more). All in all it retains the same function as your code (or the example code in the past) which a few changes around the edges. My main calls the gyro sensor file among many other files....you can just comment the others out and leave the gyro sensor in. I've done my best to comment and explain what is going on in the files. If you can take a look at these that would be great. The one thing you might be missing however is an SD card adapter.....

main.spingyro_sensor_mod.spinfsrw.spinASCII0_STREngine_1.spin

Thanks!

MoZak18

By the way.....I tried initializing the ix, iy, and iz variables to zero at the beginning of the gyro sensor file and it almost gets rid of the error, but I am left with small negative numbers (ranging from zero to -2).....it's adequate but not perfect like the other axes. If you have a better suggestion I'd greatly appreciate it. Thanks again!

ratronic

Your gyro has to be "rock still" when the Calibrate method runs at startup which maybe before you remove your finger from the power switch. Try increasing the delay at the beginning of the Calibrate method from 1/2 second to a full second to make sure all movement is gone after you physically move the power switch at startup. Just to let you know I'm no expert when it comes to gyros. I've picked up what little I know from JasonDorie here on the forums following his quadcopter project in the Projects forum.

Publison

ratronic wrote: »

Your gyro has to be "rock still" when the Calibrate method runs at startup which maybe before you remove your finger from the power switch. Try increasing the delay at the beginning of the Calibrate method from 1/2 second to a full second to make sure all movement is gone after you physically move the power switch at startup. Just to let you know I'm no expert when it comes to gyros. I've picked up what little I know from JasonDorie here on the forums following his quadcopter project in the Projects forum.

Just before I went to bed last night, I added a 1 second wait to the original code, (calibration) and let it run over night. It was rock solid. I didn't post this morning, because I saw Dave already had added the wait to the same area.

I agree, 1/2 half second might not be enough to extract your finger from the power or reset switch. Running 1/2 second, I had readings of -1 or -2 as my finger left the board, (PPDB).

Jim