51uwb.cn

标题: 关于UWB定位频率的问题 [打印本页]
作者: liuchunhui321    时间: 2021-10-25 17:06
标题: 关于UWB定位频率的问题
我是DW1000，多标签定位，采样频率设置围5Hz，就是0.2秒刷新一次坐标，我需要用UWB坐标定位的信息，现在发现如下问题：
1. UWB坐标本身可能不刷新，应该是丢包（经常出现这种情况）
2. 就算刷新，拿到QT发给Matlab的坐标之后，会出现仿真时间和真实时间对应不上的问题，可能仿真时间60s，实际计时可能会80S（目前猜测原因可能是1.采样频率5Hz,实际并不是每0.2秒给串口发送坐标2.某些时刻的坐标没有刷新造成了时滞）





作者: sdfb6868    时间: 2021-10-26 09:03
通过大量实验后发现，串口输出的频率并不稳定，有很正常的误码丢包。
例如设置100HZ，串口会有60HZ左右的正常输出。哪怕你用极好的设备也不能阻止误码，对不？
通常，当前未获得新的数据，可以用以最近一次获得数据进行坐标计算。（虽然有误差）
你可以重写定位算法，matlab二十几行就能搞定。
作者: liuchunhui321    时间: 2021-10-26 14:53
sdfb6868 发表于 2021-10-26 09:03
通过大量实验后发现，串口输出的频率并不稳定，有很正常的误码丢包。
例如设置100HZ，串口会有60HZ左右的 ...

可是两标签丢包不是说短时间内丢包，是长达几秒甚至很长时间丢包，过了这么长时间坐标一直不刷新，这一问题我没法解决
作者: sdfb6868    时间: 2021-10-27 10:59
liuchunhui321 发表于 2021-10-26 14:53
可是两标签丢包不是说短时间内丢包，是长达几秒甚至很长时间丢包，过了这么长时间坐标一直不刷新，这一问 ...

你这不是丢包，你这是死机。插拔充电宝好转是重启，两个标签同时发消息又造成发信撞车，又死机（进入休眠模式）循环往复。你解决不了我也解决不了，降低频率减少容量吧。
作者: sdfb6868    时间: 2021-10-27 11:03
liuchunhui321 发表于 2021-10-26 14:53
可是两标签丢包不是说短时间内丢包，是长达几秒甚至很长时间丢包，过了这么长时间坐标一直不刷新，这一问 ...

哎，不对啊，要是5HZ的刷新，也是很难撞车啊，一般要到容量上限附近才会经常撞车
作者: 蓝点无限    时间: 2021-10-27 23:05
sdfb6868 发表于 2021-10-27 11:03
哎，不对啊，要是5HZ的刷新，也是很难撞车啊，一般要到容量上限附近才会经常撞车

http://51uwb.cn/forum.php?mod=vi ... hlight=%B8%FC%D0%C2
这里有个重要更新，看你的代码是否有合入，如果没有，你合入再试试。
作者: liuchunhui321    时间: 2021-11-18 15:19
sdfb6868 发表于 2021-10-26 09:03
通过大量实验后发现，串口输出的频率并不稳定，有很正常的误码丢包。
例如设置100HZ，串口会有60HZ左右的 ...

请问一下怎么使用最新的数据进行坐标运算，我是在simulink中使用，我尝试改QT，但是还是不是最新的数据
作者: liuchunhui321    时间: 2021-12-11 20:35
尽快解决尽快解决，UWB标签坐标不刷新，死机情况
作者: liuchunhui321    时间: 2021-12-11 20:35
四基站6标签
作者: liuchunhui321    时间: 2021-12-11 20:42
链接：https://pan.baidu.com/s/1obeWWjxXQoUqsCLDxeZdew
提取码：hv73

我的代码发在这里面了，四基站六标签，只要改标签ID，烧录六份程序即可
作者: 蓝点无限    时间: 2021-12-12 09:59
关于你的这个问题，我们这边进行了复现。
发现当合入之前的更新后，为了处理多区域干扰问题，无法处理多标签冲突问题了。
具体原因：
  1. //    dwt_setinterrupt(DWT_INT_RFCG , 1);
  2. //    dwt_setautorxreenable(1);
复制代码
这个代码的意思是，只有当接收成功后，上传中断给软件。
而我们软件流程中会处理节点冲突
  1.         if(!(status_reg & SYS_STATUS_RXRFTO))//
  2.             Tag_receive_poll = 1;//
  3.         dwt_write32bitreg(SYS_STATUS_ID, (SYS_STATUS_RXFCG | SYS_STATUS_ALL_RX_ERR));
复制代码
上面表示，当产生任何接收异常，将认为标签和其他标签产生冲突，产生冲突的原因就是因为同时发送了，而发送是通过定制器控制的，那当产生冲突后，微调一下定制器，让产生冲突的标签延后一点，具体代码
  1.         else
  2.         {
  3.             HAL_TIM_Base_Stop(&htim3);
  4.             TIM3->ARR = TIM3_Delay_Step*((SHORT_ADDR%10)+1);//random delay
  5.             Tag_receive_poll = 0;
  6.         }
复制代码

以上就是多标签冲突避免机制。

之前让你加的更新，导致软件无法收到接收异常（硬件配置后只报告接收正常）。导致冲突处理机制不能工作，相互冲突的标签不做处理，每次都是冲突的。表象就是某些标签一直不更新距离信息，看起来像死机一样。

