Head Tracking for under 10€

[CaptainObvious 95]

First of all I got Yaw on RotX, pitch RotY and Roll on RotZ (and that is how it is connected in Arduino software).

Oh fuck I feel stupid now, with proper axis' it's working as it should.

I'll have to calibrate it better at some point though, it's still getting minor "ghost input" on yaw when pitching, but now it's playable :cool:

Second you are aware of fact that front is on wider edge (in MultiWii it was diffrent). But nice steady scope from GUI calibration is good.

Yea, the same way it's shown in the rcgroups thread, only I have ~10cm wires between the Micro and the GY80.

[SnowSky 12]

Thanks SnowSky but this isn't working too well for me I'm afraid.

It seems to do strange things, like swap the Pitch and Roll axis whilst I'm playing and even after stopping and restarting (after closing the game and looking at FTNoIR) they were swapped, until I Centered and then they swapped back!

I'm also having very bad, what I guess is drift, as whenever I look around, it ends up with the view very off centre when I look straight ahead, so I'm constantly having to Centre.

Hopefully it'll be usable one day but for me right now it's just not.

Hi, well in fact, if you want to use another one, but still want to have the ingame interaction possibilitiy, you only have to copy one function and two instructions in the main loop.

in the main loop insert:

if(Serial.available() > 0)
   serialEvent();

on the outside of the mainloop, insert the following function:

void serialEvent()
{
   switch (Serial.read())
   {
         case 'C':  // Center (FT will align, so this shouldnt be used)
         // set_last_read_angle_data(millis(), 0, 0, 0, 0, 0, 0);
         //last_z_angle = 0;
         //last_gyro_z_angle = 0;
         break;

         case 'Z':  // Zero 
         last_z_angle=0;
         break;

         case 'S':  // Start
         case 'R':  // Reset
         //Initialize the angles
         calibrate_sensors(200);
         set_last_read_angle_data(millis(), 0, 0, 0, 0, 0, 0);
         break;
   }
}

if you use the spring_reset, the serialEvent function exists already, you only need to insert

         case 'S':  // Start
         case 'R':  // Reset
         //Initialize the angles
         calibrate_sensors(200);
         set_last_read_angle_data(millis(), 0, 0, 0, 0, 0, 0);
         break;

in the switch instruction.

And you have to check the rs232 settings "Flow Control" had to be Set to none in my case.

[SebastianB 10]

Oh fuck I feel stupid now, with proper axis' it's working as it should.

I'll have to calibrate it better at some point though, it's still getting minor "ghost input" on yaw when pitching, but now it's playable :cool:

Yea, the same way it's shown in the rcgroups thread, only I have ~10cm wires between the Micro and the GY80.

Do not worry it happens :).

Define minor (+-2 degrees may happen as magnetometer has its issue but yes you can always try better calibration)

BTW here is link with mine working https://www.dropbox.com/s/eofs8p71xiho05k/2014-06-11%2014.02.39.mp4 (its war thunder). Movements in X and Y are coming from camera face detection.

[CaptainObvious 95]

Do not worry it happens :).

Define minor (+-2 degrees may happen as magnetometer has its issue but yes you can always try better calibration)

BTW here is link with mine working https://www.dropbox.com/s/eofs8p71xiho05k/2014-06-11%2014.02.39.mp4 (its war thunder). Movements in X and Y are coming from camera face detection.

Nice accurate response you got there!

I think the ghost input is definitely caused by bad calibration, it's around 10 degrees when I'm looking all the way up/down, I'll have to tinker with it a bit once I get back behind my desk, I'll let you know how it goes.

[doveman 7]

Hi, well in fact, if you want to use another one, but still want to have the ingame interaction possibilitiy, you only have to copy one function and two instructions in the main loop.

Sorry, I don't understand what you mean. Use another what? What are these modifications intended to achieve?

I certainly don't want to use the spring_reset, as that forces the view back to centre when trying to look around, which I found very annoying.

---------- Post added at 18:07 ---------- Previous post was at 18:03 ----------

Got my Pro Micro and GY-85 working nicely for Pitch and Yaw now, thanks to Sebastian.

There's seems to be quite a bit of Roll when Yawing however, so I left the Roll axis disabled to prevent that but no significant interaction between Pitch and Yaw :)

[SnowSky 12]

Sorry, I don't understand what you mean. Use another what? What are these modifications intended to achieve?

I certainly don't want to use the spring_reset, as that forces the view back to centre when trying to look around, which I found very annoying.

