Wiimote Scripting - Control and Receive Data from Multiple Wiimotes - Updated:12/14/11 - A Wireless Voltage Meter Example

[RedSpawn]

it's looking good:

- buzzer works

- ir shows some data. seems ok, reacts on x/y the way i suspected.

button handling needs some work, if you enable motion- or ir-tracking you get flooded with events.

[Maffe811]

i don't know if it's ok to post a link to the offer here?

Yes, i think soo.

But post! I need a liiiiink!!!

[RedSpawn]

hope i don't get banned...

found a new offer:

wiimote + Nunchuck in black for $6.89!!!!

http://cgi.ebay.com/NEW-Remote-and-Nunchuck-Controller-Nintendo-WII-BLK-/280699132263

or wiimote + nunchuck + motionplus in red for $6.89!!!!

http://cgi.ebay.com/RED-Nunchuck-Controller-and-Remote-Motion-Plus-Wii-/280699140922

WIRELESS sensor bar $3.50

http://cgi.ebay.com/Wireless-Remote-Sensor-Bar-for-Nintendo-Wii-Controller-/300541856452

i think motion plus is not supported in the wiiuse-library!

btw. someone know what the motionplus is for?

just same data but better, or something more?

Edited June 20, 2011 by RedSpawn

[Maffe811]

You know what the sensor bar is right?

Its two IR-LEDs with space between em...

Make your own for a buck...

Edit:

btw. someone know what the motionplus is for?

just same data but better, or something more?

The Wii MotionPlus (Wiiモーションプラス?) is an expansion device for the Wii Remote video game controller for the Wii that allows it to more accurately capture complex motion. According to Nintendo, the sensor in the device supplements the accelerometer and Sensor Bar capabilities of the Wii Remote to enable actions to be rendered identically on the screen in real time.

Source: http://en.wikipedia.org/wiki/Wii_MotionPlus Edited June 20, 2011 by Maffe811

[RedSpawn]

my question was not clear:

i know what the motionplus IS, but i don't know what this results in....

is the wiimote just getting more accurate motion-detection or do you get some additional information from it? like translation and not just acceleration?

i guess it's the later since wiiuse.dll is not supporting it

(and therefor it's useless with Beege's solution)

as for the sensorbar:

if i get a battery holder and a switch from my local electronics shop i pay more than $3.50

[RedSpawn]

Beege:

what development-tools are you using for your AutoItPort?

is it possible to get your source/project files?

i managed to build the wiiuse example in visual studio express 2010, but it's not (yet) working properly.

[Beege]

Beege:

what development-tools are you using for your AutoItPort?

is it possible to get your source/project files?

i managed to build the wiiuse example in visual studio express 2010, but it's not (yet) working properly.

Im using VC++ 2010 express. What do you mean it compiled but didnt work? how was it acting? I included my source in this last update. Its not the best code since I normally dont write in c but maybe someone can point out better code to be using.

Be sure to check out the update and check for changes because there are quite a few and your scripts reflex those changes..

[Beege]

Update: Rewrote Example to include Looks so much cleaner now

[martin]

Update: Rewrote Example to include Looks so much cleaner now

Beege,

why did you use an exe to interface between the dll and the UDF rather than call the functions in the dll from your UDF, or does the exe do more than act as an interface?

Do you have any way to automaticall pair the Wii controller with the PC? This is a stumbling block for me. I know nearly nothing about Wii. Can they receive information to control things, like LEDs say, as well as transmiting data on the states of sensors and buttons?

[Beege]

Beege,

why did you use an exe to interface between the dll and the UDF rather than call the functions in the dll from your UDF, or does the exe do more than act as an interface?

Martin sorry so late getting back to you. I tried for a while to get the callbacks working striaght from Autoit but never had any luck.

Do you have any way to automaticall pair the Wii controller with the PC? This is a stumbling block for me. I know nearly nothing about Wii. Can they receive information to control things, like LEDs say, as well as transmiting data on the states of sensors and buttons?

