I posted on here a while ago that the wii motion plus gyro sensor had been cracked but didnt really get much buzz about it. Well one problem with using the M+ in addition to the nunchuck to supply the accelerometer is that both are on the same I2C address. I found a real easy way to get around that problem and now the possibility opens up for a $40 6 sensor system. Now, I love that diydrones is offering an IMU system now to play with, but being a poor college student I cant shell out over $100 bucks for a new toy. I believe using the nintendo parts serves a completely different crowd of people that want to experiment, on the cheap, and with something that they could easily use in a wii (if they have one) or sell for at least a 50% return. Check out my blog for details and code.Also, Im taking the plunge and making a kalman filtered 2d IMU in a little bit. It should be done soon. Many thanks to Jordi and the Kalman code he posted near the inception of this site. Its been helping me see a little more practically what a Kalman filter means.
There is a lot that I havent put into the basic demo codes. Ive gotten a successful integration program running which proves what Wiibrew says about dividing by 20 to get deg/s. However, this only works as long as the gyro is registering in "slow" mode. For fast mode, Ive only been able to determine one axis, the yaw axis. The value to divide by is 5 in fast mode only for yaw. Cant figure out how the invensense gyros work. Also, there is a very bad problem associated with turning on the motionplus. It gives bad data for almost the first full second of measurement after jumping addresses, so I usually test to see if the calibration zero's look off and if they do, i just push the reset button. This keeps the motionplus active and the "turn on" command is ignored. Btw, adr1an has posted a version of jordi's kalman example on the arduino forum which uses the nunchuck and motionplus. Check it out here
@Xander
From what I understand of Knuckles' code, the calibration just takes the average value from 10 samples of the raw data and scales it back to zero. Thats not really a calibration, just normalisation. How can we be sure if the WM+ says that the angular rate is 2deg/s it really is? We would either need to test it physically with some sort of calibration device or get some data on the sensors and find out how they output their rates.
Agreed you get 6dof, but need drift compensation on the yaw axis. If you're using a wiimote the infrared camera can get a yaw reference from the sensor bar. Say if you were flying the wiimote on a UAV, perhaps you could use the sun as and IR source???
There would need to be some sort of filtering on the data for use of the IMU in games, the sensors they are using are still incredibly noisy and drifty.
It is possible they implement a kalman filter though I think a simpler solution for most games would be all that's required. They don't need precise attitude sensing as we do.
Not sure the calibration data is really necessary if you can calibrate yourself at startup like knuckles does in his code.
Then again, I suppose if the whole scale is changing slightly based on that internal calibration that could cause problems... hrm... it would be nice if they were more open about this stuff.
By the way, you've got 6dof even without the infrared. Though not all of it is immune to drift. A compass could also fix that.
I'm really excited about the possibilities of the WM+ too. At the moment I'm doing some experimenting with my WM+ connected to my wiimote and then to my PC via bluetooth.
Brian Peek has released a new version of his WiiMoteLib for .Net that supports the WM+ (see his blog). So far I've managed to do some experimenting with the raw binary angular rates. The problem, regardless of whether you interface via i2c or the wiimote is that no one has seemed to make any sense of the calibration data from the WM+.
Eventually, my aim is to turn the Wiimote+WMP into a 5dof(maybe 6dof if I can fuse data from the wiimote infrared sensor) IMU. I'm assuming that this is essentially how it behaves in games. It would be interesting to know if WM+ enabled games actually implement a Kalman filter.
Comments
From what I understand of Knuckles' code, the calibration just takes the average value from 10 samples of the raw data and scales it back to zero. Thats not really a calibration, just normalisation. How can we be sure if the WM+ says that the angular rate is 2deg/s it really is? We would either need to test it physically with some sort of calibration device or get some data on the sensors and find out how they output their rates.
Agreed you get 6dof, but need drift compensation on the yaw axis. If you're using a wiimote the infrared camera can get a yaw reference from the sensor bar. Say if you were flying the wiimote on a UAV, perhaps you could use the sun as and IR source???
It is possible they implement a kalman filter though I think a simpler solution for most games would be all that's required. They don't need precise attitude sensing as we do.
Then again, I suppose if the whole scale is changing slightly based on that internal calibration that could cause problems... hrm... it would be nice if they were more open about this stuff.
By the way, you've got 6dof even without the infrared. Though not all of it is immune to drift. A compass could also fix that.
I'm really excited about the possibilities of the WM+ too. At the moment I'm doing some experimenting with my WM+ connected to my wiimote and then to my PC via bluetooth.
Brian Peek has released a new version of his WiiMoteLib for .Net that supports the WM+ (see his blog). So far I've managed to do some experimenting with the raw binary angular rates. The problem, regardless of whether you interface via i2c or the wiimote is that no one has seemed to make any sense of the calibration data from the WM+.
Eventually, my aim is to turn the Wiimote+WMP into a 5dof(maybe 6dof if I can fuse data from the wiimote infrared sensor) IMU. I'm assuming that this is essentially how it behaves in games. It would be interesting to know if WM+ enabled games actually implement a Kalman filter.