---------- Post added at 18:07 ---------- Previous post was at 18:03 ----------

Got my Pro Micro and GY-85 working nicely for Pitch and Yaw now, thanks to Sebastian.

There's seems to be quite a bit of Roll when Yawing however, so I left the Roll axis disabled to prevent that but no significant interaction between Pitch and Yaw :)

If you were using it with the GY-85 I guess you can't use the source I used because that one was for the MPU 6050 which has gy521.

regarding the roll yaw I could imagine that the sensor is not position straight on your head (this way your movement in one axis could establish the sum of two axis) - but thats just a guess.

[doveman 7]

If you were using it with the GY-85 I guess you can't use the source I used because that one was for the MPU 6050 which has gy521.

regarding the roll yaw I could imagine that the sensor is not position straight on your head (this way your movement in one axis could establish the sum of two axis) - but thats just a guess.

No, I wasn't using the MPU 6050 code with the GY-85. Two separate boards and separate code.

[SebastianB 10]

BTW for people with MPU6050 you can always try http://www.edtracker.org.uk/ . I heard that it has nicer drift compensation tool.

[doveman 7]

Has anyone successfully hooked the Pro Micro to a HC-05 to use Bluetooth? http://www.instructables.com/id/Cheap-2-Way-Bluetooth-Connection-Between-Arduino-a/?ALLSTEPS

I've got the HC-05 working and detected by my PC now and after adding the HC-05 device, Properties shows 'Serial Port (SPP) Dev B' on COM 16. If I look under BT Settings, it shows this as Outgoing and also another line for HC-05 Incoming on COM17, so I'm not sure which I'm supposed to use.

If I try and connect to COM16 with Teraterm, I get an error and although it connects on COM17, I get no output (I've uploaded the 'send test' sketch which should show a counter and does if I connect to COM 14, which is the USB port)

Reading this http://arduino.cc/en/Reference/SoftwareSerial#.UxIQbXk1jFE I get the impression I can't use the RX1 pin on the Pro Micro, so I tried connecting pin 10 to HC-05 TX and 15 to HC-05 RX and adding this to the start of the sketch

include <SoftwareSerial.h>

SoftwareSerial BTSerial(10, 15); // RX | TX

but it hasn't helped.

[doveman 7]

BTW for people with MPU6050 you can always try http://www.edtracker.org.uk/ . I heard that it has nicer drift compensation tool.

I had a go with this but in the calibration GUI, the head is constantly going round in circles and the calibration doesn't move the two dots to the inner circle, in fact they stay on the edge of the outer circle.

It also seems to use a button on the device to re-centre, whereas the other sketches posted here do this in software, using a FTNoIR hotkey which is much more convenient.

[staynex 15]

Hello,

is it possible to disable the Rollback on the Roll-Axis?

[SnowSky 12]

I had a go with this but in the calibration GUI, the head is constantly going round in circles and the calibration doesn't move the two dots to the inner circle, in fact they stay on the edge of the outer circle.

It also seems to use a button on the device to re-centre, whereas the other sketches posted here do this in software, using a FTNoIR hotkey which is much more convenient.

A good solution for me would be a drift correction based on a 2nd source.

I for example use FaceTrack for Movements, and the board for rotations, this way I have 6 dof at a pretty good reaction time.

Imagine we could use the Gyro for fast movements/rotations, and the drift/error calculations get corrected by the second source which is slower but steady - that would be awesome^3.14159265358979323846264338327950!

[echoj7 11]

Any body with a NanoWii or just a good ini mind sharing it? Having no luck at all getting the thing usable.

[Crimson13 10]

I made a IR led array that's tracked via a modified psEYE.

It works pretty good. Hardest part was making the narrow light of the led be more visible on the sides. (still working on that)

Edited August 10, 2014 by Crimson13
Added picture.

[tvamvarg 0]

A good solution for me would be a drift correction based on a 2nd source.

I for example use FaceTrack for Movements, and the board for rotations, this way I have 6 dof at a pretty good reaction time.

Imagine we could use the Gyro for fast movements/rotations, and the drift/error calculations get corrected by the second source which is slower but steady - that would be awesome^3.14159265358979323846264338327950!

That seems like a very good idea! FTNoIR supports two simultaneous input sources it seems but I've never seen it used, I guess it would usually be one source for Pan/Tilt/Rot gyro and another for XYZ positioning. If the other source is to be used for the same thing FTNoIR would have to be written to support that, or there would have to be specific drivers that could take input from two sources. I suppose. Which makes me doubt it will be done (but hey, I have been known to be wrong before...)

[telejunky 0]

After upgrading my pc, i also had to reinstall my os. I did'nt keep track of my old arduino/setup files etc. And right now Sourceforge doesn't seem to work.

Can anyone provide me some links with the actual links to the arduino files/ Hatire plugin, please? Thanks a lot :)

