beta values at horizon level

[bognick]

Hi and congrats for your library.

I am noticing a slight hop in the beta values around the horizon level. Basically the horizon level cannot be reported by the beta variable in any way. There's always a jump in the beta values (up to 10 degrees) around the horizon level.

Tested in Chrome and Firefox Beta for Android.

Also I don't know if its related, but changes in the gamma value seems to affect both the alpha and the beta values for reasons that I don't understand. At the horizon level the gamma values are inverted and basically the gamma values are very sensitive at the horizon level, is this normal?

[dorukeker]

Hi @bognick. Thank you. I am glad you find it useful.

Beta values: Can you install this application https://play.google.com/store/apps/details?id=com.innoventions.sensorkinetics&hl=en and check if the same thing happen in a native application rather than the browser.

alpha, beta and gamma values are not exactly rotations over axises, but they are Euler angles. I am not an expert about the mathematics behind it. However I know the values effect each other as well. Here is some more info about Euler angles https://en.wikipedia.org/wiki/Euler_angles

What is your use case / project? I can give you more specific tips on how to apply those values. I've been there with CSS and Unity3D :)

[bognick]

Hi @dorukeker,

Before gyronorm.js I was playing with the gyro+accelerometer+magnetometer sensors directly through the devicemotionevent so I know that the beta values are fine in this case, the problem arises when I use gyronorm.js. I have downloaded the app you mentioned and everything seems to be fine, though I have to admit that I'm not sure about what to look for specifically (no beta values in there). I can reproduce this issue with both a Nexus 5 and a Xiaomi Redmi Note 3 Pro.

In my project I want to use those values in order to move in a natural way a virtual camera, in the same way we move the phone's camera as we pan around trying to shoot a physical target (check this video out if you have a minute to spare). So ultimately I want changes in the values of one axis rotation not affecting the values of another axis, as this is what we expect when targeting with a physical camera. When I play with the devicemotionevent directly I think that I observe less "inter-axis interference" and anyway it seems that it is doable as this demo demonstrates so I was wondering if gyronorm.js would support it.

[dorukeker]

Hi @bognick Sorry for the app recommendation. I now see it dosent have the beta values indeed.

I run the example in the demo/ folder on a Samsung S5 and it returned the values normally. I dont have any nexus in house so I cannot test on the device :( I will try to get one and see how it behaves.

As far as I understand what you want is to have a VR in the browser. Like viwing a skybow. Gyronorm.js uses FullTilt library to get the raw values from the device and add some extra functionality on top. As fas as I remember FullTilt library has an example like that. You can check out here https://github.com/adtile/Full-Tilt/tree/master/examples

The current version of FullTilt is not available to use for commercial projects (they changed the license). But at least the example code can give you an idea.

[dorukeker]

Just an update: I found a Nexus 9 tablet and it behaved as expected. The values was consistent for me. Did you also test with the sample file under demo/ folder? Cheers, D.

[bognick]

Hi @dorukeker,

Thanks for the heads up about the FullTilt demos. It seems that they're doing what I want, and I'm surprised that in every demo (even in the data_display.html) there's not any "interference" among the Euler angle values when rotating my devices on a single axis. In which way is the gyronorm.js using FullTilt that the Euler angles exhibit different behavior?

Unfortunately I cannot make the gyronorm.js demo to work. There are many errors showing up like 404 for the bower_components and ReferenceError: FULLTILT is not defined. Do you have any working demo online?

On the Nexus 5 the issue is more subtle but totally there. It is more evident if you play a little and give it a bit of time.

[dorukeker]

Hi @bognick

I wrote an ebook about the differences in the beta and gamma values. You can find it here https://leanpub.com/gyronormjs You can download it for free as well. The issues with the deviceOrientation and deviceMotion are listed there. Along with how Gyronorm.js is addressing it.

To run the demo:

• Check out the repo (or download the ZIP)
• Open your terminal and go to the folder
• Run $ bower install . This will install all the dependencies
• Then start a local server in the root folder and browse to the demo/index.html

Cheers, D.

[bognick]

Thanks @dorukeker

Sorry for the delay. I have now run your demo and I can confirm that the issue is still there even in the demo. I also managed to reproduce the issue with a Surface 3 (Edge, Windows 10). Btw do you have any idea why Firefox and Chrome do not report orientation data on the Surface 3?

So now I'm pretty convinced that the issue is on your part because I observe it on 3 devices (Redmi Note 3 Pro, Nexus 5, Surface 3), 3 browsers (FF, Chrome, Edge) and 2 platforms (Android, Windows 10). Also the demos of the FullTilt.js do not have the same issue and in particular it's orientation data seem to be very smooth and I'm wondering if they fuse the orientation data before applying them.

I have uploaded a short video using you demo which demonstrates the issue with the Redmi Note 3 Pro and Firefox. I admit that with the Nexus the issue is harder to observe but its definitely there and observable if you pay attention and wait for a little bit (it seems to get worse with time). Finally, the issue is much more observable when you apply the data to an actual camera where even little "hops" can move the whole 3D window awkwardly.

Nikos

[dorukeker]

Hello Nikos, I checked the code again. It passes the beta and gamma values directly as they are served from FullTilt. So there is no altering.

An idea: FullTilt updates the values using requestAnimationFrame. Gyronorm has a frequency setting. So it is possible the FT is updating faster than GN default. You can reduce that time by setting extra options.

var args = {
    frequency:50,
};

var gn = new GyroNorm();

gn.init(args).then( ... );

I quickly put together a page where you can see Gyronorm values and FullTilt values side by side. You can find it here http://dorukeker.github.io/gnvsft/

Let me know if this helps. Cheers, Doruk

[bognick]

Hi Doruk,

unfortunately the frequency change doesn't solve the issue. In your side by side comparison page I noticed that also FullTilt beta values are problematic. Then I checked again their vr_test demo and while the camera is super smooth the beta values they're reporting are also problematic, so I was deceived by the demo's smoothness and didn't look the beta values actually. In order for them to offer a smooth final result it's probable that they do not use the Euler angle values, they just offer them for anyone's interest.

I also noticed that I may have to reload the page in order for the issue to emerge. At first load its possible that the beta values are just fine around the horizon.

Anyway, I will close this issue as you cannot do much about it I suppose :)

