TagSLAM for ground robot

[Ryan Wong]

Hi Bernd,

May I know TagSLAM can produce good SLAM results for a ground robot? I've been trying to run the Online mapping after syncing odom (from my ground robot) and image timestamp in order to detect the tags. However, the pose from the dump is showing inaccurate poses with big differences.

My ground robot has a camera facing upward with 4 tags pasted on the ceiling. Tag-0 is with known pose (0, 0, 3.0) rotated with -3.14159261 radian; meaning it is pasted 3meters from the ground and rotated facing downward; same for other 3 tags. After running online mapping, I expect other 3 tags will be discovered with z value (ceiling height) and x rotation (facing downward) same/similar to Tag-0 but that's not the case. I've attached the result pose.xml for your reference.

Based on the guide at your website, there's "Measurements" section that states "Coordinate measurements are a way to impose constraints on the absolute coordinates of the corner of a given tag"; may I know if possible to use the distance & coordinate measurements to define all tags are always rotated at 3.14159261 and axis-z is always 3meters? I've tried this option but seems tagslam.yaml didn't accept these 2 parameters.

Hope to hear from you. Thank you.

Ryan.

[Bernd Pfrommer]

Ryan,

Yes, TagSlam can operate on a ground robot, there is no difference to other robots.

I can see the "z" value is not accurate, and the rotations are dubious. I suspect this has to do with image quality, lens, sensor resolution, calibration, or a combination of these.

First thing: could you post the debug image (topic "disp") of the apriltag detector? How confident are you in your calibration? What camera are you using (regular or fisheye)?

To answer your question: yes, you could force them to have the correct z-coordinate with a "coordinate measurement", see for instance example 13:

https://github.com/berndpfrommer/tagslam_test/blob/master/tests/test_13/tagslam.yaml

The other option is to actually specify the pose of the tag, but give a low noise in z direction, and a high noise in x and y. That will allow the optimizer to move the tag only in x and y. Same idea works for the rotations.

But that's something you want to do once you understand why the coordinates/rotations come out so poorly. So before you start forcing tags to their place, please post the debug images.

Thanks,

Bernd

[Ryan Wong]

Hi Bernd,

Thanks for your quick reply =). I'm using Raspberry Pi HQ "regular (not fisheye)" camera with following parameter: -

camera_model: pinhole

resolution: [1280, 960]

I've recalibrated my camera and retry with TagSlam but get similar poor results. Below is the link for my rosbag, hope you have time to take a look. 

https://drive.google.com/file/d/1yr3A9MYD2M4Ss5Xi_k92P4suPxkqTQWN/view?usp=sharing

Note: I tried to export only disp but encountered some error, so uploaded whole bag.

Ryan.

[Ryan Wong]

Hi Bernd,

I've tried both options to force tags to their place: 

(1) Set low/high noise and allow optimizer to move tags to correct place: I've tried this and the optimizer keeps throwing "optimizer crapped out!" after running Online mode for few seconds even after increasing the max_subgraph_error: 100000.0. Below is my setting with low noise at 0.0001 and high noise at 0.05.

     - id: 1
       size: 0.16
       pose:
         position:
           x: 0
           y: 0
           z: 3.0
         rotation:
           x: 3.1415927
           y: 0
           z: 0
         position_noise:
           x: 0.05
           y: 0.05
           z: 0.0001
         rotation_noise:
           x: 0.0001
           y:  0.0001
           z: 0.0001

(2) Use coordinate measurements: I've tried this option and seems to get a good result. However, to set both "z" value and rotation to fixed value, I had to define all 4 corners for each tag with length value=3meters, not sure if this is good practice? Btw, may I ask what is the meaning for direction: [0.0, 0.0, 1.0]?

- tag1_z0:
    tag: 1
    corner: 0
    length: 3.000
    noise: 0.001
    direction: [0.0, 0.0, 1.0]
- tag1_z1:
    tag: 1
    corner: 1
    length: 3.000
    noise: 0.001
    direction: [0.0, 0.0, 1.0]
- tag1_z2:
    tag: 2
    corner: 2
    length: 3.000
    noise: 0.001
    direction: [0.0, 0.0, 1.0]
