Thank you @Medabit for the information. If the distance is truly in mm then jumps in the pose matrix aren't as bad as I had initially thought. I had done a quick search in your documents and wasn't able to find information on the units, would you be able to point me to the document I missed?

Quote:

To confirm, you're using the pose from the target (crayonbox) to calculate the pose of another object in a known, fixed location (medbox). This means if there is significant variance in the pose of the crayonbox, this will be reflected in the augmentation associated with the medbox?

I'm using the pose matrix of the crayonbox and the pose matrix from the medbox to determine the distance between the crayonbox and medbox. I'm then using the distances from one second to another to determine if the objects are moving towards or away from each other. The problem then occurs when the objects are stationary but I'm registering movement within the pose matrixes and therefore within the distances - making it seem like the objects are moving when they are not. I apologize for the confusion.

Quote:

What device are you using? Please provide the exact model name.

I'm using the Epson Moverio Bt-200 Model: V11H560020. I also have a Nexus 7 tablet running android 6.0.1 which I'm using to test, I can observe the issue on both devices.

Quote:

Have you considered setting the target closer to the camera to see if the pose variance is a function of the percentage of the camera's field of view that the target occupies? My experience is that there is a correlation.

I ran a 5 minute test and observed the same jumps in x, y, and z on both the medbox and crayonbox (at the approximate distance from the previous test which can be seen in the screenshots). I can try moving closer to the crayon box but then I will loose the recognition on the medbox. Though I appreciate the suggestion for debugging, it's not a valid long term solution.

During the longer test it looked like the medbox and crayon box 'jumps' had a range of 35 in the x, 65 in the y, and 30 in the z. Now that I'm aware of the general 'movement' I can account for it in my app. The data indicated that the 'jumps' in the x, y, and z were the same for both objects as I mentioned before (ie if the medbox jumped 15mm in the X the crayonbox also jumped approximately 15mm in the X) - so it does seem to be consistent.

Hello

In my case I am using the targets given with vuforia SDK, with extended tracking activated and 2 image targets detected at the same time.

I use a Samsung Galaxy S7 to test the fact of filming the two targets at the same time.

If I calculate the position of one target to another, the result is varying when I move the camera around the two targets (with them still in the field of view of course)

After realising some tests facing the two targets and only translating the camera, rotating a bit the camera and so on I figured out that a translation is added to the result.

After an investigation I saw that the calibration matrix used in vuforia is odd. I think that the calculations made in vuforia can't give good positions if the phone is moving when filming the targets.

I am trying to recreate a calibration matrix for the Galaxy S7 to find the matrix compensing the translation I see.

Hello,

Thank you for providing the information. Very helpful.

To answer your question, the scene units for Vuforia 5.5 SDK mobile device sample apps is millimeters. Keeping this in mind while reviewing the data you've provided, the most significant variance is in the 'timer 49' value of the Y coordinate. Otherwise, there looks to be decent tolerance in the poses returned with respect to translation variance (considering that the unit of measurement is mm).

All poses returned by Vuforia will have some amount of variance associated with them. If you're not using extended tracking, and the crayon box is your object target, the fact that it occupies such a small part of the camera's FOV would, in my experience, increase the frequency of pose errors.

A few more questions:

1. To confirm, you're using the pose from the target (crayonbox) to calculate the pose of another object in a known, fixed location (medbox). This means if there is significant variance in the pose of the crayonbox, this will be reflected in the augmentation associated with the medbox?
2. What device are you using? Please provide the exact model name.
3. Have you considered setting the target closer to the camera to see if the pose variance is a function of the percentage of the camera's field of view that the target occupies? My experience is that there is a correlation.

Thanks

Thank you for your assistance @medabit

medabit wrote:

Can you please provide examples of the targets being used? Are they highly rating by our Target Manager (4 or more stars)?

I've provided an object database 'testing objects'. The two objects I'm using for object recognition don't seem to have much trouble getting recognized. They have a N/A star rating on the objects and a 5 star on the image target I'm using.

medabit wrote:

What are the scene scale units being used? cm? mm?

The units are in whatever units I'm given by the vuforia api. I'm actually curious about what units are used and would like to know myself.

