+1 to the others, this is possibly one of the hardest problems in computing. For one person it is easy enough (especially if you "train" them) but for a "general" population you are facing serious problems. Firstly I am not overly familiar with the wiimote's limits from a programmers perspective so you will need to read up on those before you get into things.
First read up on fuzzy logic (a good start
http://www.seattlerobotics.org/Encoder/mar...uz/flindex.html ), it is about the only way to account for the inherent unpredictability of the input (the person and the device: people are not so hot at gestures and the wiimote is not known for greatness in this regard either).
In the simplest form if you have a preset range of tasks then assigning simple movements (move to the right for a circle, left for a square, up for a triangle.....) is probably the easiest option. I assume this is not the case though so you will have to account for speed, range of movement (most people can not even draw a freehand circle of a decent size with full concentration let alone using a wiimote while otherwise occupied).
The wiimote is a crude 3d space sensor so assign values at or above limits/scales of sensitivity for each "axis". I will leave it to you to work out what range you want to cover, it might also be worth enhancing sensitivity between certain ranges (most people will use either wrist rotation or movement about the shoulder and elbow which gives you about 0.8m for comfortable movement, if you are going to have them move on their feet then things change again).
As mentioned you also have accelerometers, this can save you some minor effort and decrease the "refresh rate"/polling interval if you go that router.
After this I would start the other side of things and get as many people as you can to draw shapes/perform movements to try and get some idea for the "fuzziness" required. You can not really do this yourself as you run the risk of training yourself and trying to correct things/adapt for your code.
A final though before psuedocode, many problems for gestures in games arise from somewhat harsh penalties for "failing" a gesture. Perhaps a "slowdown" of the game upon failure to allow for a second go.
psuedocode: "#"is start of a comment line, "[" is what I will put when you need to fill in the blanks, my pseudocode will likely be a hybrid of different languages but hopefully you can follow it. I make little to no attempt to make a clean running program/library.
Nothing that comes should be "new" but none the less I stake no claim on what follows.
#Wii Gesture recognition
#y z
#| /
#|/__x
#that will be my definition of the axes, you may want to change that to a more conventional (from a 3d programming perspective) method.
#I will try to stick to those axes and not define a second set, depending on your app though you might like to but it should not be that difficult to change.
Set poll interval = 60 milliseconds #this is about 17Hz, another option is interrupt based rather than polling based. You will have to set a range for an interrupt though which tends to get a bit hairy to do from a speed perspective (especially on hardware like that of the wii).
#My thought would be that interrupts are better for games while polling based is better for applications.
Set X = quad #x- variable# Hopefully 32 bits will provide a fine enough resolution.
Set Y = quad #y- variable# A secondary idea might be to use a finer resolution in the "typical range" and then reduce the effectiveness on the outside range
Set Z = quad #z- variable# Example: in the "usual" 80 cm sided box give 90cm to the high precision but then only add a bit for movements twice as far outside of it.
# People dislike calibrating things so it might be worth trying some form of "learning" to define the "typical range".
#I will leave it to you to choose if you want signed variables, I am inclined to leave it and set the bottom left of the person as the origin going away, up or "right" as positive and then calculate after the fact.
#If it has the provisions in hardware then by all means use them.
Set xaccel = signed float #you want signed here here to simplify the maths and float should also help.
Set yaccel = signed float
Set zaccel = signed float
#You also have rotational sensors, without testing I am not inclined to say but I suspect rotation plays a role in the given movements (how many people twist their wrist to draw a circle? now for a similar size square what happens?).
#I seriously doubt rotation of more that 180 degrees about any axis will occur. I suggest radians as we are ultimately going to be dealing with high level geometry and probably calculus using it and degrees are not especially suited for either.
#I will leave it up to you to choose whether to "retain" until calculation or use data during calculation and incur the accuracy penalties (remember errors stack/compund and fuzzy logic is somewhat long winded).
Set xrot = signed float
Set yrot = signed float
Set zrot = signed float
#from here my instinct would be to try to make branching code (potentially slower although able to be done in real time) although you could make "after the fact analysis" if you wanted.
#
#A further option is some kind of "learning algorithm" but this takes us into very complex territory.
#This is also where the fuzzy logic comes in, start with the geometric shapes (circle being radius squared= x squared + y squared in the simplest form).
#Your main problem here is 1) starting point (do you start the circle at a given "compass point", any "compass point" or some arbitrary point.
#This is not so much of a problem for simple shapes but as a thought exercise try it for a semicircle and all the places it might start.
#
#Personally I suggest breaking down a shape into sections: squares into lengths/sides, circles into quarters, triangles into subtype and then sides......
#Another problem is over or under rotation, even with fuzziness you are likely to find yourself outside a strict set of parameters. Interrupts should take care of this but you could also try disregarding data.
#Matrices are probably the easiest way of doing things here. You will also want to account for sizes, the easiest way to do this is to differentiate or interpolate.
# You could also try normalising or even reducing the value contained to a simple term (left movement=0, right=1).
#
#Whether you pile everything into one large matrix or use many is up to you, I would lean towards the halfway house at first of using several bigger matrices.
#Obviously the first step is to make the matrices.
#For polling:
#nicely you have 9 main variables which is a 3x3 matrix although you will need to write the pulse number somewhere else (probably a simple adder will do).
on_event(pulse) write
(x, y, z, xaccel, yaccel, zaccel, xrot, yrot, zrot) to mem location.
#At 17Hz you are looking at about 6 kilobytes for a 10 second gesture/recording time. This will go up if you account for boundaries but probably not by much.
#Interrupts could be useful for determining end of gestures.
#For interrupts, this one gets trickier as you will have to decide what you want to use, probably on a per game or even per action basis.
#Generally you will want a rest value (this need not be “zero” or even a set value:
#think sweeping action: acceleration changes and will probably be in a sinusoidal motion,
#As a nod to the fuzzy logic that governs this thought exercise you could even use multiple interrupts to trigger an event: one interrupt primes another.
write (x, y, z, xaccel, yaccel, zaccel, xrot, yrot, zrot) to mem location (a) # this is your base value.
Set interrupt (x-xa > 30)# this could be anything.
write (x, y, z, xaccel, yaccel, zaccel, xrot, yrot, zrot) to mem location (?)
#either way we end up with a bunch of matrices
#The nice thing about matrices is that you can kill various terms quite simply and manipulate others.
#here you would perform various operations on the matrices depending on what you needed.
[
[
[operations as required.
[
[
[
write “matrixmod(number)” to memory location (?)
#You could now do interesting things. On the one hand you could normalise a matrix (set a y value to 0 if it falls between a given range for example) and then work with “precise” maths or you could use the various range based instructions of a processor or features of a language.
#Back to branching. The easiest way here would be to have a library of shapes/gestures/sections as required and then only compare key things.
#This will of course up memory demands but I suspect a form of dynamic generation could be used (shapes easily being able to be generated from algorithms).
#Such a section would likely read:
compare matrixmod(number) to reference matrix(othernumber)# you need not use a matrix either, you could use a single term.
if
matrixmod(number)=referencematrix() then goto routine “circle?”
else
compare matrixmod(number) to reference matrix(othernumber+1)#this might be a good time to start a new routine.
#So far we have only flirted with fuzzy logic, in practice you may completely disregard a data set (I suspect this will mainly be the rotation)
# and more interestingly you may bring it in and take it out as necessary; not sure if the square is a square where you were in the previous section: bring back rotation.
[
[
[here you put the "end game" of determining what the gesture is.
[I suggest you make this a library and simply write a value to the memory and then have said memory referenced by something else.
[
[
End of psuedocode.
Good luck writing the apps.
