Overview
mobile“tags”, fixed “anchors” and “gateways”
Positioning and Networking Stack (“PANS”)
Two-Way-Ranging Real Time Location System (“DRTLS”)
在 DRTLS模式下的性能.
DRTLS 操作
一个DRTLS系统最少需要三个anchor, 其中一个必需作为initiator存在,用户控制网络的接入和产生.
gateway 可以使用 linux Host(例如树莓派) + Bridge Node(passitive node)实现.
DRTLS 使用 TDMA(分时多址)通道访问. 各个节点每100ms重复发布"superframe".
initiator 控制时间,
superframe 从16个 BeaconMessageSlots开始. anchor 发从BeaconMessage(自己的位置)+Almanac Service + Network ServiceMessage(例如Join Request). 其他15个 TWR Slots 用于 Tag和 Anchor 之前的通讯. 然后还有一些空余时间(在 superframe之后).
Tag从BeaconMessage +Almanac 中 得到各个anchor的位置, 并选择3/4个anchor进行通讯., 通讯的结果通过BT传出.
网络初始化
当网络存在多个inititor是允许的, 但只能有一个处于active状态, 其他将处于普通anchor状态.
inititor被设置成0号,意思为他能在 Slots0发送 BeaconMessage, 他也能广播 Beacons and Almanacs
anchor要入网首先要监听其他anchor的beacons, 然后尝试入网. 入网后他们也发送 Beacons and Almanacs. (包含了自己的位置,网络信息,与Tag的交互方式等 )
每个
anchor的superframe都需要一个BCN slot, 这里有16个BCN slot, 说明在同个物理空间区域内, 同时最多有16个anchors同时工作.(注意这里不是说系统内最多有16个anchor)
anchor验证
1. cluster map and cluster neighbor map 必须由一个空位给新要加入的
anchor占用. (map信息包含在BeaconMessage中), 也就说在superframe数据帧中 BCN slots的占用数 < 16.
2.
anchor的 要 < 127, 因为
anchor监听initiator’s Beacons要在clock level 0. 下个要在 clock level 2 ...
3. 所有网内的anchor都确认了自己的位置并且相互没有冲突.
4. 固件必须兼容. 版本继续和 inititor相同. (版本号在
Almanacs 消息中 )
anchor入网:
anchor确认了版本和有空位slots. 则从空闲的 SVC slot发送 ClusterJoinRequest消息. anchors则会用beacon Message(包含了
ClusterJoinConfirm), 这个过程需要重复三次, 这样新加的anchor会被锁定lock.
...
...
......冲突解决/签名入网/ 此处不再翻译. 类似于 zigbee 机制
......*****************************************************************************
在网的 anchor 操作
1. anchor (在 initator 范围内, 即clock level = 1的)需要和 initator 保持时钟同步, 这样即可按照 initator superframe timings的设定进行时间刻度的对齐.
2. 其他anchor( clock level > 1)的, 其需要和 最近的anchor(clock level 最小的那个) 保持时钟同步
3. 每个anchor发送Beacon(通过BCN slot), 发送AImanacs(通过SVC slot).
*****************************************************************************
Tag的操作
Tag周期性睡醒, 周期性的监听 anchor的 Beachon + AImanacs 消息.
Tag收到消息, 确定 HW/FW的兼容性, 确定是否要进行固件更新.
Tag进行TWR 操作.
Tag两种工作模式
1. Responsive模式: 在开始 TWR 调度后, 确定何时接受Beacon(superframe), 此时不会进入休眠模式而是 idle模式.
2. 低功耗模式: 在TWR完整之后, 进入DeepSleep模式. 在下个TWR 任务调度时被唤醒.(或者其他RTC, Accelerometer), 此时不再监听BeaconMessage.
*****************************************************************************
TWR协议/ TWR slot预定
tag 保存周边anchor的slot map(通过BeaconMessage). 并确定一个空闲的ranging slot(通过此slot发送superframe用以进行range测量). 没有空闲的ranging slot时, 每隔一定时间(TDMA bitmap的有效期)重新通过superframe确定 free ranging slot. 因为每100ms, 都会有superframe发布, 其中包括15个ranging slots.
在所有 ranging slot 都被占用时, 新tag是无法进行range 测量的.
tag通过接受的 Beacons的时间点计算Msg在空中的传输时间延迟. 通过
1->GroupPoll (broadcat) 包括更新频率
2<- Poll(P2P)
3-->Poll Response(broadcat) (在新 TWR slot 进行)
4.-->Final (P2P)
5. Location Engine 计算.
注意: anchor 保存 TDMA bitmap, bitmap的有效期为 60s(可修改, 60s的设置为最小的location update rate决定的).
*****************************************************************************
TWR 冲突检测和解决
DRTLS使用 TDMA, 这说明 tag 进行 TWR时 使用指定的slots, 这样他们他们不会产生冲突.
但是当 多个Tag移动, 尤其一个tag从一个area到另外area时(例如:一个anchor已经离开可测的方位,或者网络检测到tag冲突或者anchor冲突), 在初始化时确定"Free slots"时, 两个Tag可能会同时发出消息. 此时需要进行冲突检测和解决算法.
此时 anchor保持 TWR的原子性或者等待超时. tag如果多次检测(>3次)TWR不完整(超时或者受到冲突)则放弃对应的slots. 然后找新的slot进行 TWR.
*****************************************************************************
tag TWR Strategy策略
1. tag 通过 BeaconMessage, 获得各个anchors的位置.
2. 通过TWR得到各个anchor的距离.
3. 获取自己的位置, 然后确定下次要测量的anchors. (系统启动的时候默认自身为为 0,0,0)
4. 确定要通讯的anchors的规则
a. 尽量在其坐标系的每个坐标系的四个象限内, 每个象限内选一个, 尽量保持多边形.
b. 尽量选择最近的. 选后尽量保持通讯,直到脱离其范围(TWR fail 或者 发现冲突)
*****************************************************************************
定位引擎 Location Engine
Tag node 内部集成定位引擎, 通过 range 信息(至少3个)以及各个 anchor的位置计算自身位置.
引擎采用最大似然估计方法(即最大相似法), 例如在有4个距离信息时,则分成4组3个距离信息, 每组产生的一个位置信息, 4组信息同构不同标准进行组合确定预估位置, 预估位置在经距离信息再次确认, 则 预估位置 比测量的距离更短的则认为更准确(避免多径问题).
*****************************************************************************
开发资源:
DWM1001 Tag 默认使用低功耗模式, 固件使用eCos实现, 通过多个Task管理一下子模块. 所有子模块完成, 则进入Sleep模式.
UWB radio; location engine operation; BT radio;UART shell; UART/SPI API; UserApplication; PowerManager.
*****************************************************************************
唤醒源:
Tag从低功耗模式唤醒:
1. RTC
2. Accelerometer: 加速剂.
3. Uart RX GPIO/ SPI CS GPIO
4. USER button
*****************************************************************************
Tag有定位模式:
1. nominal: 普通模式 周期性定位.
2. stationary: 板载加速计检测到设备静止时,
stationary模式启用, 如果加速计禁用, 则nominal模式启用.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
系统扩展 - anchors
整个UWB DRTLS系统的基础架构由 anchor-initiators 和 anchors组成, 整个网络使用 TDMA方案, 所有的anchor 应当在指定的slots上发送以便于
和 initator的superframe时序保持同步.
网络使用碰撞避免/检测/解决方案, 每个anchor获得一个 BCN slot. 这样anchor既可参与到网络,分发 Beacon + AImanac 消息.
这样系统可以扩展到很大, 但是要基于一定得扩展的规则.
在每个anchor的有效区域内, 不能有两个同样的anchor占据通过slot座位.
如图: 从anchor A - P占据了 [A]-[P]的slot位置, 那么Q则占据 Slot0位置.
每个anchor不要一个 0-15的序号.
同一座位号的两个锚不可同时使用
所有节点必须和 initator进行同步, 使用 initator 超帧规定的时序
*****************************************************************************
*****************************************************************************
*****************************************************************************
局限性
最大的anchor的座位数为 16 (slot的位置)
1. 如果系统有<=16个anchor, 那么不会有任何限制. 他们可以在每个anchor的区域之内.
2. 如果第17或者更多anchor加入, 那么应该复用 slot 位置,
只有当其他anchor之间的距离足够远，没有一个anchor听到两个位置相同的anchor时，才能实现这一点。
3.
第17在加入之前, 那么第17 anchor距离内的多有anchor必须确认对应的 座位号 是否有效.
4. 例如: 当 anchor[0] 和
第17 anchor 都在anchor[9]的范围内时, 第17 anchor就不能使用座位号 0, 因为anchor[9]不能同时得到2个相同座位号的 anchor.
5. 这样的规则保证用户需要合理的部署anchor, 以便于复用座位号, 也就说没有必要同个区域部署了太多anchors.
*****************************************************************************
*****************************************************************************
*****************************************************************************
限制2: 最大clock level is 127.
1. 每个连接的node都有自己的时钟, 来自initator或者相邻的anchor(和initator相近的)
2. 在
initator区域内的node,拥有 clock level 1
3. 在拥有clock level 1的anchor内, 但不在initator内的节点, 拥有 clock level 2, 以此类推...
4.
最大clock level is 127.
*****************************************************************************
*****************************************************************************
*****************************************************************************
系统扩展 - Tags
DRTLS系统拥有 150Hz的系统容量. 即
15 tags @ 10Hz (最大的定位速率)
150 tags @ 1Hz
300 tags @ 0.5Hz
9000 tags @ 0.01667 (最小, 每分钟定位一次.)
基于 tags 使用 TWR slot, 并且和 4 个 anchor 进行测距.
当superframe的15个slots 被 tag占据了, 那么 新tag 则无法获取一个slot进行测距.
所以, tag在某个区域要确定使用何种更新频率需要根据实际环境确定, 否则有可能在某些区域造成tag无法获取 ranging slot,造成无法定位.
*****************************************************************************
*****************************************************************************
*****************************************************************************
网络覆盖和拓展
1. DRTLS支持两种拓扑: 星型和线性结构. (star and line.)
星型网络
ANR:
routing anchor
ANx: anchor node
TNx: Tag node
BN1: gateway node.
橙色矩形框内为Tag的可检测区域.
如上所示为一个40m可视距离内的包含一个
gateway node的星型网络图.
因为上图存在
gateway(或者说listener节点), 所有节点必须至少在一个routing anchor的范围内, 以便于同 gateway 进行 uplink/downlink数据连接.
上图如果要扩展, 增加
routing anchor 即可.
上图为包含一个gateway node的线性网络拓扑.
*****************************************************************************
*****************************************************************************
*****************************************************************************
固件更新方式
在网络建立的器件,
initator 会自动检测各个节点的固件版本号, 如果不一样, 则会自动更新其固件(在配置了固件自动更新的选项时)
1. BT
可以使用 BT 更新 initator anchor 的固件, 然后 initator 会通过UWB radio link 传播新的固件给任何接入网络的节点.
initator anchor 更新后, 会自动重启. 所有节点会自动重连. 这样固件会通过UWB radio link更新, 更新期间, node会处于offline状态.
2. UWB:
要入网的节点, 监听Almanacs (包含了系统的硬件和固件信息), 如果需要固件更新,并且附件anchor的 TWR/data slot 是空闲的, 那么发送 "Firmware Update Data Request message".
收到Message的
anchor会通过UWB 信道, 发送firmware data(firmware data是广播性质的, 这样所有需要更新的的节点都可以接受并更新固件)
固件更新时, 数据先写入 softDevice(此时BT会失效, 写入速度比较慢, 每页约500ms). 校验后才写入FW区, 如果传输中断了, 节点发起断点自动重传, 直到所有数据OK. 校验失败也是自动重复更新过程.
手动升级可以通过SWD和 APK(BT)
*****************************************************************************
*****************************************************************************
*****************************************************************************
数据格式
系统使用标准的 IEEE 802.15.4 (MAC layer)格式.
Control + Seq + PANID + dst addr + src addr + payload + FCS
payload = MSGID 包含(BCN,SVC,CL_JOIN,POS,FWUP_xxx,TWR_xxx)
通过MSGID标定的消息格式有
BeaconMessage : anchor 通过 superframe 经由 BCN slot发出. 包括网络的一些使用情况(例如 TWR slot是否被使用, 一些Map信息.)
JoinRequestMessage: anchor
通过 superframe 经由 SVC slot发出. 包HW/FW版本号, 请求的座号等等.
JoinConfirmationMessage: 在 BeaconMessage之后发出.
AImanacMessage: 在网的
anchor 通过 superframe 经由 SVC slot发出, 包含自身节点的信息.
ServiceMessage:
在网的anchor 经由 SVC slot发出, 用于服务请求. 包括请求服务的服务ID,参数等.
FW_update_request: 更新固件请求.
FW_update_data:
固件报文
PositionMessage: 是 BeaconMessage的一部分, 包括anchor的位置信息.
GroupPollMessage: 广播报文, 从需要进行TWR exchange的节点发出, 一般是tag也可以是anchor(例如在auto-position时).
PollMessage: 有多个anchor会发出Poll, 作为
GroupPollMessage的响应. 作为 DTWR协议的一部分发给GroupPollMessage的发起者.
ResponseMessage: Tag 收到Poll后发起的广播报文.
FinalMessage: anchor收到
ResponseMessage后, 回应给 tag 的是 FinalMessage. 内容包含了用于确定距离的三个时间点(TX poll timestamp, RX response timestamp, TX final timestamp).
Tag 收到
FinalMessage, 计算得到距离. 因为入网是已经通过BeaconMessage获得了各个Anchor的位置, 通过内置的计算单元, 得到自己的位置.