At this time no I dont know of anyway to automattically pair the Wiimote with the pc. Each time I start playing around with it I have go into "Bluetooth Devices" and pair the PC to the wiimote manually. But from there it should stay connected until you power down the wiimote. Are you able to get it paired at all? The demo I have up now does everything your asking about with LED's, buttons, and sensor information. Do you have a wiimote to mess around with?

Edited July 7, 2011 by Beege

[martin]

Martin sorry so late getting back to you. I tried for a while to get the callbacks working striaght from Autoit but never had any luck.

At this time no I dont know of anyway to automattically pair the Wiimote with the pc. Each time I start playing around with it I have go into "Bluetooth Devices" and pair the PC to the wiimote manually. But from there it should stay connected until you power down the wiimote. Are you able to get it paired at all? The demo I have up now does everything does your asking about with LED's, buttons, and sensor information. Do you have a wiimote to mess around with?

Thanks for your answers.

I don't have a wiimote to mess around with yet but that isn't a problem because if I decide it's worth investigating it's easy to buy one.

I'm not clear about the 2-way infprmation bit. I understand that the PC gets information from the wiimote and can work out the states of switches and sensors, but I don't understand the bit about L:EDs; is there information or commands that can be sent to the wiimote to affect things like, say, turn an led on or off on th ewiimote? If so then I am more interested and I would certainly buy something to play with because I could use a pc to control something over bluetooth. I read that user profiles for some games can be sent to the wiimote and stored in an eeprom so I imagine that there is some 2-way communication going on, but I haven't been able to find any references to a wiimote being used as a remote I/O device for a PC, it all seems to be related to understanding the information which comes from the wiimote and nothing to do with sending it information.

[Beege]

Thanks for your answers.

I don't have a wiimote to mess around with yet but that isn't a problem because if I decide it's worth investigating it's easy to buy one.

I'm not clear about the 2-way infprmation bit. I understand that the PC gets information from the wiimote and can work out the states of switches and sensors, but I don't understand the bit about L:EDs; is there information or commands that can be sent to the wiimote to affect things like, say, turn an led on or off on th ewiimote? If so then I am more interested and I would certainly buy something to play with because I could use a pc to control something over bluetooth. I read that user profiles for some games can be sent to the wiimote and stored in an eeprom so I imagine that there is some 2-way communication going on, but I haven't been able to find any references to a wiimote being used as a remote I/O device for a PC, it all seems to be related to understanding the information which comes from the wiimote and nothing to do with sending it information.

Yes the wiimote defiantly has commands/data being written/sent to the wiimote. If you look HERE you can view most of the library main functions. The library has lots of wrapped up functions like "wiiuse_set_leds()" and ""wiiuse_set_rumble()" that use more core functions like "wiiuse_send()" and "wiiuse_write_data()". Those sort of "core" functions I havent played around with since most of the functionality I was looking for was already wrapped up.

I do hope you get one martin. Its been a lot of fun for not much money at all and there's still a lot more that could be done. The lack of interest from the community kinda lowered my drive a little but i would be happy to start back up.

[martin]

Yes the wiimote defiantly has commands/data being written/sent to the wiimote. If you look HERE you can view most of the library main functions. The library has lots of wrapped up functions like "wiiuse_set_leds()" and ""wiiuse_set_rumble()" that use more core functions like "wiiuse_send()" and "wiiuse_write_data()". Those sort of "core" functions I havent played around with since most of the functionality I was looking for was already wrapped up.

I do hope you get one martin. Its been a lot of fun for not much money at all and there's still a lot more that could be done. The lack of interest from the community kinda lowered my drive a little but i would be happy to start back up.

OK, I've ordered one.

[Beege]

OK, I've ordered one.

Awsome! Im gonna start playing around again. One thing I never implemented was unique ids for the wiimotes. This way we can connect up to 4 wiimotes

[Maffe811]

I WANT ONE SOOOOO BAD!!!!

But I just spent my last buck on ram and a grapichs card.

I'll get paid in the end of the month or something and then I'll order one!

Q: Why only 4 wiimotes ? Isn't there a way you cant trick the software into thinking there is only 1 or something and then you can add ∞(infinite) controllers!

[martin]

Awsome! Im gonna start playing around again. One thing I never implemented was unique ids for the wiimotes. This way we can connect up to 4 wiimotes

My wiimote arrived and I have some problems. Never-the-less I am impressed so far.

If I turn rumble on it won't always turn off and I have to restart the program.

The motion tracking sometimes works and sometimes not. If it isn't working when I start your Wiimote Example program then it doesn't start working again untill I stop the program and start it again. When it won't work checking and unchecking the Enable motion Tracking has no effect.

The leds don't match the actual states on startup, so I think LED() needs to be called initially. Similarly, enable motion tracking is not checked to start with but positions are displayed. It requires the box to be checked then unchecked to stop the display of postion.

For some reason, after running the program a few times, all the labels have changed to have a dark grey background !! So I changed $g_iBGColor from Default to 0xffffffff;

The roll on mine gets stuck at about 83 degrees untill past 93 degrees and it will suddendly start changing with angle again. If I hold it to about 90 it will first be stuck on 83 but if I give it a tap it changes to a more beleivable value. I could just turn the rumble on briefly every so often instead of tapping it but the problem is that usually I can't turn the rumble off. I assume that I have a faulty wiimote.

There is nothing on your example to show the operation of the HOME button. Can that be done?

I think you should not stop other applications detecting Shift o, so the _hkOrient() function should be something like this

Func _hkOrient()
    If WinGetHandle(WinActive("")) <> $Form1 Then
        HotKeySet("+o")
        Send("+o")
        HotKeySet('+o', '_hkOrient')
    Else
        _Wii_SetOrientThreshold('0.1')
    EndIf
EndFunc   ;==>_hkOrient

Same idea for Func _hkvres(). Or use accelerator keys.

I also bought a Nunchuck joystick and I would really like to be able to read the xy values of the joystick. Do you know how to do that? There are also buttons 'C' and 'Z' which would be nice to detect.

I read about how the IR tracking works. It's really amazing how it's done and what can be done with it. Have you seen this by Johnny Lee?

Can you get the xy for IR dots 3 and 4?

I think I see why the rumble can't be turned off. Once the rumble starts all the values for position tracking change very fast and the gui spends all its time updating the labels and even closing the script can be difficult.. If I uncheck the rumble checkbox after turning the rumble on and just wait then the rumble is truned off after maybe 1 or 2 seconds.

EDIT: I think the problem with the rumble is that the timers are set too fast. 1ms cycle time is suicidal and there is no time for anything else to be done and in fact not even enough time for the callback functions to complete if a lot of labels need updating.

I changed mine to 50mS and commented out the second timer which seemed redundant, and now the rumble turns on and off ok and the update is still way to fast for me to see any difference. However, I think some different approach is needed because when the rumble is on the _WiiCheckMsg function can take 160mS to complete on my laptop. So I tried commenting out th etimers completely and instead I added a line _WiiCheckMsgB() to the main while loop in the example and that gave me the best performance.

Why did you use StdIn and not use messages?

Edited July 9, 2011 by martin

[Beege]

My wiimote arrived and I have some problems. Never-the-less I am impressed so far.

--> Awsome. Happy to hear its at least its working. I can work with bugs

If I turn rumble on it won't always turn off and I have to restart the program.

The motion tracking sometimes works and sometimes not. If it isn't working when I start your Wiimote Example program then it doesn't start working again untill I stop the program and start it again. When it won't work checking and unchecking the Enable motion Tracking has no effect.

-->This could be fixed in the update. Ill look into it

The leds don't match the actual states on startup, so I think LED() needs to be called initially. Similarly, enable motion tracking is not checked to start with but positions are displayed. It requires the box to be checked then unchecked to stop the display of postion.

-->that was me on the exe side. I had it rumble for a second and set the LEDs to the wiimote id number. Thats been removed. All wiimote LEDs start off now.

For some reason, after running the program a few times, all the labels have changed to have a dark grey background !! So I changed $g_iBGColor from Default to 0xffffffff;

--> that was a bug in my flicker free labels UDF. Fixed

The roll on mine gets stuck at about 83 degrees untill past 93 degrees and it will suddendly start changing with angle again. If I hold it to about 90 it will first be stuck on 83 but if I give it a tap it changes to a more beleivable value. I could just turn the rumble on briefly every so often instead of tapping it but the problem is that usually I can't turn the rumble off. I assume that I have a faulty wiimote.

----> yes I will definatly put glitches like that on the hardware. The accelerometers cant be the same and can sometimes sort of "stick" depending on the amount of force. If you ever played the wii you might find you play better with a certian wiimote over another. have 3 wiimotes right now and two of them dont recoginze size change in IR Dots. The number always stays at 2.

There is nothing on your example to show the operation of the HOME button. Can that be done?

---> Fixed. But just realized I didnt add it to example. I plan on working on the main example and some other examples I got this week.

I think you should not stop other applications detecting Shift o, so the _hkOrient() function should be something like this

--> All the Hotkey functions in the example were just quick ways of testing the functions as I wrote them in. those will all be removed.

I also bought a Nunchuck joystick and I would really like to be able to read the xy values of the joystick. Do you know how to do that? There are also buttons 'C' and 'Z' which would be nice to detect.

-->Yes nunchuck will be added. I need to one first. Same with all the other capable devices. (Classic controller, Guitar Hero)

I read about how the IR tracking works. It's really amazing how it's done and what can be done with it. Have you seen this by Johnny Lee?

--> Oh god YES! I remember the first time seeing it. It blew me away! All his projects did that to me. He got invited to to show if off at TED which I thought was even cooler. Here his page if you havnt seen his other projects. His Automatic Projector Calibration was another of my favorites.

Can you get the xy for IR dots 3 and 4?

-->They should be getting sent already, just didnt write it in to the example. I havent actually tried more than 2 yet. Are they not working or just asking?

I think I see why the rumble can't be turned off. Once the rumble starts all the values for position tracking change very fast and the gui spends all its time updating the labels and even closing the script can be difficult.. If I uncheck the rumble checkbox after turning the rumble on and just wait then the rumble is truned off after maybe 1 or 2 seconds.

--> Im stumped on this one. the way I wrote it all msgs should eventually get processed even if is real busy. It just might be delayed. Plz check the new version before I look deeper

EDIT: I think the problem with the rumble is that the timers are set too fast. 1ms cycle time is suicidal and there is no time for anything else to be done and in fact not even enough time for the callback functions to complete if a lot of labels need updating.

I changed mine to 50mS and commented out the second timer which seemed redundant, and now the rumble turns on and off ok and the update is still way to fast for me to see any difference. However, I think some different approach is needed because when the rumble is on the _WiiCheckMsg function can take 160mS to complete on my laptop. So I tried commenting out th etimers completely and instead I added a line _WiiCheckMsgB() to the main while loop in the example and that gave me the best performance.

--> crazy enough I added _wiicheckmsg to public functions and told user to do the same (add to main loop) before reading this. only I did that so that it would check msgs often. Im not sure I agree with your thought on the timer because though its set to 1ms, it does actually get executed that much. Running the test below I only get about 60 calls/sec from the callback timer . The second callback was a test and should not have been left in the udf. Ill look into what you said about rumble being on. Im guessing motion sensing was also on? If it is on at the same time then that could generate a lot of data since the rumble is causing lots of motion. Maybe I can do something to were if rumble and motion sensing are one, it drops some of the data since its all just random vibration values.

