Can I access the stm32f3 "Foculus" output without Rift SDK?

[Elwood]

So I've flashed the STM32F3 board with the modified firmware by Yetifrisstlama (this has been described many times in the DIY Rift topics elsewhere on MTBS).

I installed the Oculus SDK ver 0.32 because since the 0.4 update the fake tracker is no longer recognized. Upon connecting the device it is recognized in 0.32, but the SDK is still unhappy due to lack of display. Now I'm planning to make an EDID spoofer later on, but right now I don't have the parts.

Apart from that, it is indeed working very well (compared to my phone's IMU via Freepie) in the few demos that do not check for the presence of the Rift Display. These programs probably do not even check if the SDK is running and get the data straight from the tracker;). One such demo is the very funny "Dumpy_Going_Elephants" game.

In Freepie, however, when I try to access the tracker's output I get a "Oculus VR SDK failed to init" notice. And I think that the SDK won't start without the screen. Sooo the obvious question is - is there any other way to get the tracker's output into Freepie?

[CyberVillain]

No we use the latest SDK to read the data so if the SDK requires the EDID so will FreePIE (Really stupid of them, probaly so that fake devices wont work easily).
You could recompile the OVRFreePIE dll under older version of the SDK

https://github.com/AndersMalmgren/FreeP ... lusVR/Code

[Elwood]

Recompile - if only I knew how to do it.
I take there is no "old version" I could download instead?

The tracker also shows up in Windows as both an USB device and a HID device. Any chance these can be used to gt the data?

[CyberVillain]

Recompile - if only I knew how to do it.
I take there is no "old version" I could download instead?

The tracker also shows up in Windows as both an USB device and a HID device. Any chance these can be used to gt the data?

No, when Oculus rewrite their SDK (Version 4.1 i think) we changed the signature of our dll (OVRFreepie.dll) so you cant use the old version with latest FreePIE


You can create a plugin for FreePIE that reads the raw HID data and reverse engineer the SDK, but that sounds like a lot of work

[Elwood]

OK so it might work with an old Freepie version? The previous Freepie 1.3 and 1.4 versions both have "Oculus SDK updated" in the release notes, which one of them is still compatible with the old SDK?

BTW Yetifrisstlama has recently answered to a thread on his Github, stating that might update the STM32F3 firmware for the new SDK when he has the time. Not much, but at least he did not say he won't;)

[CyberVillain]

1.4 has 0.2.5

You could try with that version, but I dont keep links to old version, have you found it on the net?

[Elwood]

I had an older (FreePIE.1.5.459.0) installer on my HDD. There are no Oculus SDK updates between this and 1.4 according to the release notes. This one simply crashes when trying to run a script with Oculus commands, regardless of the tracker being connected via USB or not. Will try again later when I make the EDID spoofer and report with results.

[Elwood]

And so I'm back and happy to confirm that it does work with the EDID spoofer attached. The tracking is beautiful compared to what I was getting from my Android phones - S3 and LG G3.

Cybervillain - would you consider adding support for both Oculus SDK .3 and .4 versions in the future? The stm32f3 board is quite popular in some circles... mostly the one particular circle which is the DIY forum here on mtbs .

And while at it - that is if you decide to do it of course - how about skipping that EDID test, not everybody is a leet soldering iron operator like me (just joking, I was actually very suprised that my ugly creation worked at all).

EDIT:
Actually, scrap that. I wrote this BEFORE atually running any game with Freetrack or TrackIR support.

The tracker DOES WORK GREAT. IN THE OCULUS GAMES AND DEMOS THAT IS.

Using freepie... and with a simple script like like:

yaw = oculusVR.yaw
and so on for the other rotations...

it produces MASSIVE, MONSTROUS DRIFT in pretty much all directions.
Note that I'm using FreePIE version 1.5.459.0 - can this be the problem?

[CyberVillain]

Post the Freetrack script please. Freetrack is absolute and so is Oculus so if there is drift its in the hardware or your script

[Elwood]

The script I'm using is very basic:

Code: Select all

def update():
    global yaw
    yaw = filters.continousRotation(oculusVR.yaw)
    global pitch
    pitch = filters.continousRotation(oculusVR.pitch)
    global roll
    roll = filters.continousRotation(oculusVR.roll)

if starting:
    centerYaw = 0
    centerPitch = 0
    centerRoll = 0
   
    yaw = 0
    pitch = 0
    roll = 0

oculusVR.update += update

freeTrack.yaw  = yaw - centerYaw
freeTrack.pitch = pitch - centerPitch
freeTrack.roll = roll - centerRoll

diagnostics.watch(math.degrees(freeTrack.pitch))
diagnostics.watch(math.degrees(freeTrack.yaw))
diagnostics.watch(math.degrees(freeTrack.roll))

if keyboard.getKeyDown(Key.LeftControl) and keyboard.getPressed(Key.C):
    centerYaw = yaw
    centerPitch = pitch
    centerRoll = roll

and still the results are not the same as in native Oculus programs. Using Freepie, I get like 10 degrees drift on some directions within the first 10 seconds of the script running, and that is with the tracker laying flat on the desk, completely immobile. Once it does settle, it is still very shaky, and every movement is followed by more drift.

It could be that the stm32f3 tracker is sending data at at different rate than the real Oculus (or was it just magnetomer sampling?), but the 0.3.2 Oculus SDK demos don't seem to mind at all, and results are very different. In the SDK sample demo room scene, and some other games (Dumpy Going Elephants, Kite&Lightning's The Station) the drift is pretty much unnoticeable, and the overall tracking is very stable.

So definitely Freepie is doing something diferrent?

[CyberVillain]

Nope, it just reads the values from the Oculus SDK and Feetrack is just feeding those values into the Freetrack client

remove freetrack and just try for example simple mouse emulation, is the mouse cursor drifting?

[Elwood]

One word... INDENTATION. Of "oculusVR.update += update". Aaand we have a winner!

BTW this applied to all my previous Android scripts. So with proper indentation, I found out that my LG G3 is actually halfway decent, some drift, bit unstable but OK. Tried the S3... literally no change with corrected script, just as bad as it was before.

[CyberVillain]

lol!

Sorry, I should have seen that!
It means for each loop you add a new listener.

[Elwood]

Well, you did help me in the end. I checked the example mouse script like you said and I noticed that it did not drift, even though it used the same oculus commands. And then the "little difference" became very easy to spot . So thank you anyway!