Add Support for legacy ARToolkit family

[atuleu]

I am working on the new iteration of realt-time ant tracking system that was originally build using artoolkit, and the apriltag2. It would be nice for us in the future to upgrade to apriltag3.

However the version 3 has dropped the support for artoolkit family. Even if we try at the moment to move to tag36h11 and tag36h10 families for the future, it would be nice for us to still be able to use if possible the artoolkit tags.

Is there any technical difficulties to add support to import the previous tag36artoolkit family back in Apriltag3 ? I noticed that a few new field appeared in the apriltag_family_t structure. What would be the good new value for those fields.

Also does the opaque void* impl pointer changed for version 2 to version 3 ?

I can contribute to do this port as it is required for my project. Maybe the best place for such a port would be in its own aprilttag-img-legacy repo, to indicate that this is a clearly depreceated feature.

[mkrogius]

Hi,

There should not be too many technical difficulties, the main thing is just to update the c file for the artoolkit tag. Most of the values can be taken from the current implementation of the tag36h11 family. The main work is to shuffle the bits in each of the code values to line up with the new order in which the bits are read from the tag. I would be ok with this family remaining in the current repo.

Best, Max

[atuleu]

I am reviewing the code and from what I understand, the order you read the bit is completely shuffled. Is there any reason to this (I tried to find it in your IROS 2019 paper, but it is still unclear).

Woudl it not be simpler to just reassign the bit_x bit_y values to read the bit sequentially and leaves the code the same ?

[mkrogius]

You are asking the right question. The answer is that we have a function, rotate90, which gives us the bits in a tag as if it were rotated 90 degrees. This is used for decoding tags, since we may not always have upright images of tags. We had to come up with an order of bits that would allow rotate90 to work for any tag shape. The bits are now read one quadrant at a time s.t. it requires (mostly) just a simple bit shift to do rotate90.

I started thinking about how it worked and decided to just write up a quick program to do the conversion. Check out the artoolkit branch on the detector repo and let me know if you find any bugs with it.

[mkrogius]

@atuleu Have you had a chance to try it out?