【问题标题】:bad Accelerometer data with vibration加速度计数据与振动不良
【发布时间】:2012-05-22 14:17:58
【问题描述】:

我正在开发一个自行车电脑应用程序。我希望使用加速度计计算出斜坡的倾斜度,但效果不太好。

我已经输入了测试代码来获取传感器数据,我只是以 UI 速率进行扫描,并在 128 个样本上保持移动平均值,大约需要 6 秒。拿着手机,数据很好,与我的校准平面矢量相比,我可以计算出一个很好的角度。

如果手机安装在自行车上,情况就一点也不好了。我希望得到一点噪音,但我希望在大时间窗口内的大量样本能够消除振动效应和一般的自行车运动。不幸的是,这不起作用,加速度矢量的幅度并没有真正保持在 9.8 左右,而是下降得更低,这对我来说表明某处不正确。

这是来自试驾的部分数据的图表。

正如您所看到的,在开始时静止时,幅度还可以,但一旦我开始,它就会下降。我很确定问题与振动有关。我最初下降时振动很大,然后爬升,振动较小,震级回到 9.8,但随后我在糟糕的道路上迅速下降,震级小于 3 .

这是与使用BMA250 sensor 的 SonyErricson Xperia Active 一起使用的,datasheat 看起来传感器应该有能力。我对问题原因的唯一理论是范围设置为 2g 范围,并且振动导致数据超出范围,这导致了我的问题。

有人见过这样的吗? 有没有人对问题的原因有任何想法?
有什么办法可以改变我没有找到的敏感度?

附加信息。

好的,我在过滤之前记录了原始传感器数据。这里展示的一小部分 主轴是绿色的,在平坦的地方,我相信这应该没有振动,它应该是大约 8.5。数据没有明显的限制,但我得到的低于 8.5 的值多于高于 8.5 的值。即使传感器设置为最灵敏的 2g 范围,它看起来振动应该没问题 我这里的最大值刚刚超过 15 并且最小值为 -10 以及 +- 20 ragnge 只是没有正确居中在8.5应该是。

我会找出我的另一部手机,它看起来有一个稍微不同的传感器 BMA150 并尝试使用它,但除非它是完美的,否则我认为我将不得不放弃这个想法。

【问题讨论】:

  • 等一下。你下降,G下降,你爬升,G上升??这不正是应该发生的吗?至少,在你减速或加速的时候。顺便说一句,为精彩的数据 +1。
  • 我以缓慢的速度向下加速,反向向上。图上的 x 轴以秒为单位,因此在图中大约需要 10 分钟。如果我真的能连续几分钟做那种加速,我会很高兴....

标签: android accelerometer


【解决方案1】:

我怀疑加速度计在如此大的 G 范围内不是线性的。如果是这样,并且如果有任何不对称,它会做你所看到的。

对此的解决方案是将加速度计支架垫得更多一些,泡沫橡胶,蹦极绳等,可能将其安装在更重的舞台上以更多地过滤振动。

或者(不是一个好的解决方案)尝试对错误进行建模并进行补偿。

【讨论】:

  • 是的,我将修改我的坐骑以尝试阻止最严重的振动,看看是否有帮助。从长远来看,如果典型的传感器是这样的,我认为我无法将该功能放入已发布的应用程序中。数据表并未指出 BMA250 的非线性不良。它说 +- 0.5% 的最佳拟合直线对我来说听起来不错。
  • 我没有看到线性规范(一些信息在我的 pdf 查看器上显示为方框字符)。但是曲线弯曲的地方必须有限制,尽管可能超出了数字化仪的限制。删除移动平均线应该很容易,并查看各个点以将其固定在某个最大值。钳位,你可以处理噪声分布的模型,基本上可以预测有多少被钳位。
  • 它看起来确实像钳制或限制,因为 g (z>y>x) 越高,倾角越大。
  • 第 8 页的表格为非线性线。我将添加一些代码来转储一些原始原始样本,并查看是否有任何内容显示出来更详细地查看它们。
【解决方案2】:

几年前,我使用相同的手机,巧合的是,应用程序的平均间隔为 6 秒,但我不记得在图表中看到过这种行为。

我想知道问题是否在于 6 秒平均值的累积方式。我遇到的一个问题是采样间隔不是恒定的,而是取决于处理器的繁忙程度。在指定时间获取样本,但事件处理程序的调用取决于调度程序。当处理器空载时,采样以恒定频率发生,但随着处理器工作得更努力,采样频率变得更慢且更不稳定。您可以编写应用程序以在采样时保持较低的处理器负载。我们所做的是采样 6 秒,什么都不做,然后停止采样并处理最后一个示例集,但这只是部分成功,因为您无法控制同时运行的其他应用程序,并且调度程序在它们之间共享处理器资源全部。在 Xperia Active 上,我发现它偶尔会在样本之间出现几秒钟,我将其归因于其中一个 JVM 中的垃圾收集。我们的解决方案是给每个样本打上时间戳,然后对样本集进行一些质量检查,并丢弃那些未能通过质量检查的样本。这是一个糟糕的解决方案,因为定义什么足够好是不精确的,当用户运行另一个使用大量资源的应用程序时,大多数样本集可能会被丢弃,因此应用程序需要额外的逻辑来处理它。

当前的 Android API 在 Xperia Active 上不可用,应该已经消除了这一点,因为可以按照 https://source.android.com/devices/sensors/hal-interface.html#batch_sensor_flags_sampling_period_maximum_report_latency 中的说明对样本进行批处理。

如果算法假设特定数量的样本而不是计算它们,并且随着自行车的速度越来越快,处理器会更加努力地工作,尽管我不确定为什么会这样,但它会产生类似于第一张图的东西,因为当自行车行驶时下坡幅度下降,上坡时幅度上升。那里有很多猜测,但根据我使用此传感器的经验,6 秒的平均值给出的幅度小于 3 m/s^2 看起来不可信。

【讨论】:

  • 感谢肯输入。我仍然看不到我会看到我看到的一致的阅读错误。我真的应该用我的新 Z3 Compact 重新启用代码(假设我没有过多地破坏它),看看它是什么样子。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多