WiiLi.org

[andy753421]

I'm doing some work on the driver for the wiimote but I'm having some problems figuring out how it should functions. What do you think would be the most useful way to write programs that use the wiimote. Here are a few examples.

1. Current state (as close as possible): This would give an angle the nose(IR sensors) is up from horizontal and an angle that it is rotated along the lengthwise axis.
2. Changed data: e.g. wiimote has rotated 30 degrees clockwise along Y axis and left 3 inches since last update.
3. Process data. e.g. Controller is rotating right at 30 degrees per second, left at 10 cm/s
4. Raw data. x, y, z forces.

Right now I'm just thinking along the lines of motion data. Once we get the sensor bar working we can have more precise control, however I'd also like to have it be usable with only the movement. This is mostly because sensor bars are bulky.

Also, does anyone know how the wii programming interface works?

[volsung]

My vote is to break the system into two parts:
1. userspace daemon (but needs root privs)
2. client C library, with various bindings

Daemon

As far as I can tell, you need root privs to do the bluetooth communication required to actually talk to the Wiimote, but you don't need kernel level access, so a userspace daemon can act as the driver. Since this thing runs as root, and also to allow clients maximum flexibility in how they want to interpret the data, it should be very simple. No fancy math, just the minimum translation of HID packets to understandable structs. Some data dependent behavior might be needed, like reinitializing the remote after something is plugged into the extension port.

I'm not sure what the best IPC mechanism is to talk to the daemon. The FIFO is simple, but I don't think that lets you discard old data if no one is listening, so you might have to go to sockets (defaulting to the local kind, with the ability to use the TCP/IP kind for truly odd projects that need that sort of thing).

It will be very important, though, for the daemon to timestamp packets as they come in, or at least save that information from the Bluetooth layer, and pass it along to the client. The timing info will be essential to understanding the motion of the remote, which will probably involve looking at the time derivative of the acceleration vector. (Random Brainstorm: maybe those random first two bytes in the motion packet payload are "time since last sensor read". The rate of packets is not uniform, so maybe Nintendo is coding some crude delta-t info in there. Need to remember to plot the value of those two bytes when I'm moving the controller fast and slow to see...)

Client Library

All of the interpretation of the raw data should be pushed into a client library can do the following things for you:
* Open a socket to the wiimote daemon
* Provide a "push" or "pull" interface to incoming events. i.e. the difference between registering a callback, or putting events into a queue which the client reads when it wants.
* Perform any math, filtering, synthesis of the motion data as requested by the client. This is where the client can decide how much information they want to use, and precisely how they want it interpreted if there are multiple methods.

The client library should probably be C, as the sort of least-common denominator language on Linux, but wrappers (time to go learn about SWIG?) to other languages, like Python, would be important.

As for the interface Nintendo provides to licensed developers, any one who knows probably can't say due to an NDA. However, Nintendo did say they were planning to offer tools which would allow developers to "record" a motion and recognize it later. Fuzzy matching of motion profiles sounds like a fun Ph.D. thesis for anyone who is looking (or maybe a few have already been written). This would be a nice long term feature to develop as well, though it sounds much harder to get right.

[pepsiman]

[squeakypants]

I don't know where you'll actually be outputting this data, but the best way would be to have raw data including the "mathematized" data. So not only should it output the raw acceleration data (and the buttons, etc), but it should also output the raw rotational data, the driver should be the one doing the math, not an external program.

Where are you going to output the data, though? My two-cents are that it should output as a gamepad, or another device. The driver should just simplify the data for any program (ala Wiili) to use.

GAMER GIBRISH: The reason I say gamepad is of course for games As soon as we accomplish that I'll buy myself a bluetooth adapter, boot up into DSL, and try me some classic NES gaming! Then I'll see if I can configure the rotation to some F-Zero, maybe even Star Fox!

(back to normal)
Also, what license are you going to release the code under? Is it officially part of the WiiLi project, or will the drivers be a separate project? If separate, will you keep it open source? (I'm guessing WiiLi is open source, as doesn't Linux need to be?

[volsung]

I have to disagree about pushing the math into the driver. There is no one correct way to analyze the accelerometer data. Different methods apply depending upon what you want out of it. That's why I suggest putting it into a library, so people can swap in or out whatever method makes sense for their app, or even use several methods at the same time.

Although, for the application you are thinking of, you could have something that uses the math library to translate wiimote movements into gamepad-like events. This can be separate from the "driver", or at least be a second layer to the driver so it can be easily changed out.

[squeakypants]

I was definitely thinking it should be customizable (an on/off thing). However, the option should be there.

[RandomInsano]

I definetely agree with math in the client. No need to bog down the driver with math it may never use. Volsung has the right idea on this in my opinion.