Tracker DK magnetometer 2-axis, or 3?

"geekmaster" wrote:
I posted the relevant code snippet above. It looks correct, and I also tested another method just like the SDK uses and it returns the same values. My Rift actually DOES return varying magX in some (rare) cases, so I think it is a magnetometer calibration issue. I am just using it after a fresh power up with no initialization. Just open the device and request HID frames...

You code does indeed look correct... and if you're getting the same readings through the SDK (or alike)... then edzieba is correct, this has all the hallmarks of a hardware (or firmware) issue. It is NOT a calibration issue.

ALL axis should change when you rotate your device. If you're only experiencing rare cases of x-axis variation... then something is very wrong.

"geekmaster" wrote:

"Sebbi" wrote:
If I only send feature report 2 when I open the device, the Tracker DK *SOMETIMES* stops sending HID packets after about 10 seconds. This behavior seems intermittent (perhaps depending on what Rift apps have been run since the Rift DK was powered on), and I can probably send feature report 2 a lot less often.

You don't need to send feature report 2 more than once (or at all actually). You can reliably keep incoming packets from the rift flowing using feature report 8 which has only one parameter besides the command ID, which is the number of milliseconds you want to continue receiving packets. I set it to 10 * 1000, and then set a timeout in my loop to resend a keep-alive every 3 seconds.

Currently I'm not sending feature report 2 at all, which may be related to my hit/miss rate for magnetic sensors. I just tried running my app and saw that I'm currently getting values for all three directions in the magnetic sensor, which is probably related to how the last application that used the rift set it's config, or it's simply random if you don't set it.

I added magnetometer values to the latest OculusRoomDemo sample code. Pressing the spacebar displays those values. Even after running auto-calibration for the magnetometer, my Mag X value is frozen at 2.80 in the display.

My Rift is one of the first batch of 300, which I received before GDC 2013. Was there a firmware change that could affect this behavior. Can my firmware be updated over USB?

I get the same behavior from my magnetometer in the SDK too, even after calibration. No useful X value...

"jherico" wrote:
Here's a capture of the settings and raw tracker packets from my Rift. This is an 8-second capture of me looking at the screen, turning my head left, then back, then right, then back. The magentometer values seem to behave rationally to me. Try comparing it with the values you're getting from your config / packets.

Let me know if you want a longer sample or orientation on different axes.

You sent this while I was editing my post above. My mag X value is frozen at 2.80 in the OculusRoomDemo, when I added the magnetometer values to my sensor display.

However, the magnetometer field marks seem to be fixed in place as expected (most of the time).

Since the new 0.2.1 code (and the latest 0.2.2), my Rift started getting pretty bad yaw drift. Disconnected and reconnecting power stops the drift, until it happens again. I did not see any drift with the 0.1.5 SDK.

Perhaps the magnetometer yaw drift correction is borked by my bad mag X values, causing it to drift faster...

How did you create that HID packet dump?

"geekmaster" wrote:
How did you create that HID packet dump?

Using my Java SDK, which is built on top of the HIDAPI Java library. I have a RiftTracker class which contains a callback method that gets called every time a packet is read from the tracker. I turn on recording like this:

public synchronized void record(Writer os) throws IOException {
    this.os = os;
    startMillis = System.currentTimeMillis();
    os.write("[\n");
    // MAPPER is a static instance of the Jackson ObjectMapper() type
    // It will produce a reasonable JSON object from any Java bean
    os.write(MAPPER.writerWithDefaultPrettyPrinter().writeValueAsString(getDisplayInfo()));
    os.write(",\n");
    os.write(MAPPER.writerWithDefaultPrettyPrinter().writeValueAsString(getSensorConfig()));
    os.write(",\n");
    os.write(MAPPER.writerWithDefaultPrettyPrinter().writeValueAsString(getSensorRange()));
}

In my reader thread I added this code:

synchronized (this) {
    if (null != os) {
        // Cache is a HashMap<String, Object>
        cache.put("time", System.currentTimeMillis() - startMillis);
        // Hex is from the Apache Codec library
        cache.put("packet", Hex.encodeHexString(buffer.array()));
        os.write(",\n");
        os.write(MAPPER.writer().writeValueAsString(cache));
    }
}

I'd already done something similar with my Kinect so that I could play back the data into code I'm working on to interpret it, without having to cart my Kinect around along with my laptop.

I'm hoping to write up some tutorials on how to interact with the tracker using any language and the HID library directly, and doing this seems like it's on the critical path, but I don't know if I'll ever have the time. I probably should have included the computed quaternion after each packet, but then I'd want to include the predicted and calibrated quaternions as well, and I don't have prediction or calibration implemented in my Java code yet.

I was just reading about sensor fusion. In that document, they said the magnetic sensor reads the gravity that points at the magnetic center of the Earth (mostly downward). I wish I knew that before -- it would have saved me from a whole lot of confusion.

In that respect, the gravity vector and the magnetic vector are quite similar, having somewhat different centers (both mostly downward).

This makes it a lot easier for me to picture in my "mind's eye", which is very important for my understanding.

I am still having difficulty envisioning that 4-dimensional quaternion sphere though, although the 3-D vector plus rotation about that vector description is easy enough. It is the "rotation about the surface of the quaternion sphere" thing that is hard to imagine...

More study...

But my Rift Tracker DK mag sensor is still returning a magX of 2.80 all the time in the OculusWorldDemo app...

If you're talking about the article here http://www.oculusvr.com/blog/sensor-fusion-keeping-it-simple/ then make sure you're not confusing what he's saying about the acceleration sensor and the magnetic sensor. Drift correction for pitch and roll use the acceleration sensor, which typically points at the center of the earth. The magnetic sensor is only used for yaw correction.

The discussion of yaw error correction is planned for a future post due to the complications of using a magnetometer; some of the ideas below, however, apply to that case as well.

He doesn't cover yaw correction in that post, and the vector pointing 'down' doesn't apply to the magnetic sensor.

"jherico" wrote:
If you're talking about the article here http://www.oculusvr.com/blog/sensor-fusion-keeping-it-simple/ then make sure you're not confusing what he's saying about the acceleration sensor and the magnetic sensor. Drift correction for pitch and roll use the acceleration sensor, which typically points at the center of the earth. The magnetic sensor is only used for yaw correction.

The discussion of yaw error correction is planned for a future post due to the complications of using a magnetometer; some of the ideas below, however, apply to that case as well.

He doesn't cover yaw correction in that post, and the vector pointing 'down' doesn't apply to the magnetic sensor.

I did not notice any blogs here. Thanks for the link!

Aha! That blog gave me a way to envison quaternions! Yay! I can think of the quaternion for head rotation as the base of my neck as the origin, then pointing the top of my head in any 3-D direction, then twisting my head about my neck. That gives four coordinates quite nicely, while still letting me visualize it internally...

I searched for that little spot where my magX changed over a small area when reading raw HID values, while in the OculusWorldDemo app. I found it. The values jump right at the edge from 2.80 to 1.86, and moving a little changes the value between 1.86 to 1.83, but then I hit the other edge and it jumps back to 2.80. Magnetic calibration does not fix this.