FreePIE wiki or some other script repository?

[TiagoTiago]

Is there a FreePIE wiki or some other sort of place where users can post scripts and codes snippets they think would be useful to others?

[CyberVillain]

No but thats a good idea, I could add a wiki page to our Github wiki

[NoxWings]

Nice proposal. I've currently created a git repo on github to share a script but it would be nice to have a wiki or something to host them all.

[CyberVillain]

There you go

https://github.com/AndersMalmgren/FreeP ... ed-scripts

[NoxWings]

There you go

https://github.com/AndersMalmgren/FreeP ... ed-scripts

Thanx, I've just finished a speech to key commands script. It may be useful for some folks.

Do you mind if I place a link instead of the actual script there? It is almost 150 lines long :S

https://github.com/NoxWings/FreePie-Scr ... Command.py

[CyberVillain]

Sounds good

[CyberVillain]

Nice work with that script by the way, Command pattern is nice

[NoxWings]

Nice work with that script by the way, Command pattern is nice

Thank you. Ouch I've just seen the pattern in wikipedia, I haven't used it intentionally It just came to my mind to make keyActions extensible but looks like I even named it the same way lol xD

[TiagoTiago]

I added a few snippets there that I use a bit frequently.

I'm not all that familiar with Github's wiki system though; couldn't figure out how to make them sub-pages of the Community contributed scripts page, nor have I found a way to put pages in categories so far.

[CyberVillain]

We have a built in filters.mapRange thats doing the same as yours EnsureMapRange

[CyberVillain]

sign is also built into the python math lib, its called

math.copysign(1, x)

where x is the variable you wanna test

[TiagoTiago]

We have a built in filters.mapRange thats doing the same as yours EnsureMapRange

Oops.

Hm, where can I find all the builtin functions that don't come stock with Python?

sign is also built into the python math lib, its called

math.copysign(1, x)

where x is the variable you wanna test

Hm, and it returns 0 for zero as well?


I remember back when I first wrote it, I did a quick google search before and all I could find was that Python didn't had a sign function like that, it would just return 1 or -1, but never zero.

[TiagoTiago]

We have a built in filters.mapRange thats doing the same as yours EnsureMapRange

Actually, I just did a quick test, and mapRange is not the same as EnsureMapRange. With just mapRange values outside of the range get extrapolated instead of capped. In GlovePIE that is the difference between MapRange and EnsureMapRange.

[CyberVillain]

Ah, true. Can add ensureMapRange too

Youre right copysign return 1 for 0


A shorter sign implementation

Code: Select all

def sign(x):
	return x and (1, -1)[x<0]

[CyberVillain]

Added ensureMapRange

https://github.com/AndersMalmgren/FreeP ... 011604d827

[TiagoTiago]

Ah, true. Can add ensureMapRange too

Youre right copysign return 1 for 0


A shorter sign implementation

Code: Select all

def sign(x):
	return x and (1, -1)[x<0]

Cool! Should I change the code on the wiki?

Added ensureMapRange

https://github.com/AndersMalmgren/FreeP ... 011604d827

Awesome! Thanx!

[CyberVillain]

We can fix that for next release when FreePIE has the ensureMapRange.

Btw, there is also a deadband filter in FreePIE that might replace that part of the code

Code: Select all

filters.deadband

[TiagoTiago]

We can fix that for next release when FreePIE has the ensureMapRange.

Btw, there is also a deadband filter in FreePIE that might replace that part of the code

Code: Select all

filters.deadband

Doesn't look like filters.deadband allows you to get any values smaller than the deadband size. With ScaledDeadzone, the whole range starting from zero is squeezed to give room for the deadzone instead of just overwriting the low values values with zero.

Sorta like this:

Code: Select all

Deadzone size: 0.5

input:
0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0

filters.deadband's output:
0.0, 0.0, 0.0, 0.0, 0.0, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0

ScaledDeadzone's output:
0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.2, 0.4, 0.6, 0.8, 1.0

