> I haven't fully tested this myself but I'm hoping to use this data to
> construct an internal representation of all object positions. I hope to
> construct a 'map' of all objects by calculating and storing the 
> relative
> positions of the few markers that are actually visible. This 'map' 
> would
> then be able to be used for game logic.
> Are you trying for something similar? If so, I'll post another message
> once I had a chance to implement a few ideas and experiment with them.

If you want to use the absolute values of the marker positions, make 
sure you PRECISELY calibrate your camera.  Even then, the pose 
estimates of the camera relative to the fiducials will not be 
particularly good, especially when the markers are not perpendicular to 
the camera, so if you hope to build up a map over time you shouldn't 
try to rely on the exact values.

However, you could build up the topology (say, a graph of the relative 
positions) which might be more robust to errors and will not suffer too 
much from the inaccuracies of the pose estimation.

>> If you want to use the absolute values of the marker positions, make
>> sure you PRECISELY calibrate your camera.  Even then, the pose
>> estimates of the camera relative to the fiducials will not be
>> particularly good, especially when the markers are not perpendicular 
>> to
>> the camera, so if you hope to build up a map over time you shouldn't
>> try to rely on the exact values.
>>
>> However, you could build up the topology (say, a graph of the relative
>> positions) which might be more robust to errors and will not suffer 
>> too
>> much from the inaccuracies of the pose estimation.
>
> I was indeed thinking of a graph of relative positions. I hope I can 
> get
> some error reduction by calculating the relative positions towards
> multiple markers whenever there are multiple markers visible.
> I'll probably use four markers to represent the corners of a playing
> board. The other markers (the game pieces) will most likely not be too
> far away from one of those corners.

The pose estimation of the ARToolkit (and any small marker of this 
sort) is pretty good in location perpendicular to the viewing direction 
(ie. in the camera plane), but very poor in depth and in rotation.  
That's because any small error in the corner locations result in large 
errors in the perceived size (and thus depth calculation), and in 
possible large errors in rotations.

To compute the relative locations (one relative to the other) you need 
to invert one of these pose estimates, which causes the rotation errors 
to be magnified in their effect (since small rotation errors in the 
fiducial now are seen as large position errors in the camera).  The 
effect is that the relative location of one fiducial to another would 
be calculated very poorly.

In your case, you should consider taking advantage of what appears to 
be some nice physical constraints:  from your description, the pieces 
lie on a plane, which you could take advantage of.  Instead of using 
the 3D poses of the markers, just project everything (e.g., the 
corners) along the view direction on to the board plane, and then 
compute things.  Should get rid of much of the error!

On Sat, 2004-11-13 at 20:33 +0000, Leach, Mathew wrote:
> More of an openGL question really but Iÿm having difficulty
> understanding the structure produced by the call:
>
> argConvGlpara(patt_trans, gl_para);
>
> If the details in gl_para are in the form of a 4 x 4 matrix then which
> values relate to the XYZ translation?
>
> 0          4          8          12
> 
> 1          5          9          13
> 
> 2          6          10         14
> 
> 3          7          11         15
>
> Iÿd expected it to be either (3,7,11) or (12,13,14), but when I output
> these values they constantly change, even when the marker is
> stationary (except 13).

OpenGL uses matrices in column-major format, as you have shown above.
This means the xyz- translation values are (12,13,14).
The relation test example calculates the relation between two markers as
follows (lines 138 and 139 in relationTest.c):

arUtilMatInv(object[0].trans, wmat1);
arUtilMatMul(wmat1, object[1].trans, wmat2);

wmat2 is now a [3][4] matrix containing the difference in position and
rotation between the two markers.

Don't be too surprised when the positions vary (slightly) between frames
even when you hold the camera and the markers still.


I haven't fully tested this myself but I'm hoping to use this data to
construct an internal representation of all object positions. I hope to
construct a 'map' of all objects by calculating and storing the relative
positions of the few markers that are actually visible. This 'map' would
then be able to be used for game logic.
Are you trying for something similar? If so, I'll post another message
once I had a chance to implement a few ideas and experiment with them.

On Sat, 2004-11-13 at 17:40 -0500, Blair MacIntyre wrote:
> > I haven't fully tested this myself but I'm hoping to use this data to
> > construct an internal representation of all object positions. I hope to
> > construct a 'map' of all objects by calculating and storing the 
> > relative
> > positions of the few markers that are actually visible. This 'map' 
> > would
> > then be able to be used for game logic.
> > Are you trying for something similar? If so, I'll post another message
> > once I had a chance to implement a few ideas and experiment with them.
> 
> If you want to use the absolute values of the marker positions, make 
> sure you PRECISELY calibrate your camera.  Even then, the pose 
> estimates of the camera relative to the fiducials will not be 
> particularly good, especially when the markers are not perpendicular to 
> the camera, so if you hope to build up a map over time you shouldn't 
> try to rely on the exact values.
> 
> However, you could build up the topology (say, a graph of the relative 
> positions) which might be more robust to errors and will not suffer too 
> much from the inaccuracies of the pose estimation.

I was indeed thinking of a graph of relative positions. I hope I can get
some error reduction by calculating the relative positions towards
multiple markers whenever there are multiple markers visible.
I'll probably use four markers to represent the corners of a playing
board. The other markers (the game pieces) will most likely not be too
far away from one of those corners.

-Peter

Peter,

Thanks for your quick reply.  My problem was in fact caused by working
with doubles.  As soon as I cast everything to floats it worked fine.

The numbers below show a typical output for array components (12,13,14)
that I was getting before.

1876536475 1076448719  -450381238
1876536475 1076448719  -450381238
1876536475 1076448719  -450381238
1876536475 1076448719  -450381238
-101881528 1076438230 -1037474411
-101881528 1076438230 -1037474411
-101881528 1076438230 -1037474411
 871820191 1076445291  1680001065
 871820191 1076445291  1680001065
 871820191 1076445291  1680001065
 871820191 1076445291  1680001065

And then after casting I get nice constant values like:

-12.313079 -5.612974 368.22144

It was a schoolboy error I'm sure, but I don't have much experience with
Visual C++.

Matthew

-----Original Message-----
From: owner-artoolkit@h ..................
[mailto:owner-artoolkit@h ..................] On Behalf Of Peter Oost
Sent: 13 November 2004 22:31
To: ARToolKit
Subject: Relative marker positions

On Sat, 2004-11-13 at 20:33 +0000, Leach, Mathew wrote:
> More of an openGL question really but I'm having difficulty
> understanding the structure produced by the call:
>
> argConvGlpara(patt_trans, gl_para);
>
> If the details in gl_para are in the form of a 4 x 4 matrix then which
> values relate to the XYZ translation?
>
> 0          4          8          12
>=20
> 1          5          9          13
>=20
> 2          6          10         14
>=20
> 3          7          11         15
>
> I'd expected it to be either (3,7,11) or (12,13,14), but when I output
> these values they constantly change, even when the marker is
> stationary (except 13).

OpenGL uses matrices in column-major format, as you have shown above.
This means the xyz- translation values are (12,13,14).
The relation test example calculates the relation between two markers as
follows (lines 138 and 139 in relationTest.c):

arUtilMatInv(object[0].trans, wmat1);
arUtilMatMul(wmat1, object[1].trans, wmat2);

wmat2 is now a [3][4] matrix containing the difference in position and
rotation between the two markers.

Don't be too surprised when the positions vary (slightly) between frames
even when you hold the camera and the markers still.


I haven't fully tested this myself but I'm hoping to use this data to
construct an internal representation of all object positions. I hope to
construct a 'map' of all objects by calculating and storing the relative
positions of the few markers that are actually visible. This 'map' would
then be able to be used for game logic.
Are you trying for something similar? If so, I'll post another message
once I had a chance to implement a few ideas and experiment with them.