When ArduIMU initializes it accepts the horizontal plane to be the plane of initialization. For example, if I initialize ArduIMU tilted 45 deg in the roll axis it will begin outputting 0 deg roll when it initializes, and will count everything now from that 45 deg position. I thought that it should be capable of determining its orientation in space based on the reading from accelerometer since we always have 1G acceleration present (gravity) in the vertical direction. Am I doing something wrong or this is the way it is supposed to be? Don't know if it matters or not, but I don't have a GPS connected for this test.
You need to be a member of diydrones to add comments!
I have never used this particular IMU with any open source autopilot, but do you all guys really place your aircraft perfectly horizontally before you turn the autopilot on and wait for it to initialize? And from there on it becomes your horizon? Seems like an awkward way of doing things.
Alright, since everybody here were so helpful, I'll post a solution of sorts ... for the posterity sake. In the startup_ground subroutine of the IMU code, when IMU initializes it takes a bunch of consecutive reading of the accelerometer output and then "averages" them and assumes that it is the horizontal plane. In my "non autopilot" application I needed the IMU to "find" the horizon by itself, because the orientation during its initialization was unknown. The output of the ADXL335 accelerometer is biased right in the middle of the power supply for the 0 G condition. In other word if you put your IMU perfectly horizontal and the input voltage is 3.3V the output for x and y will read a number corresponding to 1.65V output. So knowing that you can just hard code the magic numbers for the horizontal plane. There are several things which can affect the accuracy of this: the range of the 0G output given by the specsheet is 20% in x and y and 40% in z direction. 0_0 How about them apples? I have only one unit here to experiment with, but mine comes up pretty close to the "dead center" every time. So I would hypothesize that this range refers to the static value that doesn't change with time and related to the way the chip has been manufactured. In that case it can be mitigated by initial adjustment of the "magic numbers" Now, if it is temperature dependent, then it is really not going to work. The other unknown is the fluctuation of the 3.3 power supply on your IMU board. Mine remains pretty close to 3.3
What I did in the code is commented out the line: //AN_OFFSET[5]-=GRAVITY*SENSOR_SIGN[5]; and added the following: AN_OFFSET[3] = 500; AN_OFFSET[4] = 500; AN_OFFSET[5] = 520;
Those numbers seem to work pretty good.
A better way to do it would be to use it as a starting point and then assuming that the aircraft is not moving measure the gravity using those values. If it the value is higher or lower than 9.8 then adjust those starting numbers proportionally (that would be an assumption that they all drift proportionally) However in my case it seems to be working just fine as is.
Replies
I have never used this particular IMU with any open source autopilot, but do you all guys really place your aircraft perfectly horizontally before you turn the autopilot on and wait for it to initialize? And from there on it becomes your horizon? Seems like an awkward way of doing things.
Alright, since everybody here were so helpful, I'll post a solution of sorts ... for the posterity sake. In the startup_ground subroutine of the IMU code, when IMU initializes it takes a bunch of consecutive reading of the accelerometer output and then "averages" them and assumes that it is the horizontal plane. In my "non autopilot" application I needed the IMU to "find" the horizon by itself, because the orientation during its initialization was unknown. The output of the ADXL335 accelerometer is biased right in the middle of the power supply for the 0 G condition. In other word if you put your IMU perfectly horizontal and the input voltage is 3.3V the output for x and y will read a number corresponding to 1.65V output. So knowing that you can just hard code the magic numbers for the horizontal plane. There are several things which can affect the accuracy of this: the range of the 0G output given by the specsheet is 20% in x and y and 40% in z direction. 0_0 How about them apples? I have only one unit here to experiment with, but mine comes up pretty close to the "dead center" every time. So I would hypothesize that this range refers to the static value that doesn't change with time and related to the way the chip has been manufactured. In that case it can be mitigated by initial adjustment of the "magic numbers" Now, if it is temperature dependent, then it is really not going to work. The other unknown is the fluctuation of the 3.3 power supply on your IMU board. Mine remains pretty close to 3.3
What I did in the code is commented out the line: //AN_OFFSET[5]-=GRAVITY*SENSOR_SIGN[5]; and added the following:
AN_OFFSET[3] = 500;
AN_OFFSET[4] = 500;
AN_OFFSET[5] = 520;
Those numbers seem to work pretty good.
A better way to do it would be to use it as a starting point and then assuming that the aircraft is not moving measure the gravity using those values. If it the value is higher or lower than 9.8 then adjust those starting numbers proportionally (that would be an assumption that they all drift proportionally) However in my case it seems to be working just fine as is.