[CyberVillain]

Yes, it just crops the values it does not recalibrate them to the orignal axis. Its mostly used for relative axis like a mouse, then you just want to crop too small values to eliminate drift.

To be more clear, FreePIE deadband works best with Aboslute to Relative while yours work for Abosolute to Absolute.
Maybe we should include something similar in FreePIE

[CyberVillain]

https://github.com/AndersMalmgren/FreeP ... 00d50a34a8

[TiagoTiago]

Thanx

[konstantin_lozev]

Is there a standard script already available for air mouse emulation with the wiimote?
The most often used script for that in GlovePIE was the lednerg script, I think:
http://www.reddit.com/r/oculus/comments ... arthunder/
I have had drift issues with it though. A slight drift is not that problematic in the X axis (yaw) in a VR scenario, since you are turning in circles anyway, but the vertical Y axis drift (pitch) ultimately leads to you having to face the floor/ceiling in order for your character to look straight ahead.
If an airmouse script exists in FreePIE, I would be interested to see how drift is avoided.

[CyberVillain]

how does the first script in this post work for you? Considering drift

http://www.mtbs3d.com/phpBB/viewtopic.p ... 42#p143263

edit: You can also tset with different fusions under Settings / Plugins / Wiimote / M+ fuser type

[konstantin_lozev]

Thanks, will test all those and will post back here.

[konstantin_lozev]

how does the first script in this post work for you? Considering drift

http://www.mtbs3d.com/phpBB/viewtopic.p ... 42#p143263

edit: You can also tset with different fusions under Settings / Plugins / Wiimote / M+ fuser type

Hi, I tested quickly this morning and there was surely a strong drift I made 3 videos with explanations in the description as to what should be observed. Anyway, quickly:
https://www.youtube.com/watch?v=WI7TIzA ... e=youtu.be - in just 1 minute after swinging the wiimote the way you would aim in a game the cursor moved from the center to almost at the edge of the screen.
https://www.youtube.com/watch?v=bn_280Q ... e=youtu.be - as mentioned in the description, the low deadband of 0.008 allows for smooth mouse movement and no drifting when the wiimote is on a level surface, see at the end of the video that the values are still increasing very fast.
https://www.youtube.com/watch?v=M_u4Lbn ... e=youtu.be - this is simply a proof that the drift is "unlocked" even at very small values outside the deadband.
Don't get me wrong, I don't think the problem is with FreePIE, but rather with the wiimote gyros.

Observing the three videos, this is how I imagine things happen - within the deadband the cursor is stable, but this is only illusionary, since once you exit the deadband, there is a bias in the gyro reading your movements, which over 1 minute makes the game unplayable, unless you constantly re-adjust the aim like the "calibration" of the MAG-II gun controller. So, basically, with the deadband, we are only hiding temporarily the drift, which becomes apparent and aggravates the controls over a short period of time.
Now - to the second question - is the inherent bias/drift constant or not (e.g. proportionate to your movement). If it is constant, it would be pretty straightforward how to deal with it - just measure the average deviation over a "calibration" period while the wiimote is kept lying on the table/floor and subtract that deviation-per-frame from each subsequent frame. That is supposed to cancel out any bias when the wiimote is static instead of simply hiding it with a deadband function. It should be best tested with deadband = 0 and if there is no drift, this should be a good starting point.
If the bias is constant and does not depend on the forces that the gyro experiences, this should solve the problem. However, I have the suspicion that it is not, because the drift in the third video was much smaller than the drift in the first video. If this is indeed the case, it becomes really tricky to solve.
Any suggestions are welcome.

PS: This was the only reason why I went to IR-bar exclusive scripts for GlovePIE. Unfortunately, that is not a solution for when you wear an Oculus-type of VR set and want to turn around and shoot behind you.
DDDRRRIIIFFFT

[TiagoTiago]

Just using IMUs to obtain absolute rotation and/or position doesn't work; you need some absolute measurement to recalibrate frequently because the drift is inherently random.

If you just need to keep the pitch calbrated though, if you're using accelerometers you can use gravity to get the down direction (doesn't always point down, but unless you're moving a lot, I think it should stay pointing down if you use a low-pass filter).


As for calibrating the yaw all around, you could distribute a bunch of IR leds around you and instead of assuming the dots are always the same, just count their movement; or if the wiimote is static, you could wear a crown of IR leds; or even just put them on some "antennas" so that they are always visible; or even put the wiimote on the ceiling pointing down and place 4 leds on "antennas" in a non-coplanar arrangement and use an algorithm like the one used by Freetrack.

[konstantin_lozev]

Just using IMUs to obtain absolute rotation and/or position doesn't work; you need some absolute measurement to recalibrate frequently because the drift is inherently random.

If you just need to keep the pitch calbrated though, if you're using accelerometers you can use gravity to get the down direction (doesn't always point down, but unless you're moving a lot, I think it should stay pointing down if you use a low-pass filter).


As for calibrating the yaw all around, you could distribute a bunch of IR leds around you and instead of assuming the dots are always the same, just count their movement; or if the wiimote is static, you could wear a crown of IR leds; or even just put them on some "antennas" so that they are always visible; or even put the wiimote on the ceiling pointing down and place 4 leds on "antennas" in a non-coplanar arrangement and use an algorithm like the one used by Freetrack.

Yeah, I also thought that can be an option. I can try this weekend something with GlovePIE, but I am still uncertain as to how it should look like. The movement of the mouse is tied to changes in the pitch/yaw, which should in principle be accompanied by changes to the g forces measured by the accelerometers of the wiimote. An option would be to condition the movement of the mouse to changes in the same direction of the pitch and the gz (if I am not mistaken it was the gz that increased once you point upwards and gets to 1 if your wii is pointing vertically). What bothers me is that the gz reading might not be fully synchronised with the pitch reading, resulting in jittery movements with occasional stops every few frames. I seem to remember that the gz was also somewhat erratic. Maybe a tiny deadband for those two before checking whether they are working in the same direction...
I saw this equation:
angle = 0.98 *(angle+gyro*dt) + 0.02*acc
here http://www.instructables.com/id/Guide-t ... ino-inclu/
but I don't think that is a solution for our problem.

[CyberVillain]

You can get good enough results witb only IMU so that you only need to recalibrate very seldom. Like with the Rifts IMU and fusion.

Plus if you're doing 360 VR gaming a little drift in the Yaw axis does not matter. If oyu are doing stationary gaming its more important because then you want the view to center when you are looking straight sitting in the chair

[TiagoTiago]

Hm, FreePIE can't get the IR data from the Wiimote yet?

Just using IMUs to obtain absolute rotation and/or position doesn't work; you need some absolute measurement to recalibrate frequently because the drift is inherently random.

If you just need to keep the pitch calbrated though, if you're using accelerometers you can use gravity to get the down direction (doesn't always point down, but unless you're moving a lot, I think it should stay pointing down if you use a low-pass filter).


As for calibrating the yaw all around, you could distribute a bunch of IR leds around you and instead of assuming the dots are always the same, just count their movement; or if the wiimote is static, you could wear a crown of IR leds; or even just put them on some "antennas" so that they are always visible; or even put the wiimote on the ceiling pointing down and place 4 leds on "antennas" in a non-coplanar arrangement and use an algorithm like the one used by Freetrack.

Yeah, I also thought that can be an option. I can try this weekend something with GlovePIE, but I am still uncertain as to how it should look like. The movement of the mouse is tied to changes in the pitch/yaw, which should in principle be accompanied by changes to the g forces measured by the accelerometers of the wiimote. An option would be to condition the movement of the mouse to changes in the same direction of the pitch and the gz (if I am not mistaken it was the gz that increased once you point upwards and gets to 1 if your wii is pointing vertically). What bothers me is that the gz reading might not be fully synchronised with the pitch reading, resulting in jittery movements with occasional stops every few frames. I seem to remember that the gz was also somewhat erratic. Maybe a tiny deadband for those two before checking whether they are working in the same direction...
I saw this equation:
angle = 0.98 *(angle+gyro*dt) + 0.02*acc
here http://www.instructables.com/id/Guide-t ... ino-inclu/
but I don't think that is a solution for our problem.

