[XMOVE自主设计的体感方案] XMove 4.0 无线组网协议-阿里云开发者社区

开发者社区> 人工智能> 正文
登录阅读全文

[XMOVE自主设计的体感方案] XMove 4.0 无线组网协议

简介:

一. 综述

  XMove 4.0需要支持多节点混合组网,在用户超过两个或两个以上时,可能会有多达40个以上的节点接入到系统之中。这些节点可能包括来自前几代的兼容节点,也可能是4.0的超微节点和手持节点。如何使这些节点正常无干扰的工作,并处于低功耗,是一个非常复杂而艰巨的任务。

  无线协议有以下具体任务:

  •   尽可能准确有效无丢包的将节点数据传递给上位机
  • 将上位机的控制信息有效的传递给节点,并使节点改变为相应的工作状态
  • 支持多节点多拓扑混合组网

  

  作者为通信专业出身,对无线协议有一定的了解。我通过以下方式来解决该问题:

  •   扁平的节点类型,尽可能简化的无线协议
  • 建立上行链路(从节点到PC机)和下行链路(从PC机到节点)
  • 所有协议全部内置PC端,由PC端发送指令实现控制逻辑,节点只负责按照工作模式执行工作
  • 使用多信道方式解决无线干扰问题,采用自动信道分配算法,实现最优接收结构

二. 节点状态描述

  所有节点都继承于XNode类,该类为基本的通信,工作模式提供了服务。具体细节请参看文集中的节点设计部分。

  1. 节点区分标记

  节点通过NodeType字段表明节点类型:

  

  

    例如,超微型节点XNodeMini处于XMOVE4.0,类型号为1,因此nodeTypeID=1。

  节点通过RawID确定其硬件ID号。

  注意,不同类型的节点允许存在相同ID,但相同类型节点不允许存在相同ID,否则系统无法判断。

   2. 节点能力描述

  

  六个属性分别给出该节点是否包含对应传感器是否存在的标识。

  3.节点工作状态描述

  对于节点工作状态,有两个类来描述,它们分别是描述节点自身工作状态,以及系统要求的工作状态。此处只介绍节点自身工作状态描述。

  

  三. 上行链路:从节点到PC机

  XMove上行信道统一采用24byte包长形式,其各位标记如下:

  其中,电池电量,三轴传感器数据的定义随节点不同而不同,此处不硬性规定。

四. 下行链路:从PC机到节点

  XMove下行链路控制更为简单,包长与上行一致,为24byte. 由于PC机通常没有2.4GHz无线通信能力,必须经过转接节点。转接节点收到数据后转发给各子节点。

  

  TransferID是要发送到的桥接节点ID,桥接节点发现本机ID与该字段一致时,才会认为是己方数据。

  PacketType是包类型描述,1代表是RF信道配置,用于配置本机不同射频模块的RF参数,后面每两个字节代表一个射频模块,分别是模块ID和要配置的信道ID。

  2代表配置子节点状态,桥接节点收到后,不经过任何处理,直接转发给子节点。子节点收到数据后,在该包中找到匹配的RawID,并通过该位下一位的WorkMode修正自身的工作模式。

五.  工作模式和信道控制逻辑

  控制信道涉及对节点工作模式和射频的控制两大部分。但实际上,它们是在一起发送的,下面我们分别介绍它们。

  1. 工作模式控制

  为了尽可能的降低节点功耗,节点的刷新速率和陀螺仪开启状态是应该根据需求动态调整的。在不需要节点传输数据时,节点应该以最低的4s一次的“呼吸包”通知管理器该节点依旧“存活”。而实际上,可能有多种应用同时需要该节点的数据,他们对该节点的工作状态需求是不同的。应该找到能满足这些应用的最低需求。为解决这个问题,我们设计了这个类:

  该类从NodeWorkMode继承,多了一个新属性:myNeededList ,它存储了所有应用对该节点的所有需求。当外界读取该类的WorkMode值时,它会返回满足这些需求的最低需求。它实际上是一个字典: Dictionary<IProgramWPF, Tuple<bool, NodeFreshSpeed>>。

  至于应用如何给出节点的工作模式需求,请参考XMove Studio应用开发API介绍。

  2. 信道分配算法

  为了尽可能提升系统的无线性能,硬件上采用了多个信道分配的策略,但这也造成了如何分配信道的问题。我们设计了如下的信道枚举:


/// <summary>
    /// 信道ID
    /// </summary>
    public enum RFChannel
    {
        /// <summary>
        /// 基础信道,默认节点开启时,处在该信道
        /// </summary>
        RF0=0,
        RF1=1,
        RF2=2,
        RF3=3,
        RF4=4,
        RF5=5,
        RF6=6,
        RF7=7
    }

 当节点开启时,所有的RF节点都以一秒一次的速度在RF0信道上工作。

  当所有节点都在通信方法的节点映射表中注册之后,系统会自动启动信道分配算法,并开始控制逻辑。其原则如下:

  •   系统中可能包含多个桥接节点,它们的RF信道数量可能不同,
  • 系统中包含大量子节点,它们都默认工作在RF0信道,应该将其均匀的分配在各信道中。
  • 若某信道的误包率太大,则应该将该节点切换到信道状态良好的信道。

  作者设计了RFChannelDistributor类专门解决信道分配问题:

  其具体操作流程如下:

  

  3. 发送控制信息

  当系统发现节点的工作模式与系统需求的工作模式不匹配时,系统就会启动控制信息发送过程。

  由于下行链路的包长为24字节,因此一次最多只能控制11个节点。系统只发送状态不正确的节点控制信息,若一次发不完,则分开发送。每个包发送后,都会经过300ms的延时,再发送一次,总共发送三次,保证数据发送无误。

六. 节点工作状态监视

  系统提供了节点工作状态监视组件。

  左边的列表给出了所有激活的节点队列,点选其中任意一项,右边的监测器就会对其工作状态进行监视,具体属性可参看使用说明,此处不赘述。

  若您希望手动更正所有节点工作模式和频段,在菜单栏中的“通信”一栏的“重配射频信道”选项,可以帮您完成该过程。

七. 总结

  本文详细介绍了XMove4.0的组网问题和工作模式描述。一篇文章无法描述完整内容。在上下行链路中,也仅仅介绍了2.4G射频信道的数据格式,手机蓝牙信道等都没有提及。

  实践证明,该配置可以简单高效的解决信道分配的问题,在实现各应用需求下实现最佳性能和最低功耗。

  有任何问题,欢迎讨论。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: