WiiLi.org

[andy753421]

(again posted on the wiki)

* Linear force data can be logged using a SET_REPORT HID request on Output channel 12. The first parameter is a force feedback parameter while the second must be 31. Some other 3X numbers work for the 2nd parameter and do different things, but I'm not sure what exactly. Logging can be turned back off using 30. (example to turn logging on: 52 12 02 31) When logging data data with 31 the last 3 bytes of data represent the forces with ~80 being 0 force. The 1st bit represents the side to side force, the 2nd is the lengthwise force and the 3rd is the up-down force.

This is all fine and dandy, but it doesn't really get us anywhere, in order to get something useful we'll also need access to rotational data. The good news is that we know how to do it, we just need to find the channel and opcodes that controls the other types of logging. I'd guess there's one for linear, rotational, and positional (e.g sensor bar) data. If we're lucky there may be some way to combine them all together and get some nicer data such as 'you moved left 3 cm, rotated forward 12 degrees'.

(Thanks to Volsung for posting the formatted list of HID Descriptors)

[volsung]

(Note I'm still waiting for a Triwing driver to get my Wiimote open so I can see what hardware we really have in there. The following may be useless speculation.)

If the accelerometer chip is anything like the one in my MacBook, then we might only have the 3 linear axes to work with. Normally you'd think that you would need a separate set of outputs to measure rotation, but that's only true in space. On the ground, we have a constant 1g force downward, which the Wiimote can measure in addition to the other forces on the controller. So at rest, we should get a nice 1g acceleration vector pointing where ever "down" is. As we rotate the controller, the vector as observed by the fixed axes of the accelerometer will rotate as well.

Things get complicated when you mix translation and rotation together. You'd have to decompose the time derivative of the acceleration vector into rotation and translation pieces. I can imagine some scenarios where one might not be able to separate the two very well, but I suspect that doesn't matter. We just need a way to interpret gestures and not guide a cruise missile.

(Ultimately, I think Nintendo has the right idea giving developers software that records motions rather than making them try to decompose the "sword slashing gesture" into its acceleration profile by hand.)

[volsung]

BTW, I didn't post the HID descriptors to the wiki. I just discovered them buried on another page and linked to them.

Is there a way to clean up the parsed HID descriptor output? That hand translation is kind of hard to read.

[volsung]

Oh, and one more thing your post got me thinking about:

http://en.wikipedia.org/wiki/Wii_Remote#Sensing

The article claims that the IR sensor is a 1 megapixel image sensor (which are usually sensitive to IR without any help) and the citation is a link to a press release from PixArt which goes on about motion tracking and System-on-a-chip. You can pop over to their ugly webpage:

http://www.pixart.com.tw/

and poke around their System-on-a-Chip options. A likely possibility for the Wiimote sensor is this thing:

http://www.pixart.com.tw/upload/PAC107_V14_20051122095335.pdf

which is listed as having "Toy" and "Recognition" applications. It's actually a 20,000 pixel sensor, so the 1 megapixel comment in the Wikipedia page might be speculation.

In any event, with a full microcontroller (40 MHz even!) on board, the Wiimote might locate the two regions of IR on the Sensor bar in firmware and just Bluetooth back the coordinates. That would be nice, rather than having to intepret the full CCD image ourselves. (And doing the processing in the remote makes sense, since sending even 20k pixel images at the rate needed to support a pointer would push the Bluetooth bandwidth pretty hard.)

[andy753421]

For general HID output you can use 'hcidump -X'. The -X part parses out everything it can and then appends the rest as hex data. For some reason I have to be running 'hcidump -X' from the point when I connect in order for it to parse things correctly. If i start dumping after the connection is set up it doesnt know what's going on.

For parsing descriptors there's a windows program from the usb hid page that will parse descriptors to and from binary. Going from hex to ascii is annoying though because you have to convert it to some weird binary format first. I tried it on the data from the wiimote and it was the same as what's on the wiki.

Looking at the article linked to from wikipedia it seems you may be right in that it only does 3-way linear accelerations... I guess I might have to do some math after all

[squeakypants]

I've got a question for you: Have you tried messing with the nunchuka and classic controller? There should be an output saying what is connected, as well as the outputs necessary for each of them (the nunchuka will have 8 more axes and 2 buttons, the classic controller will have 4-6 more axes and 8-12 buttons)

[volsung]

Haven't checked on the nunchuck or classic controller yet. I'm heading out to EB Games now, actually, to pick up a classic controller. I wanted the nunchuck, but they are all out of them...