nanospork / nofc Goto Github PK

The "neck model" in NOFC is currently a bit dodgy. I believe the neck model is disabled in SteamVR-OSVR as it should be with positional tracking enabled, but since the NOFC does not specify an eye offset from the headset marker in any of the server config files, users will find that their perspective in-game does not quite match their actual head motion.

Objectives

• Figure out a typical offset for the headset marker, as well as the appropriate server config commands, and incorporate this into the NOFC server configs.
• Provide instructions for users to measure and edit these values as necessary.

It has been many years. Hope you are well.

I put down VR I think in 2018 but recently got interested again last year. I started an effort to migrate Nolo code from OpenHMD to Monado (OSVR's successor).

The nolo work is here monado/nolo-standalone

As of 2024-03-22, the following is working in Monado:

Nolo

• Tracker & Controller Position & Orientation
• Controller Inputs (buttons, touchpad, etc)
• Recenter Button (double click on system button)

What isn't working

• Yaw drift is very bad
• SteamVR controller orientation incorrect in some games like Lab (but is correct in menus)
• SteamVR controller not recognized in some games (like Lab)
• Rumble
• Dedicated SteamVR graphics (I saw that on johnlajoie/NOFC's fork that he implemented a comprehensive SteamVR graphics with working buttons) - would be good to get that into monado somehow.

HDK 2.0

This is an officially supported device however, the devs do not support distoration!!!!
Because there is no distoration correct, the Headset is terrible. The devs said that the HDK2 uses a shader for handling distoration in OSVR but monado doesn't use shaders and instead uses a mapping function.

The suggestion was to port the shader code from OSVR into monado. I had a start on that but not sure it is a good solution ... I tend to think it would be better to implement the mapping function but I am guessing that is hard as one would need the specifications of the lenses (I have zero knowledge in this subject area).

Summary

Anyways, I would like to still fix nolo in monado. I was wondering if you remember how you fixed the YAW drift problem? I also noticed in the code there is a 'home' position. I didn't implement this in the monado nolo driver so maybe that would help with the yaw drift problem?

Context

Velocity reporting enables VR games and applications to understand how fast a user's controllers are moving. This allows users to, for example, throw objects. It is also important for smooth, low-latency representation of controller motion.

The recent update to NOLO firmware version 2.0 (and 2.1?) added velocity reporting to the NOLO controller hardware.

Objectives

• Implement velocity reporting in the NOFC so that games and applications can read the velocity.
• Fix any issues with controller pose filtering that arise from this change.

Tasking

• Determine what changes need to be made to Nolo-OSVR so that velocity data can be forwarded to the OSVR Server
  • Nolo-OSVR will need an update to read the new information in the USB packets.
  • Nolo-OSVR will need an update to pass this information out to the OSVR server.
• Determine what changes need to be made to OSVR-Fusion so that velocity data can be handed back to the OSVR Server in the
  • OSVR-Fusion will need an update to copy velocity data from one device to another.
• Determine what changes need to be made to SteamVR-OSVR so that velocity data can be read from the OSVR server and applied to a device.
  • SteamVR-OSVR should be updated to ask the OSVR Server for velocity data, and if none is found, do not use it. If it is found, use it.
  • SteamVR-OSVR may need an option to disable prediction on controllers, depending on whether filtering is still applied by the OSVR OneEuro filter and whether it's enabled currently or not.
• Determine whether the OSVR OneEuro filter should still be used in SteamVR and in OSVR-native apps and update the server configuration files accordingly.
  • There are two possible ways I can imagine this going, each as likely as the other:
    1. Controller pose prediction will have to be turned off completely in SteamVR-OSVR, if it isn't already.
    2. Two separate server config files will have to be created. One for use with SteamVR, where the OneEuro filter is disabled, and one for use with native OSVR apps, where the filter is enabled.
  • If the OneEuro filter performance is sufficient, solution (1) will reduce confusion among end-users, but I do not know how it will affect things such as timewarp performance. Solution (2) may be a necessity for the best experience with SteamVR.

My CV1 controllers are paired (green leds) with base station. I launch my setup in this order.

1. HDK2 2.0 is connected to PC and powered on
2. Nolo base station is connected to PC via usb.
3. Launching OSVR server with NOFC custom direct mode config
4. Starting Steam VR.
5. Nolo base is recognised in Steam VR but SteamVR can't communicate with CV1 controllers or change buttons keybin maps
6. There is no Nolo official drivers Windows installed or in Steam driver registry.

My question is what I'm doing wrong?

Context

While the NoloVR hardware is popular for its motion controller solution, many users of the OSVR HDK use Nolo as an alternative head tracking solution. Sometimes, users want to be able to sit down and play seated VR games without their controllers. This is especially important for flight and racing sims and other games where the players may be using other, fixed controllers or a gamepad. Currently, playing while seated can be difficult as the NOFC depends on the controllers for features like yaw reset.

Objectives

• Implement a "seated mode" in the NOFC to improve the user experience while playing seated games.

Tasking

• Create a "seated" server config file.
  • Likely, we will want to remove all references to the controllers and possibly point them to a null/dummy location if their semantic paths are already auto-configured.
  • 180 degree flip in the headset fusion entry will need to be bound to another OSVR input, keyboard input, etc. rather than the controllers.
  • Yaw reset will present a challenge, since the actual Nolo yaw reset is performed in firmware.
  • In the headset fusion driver entry, the yaw reset button does not actually perform the reset, it only tells OSVR-Fusion to reset the complementary filter. We may be able to remove this line completely.
  • We will need to perform testing to see if existing tools such as OSVR_Reset_Yaw will be sufficient for aligning the rotational and translational axes, or if some other solution for yaw alignment will have to be found.

NOFC currently only includes configuration files for users of the OSVR HDK 2. It would be nice to include configuration files with the appropriate filter values for other headsets. Specifically, the "alpha" value in the headset complementary filter needs to be tuned based on headset IMU timing.

If you use a DK2, HDK 1.4, etc. and you've found that the default settings for NOFC are insufficient for you, please share your experience here and help us create new configuration files with improved performance for these headsets!

Now that new versions of the NOLO firmware have been released, we need to address the issue of backwards compatibility as nolo-osvr is updated to include the velocity and acceleration data included on the new firmware.

A quick look at the data structures in the NOLO SDK seems to indicate the data format sent from hardware haven't changed, but that might need a more careful look to be absolutely sure. The state and quality of the data for things like velocity and acceleration in the old firmware is unknown (at least by me).

We need to settle on a policy and then update nolo-osvr accordingly:

-> We could just declare the version of the firmware we are compatible with and put no effort into supporting older firmware. At the very least the code should include a firmware check and a warning message. Presumably we would always support the latest firmware. This would be the most straightforward approach and require the least amount of effort.

-> We could identify the firmware version and use that to determine what information we pass along to OSVR. At this point it would just be the difference between passing along velocity and acceleration data or not, but it is possible that in the future this could become more complicated. This would be more complicated, and would require different hardware with different firmware versions for compatibility testing with new versions of nolo-osvr.

Context

The official NOLO software package created by LYRobotix allows users to attach a Nolo base station to the ceiling facing downward, rather than having it sit upright on a desk, chair, etc. From the ceiling, a Nolo setup is subject to reduced occlusion - that is, it is less likely for something to block the line-of-sight between the base station and your controller or headset, interrupting tracking. This generally provides for larger tracking areas and better 360-degree VR experiences.

Objectives

• Implement a "Ceiling Mode" in the NOFC so that users can attach their NOLO base station to the ceiling for reduced occlusion.

Tasking

• Attempt to generate a server config file that makes the appropriate coordinate system changes allowing for ceiling mode.
  • This should be all it takes - swapping and offsetting some axes, and possibly performing some rotations.
  • There is a chance that ceiling mode without changes to the firmware will impact the way the Nolo controllers report their yaw value. If this is the case, we will have contact LYRobotix for assistance.

How you can help!

Developing the ceiling mode configuration file will require the assistance of someone from the community who has a ceiling mode setup for their hardware, and a lot of trial and error. We will need to open an active line of communication (IM/Skype/etc.) so that I can suggest changes that you can test immediately. Please post in this thread if you are interested so that we can arrange this discussion.

Original comment on /r/osvr: https://www.reddit.com/r/OSVR/comments/7vtkkb/nolo_osvr_fusion_configuration_v030_release/du2v3o2/

With SteamVR beta, menu button (power button in Nolos) does nothing. This should have to do with the recent changes to input in SteamVR.

User claims that the Nolo Power/System button does not work with the SteamVR beta, perhaps as a result of the new input system.

To my knowledge, the old input system APIs are supposed to remain functional for at least some time after the new input system is fully implemented, which it presently is not. This leads me to believe the issue lies elsewhere, but I'm not sure where to start with tracking it down.

Original comment on /r/osvr: https://www.reddit.com/r/OSVR/comments/7vtkkb/nolo_osvr_fusion_configuration_v030_release/du2v3o2/

Like the last time, with default alpha value of 0.9995 when I rotate my head I notice a rotating back effect that is very nauseating. So I have changed it to 0.99995 and now I don't feel that effect, but the rotation is very sensitive, like a real rotation of 90 degrees turns into a vr rotation of almost 180.

The fact that the rotation is overly sensitive make the source of this issue, in my opinion, very clear: For some reason, the yaw reported by the user's headset is about double what it should be. This creates a large error between headset yaw and Nolo yaw, which causes the filter to attempt to "correct" back to the Nolo yaw, creating the nauseating rotation effect.

When the user changes the alpha value to 0.99995, they aren't actually fixing anything. What's happening is that with this alpha value very close to 1, they are adjusting the filter to even more heavily favor the headset yaw, and almost entirely neglect the Nolo yaw. In fact, in this situation, the user's viewport actually will rotate back slowly, but it's so slow that the user isn't noticing it.

So what is the root cause of this yaw doubling? We'll need more information about what headset the user is using, but I think it's either a matter of duplicate reports from the headset or improper timing information.