Tracker DK magnetometer 2-axis, or 3?

Another question: If the Tracker DK does indeed contain the MPU-6000 chip mentioned in the i-fixit teardown, then why does the OculusVR SDK contain its own sensor fusion code?

I see that the SDK still supports the USB VID/PID for the STM32F3DISCOVERY kit, so perhaps the software sensor fusion is there to support IMUs that do not contain their own sensor fusion. But using the onboard sensor fusion for the Tracker DK should be faster and more reliable than doing it in the Rift DK firmware, IMHO...

I have not studied the OculusVR SDK to any great depth, so perhaps it does use the onboard sensor fusion, and only does its own sensor fusion for non-Oculus trackers.

But unanswered questions leave my curiosity unsatisfied...

My GY-85 IMU can support sensor readings up to 3200Hz, but the spec says that at 100Hz it is only accurate to 1.5LSB, and for each frequency doubling you lose another 1.5LSB of accuracy. So running it at 800Hz means that bottom SIX bits of the raw sensor values would be "just noise".

The Tracker DK uses a different IMU (as mentioned in a previous post above), and I did not find such "LSB accuracy" specs in the downloadable PDF files for that chipset. However, even if it maintains full accuracy for its entire operating range, the ADCs it uses are only 16-bits, but the HID packets store them as 21-bits, which means that the bottom five bits will always be "just noise" for raw sensor data. It is possible to gain extra bits of accuracy by averaging the noise, but only at the expense of increased latency.

It does not make much sense to try to filter the sensor data to stabilize the bottom noise bits (which are not real data anyway). It may be better to just truncate the noise bits.

I am only concerned about this because I am writing my own head tracker software from scratch, so I can use it on any generic hardware platform. I am pleasantly surprised to see that the Tracker DK chipset has built-in sensor fusion. I would like to start with that instead of needing to do my own sensor fusion. But then again, I want to mount some of my other sensor on my body anyway, so perhaps I will eventually need my own sensor fusion.

I got some nice 3-axis I2C accelerometers (no gyro) mounted on small breakout boards, from an ebay store for $4.69 for two of them, with free shipping:
http://www.ebay.com/itm/200916416916
Barometric Digital Pressure Sensor ($6.99 free shipping, accurate to 25cm elevation)
http://www.ebay.com/itm/280936515643
(can detect standing/seated/prone elevations).
I got one of these GPS units too ($9.69+$1.90 shipping):
http://www.ebay.com/itm/350753812611
and this GPS antenna ($4.51 free shipping):
http://www.ebay.com/itm/251265487253
And here is where the USB and TTL serial pads are on that U-blox PCI-5S GPS:
http://emerythacks.blogspot.com/2013/01/u-blox-pci-5s-cheap-gps-module-for-your.html
(and there is speculation that you may be able to cut off the mini-PCIe half of the card).

With my Rift DK, and my GY-85 IMU, and those devices, I want to try some free-range body tracking (using my portable Rift and RasPi)...

I'll try to answer in list form ...

• All three axis of the magnetometer have changing values on my side


• The sensorfusion in the MPU6050 is crappy. It wont work with higher frequencies than 100 Hz and I know of nobody who could integrate the magnetometer with it ... and it is a big black box (nobody knows what it does internally). Basically, every other sensorfusion algorithm running on a µC is superior to the DMP solution of Invensense ;-)


• Having said that, Oculus could integrate sensorfusion on the M3 that resides on the tracker. Harder to update, but at least we would have the same sensor fusion in every game ... maybe in the consumer version?


• The MPU60x0 is capable of 5000 Hz measurements, but even at just 1000 Hz the noise is big factor


• HID-packets use 21 bits, since they transmit float values in different units (cm/s^2, etc). They don't transmit the raw 16 bit values from the sensors.

"Sebbi" wrote:
I'll try to answer in list form ...

• All three axis of the magnetometer have changing values on my side


• The sensorfusion in the MPU6050 is crappy. It wont work with higher frequencies than 100 Hz and I know of nobody who could integrate the magnetometer with it ... and it is a big black box (nobody knows what it does internally). Basically, every other sensorfusion algorithm running on a µC is superior to the DMP solution of Invensense ;-)


• Having said that, Oculus could integrate sensorfusion on the M3 that resides on the tracker. Harder to update, but at least we would have the same sensor fusion in every game ... maybe in the consumer version?


• The MPU60x0 is capable of 5000 Hz measurements, but even at just 1000 Hz the noise is big factor


• HID-packets use 21 bits, since they transmit float values in different units (cm/s^2, etc). They don't transmit the raw 16 bit values from the sensors.

Hmm.... How sure are you that the Tracker DK is returning floating point numbers in the HID packets? The 0.1.5 and 0.2.1 SDK sources I downloaded from OculusVR both return signed int32 sensor values extracted from the HID packets, as you can see by looking in the UnpackSensor() function of OVR_SensorImpl.cpp. And the bottom few bits of all the values are a bit jittery, so they cannot be scaled differently. The upper bits are always zero, so they sure LOOK like they have about 16 active bits. Of course, that can all change if you reprogram the Tracker DK by rescaling the sensors after you power it on. I am just using the default power-on values, which appear to be returning max values just beyond +/- 100,000 (or about 18 bits), so there is obviously SOME adjustment going on inside the Rift tracker between the the time that the 16-bit values are read from sensors and when the +/-100K values are placed into the HID packets. I suspect that the 3 extra bits are just there in case you want to program the sensors to return a larger range. Sorry, I do not see any floats in the HID packets...

Although my mag sensor does return correct values for yaw/heading/azimuth/longitude and pitch/attitude/elevation/lattitude, that other value (roll/what?) is locked to a fixed value as returned from UnpackSensor(). What real-world coordinate does that "roll" mag sensor value correspond to anyway in the various real-world coordinate systems (as shown in my examples for yaw and pitch)?

So if your HID packets are returning three changing mag sensor values, and they are floating point values, what do they represent, and why are they different from the integers that the SDK is extracting from HID packets?

And if you claim the invensense sensor fusion is crap, why are you suggesting that it become the cross-platform standard in a future Rift? Or did I just misunderstand your claims and suggestions?

And is the Rift DK using the MPU6050 as you say, or is it the MPU6000 as the iFixit guys claimed in their teardown? Although from the same chipset family, there are some differences. And why would invensense make this claim that you seem to dispute:

"

"Sebbi" wrote:

Having said that, Oculus could integrate sensorfusion on the M3 that resides on the tracker. Harder to update, but at least we would have the same sensor fusion in every game ... maybe in the consumer version?

"geekmaster" wrote:
And if you claim the invensense sensor fusion is crap, why are you suggesting that it become the cross-platform standard in a future Rift? Or did I just misunderstand your claims and suggestions?

The tracker board contains the MPU6000 (the teardown photo shows that model number) and an STM32, which is an Arm Cortex M3 cpu. So what he was suggesting is that while the MPU6000 itself may suck at it's built in sensor fusion, oculus could program the STM32 to do it instead of the host pc doing it in the sdk.

"kojack" wrote:

"Sebbi" wrote:

Having said that, Oculus could integrate sensorfusion on the M3 that resides on the tracker. Harder to update, but at least we would have the same sensor fusion in every game ... maybe in the consumer version?

"geekmaster" wrote:
And if you claim the invensense sensor fusion is crap, why are you suggesting that it become the cross-platform standard in a future Rift? Or did I just misunderstand your claims and suggestions?

The tracker board contains the MPU6000 (the teardown photo shows that model number) and an STM32, which is an Arm Cortex M3 cpu. So what he was suggesting is that while the MPU6000 itself may suck at it's built in sensor fusion, oculus could program the STM32 to do it instead of the host pc doing it in the sdk.

Yes, that makes sense now. The "M3" is an ARM CPU... But the other questions remain unanswered, like "floating point data in HID packets" that I do not have in my HID packets...

"geekmaster" wrote:

Hmm.... How sure are you that the Tracker DK is returning floating point numbers in the HID packets? The 0.1.5 and 0.2.1 SDK sources I downloaded from OculusVR both return signed int32 sensor values extracted from the HID packets, as you can see by looking in the UnpackSensor() function of OVR_SensorImpl.cpp. And the bottom few bits of all the values are a bit jittery, so they cannot be scaled differently. The upper bits are always zero, so they sure LOOK like they have about 16 active bits.

If you look at the implementation of UnpackSensor() you can what it's unpacking are 3 signed 21 bit integers out of 64 bits. So, no the sensor isn't returning floating point numbers, but neither is it returning 32 bit or 16 bit integers, except in that the extracted 21 bit integers are stored in the closest native type that can hold them.

"jherico" wrote:
If you look at the implementation of UnpackSensor() you can what it's unpacking are 3 signed 21 bit integers out of 64 bits. So, no the sensor isn't returning floating point numbers, but neither is it returning 32 bit or 16 bit integers, except in that the extracted 21 bit integers are stored in the closest native type that can hold them.

You can never have more bits of precision than the data you started with, although you can gain precision by averaging over time (at the expense of increased latency). Also, you can gain a bit of precision with sensor fusion by combining data from multiple sensors. However, you also lose accuracy by reading the sensors at a higher update rate. At the 1KHz sensor HID packet framerate, anything below about 14 bits (of USED bits) is just noise. A few of those upper 21 bits are just sign bits (unless you change the scale factor on the sensors).

