CGAL users discussion list

[Rosen Diankov <>]

Hi Marc,

I really like your idea of maintaining the estimate of the angle as
arctan! So I would just return an Object that stores two values: (y,x)
internally, and will automatically call atan2(y,x) whenever the user
requests it to be converted to a decimal.

However, this means we would also have to accept these objects in the
"set joint values" function for the robot. Most users do something
like:

values = GetJointValues()
values[i] += offset
SetJointValues(values)

So if we want to maintain exactness, then the 'joint angle' object
would have to store the history of the math operations so that the
internal SetJointValues can process it exactly?

What helper objects does CGAL provide to do this?

thank you,
rosen,

2010/12/16 Marc Glisse 
<>:
> On Thu, 16 Dec 2010, Rosen Diankov wrote:
>
>> I understand your points about not using trigonometric functions as
>> much as possible. In fact, when dealing with pure geometry, it is
>> rarely necessary to deal with sin/cos/tan.
>>
>> Because OpenRAVE is a motion planning package, it requires two things:
>>
>> - converting a rotation around an axis to a quaternion (using sin and cos)
>> - solving the joint angle using atan2 (used in inverse kinematics)
>>
>> Unfortunately, the configuration space of the robot (ie joint angles)
>> is an inescapable reality.
>
> Do the angles really need to be explicit? The most convenient would be if
> angles were reprensented by their tan (or sin or cos) and the actual value
> of the angle in radians or degrees was only implicit (you could always
> output an approximation when asked).
>
> In CGAL, most questions we have to answer on the input are predicates with a
> discrete answer (yes/no, +/-/0, etc). And I guess that most of your motion
> planning is just that, except for outputting an approximate route at the
> end.
>
>> We're just getting into CGAL, so these questions were mostly for
>> figuring out what to expect when integrating CGAL into motion
>> planning. The idea of exactness and reliability is very attractive for
>> industrial-based applications.
>
> Note that one the main interests of the exactness is for internal
> consistency (if the tests tell you that a<b and b<c and c<a, your algorithm
> is likely to fail in various unpredictable ways, and this kind of
> inconsistency happens extremely easily). It might be quite ok to approximate
> the coordinates of the input once at the beginning (your first cos/sin,
> maybe keeping the constraint that cos^2+sin^2=1).
>
> --
> Marc Glisse
>
> --
> You are currently subscribed to cgal-discuss.
> To unsubscribe or access the archives, go to
> https://lists-sop.inria.fr/wws/info/cgal-discuss
>
>