Full (yeah, well) Wiimote Support in FreePIE

Official forum for open source FreePIE discussion and development.
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberVillain »

We are workign on reaslign the next version soon
CyberCT
One Eyed Hopeful
Posts: 2
Joined: Tue Jun 17, 2014 6:41 pm

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberCT »

Hello. I joined this site (finally) after researching perhaps the best way to use the wiimote plus with Half Life 2 for Occulus Rift. I just sjoined but I get an error message that I don't get permission to download the following file. Please make sure it still works:

wiimote_nunchuck_and_motionplus.txt - using both motionplus and nunchuck at the same time, to control the mouse
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberVillain »

Code: Select all

def log_motionplus():
	diagnostics.watch(wiimote[0].ahrs.yaw)
	diagnostics.watch(wiimote[0].ahrs.pitch)
	diagnostics.watch(wiimote[0].ahrs.roll)
	
def simulate_mouse_pointer():	
	mouse.deltaX = filters.deadband(filters.delta(wiimote[0].ahrs.yaw), 0.1) * 10
	mouse.deltaY = filters.deadband(-filters.delta(wiimote[0].ahrs.pitch), 0.1) * 10
	
def log_nunchuck():
	diagnostics.watch(wiimote[0].nunchuck.acceleration.x)
	diagnostics.watch(wiimote[0].nunchuck.acceleration.y)
	diagnostics.watch(wiimote[0].nunchuck.acceleration.z)
	diagnostics.watch(wiimote[0].nunchuck.buttons.button_down(NunchuckButtons.Z))

def simulate_mouse_press():
	global previous
	if wiimote[0].nunchuck.buttons.button_down(NunchuckButtons.Z):
		if not previous:
			previous = True
			mouse.setPressed(0)
	else:
		previous = False

if starting:
	system.setThreadTiming(TimingTypes.HighresSystemTimer)
	system.threadExecutionInterval = 2
	
	global previous
	previous = False
	wiimote[0].motionplus.update += log_motionplus
	wiimote[0].motionplus.update += simulate_mouse_pointer
	wiimote[0].nunchuck.update += log_nunchuck
	wiimote[0].nunchuck.update += simulate_mouse_press
	
	wiimote[0].enable(WiimoteCapabilities.MotionPlus | WiimoteCapabilities.Extension)
CyberCT
One Eyed Hopeful
Posts: 2
Joined: Tue Jun 17, 2014 6:41 pm

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberCT »

Great, thanks. I got it working. I tried to download the file for JUST the WiiMotionPlus and it gives me the same error message (WTH). Could you please also post that code?

How can I change the sensitivity? Also, how do I change what the buttons do?

And finally, since I have the newer integrated WiiMotionPlus in one package controller, the only software application I could get it to work right with, is Toshiba Bluetooth Stack. I can't find the retail version to buy, so I have to uninstall and reinstall every 30 days. I have used this method with the Dolphin emulator in the past. Any other programs work completely with integrated WiiMotionPlus to be recognized by Windows?
metronome
Cross Eyed!
Posts: 114
Joined: Sat Mar 16, 2013 12:42 pm

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by metronome »

Hey I was giving this a go again on my black wiimote, however I had to invert the axis, to get it to work...
However there is alot of drift when not moving and the cursor is no where near 1:1 movement, anyway that can be fixed?? :( for example it seems that the cursor is moving about 1/4 of the speed of my hand so it will never feel like im aiming at the right place...
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberVillain »

Change the multiplier in the script. You can try to change the fusion in the wiimote settings. Also increase the deadline.
NeoTokyo_Nori
Cross Eyed!
Posts: 144
Joined: Wed Jul 16, 2014 10:29 am
Location: Tokyo, Japan

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by NeoTokyo_Nori »

Hello!

DK2 is almost upon us (keeping my fingers crossed),
and I am sure people here must be excited to get there hands on it, as am I.

So I have been using glovepie and wiimote as a gun controller,
which has been working alright up to a certain level,
but I hit a wall tyring to get to the next level,
then I finally found out about freepie,
and am hoping that this is the way through the wall,
and into the future ! ;D


So far I have things setup and run the script based on
wiimote_nunchuck_and_motionplus.txt

and I can get the motionplus data from wiimote in the watch window,
but I can only get the motionplus data OR the nunchuck data.

If one of them is enabled, then the other one does not give data.
I cannot get the data from both at the same time!

I have tried it using

Code: Select all

   wiimote[0].enable(WiimoteCapabilities.MotionPlus | WiimoteCapabilities.Extension)
As well as using

Code: Select all

   wiimote[0].enable(WiimoteCapabilities.Extension)
   wiimote[0].enable(WiimoteCapabilities.MotionPlus)
But nothing I have tried so far has worked,
So if you have any clues what todo please let me know.

Thanks !
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberVillain »

I think you are using the old version of that script. that is missing a key point

Code: Select all

if starting:
   system.setThreadTiming(TimingTypes.HighresSystemTimer)
   system.threadExecutionInterval = 2
This is needed becasue the Wiimote is need to be polled at exactly 2ms for both to work

I know this is not very user friendly, but we didnt find a better solution for now :/
NeoTokyo_Nori
Cross Eyed!
Posts: 144
Joined: Wed Jul 16, 2014 10:29 am
Location: Tokyo, Japan

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by NeoTokyo_Nori »

Hello CyberVillain, and thanks for your reply!
and for making Freepie.


Actually, that code is included in the script I have,
so I guess that is not the problem :/

btw I am also tyring to get 2 wiimotes to work at the same time. i.e.

Code: Select all

   diagnostics.watch(wiimote[0].acceleration.z) 
   diagnostics.watch(wiimote[1].acceleration.z)
I got it to work just this moment, but it does not seam to work reliably....
and it does not give any motionplus data either.

I wonder if these issues are related in any way ?

System spec: 64 bit Win 8, 16G ram
metronome
Cross Eyed!
Posts: 114
Joined: Sat Mar 16, 2013 12:42 pm

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by metronome »

Has anyone been able to get 1:1 movement to work, I feel like im just dragging the mouse cursor about, as Id like to use this with an HMD... is it possible to get this kind of accuracy?
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberVillain »

I'm guessing you need to use the IR for syncing the gyro to get reliably absolute movement.
IR support is something I really want, so if your into C++ and like to fiddle around with the Wiimote protocoll you are more than welcome!
NeoTokyo_Nori
Cross Eyed!
Posts: 144
Joined: Wed Jul 16, 2014 10:29 am
Location: Tokyo, Japan

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by NeoTokyo_Nori »

metronome, I don't know which code you are using but,
increasing the multiplier on the far right of this code (which is part of the sample provided),
seemed to get it closer to 1:1

Code: Select all

def simulate_mouse_pointer():   
   mouse.deltaX = filters.deadband(-filters.delta(wiimote[0].ahrs.yaw), 0.15) * 25
   mouse.deltaY = filters.deadband(filters.delta(wiimote[0].ahrs.pitch), 0.15) * 25
metronome
Cross Eyed!
Posts: 114
Joined: Sat Mar 16, 2013 12:42 pm

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by metronome »

NeoTokyo_Nori wrote:metronome, I don't know which code you are using but,
increasing the multiplier on the far right of this code (which is part of the sample provided),
seemed to get it closer to 1:1

Code: Select all

def simulate_mouse_pointer():   
   mouse.deltaX = filters.deadband(-filters.delta(wiimote[0].ahrs.yaw), 0.15) * 25
   mouse.deltaY = filters.deadband(filters.delta(wiimote[0].ahrs.pitch), 0.15) * 25
Are you able to post your whole script, maybe in a txt file... I have used lots of different versions of the m+ code so would be good to try something someone else has had some success with....



I'd love to be able to try it without the IR anyway :)
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberVillain »

Sorry, i didnt knwo we where talking mouse emulation.

Mouse emulation is tricky since we are using aboslute cordinates (Well Wiimote it in the land between aboslute and relative) and relative

The game has its own setting for mouse sensitivity so you need to find your own multiplier that works for each game. Keep in mind that 1:1 mouse emulation is not the same thing as drift
NeoTokyo_Nori
Cross Eyed!
Posts: 144
Joined: Wed Jul 16, 2014 10:29 am
Location: Tokyo, Japan

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by NeoTokyo_Nori »

This is pretty much the sample code, with some minor changes here and there.

Note that I cannot get the wiimotionplus and nunchuck to work at the same time,
so if you have any luck with that, do let us know.
You do not have the required permissions to view the files attached to this post.
metronome
Cross Eyed!
Posts: 114
Joined: Sat Mar 16, 2013 12:42 pm

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by metronome »

CyberVillain wrote:Sorry, i didnt knwo we where talking mouse emulation.

Mouse emulation is tricky since we are using aboslute cordinates (Well Wiimote it in the land between aboslute and relative) and relative

The game has its own setting for mouse sensitivity so you need to find your own multiplier that works for each game. Keep in mind that 1:1 mouse emulation is not the same thing as drift
yeh drift is when its a bit out, noticable when you arent moving the wiimote but the cursor is still moving and the 1:1 is how much it moves relative to your own movement.... I wonder if there is anything thats native on PC yet? I'm suprised no one has tried to do something similar for PC :S
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberVillain »

Most games that support TrackIR, Freetrack, Oculus Rift, Sixense STEm / Hydra have 1:1 tracking
NeoTokyo_Nori
Cross Eyed!
Posts: 144
Joined: Wed Jul 16, 2014 10:29 am
Location: Tokyo, Japan

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by NeoTokyo_Nori »

By the way, how is CyberRascall doing these days?
His last post appears to be in April.
I hope he "gets back in the game", since he is the point man for wiimote integraton afterall...
8-)
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberVillain »

Well, my brother is a bit hard to motivate, to bad I'm not that good with C++ :/
NeoTokyo_Nori
Cross Eyed!
Posts: 144
Joined: Wed Jul 16, 2014 10:29 am
Location: Tokyo, Japan

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by NeoTokyo_Nori »

aww, comon, CyberVillan, I mean CyberRascal!
DK2 is almost ready to be in our hands.

Maybe he could listen to grandma again,
when he needs some vr dev motivation !

http://www.youtube.com/watch?v=pAC5SeNH ... gTsCMeIhzr

:woot
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberVillain »

NeoTokyo_Nori wrote:aww, comon, CyberVillan, I mean CyberRascal!
DK2 is almost ready to be in our hands.

Maybe he could listen to grandma again,
when he needs some vr dev motivation !

http://www.youtube.com/watch?v=pAC5SeNH ... gTsCMeIhzr

:woot
Hehe, I took that alias in the days of BBS's and modems :D When my younger brother needed a online aliases I suggested that name for him :D
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberVillain »

konstantin_lozev wrote:
CyberVillain wrote: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.
:( :o :shock: DDDRRRIIIFFFT :( :o :shock:
I think its better to post here instead

Have you compared the drift with GlovePIE? I would like to know if its our fusion or the mote itself. Did you to change the fuser under settings?
konstantin_lozev
Cross Eyed!
Posts: 192
Joined: Fri Jul 04, 2014 1:43 am

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by konstantin_lozev »

Hi, I have not tried the fusion settings, I had no time and this was actually the first time I ran a FreePIE script.
It's also a good idea to check against the same script converted and run in GlovePIE. I will check that easily over the weekend.
Whatever the results, the point of using deadband function as the sole solution for drift being insufficient still stands, I think...
Maybe when I compare the GlovePIE results of the same script converted to GlovePIE, I can also try and implement the idea of "manual" calibration that I set out in my post, i.e. measure average drift-per-frame over several seconds and apply it from there on. That would work also for when the wiimote is moving, if the drift is constant. If not, I don't know...
Still, I will check a few fusion types too, as advised.
I should also say that the wiimote that I have is with the motion+ integrated in the wiimote itself.
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberVillain »

konstantin_lozev wrote:
CyberVillain wrote: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.

Something like this

Code: Select all

mouse.deltaX = wiimote[0].motionplus.yaw_down
mouse.deltaY = wiimote[0].motionplus.pitch_left
I do not undestand why yaw_down is named like it is and pitch_left :D You might need to add a multiplier too like
konstantin_lozev
Cross Eyed!
Posts: 192
Joined: Fri Jul 04, 2014 1:43 am

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by konstantin_lozev »

CyberVillain wrote:
konstantin_lozev wrote:
CyberVillain wrote: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.

Something like this

Code: Select all

mouse.deltaX = wiimote[0].motionplus.yaw_down
mouse.deltaY = wiimote[0].motionplus.pitch_left
I do not undestand why yaw_down is named like it is and pitch_left :D You might need to add a multiplier too like
Hi, thanks for moving the topic, I will continue here, I just did it this morning, only concentrating on the pitch_left part. I may make a youtube video of it, but here are the results:
- Multiplied by 0.1, the pitch_left line gets similar values to the values that you get with the line from the original script with ahrs.pitch multiplied by 30. I tried the python equivalent of timestamp that I found on google, but it threw an error; I guess my python programming "grammar" skills are at the same level as my young son's grammar :)
- the results with delta() of ahrs.pitch and pitch_left are very similar in the sense that there is still (mostly upward) drift even when the wiimote is static, without a deadband (Mahony fusion bugs out, as I said before). The drift is insignificant per frame, but consistent over time, so you's end up facing the ceiling again
- the same 2-liner in GlovePIE produces no drift at all when wiimote is static, also with no deadband, so there is definitely something with FreePIE, I will make a video of it to illustrate. It is not as accurate over time and there is the same random drifting when you move the wiimote as with lednerg's script (natural, since in its core it is based on the same values)
- I experimented with wiimote.acceleration.z and a delta function of it (I did not manage to apply properly math.aSin(), again probably due to poor python "grammar" on my side), but even in static wiimote the delta function produces nasty micro jumps similar to the micro jumps that I experienced in GlovePIE when using Delta(aSin(wiimote.gz)), so at least on that side the result is comparable to GlovePIE, but on the wrong side of comparability :(

To summarise - I cannot even reproduce the driftless static wiimote behaviour of GlovePIE using an equivalent FreePIE script.

EDIT: I guess the road from now would have to be:
- fixing of the static wiimote drift in line with GlovePIE results
- filtering out the gz/acceleration.z micro-jumps (I have an idea in my head of a single-sensor, non-Kalman filter, based on the fact that the jumps are always very short from 0 to 10 and back to 0 within a few frames, but for that I would need GlovePIE logging and I don't find a reference to this in the GlovePIE documentation, so maybe will have to go with the debug field)
- Kalman filter with the main sensor data coming from the gyro and correction coming from the filtered out accelerometer data from the previous bullet point.

That's in theory, in practice, this might take me a looooong time, unless it is already done by someone else...
CyberRascal
Two Eyed Hopeful
Posts: 74
Joined: Fri Sep 21, 2012 4:46 am

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberRascal »

Hi konstantin_lozev!

First, I'm sorry for the weird naming convention regarding pitch_left etc - I took it directly from Wiibrew when using their reverse engineering as reference when implementing the wiimote stuff. It should probably be removed :D

Regarding the drift however, that is a serious problem. Can we rule out that GlovePie uses some sort of deadband to filter out drift? There really is no gain calibration going on, only zero-point. An error with the zero-point calibration would of course cause drift... So I'm guessing that it's either the zero-point calibration that needs to be fixed or a deadband or other filtering function that needs to be applied.

So, the question is how we move forward. Initially I'll try my wiimote at home and try to see if there is something obvious wrong with the calibration. I'm an experienced programmer, but I have a very basic knowledge of sensors and their characteristics. So the implementation might be very stupid :D.

Realistically I'll have to wait until at least saturday to try it out though, but if anyone else wants a go the relevant code is in the file FreePIE.Core.Plugins/Wiimote/WiimoteCalibration.cs between lines 88-99.
NeoTokyo_Nori
Cross Eyed!
Posts: 144
Joined: Wed Jul 16, 2014 10:29 am
Location: Tokyo, Japan

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by NeoTokyo_Nori »

The return of the CyberRascal :!:
A new hope :!:

:lol:
konstantin_lozev
Cross Eyed!
Posts: 192
Joined: Fri Jul 04, 2014 1:43 am

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by konstantin_lozev »

CyberRascal wrote:Hi konstantin_lozev!

First, I'm sorry for the weird naming convention regarding pitch_left etc - I took it directly from Wiibrew when using their reverse engineering as reference when implementing the wiimote stuff. It should probably be removed :D

Regarding the drift however, that is a serious problem. Can we rule out that GlovePie uses some sort of deadband to filter out drift? There really is no gain calibration going on, only zero-point. An error with the zero-point calibration would of course cause drift... So I'm guessing that it's either the zero-point calibration that needs to be fixed or a deadband or other filtering function that needs to be applied.

So, the question is how we move forward. Initially I'll try my wiimote at home and try to see if there is something obvious wrong with the calibration. I'm an experienced programmer, but I have a very basic knowledge of sensors and their characteristics. So the implementation might be very stupid :D.

Realistically I'll have to wait until at least saturday to try it out though, but if anyone else wants a go the relevant code is in the file FreePIE.Core.Plugins/Wiimote/WiimoteCalibration.cs between lines 88-99.
Hi, CyberRascal, I understand a lot of what we have here in FreePIE is due to you, so first of all, great work! I am nowhere near experienced in programming, but I had done some fair bit of scripting over the past 2 decades as a hobby first with the Adobe Atmosphere and then with GlovePIE (I actually regard my IR mouse laser gun script as the most flexible and natural implementation for FPSs in front of a static monitor/TV that I saw so far :oops:). I have tried many many wii shooters, PS3 sharpshooter games and even got the MAG II, but they are not a solution for OR-type of setup and I don't see myself playing FPSs with OR without a solid motion-control implementation of a gun, so there I am trying to make the wiimote that gun. Since I had originally posted to another thread, I will copy here some of my links to youtube videos with experiments and the comments on those:
-----------------------------------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------------------------------
On your question on GlovePIE and deadband - certainly not in the script. I just put the exact 2-liner in the box and I see no drift when the wiimote is static. The GlovePIE documentation mentions that those are the values obtained directly from the gyro, but there is no guarantee that there is nothing happening behind the scenes. On the FreePIE drift - it is small per frame, but persistent over time and upward-biased in the normal fusion, while with Mahony it only deviates slightly and then corrects itself when the wiimote is static, but does unexplainable over-corrections once you start moving the wiimote (there is a youtube video on that too above).
I experimented also with the GlovePIE's wiimote.gz, rather, Delta(aSin(wiimote.gz)) - see the scripts linked, and there are some random jumps, but I think those can be easily filtered out once we observe a proper log, since they are very short, but significant, random and unbiased. I am not aware whether gz in GlovePIE is filtered or not. In any event, I had the idea of using it after filtering out this noise as a control/dynamic recalibration for the gyro data. I have some statistics background from my almost-forgotten studies, so I think you can use a Kalman filter in that case, but that would take a looooot of refreshment and thinking time how to apply it in this scenario. After all, I started working with the gyro/accelerometer data of the wiimote only 2 weeks ago and I have never programmed in Python.
On deadband: I think it might be a solution for a final-product script if you only have to hide small deviations with normal distribution. However, in a debugging phase (where we are now), it does more harm than help. It cannot be a solution in a final product though when outside the deadband there is still a biased drift.
NeoTokyo_Nori
Cross Eyed!
Posts: 144
Joined: Wed Jul 16, 2014 10:29 am
Location: Tokyo, Japan

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by NeoTokyo_Nori »

Hi konstantin_lozev

Sorry to jump in, but I hope that we can make a good gun controller in freepie too.
I was using wiimote and lednergs script in glovepie before also but gave up on it.
I am working on an arduino IMU solution at the moment.

Clearly drift is a big issue, and you seem to know a fair bit.
I need to ask you, since I am having trouble following this thread.

1) Are there any existing IMU solutions that you are aware of,
that has completely solved the drift problem and has near perfect tracking?
2 And is that what you are hoping to achieve with freepie?
3) Do you think that it can be done without IR, or is that essential?

:)
konstantin_lozev
Cross Eyed!
Posts: 192
Joined: Fri Jul 04, 2014 1:43 am

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by konstantin_lozev »

NeoTokyo_Nori wrote:Hi konstantin_lozev

Sorry to jump in, but I hope that we can make a good gun controller in freepie too.
I was using wiimote and lednergs script in glovepie before also but gave up on it.
I am working on an arduino IMU solution at the moment.

Clearly drift is a big issue, and you seem to know a fair bit.
I need to ask you, since I am having trouble following this thread.

1) Are there any existing IMU solutions that you are aware of,
that has completely solved the drift problem and has near perfect tracking?
2 And is that what you are hoping to achieve with freepie?
3) Do you think that it can be done without IR, or is that essential?

:)
Hi Neo, I am certainly a noob here, but I am still ready to experiment and I like the community here too.
on 1) As I said I have tried wii, ps3 move, mag II. I got an airmouse too and I have to say that the only driftless experience I had is Whitmore+IR bar. I still admire the driftless positioning in the Wii sports resort when you parachute down and your mii follows your wiimote. For me driftless means I play > 10 min and my gun still points at the centre where it started from. It does not depend on the scaling/speed you always have to end where you started. I checked recently OR DK1 and although the screen was not good, tracking was completely driftless. Who knows, they may also be facing drift, if they decided to go with the camera in the Crystal cove
On 2) Yes, I also have in mind a script that mixes dynamically Durovis dive/android and gun giving priority to the dive when the gun is on your hip and to the Whitmore/mii when aiming down the sights.
On 3) I hope so, since the IR bar is not a solution for cases when you are turning around with the OR/Durivis strapped to your head.
konstantin_lozev
Cross Eyed!
Posts: 192
Joined: Fri Jul 04, 2014 1:43 am

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by konstantin_lozev »

I made 2 tries per GlovePIE/FreePIE script and put those on youtube. The first FreePIE run was not that bad until 3 min, but then started drifting seriously upwards. The second try was worse.
The GlovePIE tries were both much more stable and no noticeable vertical drift unless the wiimote is moved very quickly, but outside that scenario, not very bad.

FreePIE pitch_left try 1 http://youtu.be/lbXZEmsH1G0
FreePIE pitch_left try 2 http://youtu.be/CdTZjS2a35c

GlovePIE pitchspeed/yawspeed try 1 http://youtu.be/U9RHK1PJbek
GlovePIE pitchspeed/yawspeed try 2 http://youtu.be/1ZatXLe2HBE
NeoTokyo_Nori
Cross Eyed!
Posts: 144
Joined: Wed Jul 16, 2014 10:29 am
Location: Tokyo, Japan

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by NeoTokyo_Nori »

konstantin_lozev wrote: the only driftless experience I had is Whitmore+IR bar. I still admire the driftless positioning in the Wii sports resort when you parachute down and your mii follows your wiimote.

I checked recently OR DK1 and although the screen was not good, tracking was completely driftless.

the IR bar is not a solution for cases when you are turning around with the OR/Durivis strapped to your head.
I was having drift problems when using wiimote with glovepie (without IR ), but I could not tell if it was a hardware issue or a software issue. When I did try it with IR, I guess it was tracking better, but I was changing so many things around, that I could not be sure.

I do think that OVR has solved the drift issue quite well, even without the camera, so I hope that "usable level drift-less tracking" is possible too on freepie plus Razor IMU or wiimote.
I can help with the coding and debugging side of things, once I have my other VR gear things sorted out!.

Regarding 360 degrees tracking,
I would have thought IR dots on the back of the head would help quite a lot.
I dont know if there is a technical reason that it cannot be done,
or if OVR decided to go without it for a strictly "seated experience".

My wish would be to have google tango hardware on the front face,
so it can do SLAM type stuff, and check the room against a known pre-captured layout of the room.
that way it wouldn`t matter where you are facing - the tracking should be bang on everytime! In theory.

Outward looking cams would have so many applications, for hand capturing, and seeing the outside view, etc. I`m sure this is all being worked on now, and am salivating at the possiblities :lol:
Aryl
One Eyed Hopeful
Posts: 1
Joined: Sat Aug 09, 2014 7:33 pm

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by Aryl »

Just found freepie after a lot of searching since glovepie seems to be completely dead.

I never had drift problems in glovepie, I have yet to find my bluetooth dongle to try freepie.

The only problem I had in glovepie was attempting to use the nunchuck and motion plus would usually end in some error message mentioning something about wii drums, or it wouldn't calibrate, or the nunchuck wouldn't work. Constantly restarting the script would make it work, eventually. When it did work, it was flawless. I modified some script I found on the forums for near 1:1 ratio using only the motion plus (From what I read it was a problem with polling either the nunchuck or motion plus at 2ms exactly?).

