DIY Head Tracker For A Tenner

[Bumvelcrow]

Brumster, I'll happily pay £25+p&p for one of these (kit form, I think you said) so put me down. Time to brush up (or develop) some soldering skills.

I've been following this thread with one eye, so can I just confirm that it needs an arduino for calibration? This leads me to another question - I've seen a lot of arduino 'compatible' boards around, some with the same functionality and some supposedly genuinely compatible, so I presume the latter category would be suitable unless told otherwise.

Time to buy a soldering iron.

Sounds like fun? The other half laughs when I wear shorts or a hat, so having a glowing circuit board attached to my head is going to be slightly embarressing.

B

 

[brumster]

No, the £25 option was a fully built up on - for a kit, just buy the board from us and then get the kit from Hobby Components (you can ditch their board, but it works out cheaper). All I'd be doing is buying the kit from HC any way, as I've not found anywhere cheaper for the bits in the UK.

 

[Bumvelcrow]

No, the £25 option was a fully built up on - for a kit, just buy the board from us and then get the kit from Hobby Components (you can ditch their board, but it works out cheaper). All I'd be doing is buying the kit from HC any way, as I've not found anywhere cheaper for the bits in the UK.

Ah, okay. In that case I shall go for a board. If I got the fully built one then I'd always feel I hadn't done enough work to enjoy the reward. Plus, I've been meaning to weld (sorry, solder) my rasberry pi to various items around the home so this will be a good opportunity to build something useful.

Besides, it sounds fun.

B

 

[JonnyRedHed]

Everyone asking for just kit parts, I feel a bit of a whimp for asking for a fully built and working one. Let me explain a bit, my arthritis in my hands is getting pretty bad these days so fine work is becoming harder.

If I started an electronics project with soldering and fine work, it wouldn't end well. So a fully built tested and working one at the price set would be perfect for me.

 

[Amos]

I received an email back from hobby components and they said

Hi,

Just to follow up on our last email, I have spoken to the supplier and we have been able to source this module. We currently have a batch on order for expected delivery at the end of this week. We expect the price to be about £13.49 for single quantity but we can provide discounts for multiple quantity.

Regards

Andrew

that is for the 9150, so all in all looking good if you guys can get the additional sensor working.

Just finished moving house 3 days of hard work and finally got the internet back on.

 

[brumster]

I received an email back from hobby components and they said



that is for the 9150, so all in all looking good if you guys can get the additional sensor working.

Just finished moving house 3 days of hard work and finally got the internet back on.

Excellent news Amos! Well done!

 

[drakmaniso]

Another tracker assembled (on a breadboard for now) and working here!

Though I had some trouble to make it work: during several hours, the X and Y axis were mixed in the output.

By that I mean that while roll was correctly output as Z, moving the device along yaw or pitch would translate into a weird output involving both X and Y axis. In the windows controllers properties, yaw would draw a diagonal, and pitch a U shape.

• I used MPU6050_calibration several (at least 10) times, and also the "Full calibration" included in the tracking program. The resulting numbers were always similar, and the problem remained.
  
• I also ran MPUReset multiple times, with no effect.
  
• Then I tried the examples of the MPU6050 library, and there the output was correct: each axis was independent. So I knew the MPU was not defective...
  
• But after a few more try, the tracking program output started to work... Unfortunately I still don't know why. I had changed a few lines in the code (see below), but even after reverting the lines, it still worked...
  

On this subject, I noticed that in the program the quaternion is converted to Euler angles directly in the code, but in the library examples this is done by the DMP (dmpGetYawPitchRoll and dmpGetGravity). Is there a reason for this? I seem to have a bit smoother output with the DMP calls, but I need to experiment more to see if this is consistent.

Anyway, a big thanks to Pocketmoon, Brumster, Dead Fred and everyone involved! This project is amazing.

 

[Amos]

Thanks mate not heard anything fro the job interview yet just got the news about alpha 4 great news

 

[Amos]

Another tracker assembled (on a breadboard for now) and working here!

Though I had some trouble to make it work: during several hours, the X and Y axis were mixed in the output.

By that I mean that while roll was correctly output as Z, moving the device along yaw or pitch would translate into a weird output involving both X and Y axis. In the windows controllers properties, yaw would draw a diagonal, and pitch a U shape.

• I used MPU6050_calibration several (at least 10) times, and also the "Full calibration" included in the tracking program. The resulting numbers were always similar, and the problem remained.
  
• I also ran MPUReset multiple times, with no effect.
  
• Then I tried the examples of the MPU6050 library, and there the output was correct: each axis was independent. So I knew the MPU was not defective...
  
• But after a few more try, the tracking program output started to work... Unfortunately I still don't know why. I had changed a few lines in the code (see below), but even after reverting the lines, it still worked...
  

On this subject, I noticed that in the program the quaternion is converted to Euler angles directly in the code, but in the library examples this is done by the DMP (dmpGetYawPitchRoll and dmpGetGravity). Is there a reason for this? I seem to have a bit smoother output with the DMP calls, but I need to experiment more to see if this is consistent.

Anyway, a big thanks to Pocketmoon, Brumster, Dead Fred and everyone involved! This project is amazing.

