Hmm, dont think so, if that was the case it the result would have been total screwed up
Will test more without the sparkfun, maybe send a nice Sinus curve

This gets more and more sick.. If i send it a cos curve it works, from a seperate program..

But if i do the same thing from my sparktest program it jitters (I do not even send anything from the sparkfun), all it takes is that i have the SerialCom class initliezed and listeing on the com port and it scews up arma?!?!

One more thing that is strange, I tried to record the jitter with fraps, but when I start fraps the jitter goes away

Wtf?! Solutions please

edit: I was wrong there, i can have teh com class inited, but if I read from teh com port in the main loop where I send to Arma it screws starts to jitter

If i uncomment these two lines the cos-curve looks nice in arma


If i uncomment them arma starts to jitter (Even if i do not use the values in the values array)

Lol.. if i hadnt written my little test program and gone and written the real program I wouldnt have had the problem..
In my test program I read from com and sent to freetrack in same loop / thread.

In the real program I would have had an Input class with a background thread and firing an update event when something new is on the com.. It turns out that putting the com reading in a own thread solves the problem!

Looks great. You could use a freetrack type thing to center the view when looking straight ahead, to compensate for that little bit of drift.

Coming along nicely

Hopefully you will be able to characterize the drift a bit in the future. (which axis is most problematic, which types of motion are problematic, how many degrees per minute on average during gameplay, etc..)

