-
• #2
You're right, that does seem strange. I'm seeing what you describe as well, and it does seem at odds with the datasheet. However I just looked and there's no inversion done in Espruino - those numbers are as they come from the sensor
-
• #3
Hi Gordon,
Currently, I use negative value of z component for adjusting this problem. Might the problem be fixed in the firmware for the future release?
Best regards
-
• #4
The issue is that fixing it would mean breaking other people's code that relies on it now, so probably not.
I'm looking at adding a universal API so I could fix it when I move over to that. However I'm still concerned that the data is exactly as comes off the accelerometer, which is contrary to what the datasheet says - unless somehow it has got configured to flip one axis.
-
• #5
Hi Gordon,
Thank you for your reply. I think that I will go through with the method I mentioned. And keep looking forward to your solutions. Thanks again :)
Hi All,
According to the description on page 18/115 of the "LSM6DS3TR-C.pdf", the x, y, z axis is following the principle of right-hand rule.
However, I just used
to get the corresponding acceleration values along the x,y,z axis to test 6 static poses of puck.js, i.e., +x, -x, +y, -y, +z, -z axis along with gravity direction. I got the coordinate system illustrated in the attached figure. This is not followed the right-hand rule. Is there something I missed?
1 Attachment