Nikos

[dorukeker]

Hi Nikos, I see your point. Some additions: The standard from W3C returns Euler angles. If you want to use other values you need to make the calculations. Not sure but maybe the VR demo is doing this. I will close the issue for now. If you have more questions later don't hesitate. Good luck, Doruk

[bognick]

After further investigation I'm noticing correct alpha, beta, gamma values behavior when locking the device orientation in portrait mode and turning the device in landscape mode. When doing this the values are very smooth and more importantly alpha, beta, gamma values do not interfere with each other. The same applies to FullTilt.js of course. The only issue in this case is that the magnetic north is offset by 90º.

I'm officially confused.

On 10 May 2016, at 10:41, Doruk Eker notifications@github.com wrote:

Hi Nikos, I see your point. Some additions: The standard from W3C returns Euler angles. If you want to use other values you need to make the calculations. Not sure but maybe the VR demo is doing this. I will close the issue for now. If you have more questions later don't hesitate. Good luck, Doruk

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/dorukeker/gyronorm.js/issues/16#issuecomment-218081911

[dorukeker]

:) If they return correctly when you lock the orientation, I assume what you were experiencing was related with the browser switching between portrait and landscape orientation.

Perhaps browser does not return the orientation values during switching between orientations? Or perhaps the function that libraries use to pass these values does not function properly during that short time.

When working on the library again for improvements I will re-visit that. Cheers, D.

[bognick]

I’m not sure Doruk, I’m confused.

It seems that the landscape orientation (either locked or not) is closer to what I believe should be right values behaviour. Values behaviour in portrait orientation are too shaky, inconsistent and interdependent. The behaviour should be consistent irrespective of the orientation and now this is not the case. Of course this is not gyronorm issue, but you may be able to find a solution when you find time.

Thanks for your time anyway, Nikos

On 11 May 2016, at 17:24, Doruk Eker notifications@github.com wrote:

:) If they return correctly when you lock the orientation, I assume what you were experiencing was related with the browser switching between portrait and landscape orientation.

Perhaps browser does not return the orientation values during switching between orientations? Or perhaps the function that libraries use to pass these values does not function properly during that short time.

When working on the library again for improvements I will re-visit that. Cheers, D.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/dorukeker/gyronorm.js/issues/16#issuecomment-218475156