SHIHUC

好记性不如烂笔头,还可以分享给别人看看! 专注基础算法,互联网架构,人工智能领域的技术实现和应用。
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

车载传感器数据研究-【MPU6050】

Posted on 2020-05-29 21:41  shihuc  阅读(662)  评论(0编辑  收藏  举报

今天要说的是一款测试加速度和角速度的6轴陀螺仪。在车载设备应用领域,有着很重要的价值,尤其是现在做基于驾驶行为的车险创新领域,车主的驾驶行为,无外乎就是急加速,急减速,急转弯这三急是最为重要的信息。

 

今天以6050为引子,同时介绍一下,车载设备采集数据后,通过4G模块传递数据,在TCP/IP通信层面,如何计算数据流量的问题。

 

(一)首先,6050的加速度数据结构,就要知道,他是一个16位的AD芯片,加速度,从空间的角度分析,分为X,Y,Z三个方向,每一个方向都是16位的精度。

这里,需要说明的是数据采集的精度问题,有4种设置模式,0-3. 选择对应的精度范围,AFS_SEL=0对应的量程是正负2g(即4g量程),AFS_SEL=3对应的量程是正负16g(即32g量程)。

这里涉及到采样数据的精度问题,多说几句,对于不太理解量程精度的读者,有一点点帮助价值。

  1. 因为6050是一个16位的AD采样芯片,很直观的理解,量程越大,对于采样位宽固定的情况下,每一个bit位的变化,映射到的量程范围是不一样的。
  2. 16位,对应的值65536种状态,对应量程为正负2g时,每一个g所占用的位宽是16384(即 65536/4=16384,单位LSB/g),同理,量程为正负16g时,每一个g所占用的位宽是2048(即65536/32=2048,单位LSB/g)
  3. 上述中LSB在这里是最小有效位的意思

因为加速度涉及X,Y,Z三个方向,每个方向的逻辑一样的,所以,这里就不再多说。

 

角速度的采集的采集逻辑,和加速度类似。

这里的数据精度分析,和加速度一样,角速度也有4种量程模式,同样的量程越大,精度越小。具体分析,参照加速度的精度分析逻辑。

 

 

(二)接下来,要说的是,车载设备采集加速度和角速度后,如何基于TCP向后台系统传递数据最省流量呢?

因为数据采样宽度是16位,所以需要2个字节传递一个方向的采样数据。就加速而言,一次采样数据就得6个字节,同理,角速度也需要6个字节。这样,加速度和角速度全采集,一次一共就是12个字节。

另外,对于匀速行驶的车辆,或者说车速变化不大的数据采集,就会存在传递的数据重复性太大,占用流量,没有产生太多价值,如何解决这个问题呢?

 

就好像我们看到的视频编码格式,最典型的H.264,为何他的编码压缩率那么高,视频质量也还是不错?就是因为他采用的是差值编码,穿插有参考帧,然后,解码的时候结合参考帧恢复视频图像。将时间轴这个维度充分利用起来,不再是独立帧解决自己的那一亩三分地的事情。

 

我们的数据传递,渗流量,同样可以采取这种模式,只传递差值,周期性的参考值,防止误差漫延

 

 

(三)车载设备消耗数据流量,如何计算这个流量呢?这个也是一个重点内容。

首先,要知道,无论基于任何通信协议或者方式传递消息,要让消息接收端能够很好的,正确的解析出内容的含义,就必然要约定一套通信规范,双方都能解读。就像我们人类语音一样,中国人是普通话,英美是英语,中国人和美国人聊天,彼此双方都懂这种聊天的语言才能继续下去,不管是说中文还是英文。

打比方,这次新冠病毒残害全人类,搞得大家生活工作受到极大的影响,假如我们人类懂CONV-19病毒的语言,我们就知道他想干啥,只可惜,我们对他的行动和所做所谓,不理解,或者不完全理解,所以,人类受到了极大的创伤。

 

话说回来,这个理解相互交流的语言的过程,就是基于一定的规范。

TCP通信,基于IP网络层,然后向下,依托以太网链路层,将数据传递到网络的对端目的地。这个过程非常复杂,我这里只是介绍,这个规范里面到底消耗了多少字节的信息,来保证通信两端能够解析彼此。

 

上图,是一个比较标准的TCP/IP的数据包的结构。TCP的数据部分,对应的是应用层数据,在我们这里,就是要传递的MPU6050采集的加速度和角速度数据。典型的,若不采用差值传递,就按每帧全数据采集(PCM编码基本思想,典型的案例AVI视频编码),采样一次12个字节。

那么传递这12个字节,需要多少通信额外开销呢?就要看TCP,IP以及以太网帧的帧结构基本字节数了。

 

(1)TCP的帧结构(端口号只是参考而已)

上图说明,TCP的包头部分,最小大小20字节。

 

(2)IP帧结构

从上面的帧结构可以看出,IP帧结构的最小大小也是20字节

 

(3)以太网帧结构

从上图可以看出,以太网帧包括目的MAC地址,源端MAC地址,类型,以及帧尾部的校验位CRC。每一个单元的字节长度在图上有标识。一共是6+6+2+4=18字节。

注意,以太网帧的数据部分字节数为46~1500字节,也就是说,对于TCP的报文,哪怕传一个空报文,也是要占46个字节的(空TCP报文,应该是20字节的IP包,加上20字节的TCP报文部分,即一共40字节)。那么这里,应该是40字节,为何是46字节,那多余的6字节那来的呢?

这里是题外话了,多余的6字节,是以太网协议完成的,在以太网封包的时候,校验到上层的数据不足46字节时,会在后面补充PAD数据,满足46字节

 

另外,还有一点需要明确的,以太网帧,从网卡传递出去的时候,需要在帧前添加引导字段(8字节),以及整个以太网帧的帧校验和字段(4字节),其排列结构如下图

 

这么一来,我们传递12个字节的MPU6050的采样数据,其实传递到后台的,是8 + ((6+6+2)+((20)+(20)+12)+4=78字节,注意,在用wireshark抓包时,只会看到66字节,因为前端的premable前导8字节和最后FCS/CRC的4字节,在网卡接收端将其去掉了。

 

 

综上,

计算网络传输流量,要相对精确的计算,就是要考虑网络通信协议的开销,以及数据载荷的开销

数据载荷的开销,若涉及降本增效的话,就要用到算法,压缩编码,节省流量