segunda-feira, 10 de outubro de 2011 22:20
I've been playing around with the sensor APIs (accelerometer, gyro, and the sensor fusion stuff) and found the performance to be horribly slow on certain things. For example, I wrote a sample Direct3D app that used accelerometer data input to transform a 3D model - this works really nicely. However, I tried the same thing using the gyro and it seems to update no more than once per second, maybe occasionally hitting 1.2Hz, but completely unusable in a real-time situation. Has anyone else experienced this? It makes no difference whether I'm using the Gyrometer API directly or the OrientationSensor API in sensor fusion; the problem still exists.
I should point out that I'm running this on the Samsung Windows Developer Preview tablet we got at BUILD, so perhaps this is unfortunately a hardware issue that can't be worked around in the code...
EDIT: I couldn't see any way to set the Report Interval for the gyro, this property seemed to be read-only (and the value reported was 50 by the way). Am I missing something?
- Editado chrisfrancis27 segunda-feira, 10 de outubro de 2011 22:22
Todas as Respostas
terça-feira, 11 de outubro de 2011 03:13
Setting the interval will be part of the solution. You should be able to set the interval simply by assigning a new value to it. Was that not working?
Coming up in the Beta release, the implementation will also be setting a sensitivity value that correlates with the requested interval. It's possible that the default sensitivity for gyro is not quite right (I'll check this tomorrow).
One last thing... have you tried using the OrientationSensor? This sensor combines accelerometer, gyro and compass in firmware to give you the most accurate and responsive rotation data (sensor fusion). The problem with gyro alone is that it drifts. The problem with accelerometer alone is that there's latency. Sensor fusion uses the gyro for tracking instantaneous changes, and uses accelerometer and compass to correct for the drift.
terça-feira, 11 de outubro de 2011 10:39
So I've managed to set the report interval - turns out I was trying to set the "MinimumReportInterval" property (which is obviously read-only!) instead of the "ReportInterval" property. I've now changed that from 100 down to 50, but it seems to make no difference. I also followed Jason Strayer's advice (~32 mins) on hooking up an empty ReadingChanged event handler before setting the property, but this doesn't actually change the physical update rate, even though the property is set correctly.
It looks to me like the problem is two-fold - not only does the sensor seem to update somewhat infrequently, but also it requires quite a large "tilt" before picking up any change. In practise it seems to require around 15 degrees of tilt around any one axis before kicking off a change event; is this the sensitivity value you are talking about?
And yes, I'm afraid the OrientationSensor has the same problem, so whilst it saves me from having to manually do the horrible maths to prevent gimbal-locking, it is limited by the same poor update rate as the underlying gyro sensor.
EDIT: Looking again, it does in fact seem to be sensitivity related more than refresh rate, as when I rotate the device extremely quickly it DOES seem to get quite a few updates per second - so perhaps the sensitivity of the gyro is set far too low... :)
Many thanks for your help!
- Editado chrisfrancis27 terça-feira, 11 de outubro de 2011 10:42
terça-feira, 11 de outubro de 2011 18:02
Chris- unfortunately, this is an issue with the firmware in the Nike-Tab. We are not sure whether an update will be available. There will be a couple issues with device orientation on the Nike Tab- some of the same aggressive data filtering issues, and there's a known issue with the Quaternion data as reported by the driver in that build (x,y,z are fine, w is always 0, similar issue with Rotation Matrix).
If we have updates, we'll post in this forum.
- Marcado como Resposta chrisfrancis27 terça-feira, 11 de outubro de 2011 20:53
terça-feira, 11 de outubro de 2011 20:52Thanks very much for your help, Gavin! I did notice the "w" value staying at 0 in the quaternion reading, but didn't really think anything of it! :) I'll keep a look out for any updates on this forum. It would be a shame if hardware/firmware limitations prevented us developers from exploiting some of the coolest features of Windows 8, but there's plenty of other metro-style development for me to be getting on with in the meantime! ;)
domingo, 11 de dezembro de 2011 20:34
Gavin we briefly talked at the build conference where you also told me this. You mentioned that if I did the fusion in software, that I perhaps would be able to do this myself using raw accelerometer, compass and gyro readings instead of the buggy fusion data. Do you have any example on doing something like this? You mentioned you have a firmware that fixes the issue, so any chance that the few who wants to experiment with this API can get to do so, of course at our own risk? I'd really like to fix and improve the stuff I'm talking about in this article: http://www.sharpgis.net/post/2011/12/07/Building-an-Augmented-Reality-XAML-control.aspx but currently that's pretty much impossible.
sábado, 18 de agosto de 2012 19:34Gavin: Now that Windows 8 has gone RTM are there any updates to this firmware issue?
quinta-feira, 30 de agosto de 2012 19:48Try the eMotion board from ST Micro to get a system with a more recent fusion solution.
This posting is provided "AS IS" with no warranties, and confers no rights.
- Editado Janet Schneider [MSFT] quinta-feira, 30 de agosto de 2012 19:48