Re: Full (yeah, well) Wiimote Support in FreePIE
Posted: Sun Jun 01, 2014 12:26 pm
We are workign on reaslign the next version soon
The Number One Resource For Stereoscopic 3D Excitement!
https://www.mtbs3d.com/phpbb/
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)
Code: Select all
wiimote[0].enable(WiimoteCapabilities.MotionPlus | WiimoteCapabilities.Extension)
Code: Select all
wiimote[0].enable(WiimoteCapabilities.Extension)
wiimote[0].enable(WiimoteCapabilities.MotionPlus)
Code: Select all
if starting:
system.setThreadTiming(TimingTypes.HighresSystemTimer)
system.threadExecutionInterval = 2
Code: Select all
diagnostics.watch(wiimote[0].acceleration.z)
diagnostics.watch(wiimote[1].acceleration.z)
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....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
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 :SCyberVillain 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
Hehe, I took that alias in the days of BBS's and modems When my younger brother needed a online aliases I suggested that name for himNeoTokyo_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
I think its better to post here insteadkonstantin_lozev wrote: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: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
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
konstantin_lozev wrote: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)CyberVillain wrote:ahrs will give you fused values.
wiimote[0].motionplus will give you gyro data (radians per second)
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.
Code: Select all
mouse.deltaX = wiimote[0].motionplus.yaw_down
mouse.deltaY = wiimote[0].motionplus.pitch_left
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:CyberVillain wrote:konstantin_lozev wrote: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)CyberVillain wrote:ahrs will give you fused values.
wiimote[0].motionplus will give you gyro data (radians per second)
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
I do not undestand why yaw_down is named like it is and pitch_left You might need to add a multiplier too likeCode: Select all
mouse.deltaX = wiimote[0].motionplus.yaw_down mouse.deltaY = wiimote[0].motionplus.pitch_left
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 ). 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: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
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 .
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 Neo, I am certainly a noob here, but I am still ready to experiment and I like the community here too.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?
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.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.
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...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.
Hello CR,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!