medabit wrote:

Is extended tracking enabled when these readings are being taken?

Extended tracking is not enabled

medabit wrote:

Can you provide a screen shot from the device of what the camera is seeing when these readings are being taken?

I've provided screenshots that correspond with the following x,y,z coordinates. The timer is in seconds:

timer: 48
renderFrame target pos crayonbox: 145.79172, 18.605583, 823.3123
renderFrame target pos medkit: -152.41446, 12.761139, 841.6942
saveScreenShot: test_8.png
timer: 49
renderFrame target pos crayonbox: 146.04663, 10.247852, 827.02106
renderFrame target pos medkit: -152.72849, 3.0383835, 840.6791
timer: 50
saveScreenShot: test_9.png
timer: 51
renderFrame target pos crayonbox: 142.6846, 17.607407, 827.393
renderFrame target pos medkit: -155.22266, 12.395798, 841.2621
timer: 52
saveScreenShot: test_10.png
timer: 53
renderFrame target pos crayonbox: 141.6962, 21.31094, 831.24255
renderFrame target pos medkit: -156.68951, 16.54546, 841.50214
timer: 54
saveScreenShot: test_11.png

Hello,

To assist with our investigation, can you please provide the following information:

• What are the scene scale units being used? cm? mm?
• Can you please provide examples of the targets being used? Are they highly rating by our Target Manager (4 or more stars)?
• Is extended tracking enabled when these readings are being taken?
• Can you provide a screen shot from the device of what the camera is seeing when these readings are being taken?

Thanks

I did some more debugging and it seems the errors is propagated from the pose matrix. As I said earlier I take the pose matrix and convert it to a GL Matrix44f using Tool.converPose2GLMatrix. I've print out 12, 13, and 14 of the resulting model view matrix each second while looking at an object the glasses recognize (a crayon box in this case). The log is below. As you can see the x, y, and z jump around considerably. I do expect the matrix values to waiver a bit as I can't stand perfectly still among other reasons but the jump 272 to 216 to 255 to 301 in the x over 4 seconds seems too much (this example from time 50-53 below). I'm building my app based on the Object Recognition example using Android studio.

My question for the developers is: Is this a known bug? Is there a fix or workaround you suggest? 

As I've commented previously I am using the coordinates to determine the distance between two objects which is integral to my app - if I can't depend on the distance to be stable then my entire app is rendered unusable. I appreciate your insight.

