[Rock-dev] RigidBodyState detecting invalid orientations

Mon Jul 2 15:06:53 CEST 2012

After a discussion the consensus was to imply that all components are 
responsible for normalising their quaternions before putting them on any 
output port. Therefore the isValid check will be extended by:

fabs(ori.squaredNorm()-1.0) < 1e-6;     //assuming at least single 
precision

Alex

On 07/02/2012 11:39 AM, Alexander Duda wrote:
> On 07/02/2012 09:08 AM, Felix Rehrmann wrote:
>> Hi all,
>>
>> I would like to propose to have a seperate function like 
>> isUnitQuaternion or similiar.
>>
>> One says that the rotation is not set,often because only position 
>> data are transmitted.
>> The other one is to check only the quaternion, which can also be 
>> non-unit for numeric reasons.
> Do you have a real use case for non-unit quaternions? I would favour 
> to use unit quaternions for all base types as convention to remove 
> another source of errors. In that case I would add the check insight 
> isValidValue
>
> Alex
>
>>
>> The user then would have the possiblity to decide what he wants to 
>> know. Furthermore
>> this function could have the accuracy as argument: bool 
>> isUnitQuaternion (double accuracy = 1e-6).
>> I would guess it could be hard to find a fixed value here. I would 
>> consider some deviation from 1.0
>> fine for further computation (e.g. like 0.9999something ).
>>
>> So long!
>>     Felix
>>
>>
>> Am 29.06.2012 18:43, schrieb Janosch Machowinski:
>>> Uhm,
>>>
>>> fabs(ori.squaredNorm() -1) < 1e-6
>>>
>>> Just as an idea ;-)
>>> Greetings
>>>     Janosch
>>>
>>> On 29.06.2012 17:58, Javier Hidalgo Carrió wrote:
>>>> On 06/29/2012 05:20 PM, Alexander Duda wrote:
>>>>> On 06/29/2012 05:02 PM, Javier Hidalgo Carrió wrote:
>>>>>> +1
>>>>>> Since Orientation is a Eigen::Quaternion we could even use the 
>>>>>> norm() method.
>>>>>>
>>>>>> Javier.
>>>>>>
>>>>>> Scalar 
>>>>>> <http://eigen.tuxfamily.org/dox/classEigen_1_1QuaternionBase.html#a844358c46408e878e60c4026c52eb1e9> 
>>>>>> norm 	( 	
>>>>>> 	) 	const|[inline]|
>>>>>>
>>>>>> *Returns:*
>>>>>>     the norm of the quaternion's coefficients 
>>>>>>
>>>>>> *See also:*
>>>>>>     QuaternionBase::squaredNorm()
>>>>>>     <http://eigen.tuxfamily.org/dox/classEigen_1_1QuaternionBase.html#a8699d72c996ca6cb4673e810fe3a616c>,
>>>>>>     MatrixBase::norm()
>>>>>>     <http://eigen.tuxfamily.org/dox/classEigen_1_1MatrixBase.html#a0be1b433c65ce9d92c81a4718daf54e5>
>>>>>>
>>>>>>
>>>>>>
>>>>> I think you do not gain so much from this functions as you will 
>>>>> get a scalar which you have to sum anyway. Do you know if there is 
>>>>> a function which checks if the quaternion is valid?
>>>>>
>>>> I don't know any valid method. Having no-normalized quaternion is 
>>>> sometimes common (e.g, passing a quaternion through a EKF) and 
>>>> normalization needs to be done.
>>>>> fabs(ori.w()*ori.w()+ori.x()*ori.x()+ori.y()*ori.y()+ori.z()*ori.z()-1.0) 
>>>>> < 1e-6
>>>>>
>>>> What should be the error threshold to define if a quaternion is 
>>>> valid or not? Perhaps norm() does some round to 1.00...
>>>>> Alex
>>>>>> On 06/29/2012 04:53 PM, Alexander Duda wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> the base type samples::RigidBodyState has a function to check if the
>>>>>>> orientation is valid.
>>>>>>> At the moment it only checks if the values of the quaternion
>>>>>>> representing the orientation are different to NaN.
>>>>>>>
>>>>>>> I propose that we also add a check that the quaternion is an unit
>>>>>>> quaternion because otherwise wrongly initialised orientations might lead
>>>>>>> to strange transformation matrices and vanishing objects in OSG.
>>>>>>>
>>>>>>> Any opinions?
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>           static bool isValidValue(base::Orientation const&  ori)
>>>>>>>           {
>>>>>>>               return !base::isNaN(ori.w())&&
>>>>>>>                   !base::isNaN(ori.x())&&
>>>>>>>                   !base::isNaN(ori.y())&&
>>>>>>>                   !base::isNaN(ori.z())&&
>>>>>>>
>>>>>>> ori.w()*ori.w()+ori.x()*ori.x()+ori.y()*ori.y()+ori.z()*ori.z()-1e6<  1;
>>>>>>>           }
>>>>>>>
>>>>>>
>>>>>>
>>>>
> -- 
> Dipl.-Ing. Alexander Duda
> Unterwasserrobotik
>
> DFKI Bremen
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-456620
> Fax:   +49 (0)421 178-454150
> E-Mail:alexander.duda at dfki.de
>
> Weitere Informationen:http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.:    DE 148646973
> Steuernummer:  19/673/0060/3
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

-- 
Dipl.-Ing. Alexander Duda
Unterwasserrobotik

DFKI Bremen
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-456620
Fax:   +49 (0)421 178-454150
E-Mail: alexander.duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20120702/912b89fb/attachment.htm 