I still have the same wiimote so I'll try out freepie and try fixing the drift, but it sounds like it may be a problem with freepie (Though probably simple to fix). The wiimote is of the older type with external motion plus

This seems to be the only remaining option for turning a wiimote into a pc gamepad so thanks for keeping this alive guys. Can't wait to play Perfect Dark on a 64 emulator with a wiimote again! I've got some plans involving dissecting a wiimote and a custom case for FPS games.
konstantin_lozev
Cross Eyed!
Posts: 192
Joined: Fri Jul 04, 2014 1:43 am

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by konstantin_lozev »

Aryl wrote:Just found freepie after a lot of searching since glovepie seems to be completely dead.

I never had drift problems in glovepie, I have yet to find my bluetooth dongle to try freepie.

The only problem I had in glovepie was attempting to use the nunchuck and motion plus would usually end in some error message mentioning something about wii drums, or it wouldn't calibrate, or the nunchuck wouldn't work. Constantly restarting the script would make it work, eventually. When it did work, it was flawless. I modified some script I found on the forums for near 1:1 ratio using only the motion plus (From what I read it was a problem with polling either the nunchuck or motion plus at 2ms exactly?).

I still have the same wiimote so I'll try out freepie and try fixing the drift, but it sounds like it may be a problem with freepie (Though probably simple to fix). The wiimote is of the older type with external motion plus

This seems to be the only remaining option for turning a wiimote into a pc gamepad so thanks for keeping this alive guys. Can't wait to play Perfect Dark on a 64 emulator with a wiimote again! I've got some plans involving dissecting a wiimote and a custom case for FPS games.
Hi Aryl, in my videos above the GlovePie 2-line script does not drift when the wiimote is static, but only when you change directions fast. I thought about it and I think this is an inherent hardware issue. since the wrist movements are much more complicated than a pitch/yaw/roll and you sometimes compensate with some moving up/down instead of swinging. It is also very natural for the gyro to lose track of the speed when it changes very quickly. Maybe increasing the refresh rate can help a bit...
I think the real long-term solution for having 100% driftless tracking is to control the gyro with the gz readings of the accelerometer. I wrote above a simple script that converts gz into pitch, based on the fact that the gravity readings transfer from gy to gz in in an aSin function. Accelerometers are jittery and I faced nasty micro jumps. Nevertheless, I studied those closely by stacking debug readings in csv form and found that those are inadvertently +/-10 jumps from 0 for up to 4 frames. I am planning to write e custom filter for those, in order to use the filtered results later in controlling the pitch gyro readings.
konstantin_lozev
Cross Eyed!
Posts: 192
Joined: Fri Jul 04, 2014 1:43 am

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by konstantin_lozev »

Neo, on the 360 degrees, I think measuring yaw precisely necessitates at least 2 blobs to be tracked lying on a plane (preferably a straight one). This is no science, which I totally lack on this issue, but rather confirmed from experience with wiimote vs ps3 move for example.
And in any event, even if you managed to get it right for the back of your head, this will not be an option for your wiimote gun. I guess you would have to spray leds around you, but I think even GlovePie would not track the led blobs correctly unless they are on a plane without significant tweaking
CyberRascal
Two Eyed Hopeful
Posts: 74
Joined: Fri Sep 21, 2012 4:46 am

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberRascal »

