WiiLi.org

[wic]

Amazing. I plotted it again, this time using f(x)=264/x.
.
Fits like a charm, I'd say.

About that konstant, k. I assume it related to the sensor bar length (lightpoint distance) somehow. How do you calculate k in the general case, ie using the sensor bar length?

While I'm at, I'd be very interested in knowing how you derived d=k/p. So if you could elaborate on that, please. It looks like some kind of projection/similar triangles thing to me?

/Thanks!

[Cha0s]

A friend of mine derived it in a very clever way using triangles. I'm not sure I can quite reproduce it. However, there is a way to demonstrate it with lens equations:

Given these two lens equations:
hi/ho = di/do
and
1/f = 1/do + 1/di
where hi is the height of the image, ho is the height of the actual object, di is the distance of the image from the lens, do is the distance of the object from the lens, and where f is the focal length of the lens (the Wii remote camera), you solve for do to get:

do = f(1 - ho/hi)

In this equation, f and ho are constants. hi is the same as your x. Where f is small (less than a centimeter is my guess), we can say:
do = f*ho/hi
Since f and ho are both constant, this simplifies to:
do = k/hi
Unfortunately, we have no idea what f is (anyone know the focal length of the camera lens?). Also, we have hi (the pixel distance between the two dots) and ho (the 7.5 inches between the lights) in different units. So we'd also need to know the pixels per inch of the camera images. If we knew one (ppi or focal length), we could determine the other experimentally using a table as you did.

Now, I'm not sure how exactly we could adapt d = k/p to depend on sensor bar length without using the lens method, but I'll look into it. I'm hoping we can get a good explanation of how to get 5DOF for the Wii remote up on the Wiki. Carl Kenner did it with his 5DOF script for GlovePie, but it is unclear what methods he used and he hasn't been around lately to explain them. Until then, we'll just have to plod on, trying to figure it out on our own. [/i]
_________________
Cha0s

[wic]

Great. That approach seems sane enough. Its odd that noone has figured out which camera chip and PixArt chip is being used. Finding the correct specs should give us much more information. Btw, I think hi/ho=di/do should be hi/ho=-di/do.

I've pondered another approach using triangles and 2d projection. This is highly speculative:

[Cha0s]

You're right, that should be negative. It was a typo. The final equation is still correct, though. Not sure about the FOV stuff (I'm not sure I understand it entirely), but good work with the similar triangles stuff. That's a good proof.

As for the right-angle issue, I think I have a solution. Take a look at this and tell me whether you agree or not (does it make sense, etc). I'm trying to work out the one where X position is constant, but yaw is allowed, but I can't seem to make any progress there.
_________________
Cha0s

[wic]

The figure makes sense, but there are some things I noticed.
Unless I'm mistaken, the final equation should be y = sqrt(d*d - x*x), ie minus.
The other thing is that you are using z as of variable length. In my mind, z is the fixed perpendicular distance between the camera and the projection plane (the image, the upper parallell line in the figure) having a value of 1320.
I think you should try to involve l in the final equation somehow and eliminate some unknowns.

The values we know are p (p1 and p2), l and (possibly) z. It may be useful to consider FOV=35degrees and also w and h (1024, 768) of the image.

[Cha0s]

Z should actually be the vertical distance (which is the next thing we need to add to this model). I think we were both wrong to use it. Good catch on the minus, though. I've uploaded an updated version addressing the issues you mentioned. We know everything in the final equations except a constant "r" (replacing "z") which can be determined experimentally as before (I'd postulate that it is the same, though no guarantees on that). It's at the same link.

EDIT: Ah, I see you were orienting your axis differently. I was using my the preconceptions I got from working with the Wii remote's accelerometer:
Forward-back (long-ways) is Y, left-right is X, and up-down is Z.
_________________
Cha0s

[wic]

Ok, lets call it r The final equation looks very good. Have you tried using it in practice and compared to the physical value?

The thing that bugs me is the r length. Judging from the figure, it looks to me that r depends on the position of the wiimote. If you move it, r will change. So how can r be considered a constant as you say?