4

I'm accessing the Kinect Accelerometer in c++ via openFrameworks and ofxKinect and am having some issues with certain angles. If I pitch the kinect 90 degrees downwards I get nan values. I had a look at the getAccelPitch() method and this kind of makes sense since asin will return 0 when there will be values greater than 9.80665 divided by 10.1/9.80665.

The main problem though is after I pitch the device 90 degrees, the roll doesn't seem reliable(doesn't seem change much). In my setup I will need to have the device pitched 90 degrees but also know it's new roll.

Any hints,tips on how I may do that ? Is there an easy way to get the data to draw the kinect's orientation with 3 lines(axes).

I'm trying to detect orientations like these: k1

k2

k3

k4

George Profenza
  • 50,687
  • 19
  • 144
  • 218

1 Answers1

3

The problem is that you are using Euler angles (roll, pitch and yaw).

Euler angles are evil and they screw up the stability of your app, see for example

They are not useful for interpolation either.

A solution is to use rotation matrices instead. A tutorial on rotation matrices is given in the

Direction Cosine Matrix IMU: Theory

manuscript.

Community
  • 1
  • 1
Ali
  • 56,466
  • 29
  • 168
  • 265
  • +1 Thank you for the handy literature ! I'll read through in detail, on a first look this looks like exactly what I need. – George Profenza Aug 20 '12 at 14:19
  • I don't know the framework / libraries you are using but I guess they implement rotation matrices so you have the necessary function readily available. Good luck anyway! – Ali Aug 20 '12 at 14:44
  • Correct, there are implementations of 3x3 and 4x4 matrices, but I can't figure out how I can plug in the accelerometer values at the moment. I'll read the document again. The setup is a little bit different since I'm not using extra data from a GPS, but also simpler then the setup proposed in the paper since I won't need to worry about centrifugal force/etc. Am I missing something obviously simple ? – George Profenza Aug 20 '12 at 16:03
  • @GeorgeProfenza There are two points. (i) The 4x4 matrix is likely to be an OpenGL matrix or something like it. Whatever you do, you should leave the 4. row and 4. column of the 4x4 matrix untouched. The first 3 row and the first 3 column of it is the rotation matrix. I have no idea what you are doing or what these frameworks / libraries are that you are using. So I cannot tell you what you need in that implementation, the 4x4 matrix or the 3x3 matrix. – Ali Aug 20 '12 at 18:43
  • @GeorgeProfenza The second point. How to get the rotation matrix from the accelerometer values, that is a new, standalone question and has nothing to do with your original question. You should post a new question, explaining what you are doing, and then ask it. – Ali Aug 20 '12 at 18:48
  • I'm can work with rotation matrices. My question was how I can reliably get rotations from accelerometer data. You pointed me to a handy document, but as far as I can understand, they've got the data split like this: Accelerometer vector = gravity, as seen in body frame - acceleration, as seen in body frame. The rotation matrix is extracted from another equation where the rotation matrix multipled by the accelerometer vector = gravity, as seen in earth frame and acceleration, as seen in earth frame. That of course, in their context, of a UAV with accelerometer and GPS... – George Profenza Aug 20 '12 at 20:30
  • In my case I don't think both gravities are the same, and I probably have one other acceleration (rather than two: in body frame and earth frame), but not entirely sure how to deal with the equation. I in a loop a bit: I know I can create a matrix and apply rotations to it, but to apply a rotation I need an angle and the way I got the angle so far was using asin(accelerometerValue/G) - but that would give me the Euler angle for an axis, so I think I'm missing the point :( – George Profenza Aug 20 '12 at 20:33
  • This discussion is getting REALLY long and has nothing to do with your original question. I linked Direction Cosine Matrix IMU: Theory as a tutorial on rotation matrices. Read the rotation matrix part only. It is likely that the rest of that document doesn't apply to you. If you have further questions, please ask it in a new question and I promise I will give it a shot to answer that. – Ali Aug 20 '12 at 21:30
  • As I mentioned before, I appreciate the materials provided. They do help, but do not solve/answer my question. My main question isn't about gimbal lock or rotation matrices per se, it's mainly about dealing with accelerometer limitations. Since Kinect offers only an accelerometer, but no other sensors (like gyro/magnetometer/gps) it's technically not an IMU. I can post another question on "How to get the rotation matrix from the accelerometer values" but I guess the answer is it can not be done reliably (mapping 360 on ZYZ). If you know this to be possible, let me know and I will gladly post. – George Profenza Aug 23 '12 at 13:24
  • 1
    @GeorgeProfenza If you only have accelerometers then you can get the tilt angles but not the rotation matrix. Just think about it: There is no way to detect rotation around the vertical axis with the accelerometers only, it is invisible to them. – Ali Aug 23 '12 at 14:40