Thanks for your work. I've tried modifying your code to recognize the motion plus and I got it to work and send the motion plus data across. One problem I ran into is that when I had a nunchuk plugged in to the motion plus, sometimes the pc would say the extension was a nunchuk, but the data coming in was from the motion plus. I'm not sure if you'll see the same thing, but that's one thing I ran into.

A few of us over at the Parallax Propeller website have written several programs, including a 6DOF using the nunchuck and motion plus. We primarily use it via the i2c bus rather than bluetooth. Here is a link.

forums.parallax.com/.../default.aspx

Great work!!! looking forward for wiimoteplus library....

Any news on this? Got the motion plus today and can't wait to see what all the fuzz is about ;)

Thx!

Well, I'm going to shamelessly promote myself, and say that you should check out my blog. I cover Complementary Filtering for combining Gyro and Accel data to get a solid angle signal. Though I could help.

www.ohscope.com/.../getting-angle.html

Thank you for submitting this cool story - Trackback from NewsPeeps

Any updates on the support of the motion plus in Wiimotelib?

Any progress or anything we can do to help out? Still "patiently" waiting for this. :)

I'd like to see an unstable release with the ability to at least see the data.  Might get some more eyes on the problem too.

As we can see in Iwata Asks interview, uk.wii.com/.../iwata_asks_motionplus_volume_1_2162.html  I guess reverse engineering the hardware and data it returns is not enough. It seems Nintendo did some algorithm works on software side, which needs to be understood.

I think the community currently has the data format wrong.  From my own data analysis, I've found 4 distinct sensitivity levels (3 in slow mode, 1 in fast) for each of the 3 gyros.  My Slow/Fast bits are also different (same location, but some values are flipped).  It doesn't make any sense.  There might be multiple versions of the motion plus floating around.  I got mine with Tiger Woods 2010.  It may be that the data is somehow encrypted, although the community not seem to think so.    

I'm somewhat confused - It appears from wiibrew.org that the 'data output format' is well understood. Is it understanding the trigonometry that is causing the problem?

Also, is the major stability issue caused by having an additional attachment?

Thank you for writing the library!

Whoops, the lib I was using (WiiYourself!, based on your library) still used the legacy encryption handling, my bad.  It's working perfectly now.

Hi Brian,

Are you aware of how games use the WM+ data? I always assumed that the Wiimote simply relays the angular rates from the gyros in the WM+ along with accelerometer data from the WiiMote and the AHRS solution is calculated by the Wii.

If this is the case, wiimotelib should only need to provide wmp.values.r/p/q (calibrated angular rates in radians about x, y and z) and wmp.rawvalues.r/p/q (raw binary from the WM+)

Let other people figure out how to calculate the correct orientation over time. My guess is that a game that uses the WM+ would need to implement direction cosine matrix and perhaps a kalman filter with the gravity vector and IR heading from the Wiimote.

I've found out how to get an orientation from the rate gyros...it's surprisingly easy, and stays pretty decent for a long time, even without a dead zone via pure integration.   The algorithm is

calculate a time step (in seconds) from the last wiimote update time

get the three angular rates (in radians/sec), yaw, pitch, roll, put them in a vector A

angle = A.magnitude()*time_step;

axis = A.normalize();

rotation = quaternion(angle,axis);

orientation_quat= orientation_quat * rotation_quat

To create the A vector, I used (pitch,roll,yaw).  This is because I started the wiimote pointing up, with the buttons facing me.  That means that these rotation corresponded to the opengl coordinate system for rotation about x, y, and z.  It would have been different if the wiimote had have been oriented differently.

Finally, I calibrated the gyros first, by taking 100 samples and finding the average for each axis, then subtracting this average value from each reading.

Correcting with the accelerometers will be a little more difficult.  The "right" way to do this is with a Kalman filter as Peter suggested, but I'll probably do it the wrong way, with just a brute force update if I detect a stationary wiimote.  How to update the global pitch and roll without updating the yaw though is slightly lost on me.  I'll post again if I figure it out.

From what I've read on Wiibrew so far, it seems that the WM+ must be deactivated in order to access a nunchuck plugged into it.  I'm pretty certain games dont do it this way, the reinitialization of the WM+ is too long.

Has anyone been able to figure out how the games do it?

Thanks!

The InvenSense website references two research papers that detail how to perform 6DOF with raw accelerometer and gyroscope data. The paper "Measuring orientation of human body

segments using miniature

gyroscopes and accelerometers" in particular uses Kalman filters to adjust for the inaccuracy and noise of lower-end sensors. I'm looking to implement the algorithm if I get time, which I probably won't.

www.invensense.com/.../motion_sensing_accel_human.pdf

www.invensense.com/.../kinematic_motion_capture_using_sensors_IMUS.pdf

www.invensense.com/.../library.html

Hi Brian,

In WiimoteLib i noticed you were getting the raw data by doing the following:

RawValues.X = (buff[offset + 0] | (buff[offset + 3] & 0xfa) << 6);

Is there a specific reason for using 0xfa? Would it not be 0xfc to get the top 6 bits of a byte? Are you trying to integrate the slow rotation bytes into the number?

I'm just asking because I am trying to add motionPlus functionallity into wiiuse and using 0Xfa gives me odd values. My 0 values for staying still seem to be different than my 0 values for moving.

This 'bug' is also present in CWiid. I've done the same error while trying to implement the MotionPlus in WiimoteLib. (before you release the Beta)

This is not my site ^^

I don't work with CWiid.

I've first tried with FC but had some glitch.

I've then heard for CWiid implementation, they uses FA, so I've tried...

The code in the new beta is almost what I've done and works simillarely : I can rotate my 3D cube in all directions but if there still some glitch.

The difference between my code and yours is that I implemented the Slow/Fast in the Extension parsing : when Fast, the value is almost x5.

Some progress has been made concerning the use of other extensions at the same time as the WMP :

www.assembla.com/.../Using_extensions_via_the_Motion_Plus

Hi guys,

Looking for wii motion plus support for the pc. Just wondering whether anyone cracked it yet?

Thanks,

Ben.

Here is what I have been trying and I seem to be getting decent results.  Hopefully someone that is a bit smarter can refine this technique.

Vector3 A = new Vector3(0,0,0);

//Use Calibration data to set X,Y,Z components                      

                               A.X = ws.MotionPlusState.RawValues.X - XCal;

                               A.Y = ws.MotionPlusState.RawValues.Y - YCal;

                               A.Z = ws.MotionPlusState.RawValues.Z - ZCal;

//Compensate for the different sensitivities

                               if (ws.MotionPlusState.RollFast)

                               {

                                   A.X = ((ws.MotionPlusState.RawValues.X) / 4);

                               }

                               else

                               {

                                   A.X = ((ws.MotionPlusState.RawValues.X) / 20);

                               }

                               if (ws.MotionPlusState.RollFast)

                               {

                                   A.Y = ((ws.MotionPlusState.RawValues.Y) / 4);

                               }

                               else

                               {

                                   A.Y = (ws.MotionPlusState.RawValues.Y / 20);

                               }

                               if (ws.MotionPlusState.RollFast)

                               {

                                   A.Z = (ws.MotionPlusState.RawValues.Z / 4);

                               }

                               else

                               {

                                   A.Z = (ws.MotionPlusState.RawValues.Z / 20);

                               }

                               //Convert to degrees per second

                               A.X *= .0155f;

                               A.Y *= .0155f;

                               A.Z *= .0155f;

                               //Implement simple low pass filter

                                   SavedAngle.X =(SavedAngle.X * .95f) + (A.X * .5f) ;

                                   SavedAngle.Y = (SavedAngle.Y * .95f) + (A.Y * .5f);

                                   SavedAngle.Z = (SavedAngle.Z * .95f) + (A.Z * .5f);

                               //Convert to radians without changing or savedangle values

                               A.X = MathHelper.ToRadians(SavedAngle.X);

                               A.Y = MathHelper.ToRadians(SavedAngle.Y);

                               A.Z = MathHelper.ToRadians(SavedAngle.Z);

//create rotation matrix

                               Rotation = Quaternion.CreateFromYawPitchRoll(A.Y, A.X, A.Z);