While I can't reach sourceforge from germany. The japanese version works soureforge.jp, but there i could not dowload it. I found the file over baidu... http://pan.baidu.com/wap/shareview?&shareid=2659504062&uk=436321480&dir=%2F-%3D%E7%94%B5%E5%AD%90DIY%3D-%2FDIY%E6%97%A0%E7%BA%BF%E4%BD%93%E6%84%9F%E5%A4%B4%E7%9E%84%2F%E5%A4%B4%E7%9E%84%E8%BD%AF%E4%BB%B6&page=1&num=20&fsid=1690880479&third=0

Edited August 23, 2014 by telejunky

[tvamvarg 0]

Posting my experience of a GY-85 build (after trying an MPU6050, seeing its great potential but too much drift so wanted to take the next step):

Bit of a hassle regarding drivers and installation/calibration. I have the Sparkfun Pro Micro which required its own drivers, so be sure to find and install those first.

The solution I went for was Sebastian's GY80facetrack which works with the Hatire plugin for FTNoIR (similarly to the MPU6050 as described in thread's start).

For the GY-85, this currently means that you have to upload one sketch and then run a Calibration GUI to do a calibration, and then upload another sketch to provide output to FTNoIR (sketches look almost identical, but they haven't yet been able to sort out how a single sketch should look to work for both calibration and running).

NOTE to potential users: I had to do a lot of trial and error before I found that the Pro Micro would stop outputting data about three seconds after "running sketch" upload, and if I start FTNoIR tracking within this time window, it will keep running - but if FTNoIR tracking is not started, it will time out for some reason and no data will be sent. A re-upload will have to be done. I also haven't been able to interpret the Calibration GUI's output and decide there whether it's ok to run FTNoIR - it's still trial and error for me here.

This wouldn't be too bad if calibration was done once and for all. But unfortunately, I've had to re-calibrate for every session (after putting the computer to sleep), and even then, the output from FTNoIR to the game is very erratic - sometimes it works, most times it doesn't. Whether it's the Pro Micro that sends weird stuff out, or if it's Hatire that is buggy, I don't know. The results are that tracking output often seems somewhat random - roll axis will be active even though it's deactivated and receives no input from the board, axes will be mixed up, and so on and so on. It's just back and re-do parts or whole of the calibration procedure.

However. When it works, which it sometimes does, it works beautifully!! Really! It's very precise and there is no trace of the drift that was very present with the MPU6050. So, a lot of promise here.

To go mainstream, we have to sort out the buggy behavior though (anyone that would like to help me with ideas on how to get good diagnostic output is welcome to PM me!). Only currently recommended to those with large amounts of patience (and who are seldom on a tight deadline to join a MP game, for example).

[Bamse 223]

Heya!

I ordered two Pro Micro 's along with one MPU6050 and one MPU9150 some time back and recently got everything home and I'm trying out some different options.

After I've spoken to the guys over at EDTracker I liked the simplicity so I built one and got everything up and running. (EDTracker supports both sensors, you just don't get any benefits with the MPU9150 over the 6050, yet).

When using the EDTracker ingame I get a _very_ choppy resolution on the analog look. It's feels like your'e mashing your face against minecraft blocks and it's pretty much impossible to use it when flying. Looking around just makes you dizzy and using zoom together with this is just not possible. The drift compensation worked like a charm and I could play for about an hour before even noticing it.

So, I uploaded one of the sketches found here (tried both the latest mentioned spring and SnowSky's) but I didn't become friends at all with the spring version and I had crazy drift with SnowSkys after just 10-15 minutes, but otherwise I liked it alot. Still, I cannot use it during my 2-4 hour long sessions.

This ends up like a Sophie's Choice kinda situation; choppy "resolution" using EDTracker or crazy drift using FTNIR/Hatire.

I still like the simplicity of EDTracker and would prefer if I could get that running. Any recommendations on how solve either situation would be most appreciated :)

Edit: Two very crappy videos I made to show the difference

FTNIR+Hatire:

EDTracker "Official":

Edited September 1, 2014 by bamse
Added videos.

[Bamse 223]

Using the EDTracker firmware or my Cyborg/Saitek FLY5 stick causes the same identical choppy-vision . Using a joystick device as an analog free look device seems less than mediocre at best.

I've gotten some input from one of the developers of the EDTracker on the youtube clip;

So for now the ruote to be taken seems to either be the spring-sketch way or using the alternative way reported on the RSI-forums that still uses the EDTracker sketch along with the excellent drift compensation ... but it take quite a bit more configuring along with 2-3 additional programs running ... stealing the precious and very well needed CPU cycles from Arma :/ I find running the "RSI"-way best so far.

Bug reported to feedback tracker, please feel free to up vote this! :)

http://feedback.arma3.com/view.php?id=20603

Edited September 4, 2014 by bamse

[denco 16]

I ended up buying DelanClip which I'll use with my PS3 eye. Can't wait for it to arrive.

http://www.ebay.com/itm/DelanClip-Motion-Tracking-FaceTrackNoIR-Free-track-compatibile-with-TrackIR-/331296415386?pt=UK_PC_Video_Games_Video_Games_JS&hash=item4d22ce1e9a

[denco 16]

DelanClip arrived and I've been testing it for days. I gotta say it work great and without issues.

[sthalik 10]

Hey guys,

As for the inertial Arduino trackers, please provide the following information:

- singularities, i.e. whether there's a glitch if put upside down, on the side, moved violently, or any other pattern

- whether it stops working suddenly, requiring reset

The reason is the firmware code that computes the data.

We're discussing Arduino/hatire development on the usual place, as well as through email.

We can act on the info and research the issues further, so state other problems as well.

-----

Magnetometer can fix drift but can cause it also. Headphones' electromagnetic emissions are enough to confuse a magnetometer.

As for calibration, changing headphones or putting the magnetometer on the other side of the head needs recalibration.

-----

Some guy's already working on an android app. No idea about iphone.

-----

EDTracker doesn't glitch anymore in today's build.

-----

For drift, use mm0zct's code from opentrack Rift tracker, it's already appreciated by Rift users with gyro problems.

-----

-sh

Edited September 13, 2014 by sthalik

[SnowSky 12]

Well -I did post it somewhere a long time ago, what I'd like to have would be a drift correction by a second static source, like for example FaceTrack.

This way you could have the responsiveness of the gyro, and the drift correction by the facetrack (this way perhaps it would be also possible to use the accelerometers of the sensor because you can correct them too).

In some manner it is possible to calculate the delay between both sources. By knowing this delay it would be possible to tell the arduino how much it has to correct (lets say your facetrack calc is 1 second behind, compare the differences you got by the arduino one second ago and then correct the drift by that value.

In winter when I will have less work to do - I may take a look into it myself.

Up to than I don't have the time to play or do anything that would need my attention for more then 20min.

[sthalik 10]

"How much to correct" is known as sensor fusion, part of control theory.

If talk about drift, there are separate issues here.

One is the algorithm itself which uses mag data only for yaw.

Second is how spring effect works wonders.

Mag, Gyro, Acc are already three data sources. Spring effect does the rest for prolonged game sessions.

There's absolutely no need for other data sources than mag/gyro/acc.

tl;dr please merely list problems for now

[doveman 7]

Hey guys,

As for the inertial Arduino trackers, please provide the following information:

- singularities, i.e. whether there's a glitch if put upside down, on the side, moved violently, or any other pattern

- whether it stops working suddenly, requiring reset

-----

EDTracker doesn't glitch anymore in today's build.

-----

-sh

Certainly my GY-85/Pro Micro is prone to stop working suddenly and when I check in FTNoIR, the raw data and output data is stuck on some high numbers. I have to disconnect the USB lead before I can restart it and it often requires several tries. It also doesn't seem to like it if I plug in the USB cable before starting FTNoIR but it's hard to be sure as it always takes me several attempts of unplugging/re-connecting to get it to start even with FTNoIR loaded.

When it's working it's been quite stable for me in DCS and ArmA3 though. I had to severely limit the Yaw in DCS, otherwise it makes the view jump when I look towards the rear but limited to about 40, it lets me look as far back as needed without doing this.

I just bought myself another GY-85 to replace the MPU on my second board, so that I could experiment with getting it working via BT, whilst keeping my other USB only board intact, to use for gaming in the meantime.

I might give EDTracker another go first though, if it's working better now. When I run "java -jar UpdateTool.jar -l" though, the latest build is dated 4 September, so where do I get this newer build you refer to from?