DIY Head Tracker For A Tenner

[Amos]

yes that makes perfect sense, I have enjoyed playing with this thing, first time I have every done such a project.

So I loaded the code the latest one I think it mentions dan's exponential response, dated 23/4/2014 I still get the same issue, I loaded an older code in the change log last entry is HD version 22/3/2014

I put these entries in below

mpu.setXGyroOffset(63);
mpu.setYGyroOffset(-22);
mpu.setZGyroOffset(56);
mpu.setZAccelOffset(3012);

I get full range of motion in the calibration box but it raps around, do you think because I have a clone board or something it is mis-representing the code?

 

[pocketmoon]

would anyone be interested in working with me on a branch of pocketmoon's code (https://github.com/pocketmoon/MPU-6050-Arduino-Micro-Head-Tracker) using the extra sensor to combat drift?

Would be cool to have this as an option. Magnetometer fusion is an art since the magnetic field isn't regular and is effected by the environment. Rather than go the whole tripple sensor fusion route you could just use the mag reading to compensate drift every few seconds. Program size may be a challenge

 

[pocketmoon]

I get full range of motion in the calibration box but it raps around, do you think because I have a clone board or something it is mis-representing the code?

Do not trust the windows joystick calibration box It does not correctly handle high-def joystick devices. Standard controller axis return 8 bit values, ours return 16bits. As long as you see movment on all axis then your good to go in-game. Even if you see a bit of cross-axis movement you should be fine. The only sign to watch out for is pitch bounce - recalibration usually fixes that!

Also, no need to use the calibrate option in the the Windows calibration tool, better to change the scaling values in the code.

99.99% of the time any problems will be code related rather than hardware. These boards survive being baked in ovens.... Unless you snap the feeble micro usb connector off

Rob

 

[Amos]

thanks rob will check this out after I have a job interview to go to, will be back after then for much testing

 

[Dead Fred]

Yeah Rob, part of the manufacturing process is to drop the whole surface mounted panel into some really strong soapy water and scrub off all the solder flux with a dish cleaner then rinse it really well in clean water then bake it at 60 degrees C for about an hour.

They are pretty tough. A bit like babies, they can survive being made.

 

[Dead Fred]

thanks rob will check this out after I have a job interview to go to, will be back after then for much testing

Good luck.

 

[Sniper435]

Would be cool to have this as an option. Magnetometer fusion is an art since the magnetic field isn't regular and is effected by the environment. Rather than go the whole tripple sensor fusion route you could just use the mag reading to compensate drift every few seconds. Program size may be a challenge

I'm doing some internet searches and reading - this:
http://franciscoraulortega.com/pubs/Algo3DFusionsMems.pdf

seems to me to be a good starting place, I'll have an in depth read and see if I can implement anything from it - you've mentioned program size, can you point me to info on what limits we have on size and memory etc...?

 

[Amos]

Good luck.

thanks

 

[pocketmoon]

Here you go...

http://arduino.cc/en/Main/arduinoBoardMicro

It's like the 'good old days' where every byte counted!

 

[Sniper435]

Here you go...

http://arduino.cc/en/Main/arduinoBoardMicro

It's like the 'good old days' where every byte counted!

Cheers, I've been reading more into this and working out what "should" be done, my next step will be implementing the ideal and trying to squeeze it into the space we have, whether the two chips can be combined into one set of code with a simple flag for the user to select or whether we need to maintain two branches I guess will depend on how small I can get the code to be.

think it will be a fun challenge

 

[Sniper435]

Another question for those who've already spent time looking into DIY head tracking in elite...

we've got the "look" capability with two axis, are those the only ones we can use in elite or is there any capability to set up axis for tilting your head side to side or translational movements?

I've no plans relating to extra axes, just curious what the limits on the side of elite are. (I've only got Alpha 1.1 access at the moment due to being a premium beta backer)

 

[xyphic]

Another question for those who've already spent time looking into DIY head tracking in elite...

we've got the "look" capability with two axis, are those the only ones we can use in elite or is there any capability to set up axis for tilting your head side to side or translational movements?

I've no plans relating to extra axes, just curious what the limits on the side of elite are. (I've only got Alpha 1.1 access at the moment due to being a premium beta backer)