I think to get pitch from acceleration, you do something like atan2(gz, gy+gx) ; but I'm not sure, and I don't have time right now to test or research. Will try to remember to come back to this later (can't promise anything though).

If it is updates less often than the fusion or gyro angle, only apply the correction when it changes, using the estimated measurement from the faster values in the mean time. And perhaps apply a low pass filter to the difference before using it to correct the final value?

You can get good enough results witb only IMU so that you only need to recalibrate very seldom. Like with the Rifts IMU and fusion.

Plus if you're doing 360 VR gaming a little drift in the Yaw axis does not matter. If oyu are doing stationary gaming its more important because then you want the view to center when you are looking straight sitting in the chair

Doesn't the Rift use a compass to recalibrate the yaw? (and the second devkit also uses a camera if I'm not mistaken)

[konstantin_lozev]

You can get good enough results witb only IMU so that you only need to recalibrate very seldom. Like with the Rifts IMU and fusion.

Plus if you're doing 360 VR gaming a little drift in the Yaw axis does not matter. If oyu are doing stationary gaming its more important because then you want the view to center when you are looking straight sitting in the chair

Yeah, I fully agree with you that for 360 degree gaming a drift with yaw is not such a big problem and can be addressed with deadband. However in my videos you saw that there is strong upward drift, which is not playable
For stationary gaming with the wii there is one clear solution - IR bar. I did make a very good script with it on GlovePIE and you can play through the wii batteries without a hint of drift.
I have no Rift so I cannot confirm whether it is better than the wii, but I guess special hardware can have its built-in calibration or filtering for drift.
I keep on thinking of ways to filter out drift and maybe the best way to use the gyro and accelerometer is to present gz as a function of pitch, if I am not mistaken, it should be SIN function. I will have to experiment to see how should this be used in a script to control for drift...

[CyberVillain]

Did you try the Mahony fusion in settings? It uses both Gyro and Acc data. Also its not just a problem with drift of the actual device, you need to sync your mouse emulation so that 1 degree tilt of the pitch axis results in a 1 degree pitch in the game

[konstantin_lozev]

Did you try the Mahony fusion in settings? It uses both Gyro and Acc data. Also its not just a problem with drift of the actual device, you need to sync your mouse emulation so that 1 degree tilt of the pitch axis results in a 1 degree pitch in the game

hi, thanks for the advice,will check the fusions tomorrow, since FeeePIE works only on my Win7 machines and I have only an Asus 901 in bed.

[konstantin_lozev]

Did you try the Mahony fusion in settings? It uses both Gyro and Acc data. Also its not just a problem with drift of the actual device, you need to sync your mouse emulation so that 1 degree tilt of the pitch axis results in a 1 degree pitch in the game

Hi, here is the result from all testing for me:
The Mahony fusion bugged out within a minute i.e. it started to overcorrect like crazy, here is the video:
https://www.youtube.com/watch?v=WFjsz1T ... e=youtu.be

Using wiimote.gz or wiimote.pitch in GlovePIE produces nasty micro-jumps, which I managed to eliminate through a simple deadband calibrated over the first 100 or so frames. Nevertheless, once you are outside the deadband, the micro-jumps come again. Those micro-jumps appear randomly and are unbiased, i.e they are randomly positive/negative of similar absolute value. Therefore, a smooth function somehow masks it, but is not ideal. The micro-jumps of wiimote.gz or wiimote.pitch also appeared somehow parallel, so correcting one with the other was out of the question.
Here is the gz script https://drive.google.com/file/d/0B_7L0f ... sp=sharing
Here is the smoothpitch script https://drive.google.com/file/d/0B_7L0f ... sp=sharing
The advantage of using the gz function (actually aSin of gz) is of course you can use it even with the normal wiimote, no motion+ needed. EDIT: I will test this with a non-Motion+ wiimote, since it might be that the gz values available through GlovePIE are already corrected through the gyro (that might explain the fact that the micro-jumps of wiimote.gz or wiimote.pitch appeared parallel).

