Enclosure for Tundra Tracker's IO Expansion board

[digitalf0x]

In brief

• Tundra Tracker's IO Expansion Board adds haptic options, but lacks the enclosure
  • Tundra Labs mentions needing to customize the 3D model of the base to fit the haptic actuator inside
  • My 1st IO board order came with a haptic actuator, not soldered - not sure if this is standard policy

Details

While it's possible to wire up the haptic actuator on the side and tape it somewhere, it'd be nice to integrate this with the Tundra Tracker enclosure directly. At the time of my order, Tundra Labs shipped the right haptics actuator with the IO Expansion Board, I'd just need to solder it on.

Looking around, I've not found any existing shared 3D printable enclosures that could hold the haptics actuator.

---

I noticed your hidden Ongoing Research wiki page mentions this is under consideration. If there's anything I can do to help that research, let me know. I'm handy with electronics, though I lack a 3D printer (I can use services such as Craftcloud if needed).

This project seems to not be too Windows-centric, either, so I'd be happy to try to help with getting it working on Linux as part of this.

[Z4urce]

Hello!
I have a discord server for research and development. Feel free to join us!

A member of it already made the tundra's haptics work with the pancake bridge software. (With the same ERM vibration motor I recommended for the pancake)

Unfortunately I'm unable to design an enclosure for them as I don't own any. But I can help you with that if you'd like to join our cause :)

And about Linux support... I made sure the software is as multi-platform as it can be :3

[digitalf0x]

Ah, awesome! I imagine the enclosure will be a bit different using the haptics motor Tundra unexpectedly included with my IO board (it looks like the Switch Joycon form factor they suggest in the description, maybe it's now standard?), but that's something we can work out.

I have been pretty busy, so it will be some time until I can contribute measurements/testing/etc. But I'll at least join the guild, and I appreciate the Linux consideration - I know it's niche to VR with Tux, but there are dozens of us :P

(I got your poke over on that IRC server, too - no worries, I got the email notification. Though I appreciate your enthusiasm and effort to navigate a platform so few people use nowadays 😅 )

[digitalf0x]

I'm still exploring this, but I figured I should share where I am so far…

• You don't need a new 3D enclosure, you just need to slot the pancake vibration motor inside the Tundra Tracker base
  • Two 0.5×0.5 inch squares of foam window insulation from the hardware store propped the motor up off the IO board into the plastic threaded mount base
  • Tundra's IO board uses JST SH right-angle surface-mount connectors in case you don't want to hardwire your vibration motor to the IO board
  • The IO board ribbon connector to the tracker itself does not go all the way inside the IO board's socket - be careful, don't force it, and be gentle with pressing flat the locking mechanism too
• Tundra Trackers and Vive Controllers use ns instead of ms as the unit of time, which contradicts the official documentation, hence needing a multiplier of 100 - as of eadf46d the Identify button now includes that
• On Linux, the Python app segfaults unless I run it with trace - I'll have to investigate this more in the future

#!/bin/bash

# Fetch repository with GitHub source code download, or…
# git clone "https://github.com/Z4urce/VRC-Haptic-Pancake.git"
# cd "VRC-Haptic-Pancake"

# Build and activate a Python virtual environment to keep your system clean
if [ ! -d "ignored-from-repo-venv" ]; then
    python3 -m venv ignored-from-repo-venv
fi
source ignored-from-repo-venv/bin/activate

# Install/update dependencies into the venv
pip3 install -r BridgeApp/requirements.txt

# Run app
python3 BridgeApp/main.py

# NOTE₁: You need to be inside the Python venv for this to work.  Redo the
#    "source […]" command if you're running this a second time, or just save this as
#    a "run-linux.sh" command in the root of the repository.

# NOTE₂: the app might segfault without tracing enabled for some reason
#    You might need to run it like so - this slows it down:
#
# python3 -m trace --count --coverdir=/dev/null BridgeApp/main.py

[digitalf0x]

Documenting this publicly for those following here, not on the Discord guild:

Nearly everything works on Linux, just using the python3 -m trace --count --coverdir=/dev/null BridgeApp/main.py launch method to work around the segfault I experience (I updated my prior comment).

Unfortunately, Tundra Trackers seem to implement Valve's deprecated TriggerHapticPulse in a way that fails to work with how VRC Haptic Pancake sends haptic pulses.

The problem might be as described on the Steam Community forums:

The parameter you pass into TriggerHapticPulse is measured in microseconds, with the max value (in my tests) being 3999, which is 4ms - each frame at 90Hz is 11ms long. Because of this, if you're pulsing each frame, the effect of pulse length is felt subjectively as vibration strength.

Dropping the intensity multiplier to 10 and boosting app_runner.py's self.interval_ms = 50 # millis to 5 milliseconds results in a partially working vibration, though the Tundra Tracker occasionally doesn't respond, blinking red, so I think I might be sending invalid commands.

(It didn't blink red when I previously put the __pulse() function into a while true: loop to cause it to vibrate near continuously, so I don't think it's an over-current situation.)

Using 1 millisecond as the target did seem to work better - maybe there's tuning to be done here.

I'll keep looking into this as I have time to investigate. Maybe the IVRInput methods would work more consistently… if it's supported by Vive/Tundra Trackers (I recall hearing something about it only working for actual full-blown controllers, not trackers).

[digitalf0x]

Doing some very rough experimentation, it seems like the Tundra Tracker stops responding for a short period of time if it's given too many triggerHapticPulse() commands (e.g. quicker than 5 ms delay), while at the same time it won't really pulse for longer than 5 ms either (possibly 3999 µs as in the Steam Community forums post linked in my prior comment).

I do not recommend implementing the following in VR Haptic Pancake yet, this is merely something kind of functional that I got with ~15 minutes of poking things:

Tweak to BridgeApp/app_runner.py:

--- BridgeApp/app_runner.py
+++ BridgeApp/app_runner.py
@@ -1,3 +1,3 @@
 
-        self.interval_ms = 50  # millis
+        self.interval_ms = 5.1  # millis
         self.interval_s = self.interval_ms / 1000  # seconds

EDIT 2024-3-9: Changed 5 millis to 5.1 millis, to reduce the likelihood of timing inaccuracy calling triggerHapticPulse() faster than 5000 µs. This might not be needed!

And the config.json, prettified:

{
  "version": 1,
  "server_type": 0,
  "server_ip": "127.0.0.1",
  "server_port": 9001,
  "pattern_config_list": [{
    "pattern": "Linear",
    "str_min": 0,
    "str_max": 80,
    "speed": 4
  }, {
    "pattern": "Linear",
    "str_min": 40,
    "str_max": 80,
    "speed": 16
  }],
  "tracker_config_dict": {
    "LHR-[device-serial-number]": {
      "enabled": true,
      "address": "/avatar/parameters/HapticsTouchWaist",
      "multiplier_override": 9.0,
      "pattern_override": "None",
      "battery_threshold": 20
    }
  },
  "tracker_to_osc": {}
}

EDIT 2024-3-9: Tentatively switched to Linear from Throb for proximity, but I haven't extensively tested this. Throb might make more sense once other aspects are tuned.

This ensures that target_ovr.py doesn't send a pulse longer than 5 ms (might need to be 3999 µs?), as longer values seem to not actually result in longer vibration. The below edit to target_ovr.py confirms this by printing a warning if you exceed that threshold.

    def __pulse(self, index, pulse_length: int = 200):
        if self.is_alive():
            self.vr.triggerHapticPulse(index, 0, pulse_length)
            # HACK: test spacing out pulses
            #pulse_max_amount = 3999
            pulse_max_amount = 5000
            #sleep_min_delay = pulse_max_amount / 1000000
            #sleep_min_delay = 5000 / 1000000
            if pulse_length > pulse_max_amount:
                print("PULSE LENGTH > " + str(pulse_max_amount) + ": " + str(pulse_length))
            #while pulse_length > 3999:
            #    self.vr.triggerHapticPulse(index, 0, pulse_max_amount)
            #    pulse_length -= pulse_max_amount
            #    time.sleep(sleep_min_delay)
            #if pulse_length > 0:
            #    self.vr.triggerHapticPulse(index, 0, pulse_length)
            #    time.sleep(sleep_min_delay)

I got the "Identify" command to meaningfully work by uncommenting the lines to repeatedly call triggerHapticPulse() (and adding import time at the top), but doing that breaks elsewhere because the sleep() halts everything else.