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 应用软件

TREK1000 评估套件的软件技术分析_第1张图片
该评估套件,通过拨位开关的拨码,从而设定标签或者基站的角色,以及基站分组、标签序号设定。这样就可以很方便地添加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 软件的架构图:

TREK1000 评估套件的软件技术分析_第2张图片

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 。

TREK1000 评估套件的软件技术分析_第3张图片
为了支持多标签,这里我们使用的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测距的机制

TREK1000 评估套件的软件技术分析_第4张图片
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 软件代码一展表
TREK1000 评估套件的软件技术分析_第5张图片

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.

具体如下面的图:
TREK1000 评估套件的软件技术分析_第6张图片

TREK1000 评估套件的软件技术分析_第7张图片

1.4.2消息帧通讯时间

TREK1000 评估套件的软件技术分析_第8张图片
TREK1000 评估套件的软件技术分析_第9张图片

基站会通过自身的基站id确定延时发送response包。延时发送的时间尽可能的短。标签的一个测距实现所需的时间,除了UWB通讯的速率,还受到两个因素的制约:SPI的通讯速率。MCU的处理速度。

通过实验测到的数据如下:
TREK1000 评估套件的软件技术分析_第10张图片

TREK1000 评估套件的软件技术分析_第11张图片

这里的Frame timings 和 Slot timings 是不同的概念,一个是Frame的通讯时间,一个MCU处理时间。

1.4.3定位的刷新率

这里两个通讯速率的模式下,对应两个刷新率。

TREK1000 评估套件的软件技术分析_第12张图片

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。
    TREK1000 评估套件的软件技术分析_第13张图片

    为了缩减能耗,我们这里使用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。
TREK1000 评估套件的软件技术分析_第14张图片
GUI的设计是通过Qt 的框架来建立的。包括如下几个方面的内容:

  • 主窗体 Main Windows
  • 串口连接
  • 定位运算模块
  • 基站列表
  • 标签列表
  • 视图配置工具
  • 系统参数配置

TREK1000 评估套件的软件技术分析_第15张图片
GUI 效果图:

TREK1000 评估套件的软件技术分析_第16张图片

2.1三边定位运算:

DEMO中提供了简便的三边定位的算法实现, 非常值得参考。算法的基础是向量法来计算标签坐标。
TREK1000 评估套件的软件技术分析_第17张图片
2.3 总结

Qt 开发GUI 有它自身的优势,向量法定位算法也非常值得借鉴。但是提供的Demo还是太简陋了。

TREK1000评估套件的软件功能的总结

TREK1000评估套件的定位方案总体还是比较详尽。用于对Decaweave DW1000的性能的概念评估已足够了。

但是二次开发,确实存在不少难度。主要难点如下:

1、DW1000通信状态机的理解,修改以及移植。
2、实际的项目中为了更好的用户体验,会去掉拨位开关,这里就会涉及到基站时序、标签时序的通信问题。
3、PC端定位上位机的算法设计。虽然该方案中提供给了一个向量法的定位算法,该算法的理解需要一定的数学功底。当然定位的方法还有很多种,不同的定位算法的优劣,需要考量。

你可能感兴趣的:(嵌入式,定位,DW1000,TREK,1000,decawave)