$hCB = DllCallbackRegister('_cb', 'none', '')
$g_aCB = DllCall('user32.dll', 'UINT_PTR', 'SetTimer', 'hwnd', 0, 'UINT_PTR', 0, 'UINT', 1, 'ptr', DllCallbackGetPtr($hCB))

$gui = GUICreate('test')
GUISetState()

Do
Until GUIGetMsg() = -3

Func _cb()
    Static $time = TimerInit()
    Static $call_count = 0

    $call_count += 1
    If TimerDiff($time) > 1000 Then
        ConsoleWrite('$call_count = ' & $call_count & @CRLF)
        $time = TimerInit()
        $call_count = 0
    EndIf

EndFunc

Why did you use StdIn and not use messages?

-->What kind of messages? I told myself using a pipe would be faster. Is that wrong? Plus Im still very much not used to using writing in c.

Edited July 10, 2011 by Beege

[Beege]

EDIT: I think the problem with the rumble is that the timers are set too fast. 1ms cycle time is suicidal and there is no time for anything else to be done and in fact not even enough time for the callback functions to complete if a lot of labels need updating.

I changed mine to 50mS and commented out the second timer which seemed redundant, and now the rumble turns on and off ok and the update is still way to fast for me to see any difference. However, I think some different approach is needed because when the rumble is on the _WiiCheckMsg function can take 160mS to complete on my laptop. So I tried commenting out th etimers completely and instead I added a line _WiiCheckMsgB() to the main while loop in the example and that gave me the best performance.

Ok I read up on SetTimer some more and it turns out the minimum timeout is 16ms giving 1000/16 = 62.5 calls/sec. Which is just about what im getting.

From MSDN: If uElapse is less than USER_TIMER_MINIMUM (0x0000000A), the timeout is set to USER_TIMER_MINIMUM.

When you changed the callback to only check for msg every 50ms (20 updates/sec), It didnt effect it because you also added _Wiicheckmsg() to you main loop causeing _Wiicheckmsg() to get called around 200/sec. At least thats on my pc.

Edited July 10, 2011 by Beege

[martin]

Thanks for your comprehensive replies Beege.

In no particular order:

I think your code

$hCB = DllCallbackRegister('_cb', 'none', '')
$g_aCB = DllCall('user32.dll', 'UINT_PTR', 'SetTimer', 'hwnd', 0, 'UINT_PTR', 0, 'UINT', 1, 'ptr', DllCallbackGetPtr($hCB))

$gui = GUICreate('test')
GUISetState()

Do
Until GUIGetMsg() = -3

Func _cb()
    Static $time = TimerInit()
    Static $call_count = 0

    $call_count += 1
    If TimerDiff($time) > 1000 Then
        ConsoleWrite('$call_count = ' & $call_count & @CRLF)
        $time = TimerInit()
        $call_count = 0
    EndIf

EndFunc

would be simpler as

AdlibRegister("_cb",1000)

Func _cb() 
    ConsoleWrite('$call_count = ' & $call_count & &CRLF)
EndFunc

By "messages" I mean Windows Messages. So to get information Autoitport could simply send the AutoIt script a message. It would be much faster I think and neater IMO. You could use WM_COPYDATA and send a message with info every 50 mS or whatever instead of writing to StdOut.. It would require very little change to your c program and very little change to your _WiiCheckMsg function. You would need to say

GuiRegisterMsg($WM_COPYDATA,"_WiiCheckMsg")

instead of using a timer.

I didn't have the timer and add _WiiCheckMsg() to the main while loop, I commented out the timer. On my laptop _WiiCheckMsg() can take up to 160mS.

I didn't realize that the information for IR dots 3 and 4 was already there.

The newer version works fine, but LED1 is still on at startup but not checked on the gui.

I look forward to more updates.

I had lots of messages in the console window like this

[WARNING] Packet ignored. This may indicate a problem (timeout is 10 ms).

[WARNING] Received data packet when no request was made.

[WARNING] Packet ignored. This may indicate a problem (timeout is 10 ms).

Where do those messages come from?

I thought that those messages were because I had 2 instances running but I tried 2 again and didn't see those warnings.

Is it possible to read the state of the leds? The wiiuse site seems to be down this weekend so I can't get any information from it.

Edited July 10, 2011 by martin

[Beege]

Thanks for your comprehensive replies Beege.

-->No thank you for the detailed descriptions. You dont always get that so I appreciate it

In no particular order:

I think your code

$hCB = DllCallbackRegister('_cb', 'none', '')
$g_aCB = DllCall('user32.dll', 'UINT_PTR', 'SetTimer', 'hwnd', 0, 'UINT_PTR', 0, 'UINT', 1, 'ptr', DllCallbackGetPtr($hCB))

$gui = GUICreate('test')
GUISetState()

Do
Until GUIGetMsg() = -3

Func _cb()
    Static $time = TimerInit()
    Static $call_count = 0

    $call_count += 1
    If TimerDiff($time) > 1000 Then
        ConsoleWrite('$call_count = ' & $call_count & @CRLF)
        $time = TimerInit()
        $call_count = 0
    EndIf

EndFunc

--> that was just an example to defend my suicidal code! I really just wanted to point out how it only gets called every 16ms even though I set it to 1ms.

would be simpler as

AdlibRegister("_cb",1000)

Func _cb() 
    ConsoleWrite('$call_count = ' & $call_count & &CRLF)
EndFunc

--> I agree using Adlibregister is much simpler, but I worry about how it pauses the main script during execution. I wasnt sure if that could cause problems in the users script.

By "messages" I mean Windows Messages. So to get information Autoitport could simply send the AutoIt script a message. It would be much faster I think and neater IMO. You could use WM_COPYDATA and send a message with info every 50 mS or whatever instead of writing to StdOut.. It would require very little change to your c program and very little change to your _WiiCheckMsg function. You would need to say

GuiRegisterMsg($WM_COPYDATA,"_WiiCheckMsg")

instead of using a timer.

-->I am very willing to try any ideas or different stragies you have, but will definatly need help on the c app part. I know how to do it on the autoit side, but not in c.

I didn't have the timer and add _WiiCheckMsg() to the main while loop, I commented out the timer. On my laptop _WiiCheckMsg() can take up to 160mS.

--> sorry I read that wrong. Not sure why it would be taking that long.. Im gonna try and set up some routines for checking perfomance. Im wonder what call its getting hung up at.

I didn't realize that the information for IR dots 3 and 4 was already there.

--> I just checked this and they are not there. They should because the code is there. Something just wrong in the wiiuse lib. In the example that comes with the lib, the same thing happens so this might be out of my hands.

The newer version works fine, but LED1 is still on at startup but not checked on the gui.

--> Make sure you have deleted the previous DLL and autoitport.exe. The udf will only extract the binarys if they are missing from scriptdir. Otherwise it will use the one in the directory.

I look forward to more updates.

--> me too!

I had lots of messages in the console window like this

[WARNING] Packet ignored. This may indicate a problem (timeout is 10 ms).

[WARNING] Received data packet when no request was made.

[WARNING] Packet ignored. This may indicate a problem (timeout is 10 ms).

Where do those messages come from?

I thought that those messages were because I had 2 instances running but I tried 2 again and didn't see those warnings.

-->They are coming from functions in the Wiiuse Lib but im suprised you are seeing them. Are you looking at the data in _Wii_checkmsg(), or maybe uncomment some of the conslewrites I have in there to see?

Is it possible to read the state of the leds?

--> did you see _Wii_GetLEDStatus()?

The wiiuse site seems to be down this weekend so I can't get any information from it.

--> no its not down, just for some reason the main page http://www.wiiuse.net doesn't work. Try going to http://www.wiiuse.net/docs/