Revision history [back]

I am tracking markers with cv::aruco. I have just updated to the newest version of this module, and i see that there is a new corner refine method, CORNER_REFINE_APRILTAG

Switching to this improves my marker detection a LOT. the range of marker detection has doubled. BUT, at the cost of speed. The detection is around 8 x slower it seems.

My question is, can i tweak the parameters to find a happy medium between robust detection and speed?

I see these options in aruco.hpp under detector params:

- aprilTagMinClusterPixels: reject quads containing too few pixels.
 * - aprilTagMaxNmaxima: how many corner candidates to consider when segmenting a group of pixels into a quad.
 * - aprilTagCriticalRad: Reject quads where pairs of edges have angles that are close to straight or close to
 *   180 degrees. Zero means that no quads are rejected. (In radians).
 * - aprilTagMaxLineFitMse:  When fitting lines to the contours, what is the maximum mean squared error
 *   allowed?  This is useful in rejecting contours that are far from being quad shaped; rejecting
 *   these quads "early" saves expensive decoding processing.
 * - aprilTagMinWhiteBlackDiff: When we build our model of black & white pixels, we add an extra check that
 *   the white model must be (overall) brighter than the black model.  How much brighter? (in pixel values, [0,255]).
 * - aprilTagDeglitch:  should the thresholded image be deglitched? Only useful for very noisy images
 * - aprilTagQuadDecimate: Detection of quads can be done on a lower-resolution image, improving speed at a
 *   cost of pose accuracy and a slight decrease in detection rate. Decoding the binary payload is still
 *   done at full resolution.
 * - aprilTagQuadSigma: What Gaussian blur should be applied to the segmented image (used for quad detection?)
 *   Parameter is the standard deviation in pixels.  Very noisy images benefit from non-zero values (e.g. 0.8).

Which of these could I adjust to improve speed?

Thanks!

I am tracking markers with cv::aruco. I have just updated to the newest version of this module, and i see that there is a new corner refine method, CORNER_REFINE_APRILTAG

Switching to this improves my marker detection a LOT. the range of marker detection has doubled. BUT, at the cost of speed. The detection is around 8 x slower it seems.

My question is, can i tweak the parameters to find a happy medium between robust detection and speed?

I see these options in aruco.hpp under detector params:

- aprilTagMinClusterPixels: reject quads containing too few pixels.
 * - aprilTagMaxNmaxima: how many corner candidates to consider when segmenting a group of pixels into a quad.
 * - aprilTagCriticalRad: Reject quads where pairs of edges have angles that are close to straight or close to
 *   180 degrees. Zero means that no quads are rejected. (In radians).
 * - aprilTagMaxLineFitMse:  When fitting lines to the contours, what is the maximum mean squared error
 *   allowed?  This is useful in rejecting contours that are far from being quad shaped; rejecting
 *   these quads "early" saves expensive decoding processing.
 * - aprilTagMinWhiteBlackDiff: When we build our model of black & white pixels, we add an extra check that
 *   the white model must be (overall) brighter than the black model.  How much brighter? (in pixel values, [0,255]).
 * - aprilTagDeglitch:  should the thresholded image be deglitched? Only useful for very noisy images
 * - aprilTagQuadDecimate: Detection of quads can be done on a lower-resolution image, improving speed at a
 *   cost of pose accuracy and a slight decrease in detection rate. Decoding the binary payload is still
 *   done at full resolution.
 * - aprilTagQuadSigma: What Gaussian blur should be applied to the segmented image (used for quad detection?)
 *   Parameter is the standard deviation in pixels.  Very noisy images benefit from non-zero values (e.g. 0.8).

I have tried changing aprilTagQuadDecimate to 1.2, or 1.5, and this helps, but adds quite a bit of jitter to the pose. Which of these could I is best to adjust to improve speed?speed, while keeping the maximum accuracy in pose estimation?

Thanks!