I don’t believe that @Simeon is using the third one (since he typically directly implements Apple’s API), but I’m running some tests now (in Obj-C) to find the difference.
I got a bit off task (and having to go), so I didn’t follow through with the exact measurements (sorry!), but Apple suggests using CMDeviceMotion. This is because CMGyroData is the raw data from the gyroscope. The rotation rate in CMDeviceMotion has calculations applied to it to make it more precise. An example of something that might skew the measurements (from the iOS 6 Programming Cookbook) is the device heat.
Hope that helps. Sorry I don’t have solid data to base my hypothesis.
Thanks, but that’s not the distinction I’m most interested in. It’s the distinction between one of those and the
CMAttitude data that I really want to know about. I want to convert the
RotationRate to a quaternion and before doing so I need to know what the data represents. The distinction between CMGyroData and CMDeviceMotion is a distinction of bias, not of encoding, so the conversion would be the same for both. But CMAttitude is a different encoding so needs a different conversion.
@Andrew_Stacey - At this points, I’m guess, but I think it’s represented as RotationRate because (as I said before), Simeon tends to directly give the Codea script the direct implementation of what Apple gives you. But I wouldn’t trust that since I can’t test it right now. Sorry! If Simeon doesn’t answer and I’ve got a bit of extra time (unlikely) I might try and look into it a bit more. I’m interested in improving the tilting mechanism in StackIt, so it’d be helpful to know so I know what I’m doing.
Have anyone used RotationRate with Gravity to fix issues with drift and figure out what direction that is up?
@tnlogy I’ve tried to do this a few times. I’m trying to make it more precise, hence the question. I don’t remember off-hand if my project “SteadyCube” on CC uses RotationRate or just Gravity.