This forum has been archived. All content is frozen. Please use KDE Discuss instead.

[SOLVED] Quaternion to rotation test

Tags: None
(comma "," separated)
myguel
Registered Member
Posts
14
Karma
0
I don't know what is the politic of eigen concerning preconditions.
For the quaternion method:
toRotationMatrix()

I noticed that if the quaternion is not normalized the method returns a wrong matrix.
While it is possible to return the closest rotation matrix to a quaternion -but I think it is not the subject there- do you want to introduce assert when the methods are not valide?

If yes I propose the following piece of code in this case:

diff -r 2dcba9122a77 Eigen/src/Geometry/Quaternion.h
--- a/Eigen/src/Geometry/Quaternion.h Fri Jun 19 20:46:55 2009 +0200
+++ b/Eigen/src/Geometry/Quaternion.h Mon Jun 29 18:05:09 2009 +0200
@@ -303,11 +303,18 @@
return *this;
}

-/** Convert the quaternion to a 3x3 rotation matrix */
+/** Convert the quaternion to a 3x3 rotation matrix, the quaternion must
+ * be normalized before the method call for a valide rotation matrix to
+ * be returned.
+ * */
template<typename Scalar>
inline typename Quaternion<Scalar>::Matrix3
Quaternion<Scalar>::toRotationMatrix(void) const
{
+ //The quaternion should be normalized
+ //for the output of this function to be valide
+ ei_assert( ei_isApprox( coeffs().norm(), Scalar(1) ) );
+
// NOTE if inlined, then gcc 4.2 and 4.4 get rid of the temporary (not gcc 4.3 !!)
// if not inlined then the cost of the return by value is huge ~ +35%,
// however, not inlining this function is an order of magnitude slower, so


in the contrary, some doc is needed. I can help with the doc too.
I have added some information in the method description.

- sincerely
User avatar
bjacob
Registered Member
Posts
658
Karma
3

Re: Quaternion to rotation test

Mon Jun 29, 2009 5:36 pm
Thanks for reporting this. I modified the documentation as you suggested, to make it clear that the quaternion is meant to be normalized, but I didn't add an assertion. Indeed, we only use assertions to guard against bad memory accesses and other fatal errors. Basically, since assertions crash the program, we only use them to guard against errors that would likely result in a crash anyway (or something worse). So here, it's better to let the program continue running even with a wrong result. Also, that always spares the cost of evaluating the assertion condition, which is a minor advantage.


Join us on Eigen's IRC channel: #eigen on irc.freenode.net
Have a serious interest in Eigen? Then join the mailing list!


Bookmarks



Who is online

Registered users: Bing [Bot], Google [Bot], Sogou [Bot]