[Video] Diy HeadTracking - Sparkfun Razor, Python, Gmod,

Post by **CyberVillain** » Wed Jan 11, 2012 3:18 pm

[youtube-hd]http://www.youtube.com/watch?v=-IJkjwypLU8[/youtube-hd]

Post by **brantlew** » Wed Jan 11, 2012 3:32 pm

Looks great! Can't wait to get my hands on one of these. Maybe you are seeing tracker noise and just need to put a smoothing filter on it. Is it bridged through GlovePie or another interface?

Also when you get a chance can you look to see if the spatial translation (X, Y, Z) tracking works at all or does it look like garbage?

Post by **CyberVillain** » Wed Jan 11, 2012 4:10 pm

Its a problem with my Freetrack emulation, if i send a static float on all 3 axis i still get jumpy behaviur.. Strange thing is when I include the freetrackclient.dll in a testproject it looks good, and Arma2 uses the same dll to read freetrack data so I do not know where they read the wrong data from :/

Hmm, theres only 3DOF? I cant get translation values of this one can I?

Post by **brantlew** » Wed Jan 11, 2012 4:22 pm

It should have the sensors on-board to estimate translation. Maybe FreeIMU only supports orientation. Bummer.

Post by **CyberVillain** » Wed Jan 11, 2012 4:41 pm

I do not think freeemu supports it oit of the box.. maybe you can take the data from the 9 sensors and do the math yourself?

Post by **CyberVillain** » Wed Jan 11, 2012 5:24 pm

There is some huge drift, I do not know if its my copy or if all suffer from it :/

Post by **cybereality** » Wed Jan 11, 2012 10:33 pm

Not bad for a first test.

You can try putting a sort-of low-pass filter on the readings. I did that for the Vuzix tracker I made. Basically set a maximum delta value with something reasonable and then ignore anything over this amount. It should be the fastest you could expect a user to move during one frame (could be around 10-20 degrees). I found this to pretty much eliminate those kinds of random jitters.

Post by **CyberVillain** » Thu Jan 12, 2012 1:56 am

YEah, I have a low pass filter... Its something else, maybe its the float precision or something, Arma2 maybe want a lower precision or something. If i use the real freetrack server everything works, but if I use my freetrack server emulator it does not work.. If I send hard coded values with low number of decimals it works, like 0.1, if i send 0.00001 or something like that I get the stutter.. So its not related to the sensordata, its something in my way of simulating Freetrack...

Post by **CyberVillain** » Thu Jan 12, 2012 2:25 am

I've also written a little freetrackclient test program that uses the standard freetrackclient.dll (same as Arma2) and that works. So its a combination of some code in Arma2 and C# floats thats strange.. I think

Post by **brantlew** » Thu Jan 12, 2012 9:16 am

Any possibility its a byte ordering issue? I've stumbled across weird crap like this a lot working in Java where the byte ordering is enforced as little-endian as opposed to x86 native. Had same problem with OSC and GlovePie.

Post by **CyberVillain** » Thu Jan 12, 2012 9:19 am

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

Post by **CyberVillain** » Thu Jan 12, 2012 11:04 am

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

Code: Select all

                            var text = serialPort.ReadLine();
                            var values = text.Split(',');

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

Post by **CyberVillain** » Thu Jan 12, 2012 11:12 am

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!

[youtube-hd]http://www.youtube.com/watch?v=EKu1BgPYhrg[/youtube-hd]

Post by **bobv5** » Thu Jan 12, 2012 1:04 pm

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.

Post by **brantlew** » Thu Jan 12, 2012 1:30 pm

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.

Post by **CyberVillain** » Thu Jan 12, 2012 1:37 pm

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

Post by **cybereality** » Thu Jan 12, 2012 7:26 pm

Great work, its looking really nice so far.

Post by **WiredEarp** » Thu Jan 12, 2012 8:29 pm

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

I thought that was what the compass component was for.

Post by **brantlew** » Thu Jan 12, 2012 8:34 pm

WiredEarp wrote: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.

Post by **CyberVillain** » Fri Jan 13, 2012 2:07 am

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...

Post by **CyberVillain** » Fri Jan 13, 2012 11:45 am

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

[youtube-hd]http://www.youtube.com/watch?v=RVIK2gm9jQ4&hd=1[/youtube-hd]

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

Post by **CyberVillain** » Fri Jan 13, 2012 7:51 pm

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" onclick="window.open(this.href);return false;

Post by **cybereality** » Fri Jan 13, 2012 9:20 pm

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

Post by **brantlew** » Fri Jan 13, 2012 10:47 pm

CyberVillain wrote:I downloaded the AHRS software to the IMU instead, it looks like it has more calibration options.

What an excellent little walk-through!

Post by **CyberVillain** » Mon Jan 16, 2012 1:40 am

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.

Post by **WiredEarp** » Mon Jan 16, 2012 4:36 am

;( 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?

Post by **brantlew** » Mon Jan 16, 2012 10:41 am

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?

Post by **CyberVillain** » Mon Jan 16, 2012 11:00 am

The AHRS software uses all 3 sensors,

https://dev.qu.tu-berlin.de/projects/sf ... he-tracker" onclick="window.open(this.href);return false;

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

Post by **CyberVillain** » Mon Jan 16, 2012 5:57 pm

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)

[youtube-hd]http://www.youtube.com/watch?v=L4plqHQpewY[/youtube-hd]

Post by **cybereality** » Mon Jan 16, 2012 9:22 pm

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.

Post by **brantlew** » Mon Jan 16, 2012 9:58 pm

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.

Post by **CyberVillain** » Tue Jan 17, 2012 2:59 am

cybereality wrote: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.

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

Post by **CyberVillain** » Tue Jan 17, 2012 3:01 am

brantlew wrote: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.

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

Post by **brantlew** » Tue Jan 17, 2012 6:43 pm

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.

Post by **android78** » Tue Jan 17, 2012 8:49 pm

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.

Post by **android78** » Tue Jan 17, 2012 8:53 pm

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

Post by **WiredEarp** » Tue Jan 17, 2012 10:49 pm

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 ;-(

Post by **CyberVillain** » Wed Jan 18, 2012 2:54 am

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

Post by **brantlew** » Wed Jan 18, 2012 9:14 am

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.

Post by **android78** » Wed Jan 18, 2012 4:12 pm

Try this one:
http://www.sendspace.com/file/q2k7mx" onclick="window.open(this.href);return false;

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" onclick="window.open(this.href);return false;) 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.