Skip to main content
bteitler
Up and Coming
November 17, 2014

Can't poll acceleration at 1000Hz from Unity

I'm pretty sure this is a Unity quirk, but hopefully someone with more Unity knowledge can confirm. I'm trying to poll accelerometer data at 1000Hz from Unity, but I seem to only get something like 200Hz on average - it keeps repeating the same data over and over. My project has a fixed timestep of 0.001 (1000Hz). In "FixedUpdate" for a particular script, I try to poll as follows:


ovrTrackingState ss = HMD.GetTrackingState();
ax = ss.RawSensorData.Accelerometer.x;
ay = ss.RawSensorData.Accelerometer.y;
az = ss.RawSensorData.Accelerometer.z;


I have code to buffer this data per tick and flush it to disk. Example subset of the data (time, accelx, accely, accelz):


0.353	-0.03393399	9.838906	-0.4828066
0.354	-0.03393399	9.838906	-0.4828066
0.355	-0.03393399	9.838906	-0.4828066
0.356	-0.03393399	9.838906	-0.4828066
0.357	0.1041964	9.800008	-0.4017263
0.358	0.1041964	9.800008	-0.4017263
0.359	0.1041964	9.800008	-0.4017263
0.36	0.1041964	9.800008	-0.4017263
0.361	0.1041964	9.800008	-0.4017263
0.362	0.1041964	9.800008	-0.4017263


As you can see.. I get the same data over a non trivial time period. Is this some quirk / feature of Unity where it is batching FixedUpdate iterations within the same actual millisecond - as opposed to actually scheduling them? Or is this an Oculus SDK issue?

Thanks in advance,
Ben
    This topic has been closed for replies.

    3 replies

    vrdaveb
    Inspiring
    November 17, 2014
    In 0.4.3.1 we fixed some locking issues that may have affected this. It works and keeps 1000Hz on my machine. Is Time.time increasing for you in each call? What is your "Maximum Allowed Timestep"? If your FixedUpdate() call is doing other non-trivial processing that takes more than 1ms, it could be skipping calls to catch up.
    bteitlerAuthor
    Up and Coming
    November 17, 2014
    Hmm.. I don't think "Maximum Allowed Timestep" is relevant here as my application logic is currently cheap and running on a beastly machine.. don't seem to be any performance issues and it seems to log every tick. I think if it was taking too long per tick I would get different acceleration readings, not the same.

    My money is on Unity FixedUpdate scheduling, which may be hardware / application / performance dependent - my guess is that if it can, it will blast through a few FixedUpdate ticks as fast as possible and the accelerometer readings haven't changed. I will do some system timing later to see if this is the case. This can be fixed by using C# threads as opposed to FixedUpdate probably.

    Good to know about about 0.4.3.1 - I'm unfortunately stuck on 0.4.1 as it seems to be the only build that runs on all my target machines without artifacts (combined with the exclusive directx fix). If I'm still having issues after testing the scheduling issue, I will try 0.4.3.1 to see if it makes a difference.

    Thanks for your response.. I'll let you know how I end up fixing it.
    bteitlerAuthor
    Up and Coming
    November 18, 2014
    So I was right about Unity batching Fixed Updates.. when I switched to a normal C# thread with busy wait, I am able to pretty consistently poll at 500Hz with different sensor time-stamps most (but not all of the time). However, I still can't get 1000Hz. If I try to poll every 1 ms, I get the same reading every 2 ms (similar to if I poll at 500Hz). I tried with 0.4.3.1 with the same result.

    Is there some way to register to receive push updates on accelerometer readings in Unity instead of pulling?
    Terms & ConditionsAccessibility statement