这个,会不会因为库计算算法的问题,或是蓝牙延迟的原因!
如果不是算法库的问题与蓝牙问题,我只能猜想是芯片本身设计的问题,加上布线引起的,比如像电感一样的电理,因为电流的突降,会有一个反动电势,可能芯片里面设计原理上没有办法避免,所以存在缓冲现像
我觉得可能是演示算法pid调参带来的问题……不过算法都会有局限,必须根据实际情况对症下药。
等五一回来听听看st专家团队怎么说吧。
这个是sensor fusion 算法收敛需要一段时间。这个fusion只是个demo,需要更准确的fusion, 需要向ST 申请,填写 LUA,来release.
恩,这个问题确实是有的,这个是由于9轴姿态解算用到了磁力计,姿态解算可以解算出俯仰、翻滚和偏航,其中俯仰和偏航使用6轴数据融合即可,由于重力的存在,融合效果是非常好的。但是偏航却无法固定,数据融合实际上是一种积分,由于零偏的存在,6轴数据的融合出偏航角会不停的变化。
要解决偏航角准度的问题可以增加磁力计,也就是9轴数据融合,磁力计的特点是长期稳定但是更新频率慢,所以短期内还是使用6轴的数据,但是长期数据却是以磁力计为准(这种关系类似于组合导航中使用INS+GPS),如果6轴融合的数据与磁力计数据有偏差,也就出现了楼主明明停止了运行,却显示在慢慢回中的现象。
出现这样不一致的情况的原因有:1.磁力计没有先校准好,2.加速度计和陀螺仪没有校准好,3.六轴融合算法存在超调或是延迟,4.9轴融合算法磁力计的权重过低。
所以如果想要解决这个问题我觉得最好的办法是直接使用6轴的数据融合,6轴融合算法不但速度快而且准确无延迟。如果一定要用偏航角可以校准下磁力计试试,如果还是没有效果那也没办法了,毕竟库是没法改的。或者你可以试试使用其他的姿态融合算法:EKF,UKF,DCM,Mahony等算法。 本帖最后由 lb8820265 于 2017-5-2 20:38 编辑
使用官方提供的SensorTile固件和APP试的,磁力计已经校准过
问题好像不光出在领航上,俯仰和横滚好像也有这种情况
我先按你的提示试一下6轴融合看看
又做了几个实验
应该能确定这个问题是由于算法中使用陀螺仪计算角度时产生了误差
最后再通过加速度传感器校正的结果
如果转动的速度不是很快,加速度实时校正后看不出变化
如果快速转动后停止得到的当前角度主要是由陀螺仪计算出来的,存在误差
再经过加速度修改正就会出现这个问题