使用 iPhone 4 上的陀螺仪补偿指南针滞后
我一直在 iPhone 4 上试验指南针和陀螺仪，并希望获得一些帮助来解决我遇到的问题。我想通过使用陀螺仪的数据来补偿指南针的缓慢。
使用 CMMotionManager 及其 CMDeviceMotion 对象 (motionManager.deviceMotion)，我获得了 CMAttitude 对象。如果我错了，请纠正我（请），但这是我从 CMAttitude 对象的 yaw 属性推断出来的（我不需要 pitch< /code> 也不是 roll 出于我的目的）：
- 当手机指向下方时，
yaw范围从0到PI（如deviceMotion.gravity.z所示），逆时针摆动， - 当设备指向上方时，顺时针摆动
0至-PI，< code>yaw 的范围分别是从-PI到0和PI到0，并且 - 从指南针数据（我正在使用
locationManager.heading.MagneticHeading），我看到指南针提供从0到360的值，其值为顺时针摆动时增加
好吧，所以综合使用所有这些信息，我能够得到一个我称之为水平的值，无论设备指向向上还是向下，都会给出以下值： 0 到 360 并在设备顺时针摆动时增加（尽管当 deviceManager.gravity.z 位于 附近时我仍然遇到问题0——yaw 值在这个 gravity.z 值下变得异常）。
在我看来，我可以使用映射到 MagneticHeading< 的计算出的 horizontal 值来“同步”horizontal 和 MagneticHeading 值。 /code>，当我感觉指南针已经“跟上”时，将horizontal值“同步”到magnetHeading。
所以我的问题是：
- 我是否走在正确的轨道上？
- 我是否正确使用了来自
CMDeviceMotion的陀螺仪数据以及上面列出的假设是否正确？ - 为什么当
gravity.z位于0附近时，yaw会出现异常？
非常感谢。我期待听到您的答案！
I've been experimenting with the compass and gyroscope on iPhone 4 and would like some help with an issue I'm having. I want to compensate for the slowness of the compass by using data from the gyroscope.
Using CMMotionManager and its CMDeviceMotion object (motionManager.deviceMotion), I get the CMAttitude object. Correct me if I'm wrong (please), but here is what I've deduced from the CMAttitude object's yaw property (I don't need pitch nor roll for my purposes):
yawranges from0toPIwhen the phone is pointing downwards (as indicated bydeviceMotion.gravity.z) and swinging counterclockwise and0to-PIwhen swung clockwise- when the device is pointing upwards,
yawranges from-PIto0andPIto0, respectively - and from the compass data (I'm using
locationManager.heading.magneticHeading), I see that the compass gives values from0to360, with the value increasing when swinging clockwise
All right, so using all of this information together, I'm able to get a value I call horizontal that, regardless of whether the device is pointing up or down, will give values from 0 to 360 and increase when the device is swung clockwise (though I am still having trouble when deviceManager.gravity.z is around 0 -- the yaw value freaks out at this gravity.z value).
It seems to me that I could "synchronize" the horizontal and magneticHeading values, using a calculated horizontal value that maps to magneticHeading, and "synchronize" the horizontal value to magneticHeading when I feel the compass has "caught up."
So my questions:
- Am I on the right track with this?
- Am I using the gyro data from
CMDeviceMotionproperly and the assumptions I listed above correct? - Why might
yawfreak out whengravity.zis around0?
Thank you very much. I look forward to hearing your answers!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
只是想回答...如果我错了请纠正我..
1.是的，你走在正确的轨道上
2.CM中的重力已经与用户重力“隔离”（由用户加速度引起的重力值），这就是为什么有两个重力，“gravity”和“userAcceleration”其在Apple CM文档中
// 注意：并非完全隔离 //
3.
如果重力为 0，则意味着相应的轴与重力垂直。
gravity.z是iPhone屏幕，这就是为什么如果你把屏幕直立放在桌子上，它是-9.82m/s2，实际上由于传感器噪音，很难得到0或重力最大值（这是正常的，所有传感器都有一个噪音特别便宜的传感器）。
我在我的应用程序上所做的是将我的参考轴切换到其他轴（在您的情况下可能是 x 或 y）以达到某些限制，策略如何取决于目的或哪一侧是您的参考。
另外，陀螺仪速度快，但不稳定，需要每隔一段时间重新校准一次。就我而言，每 5 秒一次。我已经尝试用陀螺仪来计算两个平面之间的角度，我尝试使用精确的 90 度标尺，它会每秒给出约 0.5 度的误差，并不断增加，但那是我的，也许其他人有更好的方法来避免错误。
下面是我的步骤“
注意：对于数字 7：是检查手机是否受到磁场影响或靠近大型钢铁或高压电线或工厂的嘈杂和重型设备
仅此而已 。 ..希望这可以帮助你...
对不起我的英语..
Just trying to answer... correct me if i'm wrong..
1.Yes you are on the right track
2.gravity in CM is already "isolated" from user gravity (gravity value caused by user acceleration) thats why there is two gravity, the "gravity" and "userAcceleration" its on apple CM documentation
// Note : not entirely isolated //
3.
if you have a gravity 0 it mean that the coresponding axis is perpendicular with gravity.
gravity.z is the iPhone screen thats why it -9.82m/s2 if you put on the desk with screen upright, actualy it hard to get 0 or maximum value of the gravity due to the sensor noise (it's normal, all sensor has a noise expecially cheap sensor).
what i do on my apps is I will switch my reference axis to other axis (in your case may be x or y) for certain limits, how the strategy is depend on the purpose or which side is your reference.
the other thing is, gyro is fast but its not stable, you need to re-calibrate the value for several interval. In my case every 5 second. I've experiment with gyro for calculating angle between two plane, i try with exacly 90 degree ruler and it will give an error about 0.5 degree every second try and keep increasing, but thats is mine, maybe others have a better method for avoid the error.
below is my steps "
Note: for number 7 : is to check if the phone affected with magnetic field or near huge steel such or high voltage electrical line or in noisy and heavy equipment in factory plant.
Thats all... Hope this could help you...
And sorry for my english..
以下是 iPhone 应用程序的示例，其中指南针通过陀螺仪进行补偿。代码和项目可以在这里看到：
http://www.sundh.com/blog/2011/09 /使用陀螺仪稳定 iPhone 的罗盘/
Here is an example of an iPhone app where the compass get compensated with the gyroscope. Code and project can be seen here:
http://www.sundh.com/blog/2011/09/stabalize-compass-of-iphone-with-gyroscope/
当处于零重力（或自由落体，或足够接近）时，偏航轴矢量的方向是不确定的。
为了在运动中进行同步，您需要为“水平”值创建一个滤波器，该滤波器具有与磁罗盘相同的滞后/延迟响应特性。或者，或者等到运动停止足够长的时间以使两个值稳定后再重新计算偏移。
The direction of the yaw axis vector is undefined when in zero gravity (or free fall, or close enough).
In order to do synchronization while in motion, you need to create a filter for your "horizontal" value that has the same lag/delay response characteristics as the magnetic compass. Either that, or wait until motion stops long enough for both values to settle before recalculating the offset.
问题 1 的答案是“是”，问题 2 您处于正确的轨道上，但您可以使用非“水平”的变量名称，问题 3 由 hotpaw2 回答，并且直升机或直升机在接近零高度的偏航也会发出警报飞行员发出警报。存在时间滞后，因为部分软件是本地的，而其他因素可能会减慢速度，包括访问用于检测磁波的传感器、设备位置和方向、为罗盘显示准备图形输出、计算和输出使用通用手持设备通过相对较慢的接口来自陀螺仪和传感器的数据，该设备不是针对所要求的任务类型定制设计的。
Answer to question 1 is Yes, question 2 you are on the right track but you could use a variable name that is not 'horizontal', question 3 is answered by hotpaw2 and also a yaw in a chopper or helicopter at near zero altitude would alert the pilot with an alarm. There is a time lag because part of the software is local while there are other factors which can slow it down including access to a sensor for detecting magnetic waves, the device position and direction, preparing the graphic output for the compass display, computing and outputting data from the gyro and sensors through a relatively slow interface, using a general purpose handheld device not custom designed for the type of task being asked of it.