cancel
Showing results for 
Search instead for 
Did you mean: 

Oculus always points down

tommo
Honored Guest
Hi,
I've tried a new Oculus VR on a bunch of computers and while at first it works well (usually at the first connection the Tuscany demo works as expected), after a while it invariabily "drifts" down in a matter of hours, so that "forward" becomes "down" and the axes of rotation become gimbal locked.

This makes it unusable and can't be fixed just by rotating it 90˚... so I was wondering if it's something I've been doing wrong and how to fix this 🙂
The magnetometer is calibrated, but I don't think it matters because is the pitch that drifts.

Any ideas?
7 REPLIES 7

jherico
Adventurer
Does the downward drift occur based on the time the rift has been active or the time i'ts been running in a given application? i.e. if you restart Tuscany, does the drift go away or does it persist?

You could try running a small test application that connects to the head tracker and reads out the raw acceleration data. This is the kind of code you need for the handler...

class TrackerHandler : public MessageHandler {
public:
virtual void OnMessage(const Message& msg) {
const MessageBodyFrame & trackerMessage = *(MessageBodyFrame*) &msg;
const Vector3f & accel = trackerMessage.Acceleration;
cout << accel.x << " " << accel.y << " " << accel.z << " " << accel.Length() << endl;
}

virtual bool SupportsMessageType(MessageType type) const {
return Message_BodyFrame == type;
}
};


This code should initialize the tracker and cause it to print out messages for 10 seconds reporting the current acceleration vector.

void main() {
System::Init();
Ptr<OVR::DeviceManager> pManager = *DeviceManager::Create();
Ptr<SensorDevice> pSensor = *pManager->EnumerateDevices<SensorDevice>().CreateDevice();
TrackerHandler handler;
example.pSensor->SetMessageHandler(&handler);
// Sleep and let the tracker handler receive messages, which will
// be processed in another thread
usleep(1000 * 1000 * 10);
System::Destroy();
}


If the Rift is in it's normal orientation there should be a Y acceleration of about 9.8 and minimal values in the X and Z directions (these can actually shift wildly if you're holding it in your hands due to the reporting rate). If you're seeing bad raw values, you probably want to contact OVR support.
Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action

tommo
Honored Guest
"jherico" wrote:
Does the downward drift occur based on the time the rift has been active or the time i'ts been running in a given application? i.e. if you restart Tuscany, does the drift go away or does it persist?


Nope, after it drift it keeps the drift forever, independently of which application is run, but apparently it is reset if you switch the computer with a new one, which smells a bit of corrupted calibration somewhere.

"jherico" wrote:

You could try running a small test application that connects to the head tracker and reads out the raw acceleration data. This is the kind of code you need for the handler...
...
If the Rift is in it's normal orientation there should be a Y acceleration of about 9.8 and minimal values in the X and Z directions (these can actually shift wildly if you're holding it in your hands due to the reporting rate). If you're seeing bad raw values, you probably want to contact OVR support.


Thanks, I'll try!

tommo
Honored Guest
Keeping the rift on my face looking forward this is the stream:


0.4949 2.6511 -9.5914 9.96334
0.531 2.6991 -9.5796 9.96674
0.5384 2.6247 -9.5514 9.92009
0.4493 2.6416 -9.584 9.95153
0.4733 2.6777 -9.5936 9.97152
0.5092 2.704 -9.5985 9.98509
0.4877 2.6487 -9.5866 9.95773
0.4621 2.5793 -9.4961 9.851
0.4807 2.5719 -9.5582 9.90984
0.4784 2.6729 -9.5508 9.9293
0.4688 2.6153 -9.5532 9.91581
0.4804 2.5909 -9.5963 9.95151
0.461 2.615 -9.6391 9.99815
0.5091 2.6991 -9.6081 9.99299
0.4468 2.6079 -9.6079 9.96557
0.4037 2.5696 -9.5792 9.92607
0.4417 2.7306 -9.6361 10.0253
0.4945 2.6581 -9.6487 10.0204
0.4564 2.6633 -9.6006 9.97361
0.4567 2.6321 -9.565 9.93105
0.4469 2.6392 -9.5793 9.94626
0.4685 2.6464 -9.5913 9.96072
0.471 2.6898 -9.5792 9.96082
0.4425 2.7164 -9.536 9.92522
0.3968 2.6636 -9.5454 9.91801
0.4063 2.5697 -9.5624 9.90999
0.4521 2.6298 -9.5364 9.90268
0.5095 2.5958 -9.5608 9.92001
0.5047 2.5958 -9.5726 9.93114


That is, looking forward it works again!

What happened is just that a friend tried it on his pc and voila', magically fixed again.
I'll post when it breaks again...

EDIT: there must be something wrong with my code - trying the Unity demo it works perfectly; when I plug back in my application then it works for an instant, and then *instantly switches* to "down is forward" again...

jherico
Adventurer
"tommo" wrote:
Keeping the rift on my face looking forward this is the stream:


0.4949 2.6511 -9.5914 9.96334
0.531 2.6991 -9.5796 9.96674



These values are incorrect for wearing the Rift normally. The second column is the Y axis and it should have a value near +9.8. Instead you have a negative value in the Z column of about that size. If a Unity app is working with these values, that's probably just because it doesn't have tilt correction enabled in the sensor fusion code.

However, if your Z and Y values are swapped as shown, there's another explanation. The SensorDeviceImpl class which decodes the messages from the tracker actually has a bit of code which swaps the Z and Y exactly as we see here. But this code is only enabled if a certain condition is met, that being that the Coordinates member of that class must be set to Coord_HMD instead of Coord_Sensor.

I would modify your code to call SensorDevice::GetCoordinateFrame() and make sure it's returning 1 (Coord_HMD), and not 0 (Coord_Sensor). If it's returning 0, then either you're probably calling misguidedly calling SetCoordinateFrame() somewhere in your code, OR the HID configuration stored in your Rift is messed up. This can happen if you've ever called SetFeatureReport on the device with invalid values, or in a few other circumstances (typically they all involve you having attempted to do something with writing an HID report in some fashion to the device).
Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action

elisa22
Honored Guest
"tommo" wrote:
Hi,
I've tried a new Oculus VR on a bunch of computers and while at first it works well (usually at the first connection the Tuscany demo works as expected), after a while it invariabily "drifts" down in a matter of hours, so that "forward" becomes "down" and the axes of rotation become gimbal locked.

This makes it unusable and can't be fixed just by rotating it 90˚... so I was wondering if it's something I've been doing wrong and how to fix this 🙂
The magnetometer is calibrated, but I don't think it matters because is the pitch that drifts.

Any ideas?

tommo
Honored Guest
"jherico" wrote:
*


Oh, I didn't notice that the -g value was on Z, the 4 values fooled my eyes!

Well, I just tried demos and copypasted some guide code, I never touched and/or set HID values or things like that.
But other people have fiddled with the Rift, so someone, sometimes, might have broken it.
I still wonder why the official demos get happily along with those uncorrect values though.

Also, is there a way to reset the HID calibration to factory state?

khaldi
Honored Guest
Hello guys

Could you please write the function that i need to make a file with the output points?

I mean the function that track the head and give the points (x,y,z)

thank you
Get Help
Did this answer your question? If it didn’t, use our search to find other topics or create your own and other members of the community will help out.

Check out some popular posts here:
Getting Help from the Meta Quest Community
Tips and Tricks: Charging your Meta Quest Headset
Tips and Tricks: Help with Pairing your Meta Quest
Trouble With Facebook/Instagram Accounts?