The point is that bits are bits, and in this case they are scaled (fixed point) integers, not floating point values, and the ACTUAL data contained in these numbers has a lot less precision than the storage space allocated to them.

I already wrote code that extracts the sensor data from HID packets, filters it, and removes gyro drift. I tested it. It works. The values my code returns make sense and track my Rift DK head motions nicely. I was just curious why the mag sensors provide an extra axis that does not correspond to any real-world geographic or celestial coordinate system when a compass is normal used for just such geographical coordinates, and at the same time why that mysterious mag sensor axis always returns a fixed unchanging value in MY Rift DK HID packets, as I mentioned in the first post.

My questions have not really been answered yet, other than the suggestion that OTHER PEOPLE cannot make the built-in sensor fusion work correctly OR figure out how to use a mag sensor with it (contrary to claims and examples posted at the manufacturer's web site). My experience is that if something can be done, I can figure out how to do it, given sufficient incentive, despite a long history of failure by others...

I am still curious why the HID packets have a data value reserved for that mysterious mag sensor value, and does it REALLY change in the HID packets returned by other people's Rift DK units?

"geekmaster" wrote:
I was just curious why the mag sensors provide an extra axis that does not correspond to any real-world geographic or celestial coordinate system when a compass is normal used for just such geographical coordinates, and at the same time why that mysterious mag sensor axis always returns a fixed unchanging value in MY Rift DK HID packets, as I mentioned in the first post.

For the same reason we have three axes for everything else? The magnetic field strength can be interpreted as a vector, and even though we all inhabit what amounts to a 2D plane on the small scale, the rift can be oriented in any angle you choose. If we only had two axes of reporting and you oriented the HMD in such a way that the magnetic field was at right angles to that two axis plane, you'd lose all value to the sensor.

"geekmaster" wrote:
My questions have not really been answered yet, other than the suggestion that OTHER PEOPLE cannot make the built-in sensor fusion work correctly OR figure out how to use a mag sensor with it (contrary to claims and examples posted at the manufacturer's web site). My experience is that if something can be done, I can figure out how to do it, given sufficient incentive, despite a long history of failure by others...

Good luck. I'm sufficiently happy with my Java port of the software based sensor fusion, and that's before enabling the magnetic calibration functionality. I'm also wary of getting waylaid by side projects involving fixing things that bother me technically or are insufficiently perfect but aren't on my critical path, mostly because I've done it so many times before.

"geekmaster" wrote:
I am still curious why the HID packets have a data value reserved for that mysterious mag sensor value, and does it REALLY change in the HID packets returned by other people's Rift DK units?

I haven't seen any change in the magnetic field in my rift, but since I'm still running partially ported code in Java, it's entirely likely that I'm failing to send an HID feature request that's required to turn it on.

Ooops, sorry I didn't see the replies here earlier ...

As kojack stated I was suggesting that the M3 on the sensor board could do all the sensor fusion (hell, even a small 8 bit µC can do it) and do it better than the MPU itself. Why would you use a black box algorithm when you can easily run your own?

Regarding the magnetometer integration ... I have never seen an implementation where the DMP was used to fuse those readings, too ... you get orientation calculated from the accelerometer and the gyros and at a max rate of 100 Hz (if I'm not mistaken). Using this DMP code (which isn't documented very well and full of mystery configuration options) might be useful for low power applications, but not for tracker boards like in the Rift.

Float vs. Int32 ... what I meant was that the values are scaled in a way to represent real world units and not the raw 16 bit sensor data. What you get for acceleration is cm/s^2 so you have to devide by 10000 to get m/s^2 ... I mistakenly wrote that the return values would be floats ... they are not, but if you want to save them in normal SI units you have to devide by 10000 (gyro and mag values as well, temperature only by 100).

I suppose they transmit 21 byte values because those values can be differently scaled? There are configuration options which change the sensitivity, but I have no idea if that would also change the output ... but maybe the lower bits will contain less noise then? However the default seems to be ok for normal tracking.

And yes, I get different values for all 3 magnetometer axis. As described by jherico, you have to think of this as a 3D vector of earths magnetic field. You can derive north/yaw from it and in a limited way even tilt angles (if you know how the local magnetic field is oriented).

Good luck in trying to use the DMP ... it is a futile attempt. Low frequency and black box algorithms make it unusable (as stated, every 8 bit µC can do a better and more transparent job in fusion the sensor data) and I think what you read about the magnetometer integration is just the way they connect the MPU. This sensor has a slave I2C which can be read through the MPU registers which is useful, but not for sensor fusion.