I cannot believe that I'm the only one who noticed that! I would write it off as a faulty device but I've got two brand new once here that produce identical output with the same unmodified firmware (V1.9)
Here is the description of the problem:
1. Initialize IMU level
2. Slowly turn 90 in roll
3. Return to horizontal orientation.
4. Slowly turn -90 in roll
5. Return to horizontal orientation.
6. Repeat for pitch and yaw (yaw rotate 360 in 90 deg increments)
Each axis output should correspond to the number of degrees turned. Instead I get the following:
Roll reading: actual roll: - 90 deg -> RLL output: - 120
+ 90 deg -> RLL output: + 120
Pitch reading: actual pitch: -90 deg -> PCH output: -50 (goes from 0 to -89 and then decreases to -50)
+90 deg -> PCH output: +50 (goes from 0 to 89 and then decreases to 50)
Yaw reading: actual yaw: 0 deg -> YAW output: 180
90 deg -> YAW output: 108
180 deg -> YAW output: 45
270 deg -> YAW output: -40
360 deg -> YAW output: -180
Okay, either I'm missing something or my unit is broken. A fair bit of data here, so bear with me.
I created a fork of the Arduimu 1.9.8 code and hosted it on github. In it I have 2 branches, master and correcting. In master I have a SampleOutput.txt that contains the raw serial dump from basically stock code. (Basically means changed outputs, disabled magnetometer, formatted comments, and a longer GPS timeout. No measurement functionality changed.)
In the branch correcting, I have two versions of the code. One is with 8192 gravity and with Ki_PITCHROLL and Kp_PITCHROLL modified. The other is with 8192 gravity and with Accel_Scale() used to modify read_adc returns.
Then I have a spreadsheet with three pages. The first page is formatted raw dump using stock code, the second is with PITCHROLL modified, and the third is with Accel_Scale() use. For each I tested by letting the calibration finish then rotating to a roll of 90, then back to 0 and through to -90 (or the opposite direction. Of three, two match direction. That's me rotating one of the in the wrong order, not the unit reporting wrong) then back to level. Then I pitched +90 and back down and stopped the log.
The spreadsheet contains the roll and pitch charted. As you can see by viewing them, they are not right. The only thing I wasn't sure of from the previous instructions is the weights. What is that in reference to?
Here are the links referenced above:
Could someone who has successfully gotten v3 working verify whether my changes are correct? I'm not familiar enough with IMUs, DCM, or even hardware development, to readily determine on my own what's wrong.
In my experience it seems close to impossible to get anybody to help on ArduIMU issues. I can't really help you with your problem except to say that I got v3 working correctly. It seems that you are trying to do to many things at the same time. If you can take a clean build and implement only the changes mentioned in this thread and post your output, I might be able to help. Right now it is just too confusing.
Thanks for the reply, Artem. I'm not sure what you mean by "trying to do too many things at the same time". The only functional changes present in the repository are the changes you recommended.
I'll point out the changed files so you can easily compare with what you suggested be changed.
The first change is to change gravity to 8192 and use different values (your recommended values) for Kp_ROLLPITCH and Ki_ROLLPITCH.
The second change is to retain the 8192 gravity but remove the Kp and Ki changes, and add the Accel_Scale() calls that you recommended.
As I said, you mentioned changing weights but I'm not clear on what that means. As my charts indicate in the spreadsheet in my previous post, one can sense what the axes are doing, but they don't report the correct values.
ya i too tried the same what u have Caleb but not successful yet to operate my arduino at higher speed....i would like if Artem would specify the changes ance again more clearly .....
i the attached file column O denotes the corresponding total distance and N the current displacement...the logic used for converting acc to dist is
and this is repeated for entire set of readings...can anyone please verify this method...
On keeping the magnetometer off ,there is drift is gyro(yaw)readings....any idea how to encounter this drift ...?? what changes do i need to put into the code if i want my gps to take readings periodically ...i.e switch on the gps ..take readings and aging switch it off periodically to save power...
changing weights but I'm not clear on what that means
I thought I mentioned that the new raw output differs from the old raw output by the factor 83.51?
However don't even worry about it. If you implemented the first change everything should've worked. Your output capture is inconclusive. All I can tell is that all you analog outputs are changing, which is a good thing provided your are moving your IMU. All these changes would not affect your analog values. It is the raw output of your IMU. These changes affect how you interpret these values i.e. how you calculate your pitch, roll and yaw based on these values.
So just implement the first change . Leave #define PRINT_ANALOGS 0 and see what your Euler angles output looks like. The easiest way is to move one axis at a time to predetermined angles (30 deg, 45 deg, 60 deg) and then mark it on the output. Don't use 90 deg since it might be confusing. If I remember correctly more than 90 deg pitch will cause yaw and pitch jump 180 deg off (which is what is supposed to happen) If the output doesn't track with the actual IMU movements then you might have some other issues with your unit.
Just a sanity check - you have a unit with a purple PCB, right?
I think so. It's blue or purple. (I'm color blind)
I might play with this again tonight, but I'm rather disenfrachised by the whole idea now and will likely just use computer vision alone to get the data I need. I was hoping to augment that with IMU measurements, but, as I said, I'm less enthusiastic about that now.
I appreciate your assistance.
I think so. It's blue or purple. (I'm color blind)
Read the silkscreen on the back. Does it say ArduIMU V2 ArduIMU V3?
ya mine is purple one ...i will try to incorporate suggested changes once more.
any idea what changes do i need to make into the code if i want my gps to take readings periodically and switch it off for the remaining time..is it possible?
what does 1g/4g scale actually means?
Sorry for the delay. It's a V3.
I've given up on this aspect of my project and left a note on Sparkfun warning people away from this. I am willing to accept that people might need to do extra work to get things running, but when a product has source code associated with it that claims to be compatible it and it isn't, that's pretty sad.
It is Nov 20, 2012 and I am testing a V3 board. I added Artem's two fixes in the ArduIMU.pde :
#if BOARD_VERSION == 3
#define SERIAL_MUX_PIN 7
#define RED_LED_PIN 5
#define BLUE_LED_PIN 6
#define YELLOW_LED_PIN 5 // Yellow led is not used on ArduIMU v3
// MPU6000 4g range => g = 4096
#define GRAVITY 8192
// WAS #define Kp_ROLLPITCH 0.015
// WAS #define Ki_ROLLPITCH 0.000010
#define Kp_ROLLPITCH 1.515/GRAVITY
#define Ki_ROLLPITCH 0.00101/GRAVITY
and the roll/pitch seem smooth but I still get wrong values. At roll = 30, I get about 45 on printout and for pitch = 30, I get about 40 deg on the Serial Monitor printout. Anybody else get the same? I know I am actually compiling the new source just by changing the Version printout text slightly e.g. "1.9X" I started with the 1.9.8 download.