Wii Gesture Project - version 4

(higher quality video available for viewing here!)

"What you'll probably notice is that the movement is quite stuttery, so even when the Wiimote is in a stationary position there may still be some jitters. This is due to the fact that the 3D model of the Wiimote takes it's rotation properties directly from the ever-changing data of the real Wiimote's accelerometers."

This is fixed! If you compare the movement of the Wii Remote in this video to the other 3 I've recorded so far, you'll notice that the motion much smoother. It's difficult to tell from the video, but now it's easier to select the direction you want to point the Wii Remote. Before, if the Wii Remote was held on the cusp of a different direction, for example between 'left' and 'idle', the chances were that there would be lots of 'left' directions generated as the accelerometers in the Wii Remote flit between 'left' and 'idle' positions.

The smooth movement is gained by sampling the last 15 accelerometer values for each axis (x, y and z) and calculating an average of each. This average is used in place of the raw accelerometer readings. This method irons out the little 'in-between' vibrations from the accelerometer.

The slight (and the benefits of averaging 99.9% outweigh this) problem is that there is a slight delay between moving the Wii Remote and the program reacting. This is because the latest movement is being averaged alongside the last 14 movements could be much lower or higher - so the numbers have to effectively 'catch up'. In fact, as the application is running at 30 frames per second, the movement is up to half a second behind. The delay can be reduced by taking fewer samples for the average.

...the work continues.

Wii Gesture Project - version 3

"There is a problem with this method of data collection and that is that a complete gesture must fall perfectly within each group of 8 movements."

Well, not anymore! The method of populating the array has been modified slightly so that the oldest of the 8 movements is pushed off the back of the array allowing the newest movement in at the front.

e.g:

movementList = [1, 5, 7, 3, 7, 3, 2, 1]

A new movement comes in - number 5 (which is 'down')
All but the first value from the movementList array is copied into a temporary array...

temp_movementList = [5, 7, 3, 7, 3, 2, 1]

...then the latest movement is tacked onto the end so we end up with...

temp_movementList = [5, 7, 3, 7, 3, 2, 1, 5]

...finally the contents of temp_movementList are copied into movementList and then processed into a single string...

levenshteinString = "57373215"

This process happens after every movement the user makes with the Wii Remote.

As ever, a higher quality video can be viewed here.

That's all folks!

LEDs, Camera, Tilt!

Whilst all the tilting is happening with the 3d model on the computer monitor, the Wiimote is also providing feedback to the user. Every one of the 9 positions (8 tilts and 1 'idle' position) has a different light sequence. I'm particularly happy with the way the LEDs zoom left and right when the Wiimote is held in 'idle' position - slightly reminiscent of a certain car...

Have a look at the video (apologies for the shoddy focus of my camera!)
There is a high(er!) quality version of the video here.

The picture below shows how the LEDs will behave when the Wiimote is tilted in different directions - hopefully clearer to understand than the video!
(note: the glowing circles denote LEDs that flash)

The LED sequences are merely there, at the moment, to provide the user with extra feedback as to their positioning of the Wiimote.

(it also looks rather good as well!)

Wii Gesture Project - version 2

...one step further to having some gesture recognition!

Have a look at the video.

(Once again, if the video quality is too iffy for you, go here)

You will see that the application records the user's gestures in groups of 8. The movements, each direction represented by a number, are stored in an array (or 'list' as Lingo would have us call them!). At the end of every group of 8, the array is condensed into a single string. This forms the basis of a Levenshtein Distance comparison string - I'll explain this in another post, but it's a core part of the application nevertheless!)

For example, the application may output:
movementList = [1, 2, 1, 2, 3, 5, 1, 5]

...therefore...

movementListLev = "12123515"

We take each number...
1=up, 2=up-right, 3=right, 4=down-right, 5=down, 6=down-left, 7=left & 8=up-left

So we know from 'movementListLev' that the user has moved the Wii Remote up, up-right, up, up-right, right, down, up & down.

There is a problem with this method of data collection and that is that a complete gesture must fall perfectly within each group of 8 movements. The next stage in the development will involve creating the array/list so that newest movement numbers push out the oldest numbers, that way the 8 most recent movements are ALWAYS shown...

Wii Gesture Project - version 1

Here is the first iteration of an application that will hopefully be able to recognise a gesture made with a Nintendo Wii Remote. So far, the program can mimic the rotational movement of the Wiimote and therefore, can determine which direction the Wiimote is pointing.

Watch the video above (if you haven't already!) to see how it works.

(If you don't like the Blogspot video quality, have a look at a higher resolution version here)

What you'll probably notice is that the movement is quite stuttery, so even when the Wiimote is in a stationary position there may still be some jitters. This is due to the fact that the 3D model of the Wiimote takes it's rotation properties directly from the ever-changing data of the real Wiimote's accelerometers. Perhaps the next thing to do is add a method that 'rounds' the accelerometer data to a certain (lesser) degree of accuracy - although less accurate just for the visual appearance as opposed to the inner workings of the application.

The work continues...

Movement purely on accelerometers!

Finally back on track after months of mucking about...!

Today, I altered my Wiimote program in Director to make a 3D object move around based on the data gathered from the Wii Remote's accelerometers. The control is actually pretty accurate. So far, you have to hold the remote in a fairly 'wooden' fashion. By this I mean that you can't swish the remote left or right as one might if playing a real Wii game (Wii Sports Tennis comes to mind here).

So, after some faffing with the Lingo in Director I have the following degree of control over my 3D ball...

note: the 'deadzone' for movement is attained when you hold the remote straight up in the air.

Move left: swing the remote to the left
Move right: swing the remote to the right
Move down: pitch the remote forwards (the end of the remote is moved in an arc away from your body)
Move up: pitch the remote backwards (the end of the remote is moved towards your body, the amount of movement is limited for this action)

At the moment, the movement of the ball isn't directly related to the accelerometer data in terms of the actual numbers... So if the accelerometer hints that the Wii Remote is being swung to the left then the ball is moved left by a finite amount.

That's all for the moment, however everything is well on the way to more exciting things!