Once you get the GlovePie integration in there, this could be the tracker of choice for nearly everyone here (as long as they don't mind a little soldering). I would be interested to see someone take a crack at a simple DIY design for an enclosure - a cabled design as well as a battery powered bluetooth integrated module.

I'll probably be getting one of these pretty soon to play with. CyberVillain If you can't find an easy way to get X,Y,Z position information from that API, I might take a crack at it.

I will probably focus on getting a C# program for it up and running first.. Algebra was never my thing anyway
Its the Yaw that has the drift, I havent had the time to play with it so much that I can really decide if its a problem or not.. will have to try to fix a way of mounting it on my headset so i can actually dry and game with it

Great work, its looking really nice so far.

Isn't eliminating the yaw drift the entire point of these '9DOF' sensors?

I thought that was what the compass component was for.

You know I sort of have the same question. There's no doubt that these magnetic sensors hold their calibration much better but can anyone explain to me in simple terms why they can't maintain a constant and stable calibration using the earths magnetic north? I mean I can open a box of Cracker Jack and find a sensor that keeps a better yaw heading than these IMU's. Someone please enlighten us.

The FreeIMU is not written for the exakt same sensors has in the Sparkfun 9DOF. I've talked to the guy behind FreeIMU library and he's promised to add full support to Sparkfun IMU in upcoming version, it's very likely that the drift issue will be solved with that...

edit: I do not have the exact detail but it could be that FreeIMU does not utilize all of the IMU's sensors...

I tested the IMU using the test libs that comes with FreeIMU, it looks bad



I move the device two times during the video, look at the drift

I downloaded the AHRS software to the IMU instead, it looks like it has more calibration options.. Its up and running and are sening data to my c# program, but I have to look into the calibration stuff tomorrow

https://dev.qu.tu-berlin.de/projects/sf ... he-tracker

Hmm... I wonder if there is enough data to compensate.

What an excellent little walk-through!

I did some calibrating yesterday, i dont have a compass so I could only calibrate the accelerometer and the gyro (To calibrate the magnetometer you need to know exactly were north is pointing)... But it didnt help much, still drifting like crazy on the Yaw, I guess i cant rule anything out until I have calibrated the magn. But has i understand it there is always some drift on the magn and thats why the software on the IMU should use the other two sensors to compensate for that, so i do not have my hope up that it will get much better after I've calibratet the magn.

;( unfortunately, doesn't sound that promising so far!

Why is their drift on the magnetometer? My non digital compasses never have 'drift' (although, they are operated flat, not potentially at an angle). My phone however does require calibration for its digital compass. Since normal compasses work fine, surely it is possible to create a digital compass without drift?

I'm not convinced yet that this product is flawed. Maybe we just aren't driving it with software that incorporates the magnetic readings well (or at all)?

Also I'm still confused as to why magnetic readings cannot be calibrated against the earth's poles. Maybe it's an artifact of interior environmental magnetic noise. I wonder if it behaves this way outside?

The AHRS software uses all 3 sensors,

https://dev.qu.tu-berlin.de/projects/sf ... he-tracker

I think the AHRS test software has less drift than my Arma2 test (The game you have seen on my youtube clips). Either they do some kind of additional post processing to the signal (Which i doubt because you only have access to the 3 axises from the data they receive) or drift isnt has noticable in their program because thats just an object rotating while the in the game the entire view port is rotating

edit: The magnetometer calibrating procedure is just that, to calibrate it to the northpole where you are located, the angel to the pole is different in all corners of the earth, me living in Sweden has a steap angle to the north pole while those further south has a flatter angle

I now use the exact same code (Ported to C#) as the AHRS test software. But i get a much more jumpy experience then the test software (I think that board they render are alot further away and not as notible as an entire viewport changing), can you guys download the source, look into the Razor_AHRS_test.pde file and see if you guys can see any filtering.. Thanks

edit: A little youtube clip to show my software vs AHRS test software.. Both drifts like crazy when after move (it stabaily after a second or so)

Have you looked at using a Kalman filter? Don't know too much about it myself, but I think its supposed to help with this sort of stuff.

That little red board looks jumpy to me as well. I think you are correct in your assumption that the jumpy viewport is much more noticeable. If you really want to verify it you could just record the test app values to a file and then "replay" them into Arma. Those sensors are supposed to have some noise in the raw feed so I think the typical solution is just to apply a small low-pass filter and/or a smoothing filter.

Will look into that, thanks. Right now I have a really simple filter (but superfast)

lastSample = (lastSample * x) + (Input * (1 - x))
where 0 < x < 1

x should be > 0.5 to get smoothing out of the filter

Yeah, I have to look into better filters.. I lost some of my creativity though, since it drifts so much :/

That is unfortunate about the drift. I want to do a little research on the fundamental problem of magnetic drift to understand why it happens, because it still does not make sense to me. This is making me re-think plans for my own projects to use optical yaw correction instead of magnetic correction.

Have you looked at the multiwii code?
It's designed for a multicopter, but you could basically just take away all of the pilot, RC control and use the filtered outputs from that. I tested with a multi-sensor board and it seems to get pretty good results with the digital compass.
I think there is something screwy looking at your results there and the drifting. I believe that multiwii essentially uses the compas for a long term average and adjusts the calculated value from the gyro a little each time. It could be the same as what is happening with yours.

Actually, it looks like the issue in your code could be that the scaling of the gyro is off. basically, you turn it a little, and it thinks you've turned it a lot. The reading from the compass is then off from the calculated value from the previous position+gyro reading, so it it then adjusting it back to where it should be with long-term average.

one other thought is to output the individual values from each sensor without combining them to see if they are all performing correctly.

Anecdotal evidence from FPV forums suggests that some of the new combo headtrackers are actually pretty useable. Theres one in particular that everyone raves about, that apparently requires you to face North or South when you initialize it, but after that it is supposed to work really well. I'm guessing it 'recalibrates' when you turn through North slowly.

However, whether magnetic calibration is going to helps on the pitch axis is another story ;-(

I have a dialog with Sparkfun now to see if something is faulty with my unit, they have seen the clip and they think something is fishy..

Android, sounts like you have to buy one of these and help us out here

That sounds promising.

I was having a conversation with an engineer friend of mine (he doesn't particularly specialize in this type of tech but he's a smart guy). We were speculating that maybe the magnetic environment in an indoor room full of electronics would have a larger signal than the background magnetic fields of the earth. If so then the tracker would be using a dynamic environment as a reference point instead of a true fixed reference. That would be an inherently unstable situation and might explain how this magnetic drift happens. If true, that would be good news for me because I plan on testing the Sparkfun in an outdoor environment which would not be as susceptible to these conditions. It would still suck for most indoor applications however.

Try this one:
http://www.sendspace.com/file/q2k7mx

you might need to change the I2C addresses for the sensors, and the averaging could be out, but at least you should be able to see the raw data from the sensors to see if the reading is drifting, or if it's coming from the calculations.
basically, I'd only look at the graph of the magnetometer and see if it moves when you hold the board still. Then turn it 45 degrees and do the same. Do this 8 times and you should get a pretty good idea how accurate the sensor is.
If this is correct, then I think you need to look at the driver software. The example firmware (https://github.com/a1ronzo/SparkFun-9DO ... t-Firmware) has an option to output the raw data:

//prints the raw vaues with a '$' start and '#\n\r' end
printf("$");
printf("%d,", x_accel());
printf("%d,", y_accel());
printf("%d,", z_accel());
printf("%d,", x_gyro());
printf("%d,", y_gyro());
printf("%d,", z_gyro());
magnetometer();
printf("%d,", x_mag);
printf("%d,", y_mag);
printf("%d", z_mag);
printf("#\n\r");
delay_ms(350);//at least 100ms interval between mag measurements

If you just open a serial monitor program, you should be able to get it to output that and then copy the output generated as you turn it round. paste the results into a spreadsheet and convert the values as comma delimited into cells.
I believe the y_gyro is rotation around the vertical, so you can do a comparison between that and calculated vector from y_mag and z_mag:
angle_from_y = atan(y_mag/z_mag)

If you create the above in a new column, then you can create another column for calculating the change in angle between two consecutive results from this calculation.
If you graph the change in angle from the mag sensors and the y_gyro, then you should see correlation between the two.
If not, then there could be a problem.

hmmm... too many if's in that last post. I should have used a switch/case statement.

Thanks android for the help you are giving. It would be really great if he can get this tracker to work well.

Are you using a 120Hz 3D monitor? Please I have an ASUS 120Hz monitor and it causes the Razer Hydra to get super jittery. If I turn the monitor off and use an older display, then it works fine. Seems the ASUS emits a magnetic field that messes up the Hydra, it would probably mess up an IMU as well. Try turning off anything that might interfere.

I will try this new lib tonight, its only a 6DOF library not using the gyro so if it gives me the same result I can rule out the Gyro as the faulty sensor

http://n0m1.com/2012/02/27/6dof-arduino ... lerometer/

edit: Cyber, I have a 19 inch SPVA display @ 60 or 75hz, great colors but a little small and low res

cool. curious to see the results

Dont think it will compile for the Sparkfun IMU, different sensors :/

Looks like it should be able to compile for the ADX345 Acc, but im a noob on C and Arduino, someone wanna give it a shot?

Hey CyberVillain, any update on this? Curious if you made any progress to eliminate that drift problem of yours... Also, are you using GlovePIE or FreePIE? I found this on pastebin through your YouTube channel:

This is for GlovePIE right? But (bare with me, I've only been reading up on this all since last night) can be used in FreePIE? Going to test it after dinner and see if I can hook this up with UDK (Unreal Development Kit). I'm using a Bluetooth module to send all values from the Razor, but so far in FreePIE i'm getting good results.

Also found this video of a guy using a FreeIMU with Gary's Mod and there's no drift at all. Might be worth checking out how the Source engine (or Gary's Mod itself) handles all the input! I know it's not a Razor IMU, but still, might shed some light..
Videolink: http://www.youtube.com/watch?v=vVrflj30 ... 1337100842

Thats GlovePIE code, havent bothered to upload the FreePIE code to youtube, FreePIE is still so small. But yes, I have this running with FreePIE too, nice that FreePIE is working nicly for you.

FreePIE equivalent of above GlovePIE code (Freetrack plugin used but can be switched to the other ones)


I dont know if its my Sparkfun IMU or if I live in a magnetic field of some kind, but I cant get it to work :/
Nope didnt get that code to work property, this is as far as I got




Yeah I know about that guy, it was him taht got me on the Sparkfun track.. Hes not using any filters other than the fusion in the FreeIMU lib

Thanks a lot CyberVillain! You made my day by sharing that with me

1. So far I got it working (got rid of the hotkey and use only the toggle function) and quick tested it in Crysis 2. Seems your multiplier was set pretty high, but I'm sure it's all game related?

2. And oh, just to let you know I'm having the same drift issues you've been having so it's definitely not your IMU. Haven't calibrated it yet with the AHRS so going to do that as well before trying again.

3. I've used a USB cable this time to get it to work, since my Bluetooth module outputs in binary mode by default apparently. Need to change that into text output, burn it again and test it WITH the Bluetooth module. Going to do so this afternoon and post any results here.

And now for another FreePIE question: How can I send serial commands? I know GlovePIE uses "Serialout(COM12, "COMMANDHERE")" and I did a quick search for a LUA equivalent. Or am I going at it from a totally wrong angle? Would like to know how to do this because I can make my Razor IMU output text format with a command (#ot) as you probably know. This way I won't have to rewrite the Arduino code and it gives me the possibility to synch with it so I won't run into any reset problems.

Any input is much appreciated guys!