[Rock-dev] RigidBodyState detecting invalid orientations

Janosch Machowinski Janosch.Machowinski at dfki.de
Fri Jun 29 18:43:32 CEST 2012


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;
>>>>           }
>>>>
>>>
>>>
>
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev


-- 
  Dipl. Inf. Janosch Machowinski
  SAR- & Sicherheitsrobotik
  
  DFKI Bremen
  Robotics Innovation Center
  Robert-Hooke-Straße 5
  28359 Bremen, Germany
  
  Phone: +49 (0)421 178 45-6614
  Fax:   +49 (0)421 178 45-4150
  E-Mail: robotik 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
  -----------------------------------------------------------------------

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20120629/81ef1bea/attachment-0001.htm 


More information about the Rock-dev mailing list