Hi everyone!

I've done some work on the motionplus calibration now. Basically I use the accumulated values during the calibration period to work out an appropriate deadband for the motionplus. From what I can see, there is much lower drift when wiimote is stable but I'm not sure if it will be usable anyway. Please, try the release of freepie in this post out and tell me what the result is!

Also, thanks for the tons of information in previous posts. And for the vote of confidence! :)

Hope the release works!
You do not have the required permissions to view the files attached to this post.
konstantin_lozev
Cross Eyed!
Posts: 192
Joined: Fri Jul 04, 2014 1:43 am

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by konstantin_lozev »

Hi CyberRascal, I am on vacation now but will check it out on my return. I had tried the same thing with GlovePIE (it should be in the scripts that I posted earlier) and it is indeed a very flexible approach since I guess the drift is different for each wiimote.
I've had some ideas about correcting the pitch gyro drift with the accelerometer data using aSin function, but I will first have to clear the accelerometer data of those nasty micro jumps.
I am working on that with GlovePIE and when I am ready I will post the results which we can then try and replicate in FreePIE.
For that I think we will need exposure and logging of raw values from both gyros and accelerometers. I am not sure which are those values in FreePIE, so if you can tell me and also let me know how to do logging of the watch data for those raw values, it would be great.
NeoTokyo_Nori
Cross Eyed!
Posts: 144
Joined: Wed Jul 16, 2014 10:29 am
Location: Tokyo, Japan

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by NeoTokyo_Nori »

Hello CR :!:

I have a job deadline today, but will look into it, when done :!:
NeoTokyo_Nori
Cross Eyed!
Posts: 144
Joined: Wed Jul 16, 2014 10:29 am
Location: Tokyo, Japan

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by NeoTokyo_Nori »

CyberRascal wrote:Hi everyone!
I've done some work on the motionplus calibration now. Basically I use the accumulated values during the calibration period to work out an appropriate deadband for the motionplus. From what I can see, there is much lower drift when wiimote is stable but I'm not sure if it will be usable anyway. Please, try the release of freepie in this post out and tell me what the result is!
Hello CR,
Good to see you are back in the game :!:

The last time I was working on freepie and wiimote, I didnt have much luck getting things to work,
as you can see from my previous posts on this topic. So could you briefly respond to the questions I had back then? That way I will know if it is me, or a limitation of the current version... :roll:

And can you explain what you mean by "From what I can see, there is much lower drift when wiimote is stable but I'm not sure if it will be usable anyway." Since that doesnt sound very promising :shock:
CyberRascal
Two Eyed Hopeful
Posts: 74
Joined: Fri Sep 21, 2012 4:46 am

Re: Full (yeah, well) Wiimote Support in FreePIE

Post by CyberRascal »

konstantin_lozev:

Thanks for being enthusiastic! Always more fun to work with something that someone wants to use :)

Right now I calculate deadband and scale values according to the deadband cutoff, this seems to make the motionplus a lot calmer without actually being sluggish / unresponsive, so it might be the way to go. Maybe I will rewrite the wiimote API so that we have motionplus.pitch etc and also motionplus.raw.pitch or similar. I will just have to choose the appropriate "rawness" of the raw values... Wiimote motionplus gives away values in the 4000-16000 unsigned integer range, and I calculate the zero-point offset when wiimote is stable. The gain is fixed, however.

Tell me what type of values you want and I will make sure you have them available. Logging should be easy enough using diagnostics.debug(value) for example.

Have a nice vacation!

NeoTokyo_Nori:

I looked through the topic but couldn't find any questions at first glance, but maybe I am blind! Could you post them again?

Regarding the quote you aksed about: When keeping the wiimote still, there is not that much drift. I am not sure what to do about drift when in motion however. I'm not sure how good tracking we can get with the gyro sensor only. I am not an expert on IMUs or AHRS so I'm not sure if we can use the IR sensor or acc sensor to recalibrate automatically.
Post Reply

Return to “FreePIE”