At the moment the game only exposes two configurable axes (pitch and yaw) for the head look input. The head tracker emulates a three-axis joystick so could do roll too, but there's no means to get it into the game. It doesn't look like Frontier have any plans to expose any more axes.

 

[Cosmos]

yes that makes perfect sense, I have enjoyed playing with this thing, first time I have every done such a project.

So I loaded the code the latest one I think it mentions dan's exponential response, dated 23/4/2014 I still get the same issue, I loaded an older code in the change log last entry is HD version 22/3/2014

I put these entries in below

mpu.setXGyroOffset(63);
mpu.setYGyroOffset(-22);
mpu.setZGyroOffset(56);
mpu.setZAccelOffset(3012);

I get full range of motion in the calibration box but it raps around, do you think because I have a clone board or something it is mis-representing the code?

Did you do the calibration from the joysketch as per brumsters latest blog post? Make sure the MPU is facing up when you do the calibration.

 

[Sniper435]

At the moment the game only exposes two configurable axes (pitch and yaw) for the head look input. The head tracker emulates a three-axis joystick so could do roll too, but there's no means to get it into the game. It doesn't look like Frontier have any plans to expose any more axes.

well that's a shame however I'm not really surprised, I presume the API for the "inbuilt" head tracking (i.e. however the rift or TrickIR work) isn't available / open?

 

[xyphic]

well that's a shame however I'm not really surprised, I presume the API for the "inbuilt" head tracking (i.e. however the rift or TrickIR work) isn't available / open?

The TrackIR SDK is closed (and subject to NDA). It's speculated that this NDA is the reason why Frontier don't expose more than the two tracking axes. It's also speculated that the NDA stipulates that they aren't allowed to talk about it (or the NDA!) which might be why there's been silence whenever we've asked.

Not sure about Rift, I know of at least one project that has attempted to fool the Rift SDK into thinking that a homebrew tracker is actually a Rift. Interestingly, the Rift SDK does the sensor fusion (which this tracker does onboard) so would require some CPU cycles for that. The Rift DK2 appears to be moving from an IMU concept to something similar to TrackIR that uses a camera, presumably for accuracy improvements. So any Rift emulation is only likely to work with older versions of the SDK.

 

[Sniper435]

sounds like an NDA is likely which is a bit annoying, not going to fuss myself worrying about rift or TrackIR emulation then, roll on the day when there's a standard for head tracking inputs for games rather than all these independent, closed methods.

 

[Amos]

Did you do the calibration from the joysketch as per brumsters latest blog post? Make sure the MPU is facing up when you do the calibration.

I will try that also thanks,

on a side note I was looking at enclosures for this, I have measured the pro micro and mpu and they measure at 5.35cm L and 1.8cm W

the box I have is off an old zalman fan the fan control dial, it measure at 5.7 cm L and 2.9cm W

its easier enough to pry the bottom off with a small screwdriver

 

[drakmaniso]

sounds like an NDA is likely which is a bit annoying, not going to fuss myself worrying about rift or TrackIR emulation then, roll on the day when there's a standard for head tracking inputs for games rather than all these independent, closed methods.

The thing is, there is already an open protocol for head tracking (FreeTrack).

But, because of the TrackIR bullying, it won't be supported by most games. So the monopole situation is here to stay...

The TrackIR SDK is closed (and subject to NDA). It's speculated that this NDA is the reason why Frontier don't expose more than the two tracking axes.

That, however, surprises me. I am not a lawyer, but I fail to see what kind of legal argument they could have against exposing the 6 axis of head movement. I was under the impression that the NDA was about not supporting any other head tracking protocol. Adding settings to a game is a different matter.

 

[Amos]

so I cut a prototype board up and put it inside and this is what it looks like

Spoiler

 

[PIXEL]

@ Pazmeister et al - You could try this..

KEY:

SW = SWITCH (momentary “push to make”)

BLACK RECTANGLE = PRO MICRO

GREEN RECTANGLE = MPU

THE RED DOTS = THE PINS REQUIRED ON EACH UNIT


THE COLOURED LINES:

DARK BLUE, PINK, YELLOW, ORANGE, WHITE = INDIVIDUAL CONNECTIONS (connect the 2 red dots at each end of each line)

LIGHT BLUE = Connect together ALL 5 red dots on this line.




but i haven't clarifiction from the Alpha ED Tacker forum thread whether it is totally correct yet