Le 09/02/2013 15:39, Roman Haefeli a écrit :
I believe it is (unfortunately) not as simple as that. When you rotate with [rotateXYZ], the three axis are not always perpendicular to each other. For instance, if you set Y to 90, the X and the Z rotate around the same axis.
every rotation keep the 3 axes perpendicular. but rotateXYZ do 3 rotations, X, Y and Z, in this order.
if you rotate 90° in Y, Z axe became what use to be the X axe. so rotation in Z after a 90° rotation in Y is the same than a rotation in X before the Y rotation. that's the gimbal lock.
but after the Y rotation, a X rotation is not the same than a Z rotation.
if you don't believe me, you can try : gemhead rotate X 0 Z rotate 0 90 0 cube
X and Z are still (and will always be) perpendicular.
However, the gyroscope (at least the one from Wiimote MotionPlus and most likely also the one from your phone) consists of three separate sensor which are perpendicular to each other at any time.
If I understand Fero correctly, he would like to use the sensors so he can control an object in Gem that follows exactly the orientation of his phone. I also tried that once with a Wiimote and Gem but I couldn't wrap my head around the two concepts of [rotateXYZ] and the gyro sensors.
gyro sensors give rotation speed. not absolute rotation. in theory (with infinite acurate sensors, no drift etc), you have to do a feedback loop (using gemlist_info), so that the current rotation is modify by the sensors value. (rotation did not sums up)
cheers c
Anyone enlightened might be able to shed some light on this confusion?
Roman
On Sam, 2013-02-09 at 15:18 +0100, Cyrille Henry wrote:
hello,
rotateXYZ is doing : rotation X then rotation Y then rotation Z
this is not the same than : rotation Z rotation Y rotation X
So, depending on how works your orientation sensors, you could have to change the rotation order.
you can try, using 3 rotateXYZ object.
cheers c
Le 09/02/2013 14:45, Fero Kiraly a écrit :
I have 3 axis accelerometer and 3 axis orientation sensor in my device. So i can get 0 - 360 deg on X, Y and Z.
When I draw in GEM a rectangle, I am able to rotate it with each of 3 axes, but only separately. When I try it with all three axes together it has strange movements, so I guess it has something with gimbal lock.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sam, 2013-02-09 at 16:41 +0100, Cyrille Henry wrote:
Le 09/02/2013 15:39, Roman Haefeli a écrit :
I believe it is (unfortunately) not as simple as that. When you rotate with [rotateXYZ], the three axis are not always perpendicular to each other. For instance, if you set Y to 90, the X and the Z rotate around the same axis.
every rotation keep the 3 axes perpendicular. but rotateXYZ do 3 rotations, X, Y and Z, in this order.
if you rotate 90° in Y, Z axe became what use to be the X axe. so rotation in Z after a 90° rotation in Y is the same than a rotation in X before the Y rotation. that's the gimbal lock.
but after the Y rotation, a X rotation is not the same than a Z rotation.
if you don't believe me, you can try : gemhead rotate X 0 Z rotate 0 90 0 cube
X and Z are still (and will always be) perpendicular.
Ok, this makes sense to me now. Thanks.
However, the gyroscope (at least the one from Wiimote MotionPlus and most likely also the one from your phone) consists of three separate sensor which are perpendicular to each other at any time.
If I understand Fero correctly, he would like to use the sensors so he can control an object in Gem that follows exactly the orientation of his phone. I also tried that once with a Wiimote and Gem but I couldn't wrap my head around the two concepts of [rotateXYZ] and the gyro sensors.
gyro sensors give rotation speed. not absolute rotation.
Yeah, right. But you can add the values up to get rotation (of course, it's always rotation relative to itself, which will obviously drift from reality over time).
in theory (with infinite acurate sensors, no drift etc), you have to do a feedback loop (using gemlist_info), so that the current rotation is modify by the sensors value. (rotation did not sums up)
...parsing solution .... beep...... stack overflow (in my head)!
You mean you add each increment (gyro measurement) to the rotation separately, then get the orientation with gem_list info, add the next increment to the orientation, get orientation again, add increment etc? Can you cast that into a little Gem example patch, if it is not too much trouble?
Roman
Le 09/02/2013 21:11, Roman Haefeli a écrit :
On Sam, 2013-02-09 at 16:41 +0100, Cyrille Henry wrote:
Yeah, right. But you can add the values up to get rotation (of course, it's always rotation relative to itself, which will obviously drift from reality over time).
yep. drift usually make this useless.
in theory (with infinite acurate sensors, no drift etc), you have to do a feedback loop (using gemlist_info), so that the current rotation is modify by the sensors value. (rotation did not sums up)
...parsing solution .... beep...... stack overflow (in my head)!
You mean you add each increment (gyro measurement) to the rotation separately, then get the orientation with gem_list info, add the next increment to the orientation, get orientation again, add increment etc? Can you cast that into a little Gem example patch, if it is not too much trouble?
yes. see attachment. cheers c
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Son, 2013-02-10 at 10:16 +0100, Cyrille Henry wrote:
You mean you add each increment (gyro measurement) to the rotation separately, then get the orientation with gem_list info, add the next increment to the orientation, get orientation again, add increment etc? Can you cast that into a little Gem example patch, if it is not too much trouble?
yes. see attachment.
Hey Cyrille, just before I read your mail I figured it out myself. The trick (as also shown in your patch) is to use one [rotateXYZ] for adding the increments and another one for setting the current orientation received from [gemlist_info]. You really triggered an 'aha' kind of moment in my head. Thank you for that.
Roman
Le 10/02/2013 13:54, Roman Haefeli a écrit :
On Son, 2013-02-10 at 10:16 +0100, Cyrille Henry wrote:
You mean you add each increment (gyro measurement) to the rotation separately, then get the orientation with gem_list info, add the next increment to the orientation, get orientation again, add increment etc? Can you cast that into a little Gem example patch, if it is not too much trouble?
yes. see attachment.
Hey Cyrille, just before I read your mail I figured it out myself. The trick (as also shown in your patch) is to use one [rotateXYZ] for adding the increments and another one for setting the current orientation received from [gemlist_info].
yes, and the order of the 2 rotation is important : if the sensors are relative to the object, the rotation should be in the object referential, so the sensors rotate is on top of the object. if you have a global rotation (like one would want when changing a view point with the moose), then the rotation should be next to the gemhead.
You really triggered an 'aha' kind of moment in my head. Thank you for that.
;-)
cheers c
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list