FreePieIO not working?

Trinus Forum Forums Troubleshooting FreePieIO not working?

This topic contains 9 replies, has 4 voices, and was last updated by  JustCallMeDanTheMan 11 months, 2 weeks ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
  • #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[0].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[0].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.

    • This topic was modified 1 year, 1 month ago by  JustCallMeDanTheMan.
    • This topic was modified 1 year, 1 month ago by loxai loxai. Reason: Easier title search match

    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[0] is for head tracking, fp[1] and fp[2] for hand trackers). I’ll check if there’s an issue with that.



    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[0]) 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 tab


    I found a bug in the Trinus server FreePie code, please update and check if it fixes the issue.



    Sorry for late reply, thank you very much for fixing it



    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?



    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[0].yaw
    yaw += mouse.deltaX / sensitivity * 180
    if yaw > 180.0:
    	yaw = -180.0
    elif yaw < -180.0:
    	yaw = 180.0
    freePieIO[0].yaw = yaw
    pitch = freePieIO[0].pitch
    pitch += mouse.deltaY / sensitivity * 180
    if pitch > 180.0:
    	pitch = 180.0
    elif pitch < -180.0:
    	pitch = -180.0
    freePieIO[0].pitch = pitch
    freePieIO[0].x = 0
    freePieIO[0].y = 0
    freePieIO[0].z = 0
    freePieIO[0].roll = 0

    I also tried the much simpler:

    freePieIO[0].yaw = mouse.deltaX
    freePieIO[0].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[0].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…


    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:
    if starting:
    x = 0
    y = 0
    z = 0

    x = x+mouse.deltaX
    z = z+mouse.deltaY
    y = y+mouse.wheel

    #freePieIO[1].roll = x
    freePieIO[0].pitch = z
    #freePieIO[2].pitch = x
    #freePieIO[2].roll = z
    freePieIO[0].z = y



    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.



    Update: I have verified what should be in FreePieIO[0].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[0].yaw):
    		minYaw = freePieIO[0].yaw
    	if (maxYaw < freePieIO[0].yaw):
    		maxYaw = freePieIO[0].yaw
    	if (minPitch > freePieIO[0].pitch):
    		minPitch = freePieIO[0].pitch
    	if (maxPitch < freePieIO[0].pitch):
    		maxPitch = freePieIO[0].pitch
    	if (minRoll > freePieIO[0].roll):
    		minRoll = freePieIO[0].roll
    	if (maxRoll < freePieIO[0].roll):
    		maxRoll = freePieIO[0].roll
    	#Watch everything[0].yaw)[0].pitch)[0].roll)
    if starting:
    	minYaw = 0
    	maxYaw = 0
    	minPitch = 0
    	maxPitch = 0
    	minRoll = 0
    	maxRoll = 0
    	freePieIO[0].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[1].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[1].yaw
    mouse.deltaY = -1 * pitchCursorScale * freePieIO[1].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.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.