为什么我的加速度计响应这么慢?
我以 50Hz/每秒 50 次的频率向他们询问数据。 当我突然将设备在 x 轴上翻转 90 度,而设备之前平放在桌子上且显示屏朝上时,这些值会非常缓慢地移动到该位置的“目标”值。
现在奇怪的是:如果我增加测量速率,突然将设备翻转 90 度时,该值会更快地移动到新值。 但如果我每秒询问一次新值,则需要很长时间才能达到目标。 这可能是什么原因?
我不做任何类型的数据聚合,也不积累任何东西。 我只是做了一些简单的过滤来消除噪音。 我的方法如下所示:
- (void)accelerometer:(UIAccelerometer *)accelerometer didAccelerate:(UIAcceleration *)acceleration {
// Use a basic low-pass filter to only keep the gravity in the accelerometer values for the X and Y axes
// accelerationX is an instance variable
accelerationX = acceleration.x * 0.05 + accelerationX * (1.0 - 0.05);
// round
int i = accelerationX * 100;
float clippedAccelerationValue = i;
clippedAccelerationValue /= 100;
[self moveViews:clippedAccelerationValue];
}
稍后,在我的 -moveViews: 方法中,我这样做:
-(IBAction)moveSceneForPseudo3D:(float)accelerationValue {
if(fabs(lastAccelerationValue - accelerationValue) > 0.02) { // some little treshold to prevent flickering when it lays on a table
float viewAccelerationOffset = accelerationValue * 19 * -1;
newXPos = initialViewOrigin + viewAccelerationOffset;
myView.frame = CGRectMake(newXPos, myView.frame.origin.y, myView.frame.size.width, myView.frame.size.height);
lastAccelerationValue = accelerationValue;
}
}
结果,设备在 x-achsis 上旋转 90 度或 180 度,视图只是非常缓慢地移动到目标位置。 我不知道这是否是由于加速度计的物理原理,或者是否是我的过滤代码中的错误。 我只知道有些快节奏的游戏需要使用加速计来进行转向,所以我几乎无法想象这是硬件问题。
I'm asking them at 50Hz / 50 times per second for data. When I suddenly flip the device on the x-axis by 90 degrees while the device was flat on a table with display facing up bevore, the values move pretty slowly to the "target" value for that position.
Now the weird thing is: If I increase the measurement-rate, the value will move faster to that new value upon suddenly flipping the device by 90 degrees. But if I just ask once per second for the new value, it take's very long until the value reaches the target. What can be the reason for this?
I don't do any kind of data aggregation, and don't accumulate anything. I just do some simple filtering to get rid of the noise. My method looks like this:
- (void)accelerometer:(UIAccelerometer *)accelerometer didAccelerate:(UIAcceleration *)acceleration {
// Use a basic low-pass filter to only keep the gravity in the accelerometer values for the X and Y axes
// accelerationX is an instance variable
accelerationX = acceleration.x * 0.05 + accelerationX * (1.0 - 0.05);
// round
int i = accelerationX * 100;
float clippedAccelerationValue = i;
clippedAccelerationValue /= 100;
[self moveViews:clippedAccelerationValue];
}
later on, in my -moveViews: method, I do this:
-(IBAction)moveSceneForPseudo3D:(float)accelerationValue {
if(fabs(lastAccelerationValue - accelerationValue) > 0.02) { // some little treshold to prevent flickering when it lays on a table
float viewAccelerationOffset = accelerationValue * 19 * -1;
newXPos = initialViewOrigin + viewAccelerationOffset;
myView.frame = CGRectMake(newXPos, myView.frame.origin.y, myView.frame.size.width, myView.frame.size.height);
lastAccelerationValue = accelerationValue;
}
}
As a result, of the device gets turned 90 degrees on the x-achsis, or 180 degrees, the view just moves pretty slowly to it's target position. I don't know if that's because of the physics of the accelerometers, or if it's a bug in my filtering code. I only know that there are fast paced games where the accelerometers are used for steering, so I almost can't imagine that's a hardware problem.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
此行:
是一个低通滤波器,其工作原理是计算 x 加速度的移动平均值。 换句话说,每次调用该回调时,您只需将
accelerationX
向新的加速度计值移动 5%。 这就是为什么在accelerationX
反映新方向之前需要多次迭代。您应该做的是增加
0.05
值,即0.2
。 我会创建一个全局#define
并使用不同的值和不同的刷新率。This line:
is a low-pass filter, which works by computing a moving average of the x acceleration. In other words, each time that callback is called, you're only moving the
accelerationX
by 5% towards the new accelerometer value. That's why it takes many iterations beforeaccelerationX
reflects the new orientation.What you should do is increase the
0.05
value, to say0.2
. I'd make a global#define
and play around with different values along with different refresh rates.