I had a look at Lednerg's script and the essential difference is that he uses PitchSpeed instead, which I understand is a native function, since gyros by design measure rotational speed. I only had to multiply it with a timestamp function to arrive to an equivalent to delta(wiimote.pitch). It's actually only one line.
Mouse.DirectInputY -= (wiimote.pitchspeed in radians per second)*RemoveUnits(Delta(timestamp))*500
Result - no micto-jumps at all, no need for smoothing or deadband. Most of the time it works, but on sharp change of vertical direction it would also be prone to misalignment. In short - the best approach, but still prone to drifting eventually, which I cannot correct with the other measurements since they are really much worse and prone to errors themselves.
I also applied the same approach for the x axis/yaw and derived a simple 2-line speed:
Mouse.DirectInputY -= (wiimote.pitchspeed in radians per second)*RemoveUnits(Delta(timestamp))*500
Mouse.DirectInputX += (wiimote.yawspeed in radians per second)*RemoveUnits(Delta(timestamp))*500
Maybe someone can convert this in FreePIE and see the result...

I will try and post a video with it it working in a game.

[CyberVillain]

Just a quick note,

FreePIE also exposes the gyro data

Code: Select all

wiimote[0].motionplus

But my guess is it will also drift alot

[konstantin_lozev]

Just a quick note,

FreePIE also exposes the gyro data

Code: Select all

wiimote[0].motionplus

But my guess is it will also drift alot

Thanks, I had a look at the reference for pitch https://github.com/AndersMalmgren/FreeP ... /Reference and I am a bit confused now.
There seem to be two properties:

wiimote
ahrs EulerAngles ahrs
pitch Double pitch

and

wiimote
motionplus MotionPlusGlobal motionplus
pitch_left Double pitch_left

Don't both of them use the gyro?
What is the difference between them?
Is there not an equivalent to PitchSpeed from GlovePIE? As I said I got the best results with it.
It seems that the mouse emulation script that you linked uses the ahrs pitch...

[CyberVillain]

ahrs will give you fused values.

wiimote[0].motionplus will give you gyro data (radians per second)

[konstantin_lozev]

ahrs will give you fused values.

wiimote[0].motionplus will give you gyro data (radians per second)

OK, Great, thank a lot, I understand then that wiimote.PitchSpeed in GlovePIE is wiimote[0].motionplus.pitch_left in FreePIE (I got confused why the _left moniker at the end, should not yaw and roll be left/right and pitch up/down, sorry if I misunderstood, I am new to FreePIE and still uncomfortable with the API)
I will experiment with it and try to get the same 2-line script as in GlovePIE and then compare the results.
The GlovePIE 2-liner was:
Mouse.DirectInputY -= (wiimote.pitchspeed in radians per second)*RemoveUnits(Delta(timestamp))*500
Mouse.DirectInputX += (wiimote.yawspeed in radians per second)*RemoveUnits(Delta(timestamp))*500
So I hope FreePIE supports timestamp (I saw it has a Delta() function). GlovePIE was unable to multiply speed (wiimote.pitchspeed) by time Delta(timestamp), which was more than strange, so I used RemoveUnits function. I hope FreePIE will not need that, but the whole Delta(timestamp) is only about fine-tuning the response, since in theory it should be constant depending on the given refresh rate (in practice it is not though).
From the scripts that I read so far I gather that Mouse.deltaX is only the addition to the x axis of the mouse, so no "+=", but only "=" should be used in converting from GlovePIE Mouse.DirectInputX.
I am aware that I "hijacked" the post, so if you or the OP want to move it to a new post, I am OK with that.