I just wanted to let you know I modified your subject line. There was a typo that made a swear word which flagged your message for approval. I edited the word to the intended word “Pitch” and approved your question for posting. Have a good one.
bakkar90:
I have been looking up some stuff on the internet but i can’t understand the relationship between the values and have and the values i want to get.
I don’t understand your question. Please re-word it.
What values are you getting? What values would you like?
A problem (only the 1’st) is there’s no universal relationship btw a co-ordinate system and pitch, yaw and roll. Let’s take a simple example of an airplane. I will define (my arbitrary choice) the X axis to run from aft to forward (out the nose). The Y axis will run from wingtip to wingtip leaving the Z axis to run top to bottom. Using that co-ordinate system, roll is generally considered rotation about the X axis (wings waggle). Pitch is generally considered rotation about the Y axis (nose up/down) and yaw is generally considered rotation about the Z axis (unbanked turn). Now mount your 9DOF sensors in the airplane. There’s no reason the sensors X, Y, Z has to agree w/my definition. It’ll depend on how it’s mounted and even then it may be all the sensors won’t match. Each sensor will have it’s own co-ord system, perhaps differing from accel to gyro to magnetometer.
Now consider a rocket. I might define the X axis as from tail through nose, not unlike the plane. But what of Y and Z in a vehicle that’s symmetric like a rocket ? There’s no wrong choice (obey orthogonality and right hand rule for the axes), just the one you make. Also note that gravity (at launch) is aligned w/the X axis. In the plane (in normal flight), it’s w/the Z.
Confused ? Co-ordinate systems can be a real “pitch” to keep straight.
I didn’t know this yesterday but I speculated that “Each sensor will have it’s own co-ord system, perhaps differing from accel to gyro to magnetometer.” Turns out to be true given the diagram on the bottom of the Sensor Stick. So as codlink asked, you might want to give us a better idea of what you want to do and how the Sensor Stick is to be used.
@TS-Tim: Thanks for the correction and for posting.
@codlink: Well i have a 3D Gyroscope and i get reading out of it … are those readings the " Roll Pitch & Yaw " or do i have to do some calculations on them to get the " Roll Pitch & Yaw " ???
@Mee_n_Mac: Well as u posted the sensor X,Y and Z let me show what i did …
accel[0] = (((int) buff[3]) << 8) | buff[2]; // X axis (internal sensor y axis)
accel[1] = (((int) buff[1]) << 8) | buff[0]; // Y axis (internal sensor x axis)
accel[2] = (((int) buff[5]) << 8) | buff[4]; // Z axis (internal sensor z axis)
My question is that i want to get the " Roll Pitch & Yaw " from my gyroscope ???
Are they the raw data i have from the gyroscope or do i have to do some calculations on the raw data from the gyroscope to get the " Roll Pitch & Yaw " ???
Let me use a simple 1D example. First you define what the roll axis is and the mathematical relationship btw it and your sensors. To make it simple let me arbitrarily pick the X axis of the gyro to also be the roll axis or otherwise align the gyro X axis with the roll axis of whatever the sensor stick is going to be in. This way rotation about the gyro X axis is equivalent to rotation about the roll axis. No math needed.
Second … roll is an angle, a gyro outputs angular rate. To get angle from angular rate you integrate. That is you sample the gyro out at fixed time intervals, multiply the deg/sec gyro X output by the time interval to get how many degrees you rolled in that last interval and then maintain a running sum of all of the “incremental angles” to get the roll angle difference since the start of the integration process. I note the word difference since all you can ever know w/a gyro is the difference in angle from when you started. If you were rolled 10 deg at the start of the integration process, that angle won’t be in the “integrated” angle (unless you somehow know it and add it in).
The accuracy of your “integrated” roll angle will depend on a number of things but over a “long” period of time residual gyro bias (the gyro output even when there’s zero real roll rate) will result in gyro drift (Google it) and your “integrated” roll angle will build up an ever increasing error. That’s why people sometimes use accelerometers (as a tilt sensor, Google it) and magnetometers and “fuse” their outputs to mitigate the error sources inherent in each sensor type.
bakkar90:
the simley faces rep “8” not a smiley face sorry for that
That's the BBCode over achieving. There's a way to turn it off but I'm not recalling it. I think using a code box turns it off for the text in the box.
@Mee_n_Mac Thanks a lot for that detailed answer …
Well lets say i start from a certain position call it Po and i measure the values from the Accelerometer(Axi,Ayi and Azi) Gyroscope(Gxi,Gyi and Gzi) and Magnetometer(Mxi,Myi and Mzi) then i move to position P1 and read the values of Accelerometer(Axf,Ayf and Azf) Gyroscope(Gxf,Gyf and Gzf) and Magnetometer(Mxf,Myf and Mzf)
And simultaneously measure the time needed to move from Po to P1.
Assuming that we are using your assumption.
if we integrate the difference between (Gxi-Gxf) over the time we get the Roll.
Is that correct ???
Also would you happen to know a source/code so i could use it as a reference…
Move can mean either (or both at the same time) translational movement or rotational movement. If you translate w/o any rotation, the gyros will (in theory), read zero at all times and you can’t tell position 1 from position 0 using them. If you mean rotational movement from P0 to P1 you must have some readings btw P0 and P1 to integrate (assuming no motion when at P0 and at P1, that is P1 is your final resting position).
If P1 is just some small difference, incremental position while continuing to move to P final … then yes (maybe) P1 rotation angle = P0 angle + gyro@P1*(T1-T0).
And again there’s no general naming convention that associates sensor X, Y and Z to roll, pitch and yaw.
If the ideas of integration, linear acceleration/velocity/position, rotational acceleration/velocity/position, and right handed coordinate systems are foreign to you, then you might consider a comunity college course in physics. You might be able to get this from a book or website, but a human instructor would be much better.
You will also need to learn a tiny amount of calculus (numerical integration) but that you can get from a book or a website.
The accelerator part of the module might be used as an orientation sensor. But only if it is fixed in translation, and only rotated and centered on the center of gravity or hinge point. If the readings of the accelerator axis are calibrated, then you could use the value of the acceleration components and the arctangent/arcsine/arccosine function to calculate angles. The reading of the accelerator will be caused by the attraction of gravity if translation motion is fixed (and properly centered on the hinge). Any movement by hand or whatever would add an additional acceleration that cannot be measured or derived by the other sensors of this component. If the accelerator is not centered on the hingepoint or center of gravity, then centripetal force will add to the acceleration as it turns. And wil cause the wrong angle to be calculated. So, in short, it should not be accelerated and descelerated from one position to another. And only measured when stationary.
Maybe it helps to explain what sort of thing your are holding in space, and we can suggest alternate ways to measure orientation.
The magnetomer readings could also be used as a form of angular reference. As Earth’s magnetic polar shift won’t happen that quick (cue Twilight Zone theme) But it would be susceptible to variations in the local magnetic field where it is used. So it would behave differently if the object containing the sensor comes near large steel/iron objects like steel tables/bookcases or cars, or in the vicinity of powered magnetic coils/transformers. So it should be doable, but you’ll have to live with some discrepancies as to the real angle. But that is also apparent in the video. Quite some lag and wobbly motion.
I’ve no personal experience with IMU devices, or how you would program such a system. Just a bit about the physics involved. But I am sure the links provided sofar would get you in the right direction.
