DIY Head Tracker For A Tenner

But i do have the issue still where if i look to far to the sides i get chucked across to the opposite side?

The head flip doesn't happen for me with the defaults, but it did happen when I tried enabling exponential response and also when I increased the linear response factor. I think the way the final values are constrained to be valid, is intended for the default linear response.
 
The head flip doesn't happen for me with the defaults, but it did happen when I tried enabling exponential response and also when I increased the linear response factor. I think the way the final values are constrained to be valid, is intended for the default linear response.

mmm will have to test, i was advised to use the Exponential setting as it helps with small levels of drift, and i haven't changed the linear response.

More testing needed, must get this Velcro on the bottom of its new box home.
 
Great to see people's creations :) keep 'em coming!

Distracted by ‘work’ I’ve done the easy bit and built up the Ed Tracker on a bit of double sided board. Sat in the garden on Sunday with beer and a soldering iron :eek:
Used cut down DIL sockets for the Arduino and 9150 as I may have to play around with em’ on a breadboard. Cable tie and cigarette filter and a micro USB converter with hopefully protect against the dreaded Arduino socket death. External switch (off board) is a must - but will find a box to suit the tracker first.
ED%20Tracker%20board%2020-05-2014%20003%20.JPG

ED%20Tracker%20board%2020-05-2014%20006%20.JPG

Thanks to everyone involved for providing all the info for this project.

So... big deep breath before attempting to program. V1, V2 or ‘custom board’?? could be a long evening (-:
 
The head flip doesn't happen for me with the defaults, but it did happen when I tried enabling exponential response and also when I increased the linear response factor. I think the way the final values are constrained to be valid, is intended for the default linear response.

Yes, I have modified the code for exponential on the old V1 code because as you say, the clamping assumes linear axes. You need to clamp the output (iX) values not based on themselves, but based on the underlying raw values before they are scaled...

I've raised it with Rob, I'm sure once he's got a working PC again he can address ;)
 
Just a quick update for those interested in the 9150.
I've received all the parts and assembled my tracker with the 9150, current testing looks good - I left the device running overnight and logged the rotation of each axis in degrees, showed less than 1 degree of drift over the whole night.
I've got some more testing I want to do and some more improvements to the 9-axis fusion but I'll report in more detail once I've got some fancy graphs or data to show, hopefully what I've done will be of use although the methods for calibration and such are fairly different - it might be that it makes more sense to have a separate sketch / UI for the 9150 rather than try shoehorn the two together.
 
What you want to check is drift after RAPID movement of the sensor. So vigourously rotate it for a few seconds, then return it to the base position, and see if it returns back to zero.... be surprised if the DMP does take into account the magnetometer, but be great if you can show it does... or maybe you are manually fusing the values?
 
I'm happy to try test that - the problem being accurately returning it to it's base position.
as far as the fusion goes, it's being done manually - with magnetometer calibration data first needing to be stored in the IMU (only needs to be done once unless you move to a new location).

I'll upload a share a github repo of my work for everyone to look at once I'm happier with it and the codes a bit neater.
 
just ran a highly scientific test where I constrained the device in place (flat on desk and fitted into a corner), zeroed the gyro then wvaed it around my head and spun it around on it's usb cable like a lunatic before returning it to the same constrained spot.

this showed <0.5 degrees of drift - I don't know how good that is but for such violent movements I'd say it's pretty good.
 
this showed <0.5 degrees of drift - I don't know how good that is but for such violent movements I'd say it's pretty good.

A portion of that 0.5 drift (or all of it...) will likely just be the difference in its physical position when zeroed and its resting position after movement. Given how sensitive these things are, you would need a mechanical rig to guarantee returning it to its original orientation.

Might be worth repeating the test a half dozen times and see what the cumulative drift is at the end, but sounds very promising
 
A portion of that 0.5 drift (or all of it...) will likely just be the difference in its physical position when zeroed and its resting position after movement. Given how sensitive these things are, you would need a mechanical rig to guarantee returning it to its original orientation.

Might be worth repeating the test a half dozen times and see what the cumulative drift is at the end, but sounds very promising

I'll certainly play with it more and try do more useful testing - maybe try head banging in game.

on a slight side note - does anyone know what the rotation limits are in the game (if any) i.e. can your turn a full 360, or just 90 degrees either way?
 
So, my project boxes arrived today. Had to remove a plastic clip from the inside in order to make room for the pcb, but they are otherwise spot on. I have used a blob of blutak just to make sure there is no unexpected movement inside the box, but it is looking good.

I have opted to not expose the reset switch as I can now perform the reset remotely through a little python script. Given I can bind this to a joystick button or powergrid, this is my preferred option.

olgRtks.jpg

hhNEMkj.jpg

oCMfuhS.jpg

Project box is: here

Python script is: here
 
I'll certainly play with it more and try do more useful testing - maybe try head banging in game.

on a slight side note - does anyone know what the rotation limits are in the game (if any) i.e. can your turn a full 360, or just 90 degrees either way?

I'm sure it's more than 90 degrees, you can look over your shoulder. I can't test just now as I'm downloading 4.2 :)
 
