iOS 中加速度计数据中的重力作为参考系
我正在为摩托车手开发一款 iPhone 应用程序，该应用程序可以在碰撞发生后检测到该应用程序。目前我们正在数据采集过程中绘制图表并查看数据。我需要记录的是自行车相对于直立在道路上的自行车的向前用户加速度和倾斜角度。我可以获得用户加速度矢量，即骑手前进的方向是 x、y 和 z 加速度计值平方的 sqrt。但对于倾斜角度，我需要一个恒定的参考，所以我想让我们使用重力矢量。现在，我意识到 deviceMotion API 有重力和用户加速度值，这些值从何而来，它们的含义是什么？如果我取重力的 x、y 和 z 平方分量的 sqrt，这总是会给我直接向上吗？我如何用它来找到自行车相对于道路上直立自行车的倾斜角度？谢谢。
I'm working on an iPhone app for motorcyclist that will detect a crash after it has occurred. Currently we're in the data acquisition process and plotting graphs and looking at data. What i need to log is the forward user acceleration and tilt angle of the bike relative to bike standing upright on the road. I can get the user acceleration vector, i.e. the forward direction the rider is heading by sqrt of the x,y and z accelerometer values squared. But for the tilt angle i need a reference that is constant, so i thought lets use the gravity vector. Now, i realize that deviceMotion API has gravity and user acceleration values, where do these values come from and what do they mean? If i take the sqrt of the x,y and z squared components of the gravity will that always give me my up direct? How can i use that to find the tilt angle of the bike relative to an upright bike on the road? Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
抛开“why”这样做......
你需要一个非常低通的滤波器。因此，一旦将手机放在自行车上的任何位置，您就会获得各种机动加速度和背景中始终存在的重力加速度。这为您提供了一个持续的“向下”向量，然后您可以在该上下文中解释加速数据...前进加速会使自行车与制动相反，所以我认为您也可以实时确定前进方向。
非常有趣的想法。
Setting aside "whiy" do this...
You need a very low-pass filter. So once the phone is put wherever-it-rides on the bike, you'll have various accelerations from maneuvers and the accel from gravity ever present in the background. That gives you an on-going vector for "down", and you can then interpret the accel data in that context... Fwd accel would tip the bike opposite of braking, so I think you could sort out fwd direction in real time too.
Very interesting idea.
假设这不是一个“笑话问题”，您将需要一个参考点来与用户单击“开始”时所采取的位置进行比较。然后你可以使用
cos(currentGravity.z / |referenceGravity|)和 |referenceGravity| == 1 因为 Core Motion 测量加速度（以 g 为单位）。但说实话，有几个问题，例如：
或者我们误解了您，它是只是一个游戏？
Assuming that it's not a "joke question" you will need a reference point to compare with i.e. the position taken when the user clicks "starting". Then you can use
cos(currentGravity.z / |referenceGravity|)with |referenceGravity| == 1 because Core Motion measures accelerations in g.But to be honest there are a couple of problems for instance:
Or did we misunderstand you and it's just a game?
因为这不是玩笑。
我想解决安装点问题。如何解读这些数据很大程度上取决于 iPhone 的定位。对于那些实际上不骑摩托车的人来说，有些问题可能并不明显。
特别是在转弯/拐角处时。在低速转弯时，摩托车会倾斜，但骑手不会倾斜或只是轻微倾斜。在较高的速度下，骑手和摩托车都会倾斜。如果不解决，这可能会出现问题。我不会涵盖所有场景，但是..
例如，大多数现代纺织摩托车夹克的左侧内侧都有一个手机口袋。如果用户将手机放入口袋中，您可能只会看到“加速”和“正在加速”。 “制动”(~z) 加速度。在这种情况下，您几乎不会看到大量的左右 (~x) 加速度，因为骑手会成比例地倾斜到转弯的重力。因此，当沿着曲线行驶时，人们会期望看到 (y) 比一般 1g 状态有所增加。因此，基本上，就 (x) 测量而言，骑手的躯干与重力有关。
如果该设备安装在自行车上，您将必须根据您期望在该安装点看到的内容进行调整。
就检测崩溃的算法的启发式而言，这是很难定义的。有些碰撞就像你在电视上看到的那样，自行车翻转成一百万个碎片，那种碰撞应该非常容易检测到，呵呵 3gs 测量过……碰撞！但是简单的下坡呢？（自行车侧放，哎呀，骑手站起来，骑上自行车离开）它们可能会在没有任何特别显着的重力的情况下发生。（除了 x 轴上向左或向右约 1g 的力外） ）
还有一些建议：
灵敏度调整，甚至可以使用某种学习模式（用户将设备置于此模式并骑行，然后设备记录/学习该用户的平均骑行情况）
“我已经停止”或类似按钮；也许骑手没有撞车，也许他/她只是崩溃了，这种情况确实发生了，并且由于您有某种临时网络设置，因此应该很容易传播消息。
Since this is not a joke.
I would like to address the point of mount issue. How to interpret the data depends largely on how the iPhone is positioned. Some issues might not be apparent to those that don't actually ride motorcycles.
Particularly when it comes to going around curves/corners. In low speed turns the motorcycle leans but the rider does not or just leans slightly. In higher speed turns both the rider and the motorcycle lean. This could present an issue if not addressed. I won't cover all scenarios but..
For example, most modern textile motorcycle jackets have a cell phone pocket just inside on the left. If the user were to put there phone in this pocket, you could expect to see only 'accelerating' & 'braking'(~z) acceleration. In this scenario you would expect to almost never see significant amounts of side to side (~x) acceleration because the rider leans proportionally into the g-force of the turn. So while going around a curve one would expect to see an increase in (y)down from it's general 1g state. So essentially the riders torso is indexed to gravity as far as (x) measurements go.
If the device were mounted to the bike you would have to adjust for what you would expect to see given that mounting point.
As far as the heuristics of the algorithm to detect a crash go, that is very hard to define. Some crashes are like you see on television, bike flips ripping into a million pieces, that crash should be extremely easy to detect, Huh 3gs measured up... Crash! But what about simple downs?(bike lays on it's side, oops, rider gets up, picks up bike rides away) They might occur without any particularly remarkable g-forces.(with the exception of about 1g left or right on the x axis)
A couple more suggestions:
Sensitivity adjustment, maybe even with some sort of learn mode (where the user puts the device in this mode and rides, the device then records/learns average riding for that user)
An "I've stopped" or similar button; maybe the rider didn't crash, maybe he/she just broke down, it does happen and since you have some sort of ad-hoc network setup it should be easy to spread the news.