11-26-2011 02:55 PM
I wrote a small c program reading out the x, y and z-components of the accelerometer, basically the same way as it is described in the provided NDK sample program. Everything works smoothly, but the direction of the g-force vector in z-direction points in the wrong direction, compared to the picture in the attached link.
If you put the playbook on a table in front of you, the reading of the z-component gives 1.0. However, according to the picture in the attached link it should give -1.0. The x- and y-components are correct. Is this a bug or is the x, y, z system in the NDK defined in a different way than in the HTML5 interface, from which I have taken the picture?
Thanks for any suggestion / explanation,
11-29-2011 10:46 AM
Usually when working with accelerometer data, the vector represents the direction of strongest force (in other words, if it's just gravity, think of a string with a weight dangling at the end that is attached to the back of the tablet). If the tablet is lying flat on a table, the strongest force is gravity, which is down through the table, or -1.0 in the Z axis as drawn in the image you reference.
11-29-2011 11:39 AM
The data returned in accelerometer.h is inconsistent with the description on the WebWorks page.
For something more consistent with that page, please refer to sensor.h in NDK 2.0. You should probably be using that from now on.
Hope this helps!
12-05-2011 03:18 PM
thanks for the hint to work with the sensor.h rather than the accelerometer.h. I gave it a shot and come up with the following results.
So far, obviously only the accelerometer, gyroscope, magnetometer, azimuth-pitch-roll-meter and the gravity reading are supported. The light sensor, altimeter, proximity-meter and the temperature reading are giving a "not supported" result.
What I find a little bit strange is that the directions of the x- and y-axes of the sensor.h and the accelerometer.h are exactly pointing into the opposite directions (sensor.h: x from right bezel to left bezel, y from top bezel to bottom bezel and z from front side to back side) but both are so called left-hand systems. Being a mechanical engineer myself I would have expected a right-hand system.
To make myself clear: I do not have problems using the sensor.h interface. I just want to give this comment back as a developer.
12-09-2011 11:38 AM
When putting a playbook flat on a table looking at it in landscape orientation, the sensor API gives x and y near 0 and a positive z vector showing that force is pushing up. the x-axis is positive from left to right and the y-axis is positive from bottom to top.
12-09-2011 04:24 PM - edited 12-09-2011 04:29 PM
yes, you are right, when the Playbook lays on a table in landscape orientation, the x- and y-accelerator readings are giving 0.0, since no acceleration is acting in these directions. The only acceleration acting in this position is the earth gravity, which accelerates into the table - you could see this, when you would take away the table, the Playbook would follow this acceleration and would fall to the ground (would not check it out though).
The z-acceleration reading is showing ~ +10 m2/s, which means that the positive z-axis is pointing from Playbook`s front to rear side or into the table.
Now, if you put the Playbook with the small side of the left bezel onto the table, while holding it vertically, then the x-acceleration reading of sensor.h is showing +10 m2/s, which means that the x-axis is pointing from the right to the left bezel.
And finally, if you put the Playbook with the small side of the bottom bezel onto the table, while holding it vertically, then the y-acceleration reading of sensor.h is showing +10 m2/s, which means that the y-axis is pointing from top to bottom bezel.
That is the opposite of what you are saying in your last post. Does your Playbook give different readings than mine or is your interpretation only the opposite?
12-12-2011 10:46 AM
I think you may be confusing gravity and acceleration?
When the playbook is resting face-up on a table, the table applies a positive (from back to front) acceleration in the Z axis which is counteracting gravity. This means +Z is upwards out of the screen, and -Z is through the back of the unit.
When you stand the playboox up in landscape mode, there is a positive Y acceleration (the table is pushing upwards). This means +Y is towards the volume buttons, and -Y is towards the power jacks.
When you rotate the playbook so it's left edge is down in portrait mode (volume buttons are now on the left), there is a positive X acceleration. This means +X is towards the right-hand speaker, and -X is towards the left-hand speaker.
This organization represents a right-handed axes orientation.
12-13-2011 03:22 PM - edited 12-13-2011 03:26 PM
Yes, you are right. I too much looked at the acceleration reading from a physical point of view and not so much from a measuring technique point of view. Taking the used measuring technique into account, I can see that the accelerator is giving the acceleration relative to the earth gravity. Therefore, the accelerator of the Playbook reads +10 m2/s in z-direction when placed on a table and would show 0 m2/s during the falling phase, when you would let it fall to the ground.
In the meantime, I wrote a small program which saves the maximum acceleration value in all three axes during an acceleration event. When you accelerate with roughly 10 m2/s in all three directions, it shows +10m2/s in x-direction, +10m2/s in y-direction and +20m2/s in z-direction. This confirms your description of the axis directions and the reference to the earth gravity.
Thanks for your support,