Tagged: FreePie FreePieIO
August 30, 2017 at 7:17 pm #7219
I have no gyroscope 🙁
I do, however, have a gyroscopic mouse. Using regular PC games with No Sensor and this gyroscopic mouse works absolutely fine. However, SteamVR doesn’t care about where my mouse cursor is as it’s expecting an HMD to provide head position and rotational data… and so I turn to FreePie:
Guessing from other FreePie scripts like those for PSmove and the wording used on the page for TrinusPSVR (though I am using Trinus VR with my Android phone), I made a short script to transfer mouse movements into FreePieIO.pitch and yaw (everything else maintained at zero)… and on the SteamVR tab (server 2.1.3) I have FreePieIO selected as External Input. Only I don’t know what data TrinusVR is expecting there, and no matter what I put, it seems nothing is happening… no motion whatsoever in SteamVR Home, though the Watch tab shows that FreePieIO.pitch and yaw are at least doing what I coded them to do as I move my mouse around.
Any clues what to do here?
Also… seriously… get a Paypal donate button and put it in your sig. You do a tremendous amount of work for a one-off $10 per user, and this support must cost a ton of time. Especially now you have three versions of these VR products out! Those of us who are hacking away beyond the care of most should at least be able to throw a few dollars your way for your ongoing care and support 🙂
Otherwise, I fear we’ll lose you to the faceless horde of gimme-that-app-for-50-cents-or-I-will-trash-it-in-the-Google-Play-reviews users, who seem to expect that software maintenance is a costless endeavour.August 31, 2017 at 9:30 am #7224
Thank you for the support. There certainly is a type of user that can be quite frustrating. It can be difficult to understand what’s behind a project.
I did have a donation option a long time ago, but it wasn’t that successful. And power users like yourself can already bring great value by helping others and sharing with friends/social outlets.
Regarding FreePie, it should just work (fp is for head tracking, fp and fp for hand trackers). I’ll check if there’s an issue with that.September 4, 2017 at 9:00 pm #7238
I’m using FreePieIO as external input under SteamVR tab. I tried the sample script from FreePIE for PSVR page, but I can’t change even the head position (freePieIO) using it. Any ideas?
I’m using Trinus VR Server 2.1.3
Alt. Mode, Sync, and Legacy Capture Method are all disabled under SteamVR tabSeptember 5, 2017 at 5:16 pm #7241
I found a bug in the Trinus server FreePie code, please update and check if it fixes the issue.September 6, 2017 at 5:19 pm #7243
Sorry for late reply, thank you very much for fixing itSeptember 16, 2017 at 9:14 am #7263
1. can someone send me that freepieio script? i don’t have a gyro either. 2. how does freepieio work? same phone install or second phone?September 16, 2017 at 9:19 pm #7266
Glad to hear you solved a bug for jomeady at least! Unfortunately, it is still not working for me 🙁
daniisfound, this script is for converting mouse movements into yaw and pitch head movements – the thing is: I don’t know if it should work or not! There isn’t much documentation out there at all for FreePie, especially for this example. so I found it a real challenge
if starting: yaw = 0.0 pitch = 0.0 sensitivity = 180 yaw = freePieIO.yaw yaw += mouse.deltaX / sensitivity * 180 if yaw > 180.0: yaw = -180.0 elif yaw < -180.0: yaw = 180.0 freePieIO.yaw = yaw pitch = freePieIO.pitch pitch += mouse.deltaY / sensitivity * 180 if pitch > 180.0: pitch = 180.0 elif pitch < -180.0: pitch = -180.0 freePieIO.pitch = pitch freePieIO.x = 0 freePieIO.y = 0 freePieIO.z = 0 freePieIO.roll = 0 #watch diagnostics.watch(mouse.deltaX) diagnostics.watch(mouse.deltaY) diagnostics.watch(freePieIO.yaw) diagnostics.watch(freePieIO.pitch)
I also tried the much simpler:
freePieIO.yaw = mouse.deltaX freePieIO.pitch = mouse.deltaY
As I saw a pretty much zero context example that did this kind of thing. From the watched variables, I can see both are working as I intended in terms of values of output into yaw and pitch, but my in-world VR head never moves once Steam VR Home is showing on my phone through Trinus VR. After a while, it says the display is in standby (a default effect of Steam not detecting any movement, I assume)
jomeady, since you have it working, if you use the ‘watch’ commands above in FreePie, what values do FreePie.yaw and pitch take? Does it seem to be degrees from -180 to 180, as I would expect, or a series of small numbers that would indicate deltas are the proper usage? I assume nobody is using radians…. but who knows, I can’t seem to find any explanative documentation about the values these FreePie[#].yaw/pitch/roll/x/y/z variables should take!
If I’ve got it right already with FreePie, I have no idea why it isn’t translating into movement in Steam VR…September 18, 2017 at 10:15 am #7267
Which FreePIE version are you using? I’m on 1.9.629
Data is in degrees. Here’s the quick mouse input test script I use:
x = 0
y = 0
z = 0
x = x+mouse.deltaX
z = z+mouse.deltaY
y = y+mouse.wheel
#freePieIO.roll = x
freePieIO.pitch = z
#freePieIO.pitch = x
#freePieIO.roll = z
freePieIO.z = ySeptember 19, 2017 at 10:21 pm #7268
Okay, great, so my original script was probably right for my needs (assuming -180 to 180 are the expected degree values).
I tried yours, too, just to be on the safe side (and to rule out absolutely ANY script related issue) 🙂 – same FreePIE version.
Still no movement, I’m afraid. I stay staring front and centre.
I assume it doesn’t matter what order I run things in? I currently open FreePie, load Trinus on both phone and server and connect them, start Steam VR then enable the script in FreePIE
I’m sure I’ve tried other variants, but I know this was the last order I did things in.November 4, 2017 at 11:18 pm #7347
Update: I have verified what should be in FreePieIO.yaw, .pitch and .roll – it is, in fact, radians:
Yaw: -Pi to +Pi
Pitch: -Pi to +Pi
Roll: -Pi/2 to +Pi/2
I bought a second hand PS move kit because I’m configuring a Sharpshooter setup, and the gyroscopic mouse giving me poor results when looking up/down is, in fact, a dealbreaker for Tribes Ascend where I have to do that frequently ^_^. I just set up the following script, then swung my move controller about to find maximal and minimal values.
def update(): #define globals global minYaw global maxYaw global minPitch global maxPitch global minRoll global maxRoll #Update minima and maxima if (minYaw > freePieIO.yaw): minYaw = freePieIO.yaw if (maxYaw < freePieIO.yaw): maxYaw = freePieIO.yaw if (minPitch > freePieIO.pitch): minPitch = freePieIO.pitch if (maxPitch < freePieIO.pitch): maxPitch = freePieIO.pitch if (minRoll > freePieIO.roll): minRoll = freePieIO.roll if (maxRoll < freePieIO.roll): maxRoll = freePieIO.roll #Watch everything diagnostics.watch(freePieIO.yaw) diagnostics.watch(minYaw) diagnostics.watch(maxYaw) diagnostics.watch(freePieIO.pitch) diagnostics.watch(minPitch) diagnostics.watch(maxPitch) diagnostics.watch(freePieIO.roll) diagnostics.watch(minRoll) diagnostics.watch(maxRoll) if starting: minYaw = 0 maxYaw = 0 minPitch = 0 maxPitch = 0 minRoll = 0 maxRoll = 0 freePieIO.update += update
The original orientations for front and level configured during PS Move Service setup were pretty standard e.g. level defined by the surface I had the calibration mat on, forward as defined by the direction I had the mat facing, which was my monitor.
Starting from the flat and front-facing position (zeroes for pitch, yaw and roll), the watched values showed:
– Yaw hit minimum/maximum (approximately +-3.14) when the controller is aimed directly behind by rotating left/right, growing positively when aiming to the left and growing negatively when aiming to the right
– Pitch hit minimum/maximum (approximately +-3.14) when the controller is aimed directly behind by aiming the controller up and over until it facing behind (and upside down), growing positively when aiming up and growing negatively when aiming down
– Roll hit maximum (approximately 1.56) a quarter turn to the left, decreasing again to zero by the half turn, and negative to the minimum (approximately -1.54) by a three-quarter turn (i.e. a quarter turn to the right)
These are all pitch/yaw/roll values that identify the current orientation of the controller and not ‘deltas’, or speed of pitch/yaw/roll variation.
If you’re tracking only a single PS Move controller in the FreePie bridge then you can use the gyroscope data directly (rather than the orientation calculated from gyroscope, position, accelerometers and magnetometer) via FreePieIO.yaw, .pitch and .roll, which give ‘deltas’ in the pitch/yaw/roll of the controller. Actually, in the end (perhaps affected by me only having one camera?), this gives a better experience:
#Mouse movement using Gyroscope mouse.deltaX = -1 * yawCursorScale * freePieIO.yaw mouse.deltaY = -1 * pitchCursorScale * freePieIO.pitch
Where yawCursorScale and pitchCursorScale are arbitrary constants – I use 1.2 for Tribes Ascend for both, with an in-game sensitivity of 13. (Doing it this way means I don’t need need to reconfigure the in-game mouse sensitivity when I sit down and use the mouse and keyboard)
Later, I’ll see what happens in Trinus VR and Steam VR.
You must be logged in to reply to this topic.