TREK1000 评估套件的软件技术分析
文章目录
- TREK1000 评估套件
- TREK1000评估套件的软件功能的分析
- 1、DecaRangeRTLS ARM Source Code Guide 的解读
- 1.2 软件的架构
- 1.3测距的精度问题
- 1.4 TREK1000 TWR 中的消息帧
- **1.4.1消息帧格式**
- **1.4.2消息帧通讯时间**
- **1.4.3定位的刷新率**
- 1.5 UWB通信数据流的处理--状态机
- **1.5.1 状态机工作的内容**
- **1.5.2 状态机的结构分析**
- **1.5.2.3总结**
- 2、DecaRangeRTLS_PC_Source_Code_Guide的解读
- 2.1 简介：
- 2.1三边定位运算：
- TREK1000评估套件的软件功能的总结
TREK1000 评估套件
Decawave 公司提供了TREK1000 评估套件，用户可快速评估Decawave UWB 技术在多个实时定位系统 (RTLS) 的性能。
TREK1000 是基于双向测距。通过PC端的上位机，可实现精准定位，进而实现跟踪、导航、电子围栏的应用。
该套件包括：
- 4 个装置，分别为可配置的锚点或标签
- 双向测距板软件和源代码
- PC 应用软件
该评估套件，通过拨位开关的拨码，从而设定标签或者基站的角色，以及基站分组、标签序号设定。这样就可以很方便地添加EVK1000 评估板，扩展定位系统。但在实际的项目中，考虑到用户端的体验，一般我们会开发单独的标签端电路系统，基站端电路提供，基站的分组，标签序号，也会由不同的方式去实现。
TREK1000评估套件提供了相对详细的开发方案，包括嵌入式软件、上位机定位软件、以及相关的一些开发文档。
接着，我们就对该评估套件的软件功能的结构进行解读
TREK1000评估套件的软件功能的分析
1、DecaRangeRTLS ARM Source Code Guide 的解读
1.1 DecaRangeRTLS ARM Source Code Guide 简介
该文档是一份基于EVB1000开发板的ARM 芯片的软件源代码的参考手册。
该分档主要分析的 DecaRangeRTLS ARM application的软件架构，尤其是如何计算测距值。
该文档的section 6 详细描述了如何来处理UWB的通信中的发射和接收的数据流。
1.2 软件的架构
1.2.1 软件的架构图：
1.2.2软件代码分析：
1.2.2.1 驱动接口实现及DW1000寄存器操作API函数
- The low-level ARM specific code
定义了GPIO管脚。SPI通讯相关的芯片驱动管脚和LCD驱动管脚。 - Abstract SPI Driver – SPI Level code
-封装了SPI 驱动的一些函数 openspi(), closespi(), writetospi() and readfromspi(). - Device Driver – DW1000 Device Level Code
DW1000 相关的API操作函数。
1.2.2.2 测距功能的实现
-
Instance Code（状态机的设计）
在基于DW1000 驱动API的上层，实现双向测距。
具体来说：是用运用常见的状态机的处理方式，状态机入口函数instance_run()。
单个标签按照一定的次序与基站通讯，然后实现标签到各个基站的距离，从而运用该组距离值计算得到标签的定位信息，然后将该定位信息显示到GUI。（定位和GUI不在这个状态机处理之内 ） -
Operating mode – Tag
tag 会每个一定时间发起测距。测距完后进入休眠。
tag在每次都会向4个基站发起测距。广播发送poll包，然后依次接收基站的response包，然后发送final包。如果没有接收到来自基站#0 的response包，那么tag会停止发送final包。
tag的测距周期：对于 110kbps 是 280ms；对于6.81Mbps 是 100ms 。
为了支持多标签，这里我们使用的TDMA的方式，每一个时间槽对应一个标签和4个基站的测距交互。每一个时间槽是110Kps 模式下28ms、6.8Mbps 模式下是10ms,这里支持8个标签，剩余两个时间槽是用于基站之间的测距。
- Operating mode – Anchor #0， #1，#2
基站#0 会动态地分配时间槽给每个标签，这样就避免的通讯干扰。每个标签会根据自己的标签序号来对应相应的时间槽。
基站#0 会搜集标签到各个基站的距离，然后通过USB端口上传给上位机。
基站#0也会发起基站间的测距，基站#0发起与基站#1和基站#2间的测距。基站#1发起与基站#2的测距。
这样就有6个测距值通过基站#0的USB端口发送给上位机。
1.2.2.3测距的机制
TWR双向测距方式的实现是通过状态机instance_run()函数。在instance Level 层面上，这里还提供了其他的操作函数如下：
instance_init(), instance_config(), instance_run(), instance_close(), instancedevicesoftreset(),
instancegetrole(), instancesetrole(), instancesetantennadelays(), instancereaddeviceid(),
instance_readaccumulatordata(), instancesetreporting(), instancegetcurrentrangeinginfo(),
instancesetaddresses(), instancesettagsleepdelay(), instancesetreplydelay(), instancesetspibitrate(),
instance_rxcallback(), instance_txcallback(), inst_processrxtimeout().
1.2.2.4 软件代码一展表
1.3测距的精度问题
1、天线延迟。不同硬件，不同频段模式的UWB通信，天线延迟的时间值有所不同。该值可以写入到DW1000 的OTP中。
2、Ranging Marker (RMARKER): The first ultra-wide band (UWB) pulse 的侦别。
1.4 TREK1000 TWR 中的消息帧
1.4.1消息帧格式
帧消息的格式要符合on IEEE 802.15.4 UWB.
具体如下面的图：
1.4.2消息帧通讯时间
基站会通过自身的基站id确定延时发送response包。延时发送的时间尽可能的短。标签的一个测距实现所需的时间，除了UWB通讯的速率，还受到两个因素的制约：SPI的通讯速率。MCU的处理速度。
通过实验测到的数据如下：
这里的Frame timings 和 Slot timings 是不同的概念，一个是Frame的通讯时间，一个MCU处理时间。
1.4.3定位的刷新率
这里两个通讯速率的模式下，对应两个刷新率。
1.5 UWB通信数据流的处理–状态机
1.5.1 状态机工作的内容
- TX\RX UWB通讯的发送，接收以及数据处理
- 记录TX and RX的timestamps
- 测距计算
1.5.2 状态机的结构分析
1.5.2.1入口函数 instance_run()
周期性的调用该状态机入口函数。
外部中断instance_txcallback() or instance_rxcallback()事件响应处理（队列机制）。
testapprun() 来负责整个状态机的调度。
1.5.2.2各个状态
-
Initial state: TA_INIT： 确定角色：基站还是标签。
-
State: TA_SLEEP_DONE： 唤醒DW1000。
为了缩减能耗，我们这里使用DW1000 RSTn 管脚来确定DW1000 是否从DEEP SLEEP模式进入INIT模式。
DW1000从唤醒到进入IDLE状态需要35us的时间。
-
State: TA_TXPOLL_WAIT_SEND
在这个状态里需要完成两件事情：
1、确定发送的目标地址，选择的广播方式。
2、poll包的组帧及发送。
3、设定延时接收，及接收超时时间。这样发送完毕后，会自动开启接收。 -
State: TA_TXE_WAIT
该状态是开启下一个测距前的准备状态。
在这个状态里，将判断标签是否需要进入DEEP SLEEP。 -
State: TA_TX_WAIT_CONF
在这个状态里，我们将确认消息是否发送完成。如果发送完成，我们将读取并保存发送时间。否则会继续等待。发送完成后会开启接收。进入下一个状态TA_RXE_WAIT。
-
State: TA_RXE_WAIT
该状态里是进入RX状态前的准备状态，因为我们使用的是延迟接收模式。 -
State: TA_RX_WAIT_DATA
该状态的时间处理最长，因为我们要处理所有的RX消息。同时我们还将对接收超时做出判断和处理。 -
State: TA_TXFINAL_WAIT_SEND
该状态里，我们主要做了两件事：
1、final包的组包及延时发送。
2、跳转到TA_TX_WAIT_CONF
1.5.2.3总结
状态机的设计，需要对TWR各个状态有个清晰的理解。
对标签和基站两个角色的状态处理会有所不同，但架构基本一致。
基站#0，还会动态的分配时间槽。
2、DecaRangeRTLS_PC_Source_Code_Guide的解读
2.1 简介：
DecaRangeRTLS PC端的设计，主要是实现定位运算 及GUI。
GUI的设计是通过Qt 的框架来建立的。包括如下几个方面的内容：
- 主窗体 Main Windows
- 串口连接
- 定位运算模块
- 基站列表
- 标签列表
- 视图配置工具
- 系统参数配置
GUI 效果图：
2.1三边定位运算：
DEMO中提供了简便的三边定位的算法实现, 非常值得参考。算法的基础是向量法来计算标签坐标。
2.3 总结
Qt 开发GUI 有它自身的优势，向量法定位算法也非常值得借鉴。但是提供的Demo还是太简陋了。
TREK1000评估套件的软件功能的总结
TREK1000评估套件的定位方案总体还是比较详尽。用于对Decaweave DW1000的性能的概念评估已足够了。
但是二次开发，确实存在不少难度。主要难点如下：
1、DW1000通信状态机的理解，修改以及移植。
2、实际的项目中为了更好的用户体验，会去掉拨位开关，这里就会涉及到基站时序、标签时序的通信问题。
3、PC端定位上位机的算法设计。虽然该方案中提供给了一个向量法的定位算法，该算法的理解需要一定的数学功底。当然定位的方法还有很多种，不同的定位算法的优劣，需要考量。