求助，融合算法快速移动后缓慢归位的问题

littleshrimp

求助，融合算法快速移动后缓慢归位的问题 [复制链接]

 

 SensorTile官方提供的例程，在使用ST BlueMS的Sensor Fusion时如果快速转动开发板后突然停止（转动后快速把开发板放在桌面固定）
这时骰子并不会马上停在指定位置，而是慢慢归位
用波形观察可以看到红线在波谷（-0.2）时，是开发板停在桌面上的时间
然后开发板并没有动，这个红线会缓慢变为0，最后稳定成一条直线






请问这是由什么造成的？
有什么办法能够解决或者尽量消除这个现象吗？

strong161

这个，会不会因为库计算算法的问题，或是蓝牙延迟的原因！

littleshrimp

应该不是蓝牙的问题

strong161

如果不是算法库的问题与蓝牙问题，我只能猜想是芯片本身设计的问题，加上布线引起的，比如像电感一样的电理，因为电流的突降，会有一个反动电势，可能芯片里面设计原理上没有办法避免，所以存在缓冲现像

alberthink

我觉得可能是演示算法pid调参带来的问题……不过算法都会有局限，必须根据实际情况对症下药。

等五一回来听听看st专家团队怎么说吧。

littleshrimp

感觉应该是算法或者传感器速率方面的问题

大神肖奈

这个是sensor fusion 算法收敛需要一段时间。这个fusion只是个demo，需要更准确的fusion, 需要向ST 申请，填写 LUA，来release.

littleshrimp

大神肖奈 发表于 2017-5-2 09:00
这个是sensor fusion 算法收敛需要一段时间。这个fusion只是个demo，需要更准确的fusion, 需要向ST 申请， ...

还有更准确的fusion？
open.mems里的库不是通用的吗？
如果不重新申请有没有办法解决这个问题？

大神肖奈

littleshrimp 发表于 2017-5-2 11:30
还有更准确的fusion？
open.mems里的库不是通用的吗？
如果不重新申请有没有办法解决这个问题？

是通用的，但还不是最优化的，看具体应用要求。

littleshrimp

大神肖奈 发表于 2017-5-2 13:43
是通用的，但还不是最优化的，看具体应用要求。

原来是这样啊
谢谢大神

lb8820265

恩，这个问题确实是有的，这个是由于9轴姿态解算用到了磁力计，姿态解算可以解算出俯仰、翻滚和偏航，其中俯仰和偏航使用6轴数据融合即可，由于重力的存在，融合效果是非常好的。但是偏航却无法固定，数据融合实际上是一种积分，由于零偏的存在，6轴数据的融合出偏航角会不停的变化。
要解决偏航角准度的问题可以增加磁力计，也就是9轴数据融合，磁力计的特点是长期稳定但是更新频率慢，所以短期内还是使用6轴的数据，但是长期数据却是以磁力计为准（这种关系类似于组合导航中使用INS+GPS），如果6轴融合的数据与磁力计数据有偏差，也就出现了楼主明明停止了运行，却显示在慢慢回中的现象。
出现这样不一致的情况的原因有：1.磁力计没有先校准好，2.加速度计和陀螺仪没有校准好，3.六轴融合算法存在超调或是延迟，4.9轴融合算法磁力计的权重过低。
所以如果想要解决这个问题我觉得最好的办法是直接使用6轴的数据融合，6轴融合算法不但速度快而且准确无延迟。如果一定要用偏航角可以校准下磁力计试试，如果还是没有效果那也没办法了，毕竟库是没法改的。或者你可以试试使用其他的姿态融合算法：EKF,UKF,DCM,Mahony等算法。

littleshrimp

lb8820265 发表于 2017-5-2 20:35
恩，这个问题确实是有的，这个是由于9轴姿态解算用到了磁力计，姿态解算可以解算出俯仰、翻滚和偏航，其中 ...

使用官方提供的SensorTile固件和APP试的，磁力计已经校准过
问题好像不光出在领航上，俯仰和横滚好像也有这种情况
我先按你的提示试一下6轴融合看看

littleshrimp

lb8820265 发表于 2017-5-2 20:35
恩，这个问题确实是有的，这个是由于9轴姿态解算用到了磁力计，姿态解算可以解算出俯仰、翻滚和偏航，其中 ...

又做了几个实验
应该能确定这个问题是由于算法中使用陀螺仪计算角度时产生了误差
最后再通过加速度传感器校正的结果
如果转动的速度不是很快，加速度实时校正后看不出变化
如果快速转动后停止得到的当前角度主要是由陀螺仪计算出来的，存在误差
再经过加速度修改正就会出现这个问题