Wiimote Project

i like it. it looks like it would work. but what if i was on its side so that safety glasses could be easily modded across the top rim. so it's right, middle, left. instead of top, middle, bottom.

i like it. it looks like it would work. but what if i was on its side so that safety glasses could be easily modded across the top rim. so it's right, middle, left. instead of top, middle, bottom.

That wouldn't work unless you could factor in distance from the wiimote.

.  .  . Face on
. . . Turning either way.
Get me?

I think someone mentioned this in another thread already. There is already an implementation of this, but it uses 4 points of reference.

Check out: http://idav.ucdavis.edu/~okreylos/ResDev/Wiimote/index.html

So to track 3/4 points we need a way to "know" that when a point moves to a new location where it moved from so we know that it's the same point. I don't have my wiimote yet so maybe I'm off base and maybe the wiimote libraries already help coordinate this information.

I don't think they do, because this is really hard to accomplish. I also think knowing wich point is which ist the biggest problem when tracking more than two points with a WiiMote.

Also is there any reason why it says you need 4 points (not in the same plane) to track a 3D object.

Oliver Kreylos says:
"If four 3D points and their projections are known, this results in nine total non-linear equations for seven unknowns (8 from the points and one from the quaternion's unity condition). In principle, it would be sufficient to know the projected positions of three known 3D points (leading to seven equations for seven unknowns); however, three points in 3D space are always planar, and the resulting system is very instable."

This seems reasonable and would explain why freetrack switched from 4point Tracking to 3Point tracking. However with 3 LEDs/Point you will have problems in some situations, eg. when the WiiMote sees the 3 points on a straight line (witch reduces the number of equations and makes the problem unsolvable). I think Freetrack assumed in their code, that the user would never turn the head in right angle to the screen, which is also reasonable. =)

I personally, since having seen Johnny's and Olivers videos, have been thinking of a way to track a sword in 6DOF. That's right, I want to play a real swordfight simulation =). The best solution probably is to use 2 (or more) WiiMote(s) as "cameras" (some commercial tracking systems actually use 6 to 8 cams). But the great problem remains: how do I know which point is the tip and the hilt of the sword (and probably which ones are the parrying-"bar").

The only information given by the WiiMote about a detected point is its approximate radius. Maybe this information could be used to distinguish 4 points by giving each of them a unique radius, and thus an "ID". But this radius also changes dependent on the distance between point and WiiMote. Perhaps the last successfully tracked position of a point could be used to guess the future radius? And there we are again, guessing distances and locations.
Oliver Kreylos: "and predicted target point projections are matched with camera observations on a nearest-neighbor basis"

If the ID by radius does not work I think it is impossible to solve the problem with WiiMotes in 6 DOF. One would always have to make restrictions, guess or take the brute-force approach.

And back to sword-fight. I'd probably use a third WiiMote as hilt, with LEDs or reflectors attatched to it, so motionsensor/accelometer information could be used together with IR Point tracking to track the whole sword.
Now will someone please implement this, and send me copy? ;P
(along with a Wii, as I sadly don't own one =( )

Azel

Oliver has a rudimentary light saber demo.

I know, but the direction of his sword is very restricted, the WiiMote must be pointed at his beacon for 3D tracking.

Oliver's predictive method seems pretty good.

Yes, I'd like to know how he uses the accelometer data to estimate the WiiMote position.

In Johnny's video on the automatic projector calibration, he mentions that they use predictive modelling when one of the sensors (fiber optics in this case) falls outside the view of the system.

The problem is Johnny uses 4 point but needs only two (for the location). This would be anlaogous to using 6 or 8 points for 3D tracking while you need 4. But we only have 4 points. =/

There are oodles of mathematical papers at his site:

http://www.cfar.umd.edu/~daniel/

Thanks for the link. I'll difinitely be reading this.

FreeTrack uses a version of DeMenthon's POSIT algorithm.  I can't help but think that FreeTrack could be adapted by throwing out the initial image analysis step that finds the LEDs and just substituting the output from the wii.

Yes, this might work. As I understand it the Wii implements the image analysis in hardware which is a great advantage.

As for identifying the LEDs, how fast is the refresh rate on the WiiMote's CCD?  Would it be possible to chirp each LED with a unique time signature?  Or continuously blink them each with a different blink frequency?

Johnny said its 100Hz, while I have heard others saying it's only 33Hz.
At 100Hz this might work theoretically, good idea! Though you would have to synchronize the "blinking" LEDs with the WiiMote. Reading the refreshrate from the WiiMote would require serious hardware hacking. Another problem I see is that LEDs might not be able to emit full power and go back to zero in 1/25 of a second.

Myself, I'm interested in something like a 6DOF mouse for the  analysis of 3D image data.  I want to be able to move the wii around and have my 3D data rendered following my motion.  There are expensive solutions out there.  This is the first cheap solution that looks practical.

I think tracking two points with two WiiMotes is definitly doable. There are only two possibilities and the brute force approach looks easy =).

Thanks for the reply!

Azel

Quote from: HighDesert on January 21, 2008, 08:47:42 PM

Oliver has a rudimentary light saber demo.

I know, but the direction of his sword is very restricted, the WiiMote must be pointed at his beacon for 3D tracking.

Yes, I thought of that as soon as I thought more about my own problem (manipulating 3D data) and what would happen if I rotated the wiimote out of view of the LEDs.  It does make the option of leaving the wiimote stationary while rotating a tetrahedral in its view more appealing, except that I'd lose all those buttons for interaction!  In either case, I'd have to solve the point recognition problem.

Quote from: HighDesert on January 21, 2008, 08:47:42 PM

FreeTrack uses a version of DeMenthon's POSIT algorithm.  I can't help but think that FreeTrack could be adapted by throwing out the initial image analysis step that finds the LEDs and just substituting the output from the wii.

Yes, this might work. As I understand it the Wii implements the image analysis in hardware which is a great advantage.

If I get a chance, I may dig into FreeTrack's code. 

The issue is really just point identification. If we assume that the refresh rate of the CCD is 100Hz (which I sincerely hope it is), then Nyquist[1] says the freq of the LED chirp (50% DC) needs to be less than 50 Hz. Most remote-control IR diodes can handle 40 kHz[2], so no problem there. Some error will occur, but as long as the chirp frequencies are known, it can work. A simple micro mounted inside a sword (I really like that idea) or on the back of a glove[3] can handle this easily.

With a little bandpass filtering you could select the signal from each particular LED.  The trick will be storing enough values to compute the frequencies without introducing too much lag to the response. 

On the other hand, would we need to chirp all the LEDs?  Would a known geometric arrangement with one chirped LED be enough?  Two?

A few more ideas for identifying the LEDs:

1. Fixed temporal intervals: Instead of blinking continuously at separable frequencies, perhaps the LEDs could be blinked in order at fixed intervals with all LEDs off except one and the interval between each LED changing in a fixed pattern.  Then, the interval between measured coordinates indicates which two LEDs fired most recently.  Intuitively, I'd think the chances of an obscured LED erroneously introducing a known interval to the sequence would be small.  You'd know, "Hey, that gap was too large! It's the LED2 - LED4 gap.  LED 3 is obscured."

2. Geometric LED curtain: A more elaborate and expensive geometric arrangement of LEDs similar to digital paper.  Or, a patterned LED reflective material lit by a single infrared source.  The mathematics of the arrangement would probably be much more complicated since the wiimote can change its view of the "field" while a typical digital paper pen always "looks" straight at the paper.

Basically with either the flashing or spatially positioned LEDs, the idea is to impart extra information to the setup that would enable the identification of a particular LED.

John.

P.S. Regarding the digital paper-like solution.  What about projecting an infrared pattern on the wall?  Are there infrared projection systems?  Would there be enough reflection off standard walls or furniture for the wiimote to detect?

Unfortunately, the "geometric LED curtain" doesn't work with the wiimote. The device is limited to exactly four points of detection. We should consider this lucky since Nintendo had no reason to detect any more than two.

A little more off topic, but the thing about the digital paper is that the local dot arrangements tell the digital pen exactly where on the paper it is without its seeing the entire paper.  Similar to the temporal chirping of the LEDs, the spatial position of neighoring dots on digital paper is such that an absolute location can be determined. 

I mention the digital paper or "LED curtain" idea as a way to get around the limited field of view of a single wiimote.  Perhaps accurate pointing could still be achieved with a suitable geometric distribution of LEDs.  Sure, it can only see 4 LEDs at a time, but it may be possible to position every set of 4 LEDs in such a way to know exactly which way the wiimote is pointing - absolute pointing being related to the effort to compute absolute position.

Again, this would be quite an elaborate solution.  I think the other approaches are easier to consider for a first attempt at 6DOF positioning.

John.