以上分析，如果多个标签，尽量使用更新以前的代码

  1.     dwt_setinterrupt(DWT_INT_RFCG | (DWT_INT_ARFE | DWT_INT_RFSL | DWT_INT_SFDT | DWT_INT_RPHE | DWT_INT_RFCE | DWT_INT_RFTO /*| DWT_INT_RXPTO*/), 1);
  2. //    dwt_setinterrupt(DWT_INT_RFCG , 1);
  3. //    dwt_setautorxreenable(1);
复制代码
如果是一个标签，多个区域定位，可以加入更新。

另外一个注意的问题是，标签编译地址尽量错开，因为我们的delay是模低地址

  1. TIM3->ARR = TIM3_Delay_Step*((SHORT_ADDR%10)+1);//random delay
复制代码
实际编译地址可以选用1001 1003 1005 依次类推。

我们实际测试效果如下：
(, 下载次数: 490)

另外补充一下，上面也提到了原理部分，冲突避免是一个“自适应”过程，当模块刚刚上电后，可能某些标签会同时发送产生冲突，会相互干扰。这个时候会有一段时间的自适应调整过程，一般根据标签多少会有一定时间消耗。慢慢逐步稳定下来。


通信信息个数统计：
每个标签和每个基站测距一次需要3条信息。6个标签*4个基站*5 = 120，每个信息发送时间槽只有8个ms左右，而信息本身需要几个ms发送，相互之间空闲时间槽其实已经非常小了。 这个配置基本算是TWR的极限了。











作者: 蓝点无限    时间: 2021-12-12 10:01
蓝点无限 发表于 2021-10-27 23:05
http://51uwb.cn/forum.php?mod=viewthread&tid=365&highlight=%B8%FC%D0%C2
这里有个重要更新，看你的 ...

这个更新暂时不要合入
作者: liuchunhui321    时间: 2021-12-14 08:50
我把之前的更新取消了，tx_main_c中有定时器3中断回调函数中包含   
else
        {
            HAL_TIM_Base_Stop(&htim3);
            TIM3->ARR = TIM3_Delay_Step*((SHORT_ADDR%10)+1);//random delay
            Tag_receive_poll = 0;
        }

这一段不需要修改吧
作者: liuchunhui321    时间: 2021-12-15 16:47
蓝点无限 发表于 2021-12-12 10:01
这个更新暂时不要合入

请回复我一下谢谢
作者: liuchunhui321    时间: 2021-12-15 16:50
liuchunhui321 发表于 2021-12-14 08:50
我把之前的更新取消了，tx_main_c中有定时器3中断回调函数中包含   
else
        {

我改成之前的还是有标签不刷新的情况
作者: 蓝点无限    时间: 2021-12-15 22:34
liuchunhui321 发表于 2021-12-14 08:50
我把之前的更新取消了，tx_main_c中有定时器3中断回调函数中包含   
else
        {

这个部分不能注释掉
这个功能是当标签发送信息发现数据冲突后，重新对定时器做微调，以达到避免冲突
作者: liuchunhui321    时间: 2021-12-17 09:23
蓝点无限 发表于 2021-12-15 22:34
这个部分不能注释掉
这个功能是当标签发送信息发现数据冲突后，重新对定时器做微调，以达到避免冲突

我没有注释掉，现在我改成四基站四标签，2HZ的频率，还是有不稳定，不刷新的现象
作者: liuchunhui321    时间: 2021-12-17 18:37
蓝点无限 发表于 2021-12-15 22:34
这个部分不能注释掉
这个功能是当标签发送信息发现数据冲突后，重新对定时器做微调，以达到避免冲突

而且我不太理解我一个标签数据貌似不太对ANC0 range靠近880000，程序本身没有错
作者: 蓝点无限    时间: 2021-12-19 19:45
liuchunhui321 发表于 2021-12-17 18:37
而且我不太理解我一个标签数据貌似不太对ANC0 range靠近880000，程序本身没有错

为何你的图片，tag 都是tag5，你的标签id配置有问题吗？
作者: liuchunhui321    时间: 2021-12-21 17:59
蓝点无限 发表于 2021-12-19 19:45
为何你的图片，tag 都是tag5，你的标签id配置有问题吗？

我的tagID为0x0025,0x0015,0x0035,0x0045,0x0055,0x0065，所以显示都是5
作者: 蓝点无限    时间: 2021-12-22 22:35
liuchunhui321 发表于 2021-12-21 17:59
我的tagID为0x0025,0x0015,0x0035,0x0045,0x0055,0x0065，所以显示都是5

你这个改法不好，如下代码，delay延时用的短地址模10，你的地址所有delay都是一样的，没有随机效果了。
  1. else
  2.         {
  3.             HAL_TIM_Base_Stop(&htim3);
  4.             TIM3->ARR = TIM3_Delay_Step*((SHORT_ADDR%10)+1);//random delay
  5.             Tag_receive_poll = 0;
  6.         }
复制代码


下面是之前帖子回复的正确设置短地址的方法
  1. 另外一个注意的问题是，标签编译地址尽量错开，因为我们的delay是模低地址

  3.     TIM3->ARR = TIM3_Delay_Step*((SHORT_ADDR%10)+1);//random delay

  5. 复制代码
  6. 实际编译地址可以选用1001 1003 1005 依次类推。
复制代码




欢迎光临 51uwb.cn (http://51uwb.cn/) Powered by Discuz! X3.3