Its scary when you think like an evil dictator, roll on courier and for those who cant wait, theres always the archos 9. You cant help be left with the thought that they just had to be 2nd!

The good news is that the device does not crash either WiimoteLib or my WiiCi application and the bad news is that the device does not crash either WiimoteLib or my WiiCi application so I have no place really to start.

Some information about the WiiMP has started to appear over at wiibrew however this leaves me with a feeling that getting it going in WiiCi is going to be a big job. Here is a snapshot the current state of thought from wiibrew:

The Wii Motion Plus consists of two rate-gyros. These gyros measure rotation SPEED, but can’t actually measure absolute orientation, which causes drift if not corrected by some other data source. Speed is one step better than the acceleration reported by the accelerometers. One of the two gyros will obviously have to measure yaw, since that can’t be measured by accelerometers. The other axis is unknown, but I would guess pitch. Unlike the rotation measured by accelerometers, whose axes are defined by gravity, the gyro axes are relative to the angle of the Wiimote. So even if it can measure yaw when the Wiimote is in the normal orientation, it won’t be able to detect yaw when the Wiimote is vertical.

In addition to providing yaw, the gyros also allow the software to tell the difference between orientation and acceleration, which are difficult to tell apart from the accelerometers which measure a mixture of both.

Sounds like a start from the begining job to me!

Given the fact that most current stroke rehabilitation systems employ relatively sophisticated or expensive hardware and software, one question of paramount clinical importance is whether the benefits obtained from these systems can be obtained with less sophisticated affordable systems. What now needs to be explored is the rehabilitation potential of commonly available computer games.

Wii Glove Prototype One

Although commercially available platforms lack specificity in terms of software, hardware and performance metrics they often provide other equally important advantages such as mass acceptability, easily perceived feedback and most importantly affordability for unrestricted home use.

Our solution is the development of a low cost rehabilitation glove using the capacity of the Infrared Receiver on Nintendo’s Wiimote to pick up the signal from four diodes placed at the patient’s fingertips. This compensates for the inability of previous low cost solutions to track fine motor skills. Four diodes per glove are used as it is only possible to track that number of separate Infrared Signals per Wiimote.

In all it was simple process with only a little additional code being needed to that previously detailed: Logic3 FreeBird Working with WiimoteLib

if (type.ToString("x") == "1aeafb922e3") { mWiimoteState.ExtensionType = ExtensionType.Wireless; }
else { throw new WiimoteException("Unknown extension controller found: " + type.ToString("x")); }
break;

This new code was added as the default case statement within the InitializeExtension() function within Wiimote.cs and caters for the chucks being detailed as an additional unknown extension type “1aeafb922e3″ when the chucks are connected upon start up. All the code does is to reassign the ExtensionType to that of the new Wireless type.

I have also included a new extension panel within wiindows. As well as the usual features, facility is provided to swap polling types between that of raw and value data, just in case the strange results highlighted within the Freebird post are not down to me using an incorrect receiver module (still not found it yet).

Provision has also been included to allow some of the custom extensions I am currently developing. Watch the video in high quality: here

You must start with the chuck turned off then once everything has been initialized hit the fc paring button and your all systems go.

The lib views the chuck as the unknown device: a42000000, thus, in order to get it working at this initial stage I have added the following hack/clause to the ExtensionType case poll:

if (type.ToString("x") == "a420000000") {
mWiimoteState.ExtensionType = ExtensionType.Nunchuk; }
else { throw new WiimoteException("Unknown extension controller found: " + type.ToString("x")); }

An interesting detail at this point is that only the “raw” values are obtainable for both stick and accelerometer data, any Ideas?

I was wondering if this was the case with other chucks too. Are they in fact working with version 1.7, but only detailing raw data. I have also posted these findings over at Brian Peek’s site and am awaiting feedback.

Tomorrow I aim to start implementing the Logic3 FreeBird as an additional ExtensionType within wiimoteLib.

Time for a bit of an update. I may have made a bit of a piratical error that affected the testing of the origional Logic3 Freebird Thumbstick.

Since I first posted about my findings both here and at brianpeek.com I have tested several additional sticks. The first being the intec chuck. Unlike the logic3 stick the values data stream was unaffected.

This is also the case with the Logic3 Freebird Nunchuck Adapter. My guess is at this point that I have been using the adapter receiver for the thumbstick test (I seem to have one missing, humm). This may have caused the strange no values result.

I rushed straight in to implementing wireless chucks into my wiindows, wiimoteLib application, and was done in about 10 min’s. I will test the Thumbstick again as soon as I have tracked down the missing receiver.

First of all you need to add the id definition to the ExtensionType enumeration within DataTypes.cs. I did this just below the Nunchuck definition as follows:

///
/// Wireless extension
///
Wireless = 0x000000a420000000,

If you want your wireless devices to be seen as standard chucks within your application(s) then all you need to do next is add the following case within the InitializeExtension() function inside Wiimote.cs:

case ExtensionType.Wireless:
mWiimoteState.ExtensionType = ExtensionType.Nunchuk;
Console.WriteLine("wireless detected");
break;

However if like me you would like to display as a different extension type within your application then just add the Wireless case between the Nunchuck and ClassicController, to give the following:

case ExtensionType.Nunchuk:
case ExtensionType.Wireless:
case ExtensionType.ClassicController:
case ExtensionType.Guitar:
case ExtensionType.BalanceBoard:

With this done all you need to do is expand the ExtensionType cases within Wiimote.cs so that they read as Nunchuck or Wireless as follows:

case ExtensionType.Nunchuk:
case ExtensionType.Wireless:

So there you have it, working wireless Nunchucks. An interesting point to note is that so far the Logic3 adapter seems to give the best results. I say this as it is the only one that works inserted from application start up. Also I have not had to re-pair the device and receiver.

Brian Peek has released a new project over at the Coding4Fun site, that utilizes my balance board code (cool) the following has been taken from his site:

I previously talked about my WiiEarthVR project shown at PDC project, and now I have posted the article for the application up at the Coding4Fun site.  Full source code is available.  You’ll need some hardware to make this go, namely a Wiimote, Nunchuk, Wii Fit Balance Board and a pair of Vuzix VR920 glasses, but the hardware can be toggled on or off depending on your own setup.  The VR920 glasses are pretty cool in that they also work with a variety of FPS games on your PC with a custom driver they include.

The article will, among other things, teach you how to use Virtual Earth 3D from a managed host (i.e. a WinForms app, not a web page), how to talk to the Wiimote, Nunchuk and Wii Fit Balance Board, how to retrieve the head tracking data from the VR920 glasses from .NET, and how to draw stereoscopic 3D images to the VR920 glasses from .NET.  Quite a bit packed in there…

Anyway, have a read and, as always, questions and comments are welcome.

The changes are as follows:

• Added “center of gravity” calculation to the Wii Fit Balance Board (thanks to Steven Battersby)
• Structs are now marked [Serializable] (suggested by Caio)
• Battery property is now a float containing the calculated percentage of battery remaining
• BatteryRaw is the byte value that used to be stored in the Battery property
• WiimoteTest app now reads extensions properly when inserted at startup
• Exposed HID device path in new HIDDevicePath property on Wiimote object
• Changed the time delay on writes to 50ms from 100ms…this should improve responsiveness of setting LEDs and rumble

Brian feels like he is running out of things to implement and bugs to fix.  So, want’s to hear from the people using his library…

All I can say on this topic is don’t forget the Wii Motion Plus extension out Q2 of next year Brian.

However whilst browsing some XNA resources I discovered that the guys over at Caligari have Released trueSpace 7.6 for Free download. All you have to do is register for an account, then download the software.

trueSpace7.6 is a fully-featured 3D authoring package that will let you model, texture, light, animate and render 3D content. As well as traditional images and movies, you can also make 3D content for online shared spaces, and for Virtual Earth.

An entirely re-written X format exporter lets you save your trueSpace creations to load into game engines such as XNA to develop games for Windows or the Xbox 360.

A real-time scene with several lighting set-ups (by Marcel Barthel).

trueSpace also supports import from a wide variety of formats, letting you take existing objects and use them in Virtual Earth.

Most of you probaby already know that Caligari was snatched up by Microsoft’s Virtual Earth team (keep an eye on their blog here — good hints and tips on modeling with trueSpace as well as how to integrate with Virtual Earth).

So it all looks good eh, but there is still the OSX issue, however as both Blender and trueSpace are free why not try both.

Blender also has an FBX Export and looking at the features breakdown caters for trueSpace. With this in mind its time for a play to see which is the best option, however I have a feeling that a combinational approach will prove to be the optimum solution for my needs.

Coming from years of using max at work, i reckon my evaluation of each is going to be… er fun. I just wish discreet / autodesk kept plasma going, I loved that package.

However as I develop on both a mac and pc I need a solution that would enable recording on both and ideally for FREE, Jing does just that.

SO WHATS A JING

The concept of Jing is the always-ready program that instantly captures and shares images and video…from your mac or pc computer to anywhere.

Think of Jing as a supplement to all your chat discussions, email threads, forum posts and blog entries. It sits nicely on your desktop, ready to capture and share your stuff at a moment’s notice. Simply select an area of your screen, capture it as an image or record it as a video, and then click Share. Jing conveniently places a URL to your content which you can paste into any of your conversations.

A full review coming soon, until then take a look at the jingproject.com

Open up Datatypes.cs and add the following to public struct BalanceBoardState:

/// <summary>
/// The Balance Boards center of gravity
/// </summary>
public BalanceBoardCOG CenterOfGravity;

Next add a new struct to Datatypes.cs to contain the COG X and Y values, like so:

/// <summary>
/// The Balance Boards center of gravity (float values)
/// </summary>
public struct BalanceBoardCOG
{
/// <summary>
/// Balance Board center of gravity X value
/// </summary>
public float X;
/// <summary>
/// Balance Board center of gravity Y value
/// </summary>
public float Y;
/// <summary>
/// Balance Board center of gravity point value
/// </summary>
public PointF COG;
}

Next add the following variable definitions above the default constructor within Wiimote.cs:

// length between board sensors
private const int BSL = 43;

// width between board sensors
private const int BSW = 24;

BSL is board sensor length and BSW is board sensor width. These points were obtained via measuring the distances between the centers of the boards feet. I am not brave enough to open my board up to get the exact values but these seem to work fine for me.

Finally add the following chunck of code to the BalanceBoard case of ParseExtension:

float Kx = (mWiimoteState.BalanceBoardState.SensorValuesKg.TopLeft + mWiimoteState.BalanceBoardState.SensorValuesKg.BottomLeft) / (mWiimoteState.BalanceBoardState.SensorValuesKg.TopRight + mWiimoteState.BalanceBoardState.SensorValuesKg.BottomRight);
float Ky = (mWiimoteState.BalanceBoardState.SensorValuesKg.TopLeft + mWiimoteState.BalanceBoardState.SensorValuesKg.TopRight) / (mWiimoteState.BalanceBoardState.SensorValuesKg.BottomRight + mWiimoteState.BalanceBoardState.SensorValuesKg.BottomLeft);
//
mWiimoteState.BalanceBoardState.CenterOfGravity.X = ((float)(Kx – 1) / (float)(Kx + 1)) * (float)(-BSL / 2);
mWiimoteState.BalanceBoardState.CenterOfGravity.Y = ((float)(Ky – 1) / (float)(Ky + 1)) * (float)(-BSW / 2);
//
mWiimoteState.BalanceBoardState.CenterOfGravity.COG.X = mWiimoteState.BalanceBoardState.CenterOfGravity.X;
mWiimoteState.BalanceBoardState.CenterOfGravity.COG.Y = mWiimoteState.BalanceBoardState.CenterOfGravity.Y;

This calculates the COG using moments. The values can then be obtained via the following calls:

X = ws.BalanceBoardState.CenterOfGravity.X.ToString();
Y = ws.BalanceBoardState.CenterOfGravity.Y.ToString();

COG (as floating point) = ws.BalanceBoardState.CenterOfGravity.COG.ToString();

Using COG your board can easily be adapted for use as a joystick. The X and Y values can also easily be plotted for a visual representation if required.