CyberVillain, I'm going to move the discussion onto this thread to increase visibility.
Previous thread: http://www.mtbs3d.com/phpBB/viewtopic.php?f=26&t=14167&start=0



Yeah but at least those guys are "straight-shooters". They disclose everything about their components (warts and all) so you know exactly what to expect.

The more I think about it, I'm pretty sure the 3.3V pin on the Sparkfun is an (optional) unregulated power supply pin to run the sensors and CPU. But you can also power the device through the regulated power connector (3 AA batteries would be sufficient). It's just unfortunate that the cable power can't be used because it does simplify the setup. However if you're thinking about going BlueTooth, you're going to need a battey pack anyways.

If you look at Mars youtube clip you it looks like a straight connection from the USB to the IMU, but we need his answer to be certain.. Mars where are youuu

I want to hook mine up tonight

I have a thread going on the sparkfun forum, nothing concrete yet though. I reallly hope mars reads this soon and can shed some light over it.. he doesnt mentioned anything about powering the chip in this thread so i guess i just let the pin on the cable do it, but i want confirmation before i hook up a expensive chip like this

http://forum.sparkfun.com/viewtopic.php ... 33#p137833

I think you can safely just connect TX, RX, and GND pins and then supply power to the regulated power connector via a 3 AA battery pack from Radio Shack . A temporary solution until you integrate the BlueTooth

who, me? Im not going for a wireless solution (Your thinking about the guy who is doing a VR gun).. So I would rather use the cable only if possible, but I do not like risking the IMU just to test.. I hope Mars will see this anytime soon. OH well, going to the movies with my girl now so do time for playing anyway.. Hope i have an answer tomorrow so i can start playing

Got an answer from Sparkfun



Why would i care if the internal voltage is 3.3 volt when they output 5 Anyway, I guess I can remove the 5V pin from the header and route that 5v to the JST pin which as a volt regulator

edit: But what i want is that SParkfun or my Swedish distributor supply me with a correct cable

when i connect the usb cable to the computer i get no reaction at all, and i get no voltage off the vcc pin, probably a faulty cable :/

Can a moderator change the first post in this thread and remove the link to the USB cable and add a link to this product

http://www.sparkfun.com/products/9873

The USB cable will fry the sensors on the board...

Oh crap did you fry your Sparkfun? Does that cable not downconvert from serial to TTL voltages?

No, no.. I just dont wont anyone else yo fry theirs, if they only read the first post and go try it they will
I'm waiting on a replacement cable because mine was broken.. I hope to get it tomorrow

Ok, no prob. Made the edit.

thanks CR

it is all hooked up now, but I got problems

I have downloaded this copy of the FreeIMU library

http://www.varesano.net/files/libraries_20111205_2110.zip

And i've included all the libs that the compiler complains about. Now my sketch file looks like this



Get this compiler error


Looks like there are two write methods and it does not know which one to use.... Whats wrong?

Thanks..

If you wanna try you can download the Arduino IDE, install the freeimu library and compile (You do not need the board to do this)

Didn't download code, but I suspect a #define variable would probably clear it up, but you might have to dig around to find it. You might look at the definition of uint8_t for starters.

Another more direct method would be to just modify to source code to directly cast that variable or the object that's calling it.



If that's the only ambiguous occurrence then you're golden - but don't be surprised if there are dozens in which case you might have to search for #define(s)

Hope that helps.

Fixed it! I am now receving data

Will write a quick C# test consoleprogram.. give me an hour and I have a youtube video up

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?

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?

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

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?

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

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.

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

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

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.

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.