Velocity Reporting

[nanospork]

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.

[nanospork]

I'm planning to work on the OSVR-Fusion update, but we will need an update to Nolo-OSVR first. I can work on the SteamVR-OSVR update if nobody else is available.

[johnlajoie]

I'm looking through the nolo-osvr plugin. Is there some documentation for the new NOLO firmware?

I spent yesterday pulling together all I need to rebuild NOFC, including all the dependencies and the SDK, and I can build working software from the current code. I'm willing to work on the nolo-osvr driver if no one else has spoken up for it. I'm assuming the additional angular velocity information in the data coming from the firmware is documented somewhere, but maybe not?

My motivation in this is purely so that throwing grenades works better in DoomVFR ....

Nevermind - I think I've got what I needed from the NOLO Windows SDK...

[nanospork]

Note to readers: This item is being discussed at https://github.com/nanospork/nolo-osvr/pull/2

[nanospork]

Update: The necessary changes for velocity reporting have been made in https://github.com/nanospork/NOFC/pull/6 for nolo-osvr and in https://github.com/nanospork/steamvr-osvr/tree/controller-integration for SteamVR-OSVR.

Using the draft v0.3 config, velocity reporting works. It's not 100% reliable, but I think this is a Nolo hardware limitation.

Work remains on OSVR-Fusion, which is bypassed in the above config due to a bug that is preventing the velocity data from OSVR-Fusion from reaching SteamVR intact. I haven't discovered the root of this bug - help is wanted. If anyone can review the OSVR-Fusion code, I'd appreciate any findings.

[nanospork]

I had a eureka moment: I think this bug is a result of line 134 here. Since the v0.3 config doesn't use timestamps, it hasn't been sending the velocity. Simply setting the config to use timestamps should fix the issue!

[nanospork]

Looks like Fusion still needs an update to rotate the coordinate system of the controllers - right now they are throwing in the opposite direction when you apply the 180-flip, but other than that, it works!

Also, the velocities seem a little... weak. I wonder if there is a units issue somewhere.

[nanospork]

Implemented an update to fusion that fixes the velocities when the 180 flip is in effect. We're nearly there.