- tag1_z3:
    tag: 3
    corner: 3
    length: 3.000
    noise: 0.001
    direction: [0.0, 0.0, 1.0]

On Thursday, September 29, 2022 at 1:54:09 AM UTC+8 bernd.p...@gmail.com wrote:

[Bernd Pfrommer]

Ryan,

From the bag I learned:

- the tags are fairly small and far away

- 1Hz image frequency: don't expect smooth pose estimates from this.

- adverse lighting conditions leading to long shutter times and motion blur

- a lens that has a lot of distortion. Can you please tell me exactly what lens you have on there? Focal length? Link to make/model? Just want to double check that the radtan model is indeed the right one. It probably is but given the large amount of distortion it would make sense to verify.

If you post your camera calibration (cameras.yaml), I can actually run tagslam myself on this data set. At least I can exclude user error as the source of the problem.

If you have done more than one calibration, please send me all, that way I can see how well they agree.

The vector [0, 0, 1] means this: take the currently estimated coordinates of the tag corner, project them onto the vector [0, 0, 1]. That gives you a number, let's call it L. The error to be optimized is:  noise * (L-length)^2. In your case it should only optimize the z coordinate then.

Not sure why the optimizer bombs out in the other case.

 

--
You received this message because you are subscribed to the Google Groups "tagslam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tagslam+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tagslam/782f4831-4645-47bf-9b2c-c6b6deb0d4edn%40googlegroups.com.

[Ryan Wong]

Hi Bernd,

I'm using Raspberry Pi HQ Camera with with 6mm Lens (Wide Angle):

https://static.raspberrypi.org/files/product-guides/Typical_CS-Mount_Lens_Guide.pdf 

I thought it may be due to the high resolution (1280x960) that caused the distortion so I've re-calibrate with 640x480 resolution; create a new bag with lower resolution and re-run TagSlam but didn't solve the problem (z value not accurate). I've attached both cameras.yaml.

[Bernd Pfrommer]

While I cannot promise you that all problems will disappear with better calibration, I am confident that your calibration is quite bad. Look at your distortion coefficients, they are huge! There is no point plowing ahead with a bad calibration. Whenever you see large distortion (meaning straight lines bending) near the edges of the image, and you get large distortion coefficients, there is a good chance you are dealing with a fisheye lens. Especially if it's advertised as a "wide angle" lens.

Fisheye lenses have a different projection model ("equidistant" vs "radtan"). You cannot compensate for the difference via barrel distortion, you need to use a different projection function.

Here's what you should do: use "Kalibr" with a pinhole-equi camera model:

https://github.com/ethz-asl/kalibr

It's a great tool for that. Note that occasionally it fails initialize, here is the workaround: https://github.com/ethz-asl/kalibr/issues/349

Most importantly Kalibr will produce a report that gives you reprojection errors. You want them to be virtually all inside 1pixel,  sothe "ball" off residuals on the last tab of the error report needs to look like a disk with radius <=1 (with occasional outliers), then you know you are good.

A successful equi-pinhole calibration will likely have very small distortion coefficients, like well less than 0.1, because the different projection function already covers the "distortion", so now the distortion coefficents only capture the deviation from the equidistant projection model. When you collect the bag with images for calibration make sure you cover all the corners, as far out as you can. You want to run the apriltag detector from tagslam (use the MIT detector, bordersize=2, otherwise it won't detect the Kalibr calibration board).

Good luck.

[Ryan Wong]

Thanks Bernd, will get another camera to try it again.

[Bernd Pfrommer]

Ryan, since you mention "another camera": I don't think there is anything wrong with the camera or the lens. In fact the fisheye lenses work particularly well for VIO when correctly calibrated. To speak of "distortion" incorrectly suggests that there is something wrong with the lens. The lens does not "distort", it just has a different projection function.

To view this discussion on the web visit https://groups.google.com/d/msgid/tagslam/3536b491-c0cf-4b60-8fc8-93c0444900edn%40googlegroups.com.

[Ryan Wong]

Ok, i get it now. Thanks for the clarification and save me the money and trouble to find another camera =). I will give a try on the kalibr tool.