I'm sure it's more than 90 degrees, you can look over your shoulder. I can't test just now as I'm downloading 4.2 :)

Lucky you :p really can't wait for the full Premium Beta to be out :( at least I should have my head tracker ready.

if anyone can give a rough (or accurate) estimate of how far you can tilt your head each way that would be handy.
 
if anyone can give a rough (or accurate) estimate of how far you can tilt your head each way that would be handy.

Have just had a play with this, and it looks like a 90 degree turn (in-game) takes you just past the screen on either side, with the limit being about ~120 degrees.
 
If you're using the original sketch, you can change how much you have to move your head.

Look for the following lines:
Code:
float xScale = 2.5;
float yScale = 2.5;
float zScale = 2.5;

...and change them. You'll obviously have to upload your new sketch to the tracker.

I changed mine to 5.5, so it now requires less physical movement to move your in-game view as much.
 
If you're using the original sketch, you can change how much you have to move your head.

Look for the following lines:
Code:
float xScale = 2.5;
float yScale = 2.5;
float zScale = 2.5;

...and change them. You'll obviously have to upload your new sketch to the tracker.

I changed mine to 5.5, so it now requires less physical movement to move your in-game view as much.

I'm not using the original sketch - I'm developing a version for the 9150, due to the difference in libraries and calibration methods I've pretty much started from scratch as I would have ended up re-writing most of the original sketch.
 
I'm not using the original sketch - I'm developing a version for the 9150, due to the difference in libraries and calibration methods I've pretty much started from scratch as I would have ended up re-writing most of the original sketch.
Ah, right gotcha.
 

Building on that info, I have a batch file containing the following command:

Code:
echo R > COM4

the trouble then being that the DOS window flashes on top of the ED screen when the file is invoked; a solution is to call the batch file from a vbs file:

Code:
CreateObject("Wscript.Shell").Run "d:\bin\EDTrackerReset.bat", 0, True

then I use GlovePIE to invoke the vbs file from a joystick button:

Code:
if (pressed(Joystick1.Button3)) {
    execute("d:\bin\EDTrackerReset.vbs")
}

[edit: or create a shortcut to the batch file, set it to run minimised, and invoke the shortcut from GlovePIE ... just give the shortcut a completely distinct name if you keep it in the same directory as the batch file].

[edit2] firing the weapon turns out to be a good place to do the reset every now and again, since you're probably looking ahead at that time.

Code:
if (Joystick1.Button1) {   // button 1 -- fires primary
    if ((var.now - var.tTrackerReset) > 30) {     // re-center head tracker occasionally
        execute("d:\bin\EDTrackerResetSC")
        var.tTrackerReset = var.now
    }
}
 
Last edited:
Been playing warthundertoday and edtracker II is working really, well, only a few times I had to reset, more soat the end but I had been playng for a few hours, realy pleased with this now, its working great,
 
Back
Top Bottom