Difference between revisions of "Localizing with AprilTags"

From Lofaro Lab Wiki
Jump to: navigation, search
(How the Module Performs Localization)
(How the Module Performs Localization)
Line 64: Line 64:
 
'''Step 5: Run Transformations'''
 
'''Step 5: Run Transformations'''
  
The module runs transforms on the global and local tag positions to determine the global position of the camera of POLARIS and thus the global position of the device. For every tag viewed in this cycle, we obtain a localization data point consisting of the x,y, and orientation of POLARIS.
+
The module runs transforms using the global and local tag positions to determine the global position of the camera of POLARIS and thus the global position of the device. For every tag viewed in this cycle, we obtain a localization data point consisting of the x,y, and orientation of POLARIS.
 +
First the local x,y,z values of the viewed tag obtained through the AprilTags module are transformed using the RPY values for that specific tag in order to find the tags position in reference to a local plane that is parallel to the global frame plane. Next the camera local position is obtained with respect to this viewed tag's center as the origin by simply negating the x,y,z values of the tag's local frame position. Finally, the camera's local frame position is shifted by the tag's global frame position values that were obtained from the LUT, such that we are able to obtain the global frame position of the camera. Because the camera is attached to POLARIS, we have found the global frame position of POLARIS and any device/user carrying POLARIS.
  
 
[[File:transforms.jpg]]
 
[[File:transforms.jpg]]

Revision as of 00:05, 21 May 2015

HowLocalize.jpg

Our method of indoor localization utilizes a module with a ceiling-facing camera that recognizes glyph markers on the ceiling. The glyph markers on the ceiling each have unique IDs corresponding to positions in the global map of the area that the module is localizing in.

In order to make our localization method possible, we needed to determine a practical glyph recognition system to use. We have chosen to use AprilTags as our glyph recognition system due to its robustness in accurate recognition of its tags. The AprilTags system provides quick scale-invariant and rotation-invariant recognition of its tags and will therefore prove very useful to our indoor localization project as our chosen glyph recognition system. AprilTags was developed at the University of Michigan by Professor Edwin Olson. Check out the AprilTags wiki here.









Chosen AprilTags Family

AprilTags has several tag families. We originally did testing with the 36h11 tag family. But later also considered using the 16h5 tag family instead. In the end, we decided on using the 36h11 tag family. The naming convention for tag families, for example "36h11", have the number of data bits in a member tag of the family, in this case 36, followed by the minimum hamming distance between two tags of the same family, in this case 11.

TagFams.jpg

Four member tags from each of the two AprilTags families pictured.

Hamming Distance

It is desired to have a high hamming distance between members of the chosen tag family because hamming distance, by definition, is the number of positions at which two symbols are different. Therefore, a high hamming distance leads to less of a chance of recognizing one tag as a different tag. This is one reason why the 36h11 tag family is more desirable to use than the 16h5 tag family.

Family Size

Another reason we chose the 36h11 tag family instead of the 16h5 tag family is because the 16h5 tag family only has 30 tag members, while the 36h11 tag family has 586 tag members. We must cover the ceilings of two floors of the engineering building, therefore we need a lot of glyphs. Our strategy to use pairs of tags from a given family, means we can have N^2 amount of spots marked by tags for a tag family with N members. This means that even with our tag pair strategy, the 16h5 tag family can only cover 900 spots. The 36h11 tag family, has the potential to cover 343396 spots. This was the deciding factor for why we chose the 36h11 tag family, not only will it provide more accurate tag recognition, but it will also provide us with the ability to localize more area than we will even need to localize.

Complexity

One con in choosing the 36h11 tag family over the 16h5 tag family is that the 36h11 tag family has more data bits and is therefore more complex. Because we are manually making the tags with stencils and spray-paint, the stencils will therefore have to be carved out to a higher complexity for each tag that we use from the 36h11 tag family relative to the 16h5 tag family. However, the pros of using the 36h11 tag family still outweigh the cons.

How the Module Performs Localization

The following steps are repeated in cycles as long as the program is run:

Step 1: Find tags

The module recognizes every tag in its field of view that the camera can recognize with AprilTags.

Step 2: Store Data

The module stores the roll, pitch, and yaw (RPY) of all newly recognized tags in data arrays that hold the data of the 8 most recent tags.

Step 3: Run Moving Average Filter on RPY

The module runs a moving average filter with a window size of 10 on the RPY data of the 8 most recently recognized tags. This alleviates the effects of noise that cause jumps in the RPY data of tags collected using AprilTags.

Step 4: Obtain Global Tag Pose Data

The module reads the pre-collected Look-Up Table (LUT) to obtain the global x,y,THETA,z values of the tags recognized in this particular cycle of the localization.

Step 5: Run Transformations

The module runs transforms using the global and local tag positions to determine the global position of the camera of POLARIS and thus the global position of the device. For every tag viewed in this cycle, we obtain a localization data point consisting of the x,y, and orientation of POLARIS. First the local x,y,z values of the viewed tag obtained through the AprilTags module are transformed using the RPY values for that specific tag in order to find the tags position in reference to a local plane that is parallel to the global frame plane. Next the camera local position is obtained with respect to this viewed tag's center as the origin by simply negating the x,y,z values of the tag's local frame position. Finally, the camera's local frame position is shifted by the tag's global frame position values that were obtained from the LUT, such that we are able to obtain the global frame position of the camera. Because the camera is attached to POLARIS, we have found the global frame position of POLARIS and any device/user carrying POLARIS.

Transforms.jpg

Step 6: Weighted Average of Localization Data

The localization data from every viewed tag is averaged out using a weighted average that allows a smaller weight for tags that are further away. This allows for one localization data point of x, y, z, and YAW to be obtained for POLARIS.

Step 7: Moving Average of Global Position

The global position of POLARIS is run through a moving average filter with a window size of 5 to obtain the final localization data of POLARIS that is output by the localization module.

POLARIS Level II Diagram

Polarisdiagram.jpg