I think its a known problem about artoolkit .. this link <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.64.3894&rep=rep1&type=pdf">Robust Pose estimation from planar target</a> mentions some of those..<div>

The <font class="Apple-style-span" color="#663333">artoolkitplus</font> 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. <br>

<br></div><div>Eohan </div><div><br><div class="gmail_quote">On Mon, Nov 8, 2010 at 10:47 AM, Ivan Dryanovski <span dir="ltr"><<a href="mailto:ivan.dryanovski@gmail.com">ivan.dryanovski@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Steven,<br>
<br>
I'm not sure if this is exactly the problem you are observing, but I<br>
have noticed a similar behavior from ARToolkit before. When the camera<br>
is nearly perpendicular to the marker, and the marker is in the center<br>
of the image, there occurs a singularity. Let's say the angle between<br>
the marker normal and the optical axis is 1 degree - ARToolkit will<br>
arbitrary flip between +1 and -1 degrees. If you make the angle<br>
bigger, the orientation of the marker becomes less ambiguous, and the<br>
error diminishes.<br>
<br>
Ivan Dryanovski<br>
<br>
On Mon, Nov 8, 2010 at 9:00 AM, Herman Bruyninckx<br>
<<a href="mailto:Herman.Bruyninckx@mech.kuleuven.be">Herman.Bruyninckx@mech.kuleuven.be</a>> wrote:<br>
> On Mon, 8 Nov 2010, Steven Bellens wrote:<br>
><br>
>> 2010/11/8 Steven Bellens <<a href="mailto:steven.bellens@mech.kuleuven.be">steven.bellens@mech.kuleuven.be</a>>:<br>
>>> Hi,<br>
>>><br>
>>> I'm experimenting a bit with the ar_pose package. I'm using a single<br>
>>> fixed camera to track a moving marker. To verify the estimation<br>
>>> accuracy, I just leave the marker fixed and I've plotted position and<br>
>>> orientation estimates. The position estimates are pretty much<br>
>>> constant, but the orientation estimates are oscilating a lot (see<br>
>>> appendix), and apparently always between two values. Is this because<br>
>>> of the bad capability to estimate that orientation or can this be<br>
>>> caused by the environment conditions (light - set-up - distance to<br>
>>> marker)?<br>
>><br>
>> For clarity, plotted are the 4 components of a unit quaternion.<br>
><br>
> So...? What does a jump of "0.1" quaternion units mean? And is this meaning<br>
> the same for each of the four components?<br>
><br>
> The answer to this last question is probably "no", hence...?<br>
><br>
> Herman<br>
> _______________________________________________<br>
> ros-users mailing list<br>
> <a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
> <a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
><br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</blockquote></div><br></div>