D/Matrix: printLocMatrix crayonbox @ time 50 : 272.37936 , -3.772043 , 782.1126
D/Matrix: printLocMatrix crayonbox @ time 51 : 216.1481 , -30.2614 , 820.7488
D/Matrix: printLocMatrix crayonbox @ time 52 : 255.52536 , -13.465515 , 780.9556
D/Matrix: printLocMatrix crayonbox @ time 53 : 301.86456 , -25.388443 , 707.0505
D/Matrix: printLocMatrix crayonbox @ time 54 : 304.31418 , -11.584133 , 697.81354
D/Matrix: printLocMatrix crayonbox @ time 55 : 235.73526 , -2.8857994 , 805.36566
D/Matrix: printLocMatrix crayonbox @ time 56 : 259.70938 , 3.829364 , 804.2539
D/Matrix: printLocMatrix crayonbox @ time 57 : 257.8614 , -9.380328 , 804.44104
D/Matrix: printLocMatrix crayonbox @ time 58 : 254.46094 , -15.544216 , 797.64386
D/Matrix: printLocMatrix crayonbox @ time 59 : 253.47845 , -12.152511 , 791.4636
D/Matrix: printLocMatrix crayonbox @ time 60 : 256.30576 , -14.068097 , 802.7336
D/Matrix: printLocMatrix crayonbox @ time 61 : 259.47333 , -10.621282 , 800.9758
D/Matrix: printLocMatrix crayonbox @ time 62 : 265.26804 , -5.668472 , 799.73724
D/Matrix: printLocMatrix crayonbox @ time 63 : 263.9983 , -7.4550457 , 794.42163
D/Matrix: printLocMatrix crayonbox @ time 64 : 262.45435 , -6.933034 , 796.99097
D/Matrix: printLocMatrix crayonbox @ time 65 : 265.47052 , -4.6592126 , 797.33777
D/Matrix: printLocMatrix crayonbox @ time 66 : 264.3025 , -8.039713 , 794.62555
D/Matrix: printLocMatrix crayonbox @ time 67 : 263.45358 , -8.953372 , 793.3308
D/Matrix: printLocMatrix crayonbox @ time 68 : 262.21768 , -3.8726013 , 793.5258
D/Matrix: printLocMatrix crayonbox @ time 69 : 264.492 , -2.5033474 , 805.17896
D/Matrix: printLocMatrix crayonbox @ time 70 : 265.11716 , -3.7662926 , 799.5619
D/Matrix: printLocMatrix crayonbox @ time 71 : 270.00327 , 2.1144118 , 798.9259
D/Matrix: printLocMatrix crayonbox @ time 72 : 266.76105 , -0.14821105 , 796.25323
D/Matrix: printLocMatrix crayonbox @ time 73 : 268.65448 , 1.0939136 , 800.45294
D/Matrix: printLocMatrix crayonbox @ time 74 : 270.48782 , 1.3340439 , 802.33405
D/Matrix: printLocMatrix crayonbox @ time 75 : 271.75696 , 0.30668855 , 794.84674
D/Matrix: printLocMatrix crayonbox @ time 76 : 262.94504 , 0.101476036 , 806.49115
D/Matrix: printLocMatrix crayonbox @ time 77 : 270.00882 , 0.4237549 , 804.9055
D/Matrix: printLocMatrix crayonbox @ time 78 : 267.27707 , -3.4285145 , 805.91925
D/Matrix: printLocMatrix crayonbox @ time 79 : 267.34372 , -2.100721 , 797.383
D/Matrix: printLocMatrix crayonbox @ time 80 : 262.5265 , -1.4916053 , 798.55664
D/Matrix: printLocMatrix crayonbox @ time 81 : 267.9655 , -1.1607212 , 798.13635
D/Matrix: printLocMatrix crayonbox @ time 82 : 267.39978 , -4.9988427 , 800.8022
D/Matrix: printLocMatrix crayonbox @ time 83 : 263.46417 , -9.864267 , 804.3163
D/Matrix: printLocMatrix crayonbox @ time 84 : 263.99628 , -10.491708 , 799.7593
D/Matrix: printLocMatrix crayonbox @ time 85 : 270.70236 , -6.756596 , 805.79474

Can someone from Vuforia provide a sample project that solve this problem using the pose matrix from both targets please ?

(Position of one target according to the other must not change -or very few changes due to averaged values- when moving the camera)

Edit : By the way I don't know if someone is trying to contact me directly by private messages because when I go to my account messages the title of the web page is "Messages (2 new)" but I have no messages displaying... (On the vuforia developer portal account)

Thanks for your help @alessandroB and @medabit I am also using vuforia-sdk-android-5-5-9 with the Epson Moverio bt-200

Hello and thank you all for your contributions

I use "vuforia-sdk-android-5-5-9"

I was already transposing the inverse matrix (and I tried with and without to be sure).

What I see is not just little variations in the results but values that vary when I move the camera as if the translation of the camera was still taken into acount (for example it can vary vrom -100 to +100 in the x value if I move camera from left to right when facing the two targets)

There is one thing I forgot to mention, i.e. when you compute the inverse matrix (via the SampleMath utility class), you also need to transpose it; 

this thread discusses the right approach in great depth:

https://developer.vuforia.com/forum/general-discussion/incorrect-inverse-function-samplemath-class

Note that some small variations of the relative positions or orientation between two targets can still be expected, due to precision / rounding errors during the calculation, but you should observe that these remain small in percentage of the total translation values.

Hello,

Can you both please provide the version/s of Vuforia being used when this issue is being observed?

Thanks

I am running into this issue as well. I had better luck trying to convert the coordinates of the target object into world coordinates (rather than camera) first using the following code (Java - Android Studio):

