My collegue Ingo is working on an improved version of ARToolkit Plus for
the ros community, so if you can wait a few weeks, things might get
better. (subpixel accuracy, adaptive thresholding etc.)
Generally, ARToolkit is not too good, its not estimating
subpixel-accurate and only taking the 4 outer corners for the estimation
of the homography. So you should expect the orientation to jump a lot.
Additionally, the distance will be pretty noisy and have a systematic
dependency on the shutter, gain and your threshold, as only the outside
edge from white to black is taken into consideration.
I worked with 12.5x12.5mm ARToolkit markers to detect drawer and cabinet
handles for a week or two, using PR2 forearm camera (we now have some
pcl method for detecting handles). This worked, but I wouldn't bother
looking at the orientation you get. Sometimes the orientation jumped
between something reasonable and 'the marker pointing directly to the
camera'. I had to filter this out and then averaged over 20 frames or so
and would still end up with around +-3 cm distance error and a bad
orientation. Watch out - averaging quaternions is not necessarily
trivial. The markers were however very small, maybe 1% of the image area
or even less.
Tom
from TUM
On 11/08/2010 05:10 PM, Eohan George wrote:
> I think its a known problem about artoolkit .. this link Robust Pose
> estimation from planar target
> <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.64.3894&rep=rep1&type=pdf> mentions
> some of those..
> The artoolkitplus has a robust pose estimate api which "reduces" this
> problem. However, I did see this issue to a smaller extent even with
> rpp. I am not sure if I was using it the wrong way though.
>
> Eohan
>
> On Mon, Nov 8, 2010 at 10:47 AM, Ivan Dryanovski
> <ivan.dryanovski@gmail.com <mailto:ivan.dryanovski@gmail.com>> wrote:
>
> Steven,
>
> I'm not sure if this is exactly the problem you are observing, but I
> have noticed a similar behavior from ARToolkit before. When the camera
> is nearly perpendicular to the marker, and the marker is in the center
> of the image, there occurs a singularity. Let's say the angle between
> the marker normal and the optical axis is 1 degree - ARToolkit will
> arbitrary flip between +1 and -1 degrees. If you make the angle
> bigger, the orientation of the marker becomes less ambiguous, and the
> error diminishes.
>
> Ivan Dryanovski
>
> On Mon, Nov 8, 2010 at 9:00 AM, Herman Bruyninckx
> <Herman.Bruyninckx@mech.kuleuven.be
> <mailto:Herman.Bruyninckx@mech.kuleuven.be>> wrote:
> > On Mon, 8 Nov 2010, Steven Bellens wrote:
> >
> >> 2010/11/8 Steven Bellens <steven.bellens@mech.kuleuven.be
> <mailto:steven.bellens@mech.kuleuven.be>>:
> >>> Hi,
> >>>
> >>> I'm experimenting a bit with the ar_pose package. I'm using a
> single
> >>> fixed camera to track a moving marker. To verify the estimation
> >>> accuracy, I just leave the marker fixed and I've plotted
> position and
> >>> orientation estimates. The position estimates are pretty much
> >>> constant, but the orientation estimates are oscilating a lot (see
> >>> appendix), and apparently always between two values. Is this
> because
> >>> of the bad capability to estimate that orientation or can this be
> >>> caused by the environment conditions (light - set-up - distance to
> >>> marker)?
> >>
> >> For clarity, plotted are the 4 components of a unit quaternion.
> >
> > So...? What does a jump of "0.1" quaternion units mean? And is
> this meaning
> > the same for each of the four components?
> >
> > The answer to this last question is probably "no", hence...?
> >
> > Herman
> > _______________________________________________
> > ros-users mailing list
> > ros-users@code.ros.org <mailto:ros-users@code.ros.org>
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org <mailto:ros-users@code.ros.org>
> https://code.ros.org/mailman/listinfo/ros-users
>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
(text/plain)