Camroll offset for gyro (for surface pro)

1. offizieller Beitrag

    Hello,

    I have a surface pro and i would like to use the gyro, i activated the plugin (desktopsupport=true and modify the skin to actually load it), but when i use it the whole panorama is rotated 90deg.

    I can disable the camroll in the plugin, but doing so everything becomes really unstable.

    I tried adding a camroll into the view to "compensate", but obviously it gets overridden by the gyro.

    Do you have any suggestion?

    I also tried autocalibration, sensor=0, absolute but nothing really changed

    Latest Edge and Chrome - so same engine.


    The surface is brand new, trying to do all the updates just in case that's the problem, but i would doubt...


    EDIT: I tried with Firefox just to double check, same behaviour. For what i can tell, XY are inverted (hence rotating by 90 sorts it out).


    EDIT 2: all updates done - same problem

    3 Mal editiert, zuletzt von Skia (11. März 2024 um 16:16)

    • Offizieller Beitrag

    It can be also that the gyro sensor/driver on that device simple reports the gyro-orientation in that way...

    In my tests I have seen many desktop/laptop devices misbehaving, sometimes the gyro-orientation is landscape-based, sometimes portrait-based...

    I have no Windows-tablets here for testing now, but I have added this to my checklist.

  • klaus.krpano 11. März 2024 um 18:02

    Hat das Label Checking hinzugefügt.

    Thank you


    Meanwhile do you have a quick workaround i could use?

    I tried using pre align but doesn't really work, the best way i found is to rotate the canvas, but i don't know if there's some other level (i guess view? or krpano?) i could apply a rotation and fake it that way


    Edit: thinking about it, wouldn't it be more beneficial to allow some customisation instead of having to buy every other device?

    For instance you could:

    - expose a change of basis matrix to apply just before transforming the quaternion to Euler (IE after the kalman filter)

    - or expose a oninput/onoutput function: the input could be quite interesting, as you could effectively "slow down" one of the axis. Both functions would have as input/output a quarternion (the latter function would be exactly where the change of basis would be).


    This way the pano creator could pass a parameter in the link/implement his own recognition algorithm for the device that misbehave and apply a solution

    Einmal editiert, zuletzt von Skia (11. März 2024 um 20:43)

    • Offizieller Beitrag

    Okay - a workaround might be possible...

    krpano checks for multiple orientation values in the Browser (for compatibility reasons) and one check is for:

    window.orientation

    But in the most modern browser versions, this variable is no longer used and available, so it should be available for faking a custom window orientation...

    E.g. try adding this code:

    Code
    <action autorun="onstart" type="js" devices="desktop">
  window.orientation = 90;
</action>

    and that with these values: 0, 90, -90 and 180 for window.orientation.

    With the right value, the gyro should behave correctly.

    Best regards,
    Klaus

    Klaus,


    thank you, that did the trick!


    The right value is 0 for landscape and -90 for portrait - looking at it, the desktop browsers drop the support for it (so it's undefined), while the mobile ones still have it.

    Since the gyro is mainly used on mobile, probably not many encountered this problem.


    I just checked on my android and i can confirm it's automatically set to 0, while on the surface pro it was undefined.


    Looking at this ScreenOrientation the solution looks like it's as simple as:

    Code
    if (window.orientation == undefined)
{
	window.orientation=screen.orientation.angle;
	screen.orientation.addEventListener("change", (event) => {
   		window.orientation = event.target.angle;
  	});
}
    • Offizieller Beitrag

    Hi,

    on mobile and tablet devices there shouldn't be a problem or a need to manually adjust anything!

    The problem are only Windows 'desktop' systems (the Surface Pro and Windows Laptops are technically desktop systems, there is no real API or way to differ between Windows laptops and tablets) - the gyro orientation there is inconsistent(!) across several devices!

    Some devices report the gyro orientation rotated (90 degree in the one or the other direction), some are correct and some even say they support gyro and then don't provide any values at all...

    I think that's depends how the Windows tablet/laptop manufacturer configures the gyro sensor, to act like a phone (portrait-based) or like a tablet (landscape-based).

    That's the reason why the gyro desktop support is disabled by default *wink*.

    I think it might be necessary to collect some data about different Windows systems and how their gyro work, to choose a good default behavior (e.g. I have two Windows test devices here that worked with the current settings correct).

    Best regards,
    Klaus

    Hi Klaus,

    On my android the window.orientation is set to 0 or +/-90 by the browser(depending if portrait or landscape) - i think that's why there's no need to adjust anything: you have the right value.

    On the desktop Window.orientation is undefined - the code above just set it using another API and then everything else is working.

    If you have other windows devices could be interesting to test if the code above is the solution - maybe it's incosistent when used without the window.orientation, but together everything works fine!

    But yes - not surprised in the slightest they are incosistent *tongue*

    • Offizieller Beitrag

    The gyro plugin is automatically using other values like screen.orientation (and older browser specific derivatives) and there the angle or type value depending on what's actually available. That means it automatically tries everything to provide the the widest possible support.

    The example with window.orientation from above was only though as workaround for your actual case - and to test what orientation value might fit there.

    • Offizieller Beitrag

    Hi,

    I have redone some Windows device tests - it seems that some recent Windows 11 update has removed the Tablet mode and also the availability of the gyro in Normal mode. That means it is no longer possible to use a normal Windows Touch Laptop with gyro control (even when it would have a gyro sensor).

    But I think that's a welcome Windows change. On a Laptop the gyro usage might be unwanted anyway in the most cases. And because detecting between a Windows Laptop and a Windows Tablet is not possible in the Browser, this would allow keeping the gyro support automatically available, so no need for a desktopsupport setting anymore.

    Maybe the orientation-issue is fixed as well by this.

    I have just ordered a new Windows tablet for testing. My old Windows Tablets are Windows10-only and my current Windows Laptops with Windows 11 no longer allow using/testing the gyro.

    When the tests work well, it should be possible to support the gyro on Windows tablets automatically (and with correct orientation).

    Best regards,
    Klaus

    Hi Klaus,


    Sorry for the late reply


    it was the device of a client he bought just for a presentation.

    It was a the latest model of Surface Pro, we did all the updates of Windows 11 and downloaded chrome.

    To test i went to https://sensor-js.xyz/demo.html and i can see the gyro working, i then had to play around with the above to make it work

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden