Well tomorrow is the day of my final presentation and I’ve just finished preparing everything in preperation.
I just thought I should share my Max5 patch, purely because it’s such a beast!
As you can see in the last image, despite the fact that the WiiMote can only see 2 points of light, it was able to work out the position of the other 2 based on what it knows about the relationship between their distances before they left the field of view.
As always, I have included a grab of the unlocked patch, just so you can see how difficult it is to keep track of all the patch lines!
Well well well! I am still going with my trig work, but the more I equate, the easier it becomes. The first set of functions described what to do with the values and this set calculates how to get said values.
The equation I spent the entire afternoon working on takes a distance between 2 points seen by the Wiimote and uses triangulation to calculate the distance of the sensor bar from the Wiimote. Unfortunatley, because the distance between the points is measured in pixels and the distance between the sensor bar and the Wiimote is measured in ‘real’ units (i.e. cenitmetres or inches) there is a conversion or ‘scale’ factor to be taken into account.
…and after all these scribbles, the final equation is as follows:
Where:
d = distance between Wiimote and sensor bar
s = distance between the 2 points as seen by the Wiimote (pixels)
Horiz FOV = Horizontal field-of-view of the Wiimote, roughly equal to 41° (to be measured)
Vert FOV = Vertical field-of-view of the Wiimote, roughly equal to 31° (to be measured)
The problem, as I mentioned is that the scale of the model has not been set, and d may need to be multiplied by a certain number to make the numbers work, but nevertheless the relationship between d and s should work out to be correct.
After a lot of fiddling about on Max5 and testing different hardware, I have had a breakthrough! I have now successfully got a Wiimote to not only ‘see’ and follow 4 IR LEDs, but also return the values into Max5!
Below is a crude(!) video taken on my old-as iPhone 3G, showing the tracking as I move the Wiimote around:
The next step in my development is to use triangulation to determine the distance between the Wiimote and the LEDs, in such a way that I can change the configuration depending on the fixed distance between the LEDs.
If i were just moving the Wiimote along a single axis towards the LEDs, then the calculations would be very simple, but nothing in my life is that simple! Not only is the positional and spacial relationship between the 2 objects 3-dimensional, but the rotation (pitch, roll and yaw) of the LEDs (or in this case, the Wiimote) is also 3-dimensional and it is here that lies the problem.
If the 4 light sources are close together, there could be 2 possible senarios:
The LEDs are far away
The LED array has been tilted so that the angle of incidence is very small
A successful and stable solution for this has not yet been created. Until now…maybe!
Because the IR camera on the front of the Wiimote is of such a high quality (1024 x 768px!) with a narrow viewing angle (~45°) it suffers foreshortening much more pronounced and acurately reproduced than that of a normal webcam. This means that if the sensor is far away from the source, the distance between the points will be small, but consistant between them. If the sensor is tilted, the distance between the 2 leftmost points will differ from that of the 2 rightmost. There is a value returned for the size of each of the light points, but this is inacurate and unstable due to the narrowviewing angle of the LEDs. I am currently looking into way to increase the viewing angle of the IR LEDs, which will help the accuracy and reliability of the values returned.
Finally, credit where credit is due. Thank you to Alex Harker for the updated ajh.wiiremote Max5 patch: http://cycling74.com/forums/topic.php?id=22500
Well now that I have the technicalities (kind of) worked out, I had to think about how I would work out the viewing angles needed for my screen/window project. Sounds simple, eh? Below are a few drawings for the planning of my system.
As it turns out, I had forgotten a lot of what I had been taught in GCSE Maths, but I eventually got going and used my powers of substitution and diagram-drawing:
To see if the final equations worked, I created a Max patch to check the variable inputs for a 2-dimensional system. The full system will be the same, but with values for the y-axis as well.
Amazingly, the patch returns values that are believeable, but I will only know if it truly works when I get my homebrew Wii Sensorbar made up. I already have on my desk a Wiimote and I have downloaded the Max5 patch to get the data from it:
In my effort to get more aquainted with both Max5 and my Arduinos, I have started to look at projects that I can build using them both. My first idea is a binary clock – an idea that I thought might be quite easy. As it turns out, I was able to build a patch within about 2 hours:
To get a physical clock, all I would have to do is plug in some LEDs into the respective outputs of my Arduino…not all that difficult. However, I would like to eventually make a new clock concept, although practically every clock idea and variation of every idea has already been built.
