Announcement

Collapse
No announcement yet.

Vuforia Image Sizes in Xml

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Vuforia Image Sizes in Xml

    Does anyone know why the Y value in the assets/RoverRuckus.xml files are not consistent?
    All four images have the same 10"x7.25" (254mm x 184.15mm) image area with the same cross-hair edge alignment marks and same FIRST logo size/location.
    All have the same X dimension in the xml, but different Y. Unless the images in the .dat file have different areas of interest, this seems odd.
    We have not had time to test the accuracy of the pose information, but I do know that if the config is not correct the pose result will be off.
    Here is the configured sizes:

    Code:
     
    <ImageTarget name="BluePerimeter" size="254.000000 183.280029" />
    <ImageTarget name="RedPerimeter" size="254.000000 181.783096" />
    <ImageTarget name="FrontPerimeter" size="254.000000 158.794403" />
    <ImageTarget name="BackPerimeter" size="254.000000 199.508209" />

  • #2
    Hi shelbyRobots,

    The aspect ratios for the four different images used for this season's image targets are all slightly different (hence the difference in the height of the images). the size 254.0 refers to the width of each image in mm. When you print the image targets out from the PDF files that are available on the FIRSTInspires.org website, all of the images should have a width of 25.4 mm (or 10 inches). Their heights might differ slightly due to the different aspect ratios of the pictures that were provided to me (by FIRST Marketing) when I generated the targets for this year

    I hope this info helps. The info in the xml file should be correct. The cross hair marks are not actually part of the image targets.

    Tom

    Comment


    • #3
      Tom,

      Thanks for the reply. When I look at the printed images, they all seem to have the same width (25.4mm) and height (18.41mm) for the printed area sans crosshairs. Do the asset files have different data than the printed images from the pdf. I did not apply a scale when printing.

      Comment


      • #4
        Hi FTC7253

        The images are supposed to print 10" (25.4 cm) wide and whatever the corresponding height is for the aspect ratio. I do not believe they were scaled when the PDF versions were created. Have you tested localizing using the image targets? Are you noticing a large discrepancy in the position and orientation information that is returned?

        Tom

        Comment


        • #5
          Tom Eng
          We are working through some tests right now. We worked on some of this last night, but still have more to do...

          We are seeing similar results from 3 images. The craters image seems to gives a significant difference.
          Still working through the details.

          There seems to be some inconsistency in the robot reference frame among the examples.
          ConceptVuforiaNavigation.java and ConceptVuforiaNavigationWebcam.java appear to treat Xr as out right side of bot, and Yr forward.
          ConceptVuforiaNavRoverRuckus.java, however, states that Xr is out the front of the robot, and Yr is out left side.
          This difference is confusing at best, but may not matter as long as the user knows the the robot reference frame definition being used.
          Does the SDK "care" about the robot reference frame convention used, or is it simply providing results of matrix multiplications and inversions?

          In all cases, the phone appears to use the convention with screen up in portrait: Xp out right side of phone, Yp out top, and Zp out of screen with origin at camera.
          Likewise, the field is always Xf parallel to red alliance wall +ve to right, Yf running +ve away from red alliance, and Zf up with origin at center of field.

          We started with ConceptVuforiaNavRoverRuckus.java and tried modifying the image placement from the real field locations to all be at 0, 0, 0 translation from field. We tried with both a simple 90 rotation about X to stand the image up (facing -Yf), and also adding a -90 Z so the image would face -Xf. The latter was in an attempt to see 0 deg HPR for robot orientation when aligned with field.
          Interestingly, we haven't seen 0,0,0 HPR. There always seems to be a significant pitch or roll - regardless of having the camera square to image and aligned with center. We also see a Y or Z component to translation, which isn't making sense.
          Making all image transforms the same allows us to simply change the image while leaving the rest of the set up static.
          We tried both with and without Z offsets in both the image placement and robot->phone transform.
          We are going to try to set up this test tonight:
          • Robot X forward
          • phone in robot = {0,0,0} {XYZ, EXTRINSIC, 90, -90, 0}
          • Images in field = {0, 0, 0}
          • Back camera facing image in landscape mode with camera Y/top pointing to left (along "field" Y).
            I think this is camera -Z?? aligned with "field" X.
            With camera=BACK, is -Zp out lens?
          • Phone rear lens centered up/down and left/right with center of image.
          This should represent robot Heading 0 (robot X=forward) aligned with "field" X. Camera mounted at robot origin (for test purpose only) with screen facing rear of bot and phone top pointing left.

          With this setup, I would expect to see 0 for robot Y and Z location and 0 for robot HPR. I should only see a robot X location in field.

          We did also print off the image pose. It seemed to have much less in the way of Y or Z components - suggesting perhaps something amiss in the other transforms or the chaining process.

          Finally, We did see nice pose distance values for 3 of the images at ~24" (~0.5" delta). As we moved back, the difference between actual and reported distance increased (~1.5" delta at ~36" IIRC). Again, crater jumped to different values. We haven't tested much with the phone at an angle to the image yet.

          If any of this long babble needs to be corrected, please fire away. Also, please suggest improved test procedure if you see one.

          I will get back to you when we actually have some values to log - I was just trying to get the returned robot on field matrix to make sense before having the kids gather data.

          Thanks,
          Stephen

          Comment


          • #6
            Tom Eng
            BTW, I just reprinted the images from the pdf. I downloaded the pdf and opened it with Acobe Acrobat (I think last time I opened it in IE). I made sure to print with Actual Size and Landscape orientation settings.
            All images printed with 254mm width. Heights were: Crater 183mm, Space 184mm, Rover 183mm, Footprint 181mm
            I am not sure what goes into creating the version of the image that gets loaded into the .dat file, but the numbers above do not match in some cases what is in the supplied xml (crater 158.79, space 199.51, rover 183.28, footprint 181.78).

            The images pulled from the pdf have the following pixel dimensions:
            space: 1819x1321 (ratio=1.377)
            rover: 2199x1587 (ratio = 1.386)
            crater: 1829x1319 (ratio = 1.387)
            footprint: 2047x1465 (ratio = 1.397)

            All of the pixel dimension ratios match the printed ratios with 254mm width and the heights given above in this post.

            Are the .dat versions of the images scaled down version of the pdf images, or are they cropped/subsets?

            Note: given this info, I am going to re-verify the space image distances produced in our testing. We were going pretty quickly through them.

            Thanks,
            Stephen

            Comment


            • #7
              Tom Eng
              Even more info...
              I saved each of the images from the pdf, and loaded them into a new device database using the online Vuforia Target Manager.
              This is the resulting xml (different image names):
              <ImageTarget name="space" size="254.000000 184.460693" />
              <ImageTarget name="footprint" size="254.000000 181.783096" />
              <ImageTarget name="crater" size="254.000000 183.174408" />
              <ImageTarget name="rover" size="254.000000 183.309692" />

              Comment


              • #8
                Hi Stephen..

                I just spent some time on the phone with Tom Eng, and we have tracked down the issue (Also reported here https://ftcforum.usfirst.org/forum/f...d-target-error).

                The XML size data, and image feature data was generated by the Vuforia Developer site, and is correct.
                BUT when the actual image PDF file was created, there was a bit of a SNAFU and the images were stretched to fit a constant aspect ratio.

                The was definitely not the intent, but it happened. This is the cause of the missmatching numbers and the incorrect localization reported on the other post.

                As you have posted, it's possible to change the XML file to match the actual printouts, but this may "not" really correct the problem. (It's probably more involved than that.)

                Since changing the image datasets in the App is more difficult to support, Tom is proceeding to get the target image PDFs updated, and they will probably have a V2 designation.

                Until then you can continue to use the old images, but know that the absolute positioning will be off until they are replaced.

                Phil.

                Comment


                • #9
                  HI Stephen,

                  Thank you for catching this error. Due to a cut and paste issue, the images were pasted into the template for the image targets with the wrong aspect ratio for 3 of the targets, but is most noticeable with the crater target (which should naturally have an aspect ratio closer to 1.6). We are working on getting the new image targets updated on our website. Thank you for finding this issue!

                  Tom

                  Comment


                  • #10
                    Philbot and Tom Eng
                    Thanks for the follow up. I look forward to trying the new pdf images.

                    I still had a couple of other embedded questions in my 9/25 02:30PM post.
                    Is the robot reference frame convention definable by the user? Or are there assumptions in the OpenGL transformation chaining that impose a specific standard? The reason I ask is due to the discrepancy amongst the Vuforia examples when assigning PhoneInBot transforms. A couple use X=Right, Y=Fwd on bot, but the RoverRuckus example uses X=Fwd, Y=Left.
                    If we start with the shell from ConceptVuforiaNavRoverRuckus.java, and put all images at
                    Code:
                    Translation=(0,0,0); Orientation {EXTRINSIC, XYZ, (90,0,0)}
                    ,
                    shouldn't this put the images in landscape mode facing Field -Y?
                    If we define bot ref frame as X=Right, Y=Fwd and then set camera in bot as
                    Code:
                    Translation (0,0,0) and Orientation {EXTRINSIC, YZX, (-90, 90, 0)}
                    , shouldn't camera be oriented with rear camera forward and top of phone pointing left on bot with lens at bot origin?

                    If so, when we square and align the camera lens pointed at center of image, I would expect the translation retrieved from the matrix
                    Code:
                    OpenGLMatrix robotLocationTransform = ((VuforiaTrackableDefaultListener)trackable.getListener()).getUpdatedRobotLocation();
                    to return Robot locations along field -Y. However, I am seeing the values in Z.
                    This is when values are printed with:

                    Code:
                     
                    VectorF translation = lastLocation.getTranslation();
                    telemetry.addData("Pos (in)", "{X, Y, Z} = %.1f, %.1f, %.1f",
                    translation.get(0) / mmPerInch, translation.get(1) / mmPerInch, translation.get(2) / mmPerInch);
                    Can you correct what I have wrong?

                    Thanks,
                    Stephen

                    Comment


                    • #11
                      Yes Z is the distance away from the phone.

                      Comment


                      • #12
                        suriono I understand that the raw Vuforia (and SDK modified) image in camera matrix will have the primary component of distance in Z. However, When the phone is rotated on the bot, I would not expect the bot In field matrix to be in Z, which is what is being reported with the setup described.

                        Comment


                        • #13
                          shelbyRobots
                          The new images should be released next week. Thank you for catching this issue. The new images have a "v2" in the text on the lower left hand corner to distinguish between the older (and incorrectly scaled) image targets.

                          Comment


                          • #14
                            shelbyRobots
                            The robot reference frame is user-defineable, but the phone reference frame is not. Phone axes are: {X=right, Y=top, Z=pointing out of screen}. When working out what rotations are needed to establish phone pose on robot, the phone must start with its X,Y,Z axes aligned with the X,Y,Z axes of the robot. So, for the examples you gave:

                            Robot axes {X=front, Y=Left}, Orientation {Extrinsic, XYZ, (90,0,0)}: Portrait mode, Back Camera facing robot-left (+Y)

                            Robot axes {X=right, Y=front}, Orientation {Extrinsic, YZX, (-90,90,0)}: Landscape mode, Back Camera facing robot-front (+Y)

                            Since you aren't using any translation, camera lens would be at robot 0,0,0 in each case.

                            When you did your testing of getUpdatedRobotLocation(), what have you used for the target position on field? If it is set to translation (0,0,0) and rotation (0,0,0), then getUpdatedRobotLocation() would just return the robot location relative to the target. Since the Target-Z axis points straight out of the target, that could explain why you're seeing Z values in your translation.

                            Comment


                            • #15
                              Tom Eng - Is there an ETA on the availability of the v2 image asset? We have a meeting tomorrow with the team, and I would like to have a test prior to the meeting. Thanks for your help.

                              Comment

                              Working...
                              X