I have this exact problem although I mounted it on my headset I can get X pretty much of but Z ok but x and y and sort of mixed up I also tried what you said, also pocketmoon brumster deadfred omegahunter and they did help me alot, and thank you for that, mounting it on my headset helped and also I just mapped the x to the z which gives me really nice X I dont have much Y so I might try that when I unpack all my stuff and find the thinbg again lol.

 

[Leonick]

In the windows controllers properties, yaw would draw a diagonal, and pitch a U shape.

If memory serves me right it's be said a couple of times in this thread (or the one in the Alpha forum) that the visualization in the windows controller properties should just be ignored, it'll look weird but it'll work just fine in game. Something about the head tracker "joystick" outputting the values with more detail (more bits) than the controller properties can properly handle.

 

[Amos]

yeah pocketmoon said that I think, I ignore it now, my problems are ingame but hey its all good

 

[drakmaniso]

If memory serves me right it's be said a couple of times in this thread (or the one in the Alpha forum) that the visualization in the windows controller properties should just be ignored, it'll look weird but it'll work just fine in game. Something about the head tracker "joystick" outputting the values with more detail (more bits) than the controller properties can properly handle.

No, it didn't work correctly in the game either, the axis were mixed. I could make it work by using the X and Z axis instead of the X and Y axis, but then the device had to be rotated accordingly.

Also, it now works perfectly, so I don't think it's a precision issue (the code seems to scale the output to 16 bit correctly anyway).

Now that I think about it, maybe the difference comes from the call I made to dmpGravity. I don't know how the MPU works, but maybe a single call to this function calibrate something inside the MPU itself...

 

[n0ahg]

No, it didn't work correctly in the game either, the axis were mixed. I could make it work by using the X and Z axis instead of the X and Y axis, but then the device had to be rotated accordingly.

Also, it now works perfectly, so I don't think it's a precision issue (the code seems to scale the output to 16 bit correctly anyway).

Now that I think about it, maybe the difference comes from the call I made to dmpGravity. I don't know how the MPU works, but maybe a single call to this function calibrate something inside the MPU itself...

The code appears to use it's own quaternion to euler method to allow mounting the head tracker on the side as well as on the top of the head but this has always caused the axis to be switched.

 

[drakmaniso]

The code appears to use it's own quaternion to euler method to allow mounting the head tracker on the side as well as on the top of the head but this has always caused the axis to be switched.

I see the point of not using the library functions now.

But my problem was not that axis were swapped: they were interfering with each other. Moving the tracker along pitch or yaw would cause movement along both the X and Y axis; one would have a diagonal output, the other a U shape.

This sounds like the device was calibrated at a wrong angle, but I ran both the calibration sketch and the "full calibration" option of the tracker sketch, several times (as well as the MPUReset sketch). Always getting the same numbers, and the problem remained. Now the problem is fixed, the tracker works correctly, and calibration still gives me the same numbers...

Since others seem to have this problem, I'd really like to understand what fixed it... (My initial guess about dmpGetGravity is wrong, that's not even executed by the DMP, it's implemented by the library.)

 

[brumster]

If your code hasn't changed one iota then I honestly don't know, however I will say that occassionally the DMP initialisation routines just randomly 'hang' on the JR libs; presumably this is why a lot of checking is done to see if the returns/initialises work! No real explanation as to why, so I just turn off and back on again. I guess this could explain the occassional variance in behaviour, but it certainly doesn't happen with any regularity, so I'm not sure it explains your problems.

 

[Pazmeister]

All my components have arrived and I have soldered pins to respective items. Come on FD say yes so I can buy a PCB from pocket moon and get gaming!!

 

[drakmaniso]

If your code hasn't changed one iota then I honestly don't know

I just checked again with the original tracker code and my very first calibration offsets, it still works correctly, I don't see the axis interference I originally had. Maybe it's running the library examples that triggered something in the DMP, but I fail to see what.

however I will say that occassionally the DMP initialisation routines just randomly 'hang' on the JR libs

Yes, I did notice that, especially during calibrations. It's a shame there is no official documentation for the DMP...

 

[brumster]

Maybe. For reference (you're probably know this) the DMP needs setting up each and every time the unit is powered on; bar some sensor calibration offsets (which have to be forceabley stored with a function call) it remembers nothing - so you have to load it with specific binary-level firmware every time you power it up, plus set any configuration options for its behaviour. The firmware is completely undocumented so we basically have two images out there in the public domain - the firmware in Jeff Rowberg's libraries (MotionApps 2.0 for 6axis, or 4.1 for 9axis), and the 5.1 firmware in the nav6 libraries. Naturally, you'd expect the later 5.1 firmware to be better

All I can assume is that occassional errors in the i2c comms stuff up the programming of the DMP, maybe around the firmware flashing which could be sensitive, and this results in a non-functional unit (until next reset, obviously - nothing permanent).

Just hypothesising though

 

[drakmaniso]

Thanks. I'm still getting up to speed with that whole micro-controllers thing, so I did not have the full picture. That makes my problem even stranger, since it persisted after several resets and power up. Maybe it was some kind of hardware malfunction that sorted itself out, after all.

 

[Sniper435]

well my arduino has arrived and I'm now bored playing with the flashing LED, just waiting for my 9150 board to arrive and (if possible) a nice little pcb to mount them both on so I can test and work further on my variant of your head tracking software