Matrix44F modelViewMatrix_Vuforia = Tool.convertPose2GLMatrix(result.getPose());
float[] modelViewMatrix = modelViewMatrix_Vuforia.getData();

// deal with the modelview and projection matrices
float[] modelViewProjection = new float[16];

float[] objectSize = objectTarget.getSize().getData();

Matrix.translateM(modelViewMatrix, 0, objectSize[0]/2, objectSize[1]/2, objectSize[2]/2);

Matrix.scaleM(modelViewMatrix, 0, objectSize[0], objectSize[1], objectSize[2]); //was /2 on all scales

Matrix.multiplyMM(modelViewProjection, 0, vuforiaAppSession.getProjectionMatrix().getData(), 0, modelViewMatrix, 0);

         
Matrix44F mviewProjMatrix = new Matrix44F();
mviewProjMatrix.setData(modelViewProjection);

I am then storing the mviewProjMatrix and averaging values at 12,13, and 14 over several seconds.

To get the distance between two objects position (averaged over several seconds) I am doing the following where the averaged translation float[] is from the above mviewProjMatrix values at 12, 13, and 14.

public double getAvgDistanceTo(float[] avgPosOtherObj){
    float[] myAvgPos = getAveragedTranslationVector();
    float vx = myAvgPos[0] - avgPosOtherObj[0];
    float vy = myAvgPos[1] - avgPosOtherObj[1];
    float vz = myAvgPos[2] - avgPosOtherObj[2];

    double dist = Math.sqrt(vx * vx + vy * vy + vz * vz);

    return Math.round(dist);
}

As I said this distance is fairly stable though every couple of seconds it will vary wildly even with no movement from the camera. I'll also note that I'm calculating the distance from object 1 to object 2 as well as object 2 to object 1 and they are not always consistent. I apologize that this isn't *super* helpful as it doesn't solve the problem and would love to hear from a vuforia developer on either what we are doing incorrectly or why the positions of the objects vary so wildly.

Thanks!

Hi AlessandroB and thank you for you answer,

As I said in the previous post I followed your answer at  https://developer.vuforia.com/forum/qcar-api/proper-way-get-coordinates-position-tracker?sort=2

Which is equivalent to your answer here and I agree with the calculation.

However, when I do that, the results in position are changing when I move the camera (but the targets stay at the same place).

I wondered if I had to make something more to have the positions ?

What seems to happen in the result of the operations you wrote is that when I face the two targets with the camera and I move the camera to the right for instance the x value is increasing (even if the targets don't move)

Have you tried it ? Is it something I am the only one to experiment with these operations ?

I was also wondering if the two targets were detected in separate threads ? As it would be possible I does not make the operations in good conditions ?

Assuming the following matrix notations:

T1_to_Cam = Pose Target 1 with respect to Camera

T2_to_Cam = Pose Target 2 with respect to Camera

you should be able to get the Pose of Target 2 with respect to the Target 1 coordinate system via this simple matrix math:

T2_to_T1 = T2_to_Cam * inverseMatrixOf( T1_to_Cam )

Hope this helps.

up, any idea around why the values are changing ?

Hello and thank you for your answer,

Actually I'm just trying to obtain the position of the second target according to the first one and not according to the camera, which should be a very simple maths problem but I can't manage to obtain viable result. (I need the position of the second target according to the first one for my project)

I tried to proceed like in this post : https://developer.vuforia.com/forum/qcar-api/proper-way-get-coordinates-position-tracker?sort=2

(Which by the way is not consistent with the calculation in this other post for the calculation of the camera position according to the target : https://developer.vuforia.com/library/articles/Solution/Get-the-Camera-Position)

To test the result I use two fixed targets (they stay at the same place) but the position I obtain for the second target according to the first change when I move the phone camera (and it should not as the two teapots seems not to move one from the other). The targets are default chips and stones in Vuforia Image Target Native sample.

So now I am just wondering why I can't manage to obtain the second target position according to the first correctly.

Hello,

I'm afraid I don't understand your use case. If both targets are detected and return a pose that is relative to the camera's position, why do you need to calculate the position of the second? Is it because you are not actually detecting the second?

Thanks.

up, can someone please help me ?

Edit : Title changed to be more precise