3

扫地机器人地图与用户终端的同步 - englyf八戒

 1 year ago
source link: https://www.cnblogs.com/englyf/p/16853129.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

以下内容为本人的学习笔记,如需要转载,请声明原文链接 微信公众号「englyf」https://mp.weixin.qq.com/s/APaJheSbgTW3jNssWsp5Ng


地图数据来源于机器人算法模块,一般通过SLAM算法完成建图的过程。

2962155-20221103020255978-1058625772.jpg

建图过程中,基础数据涉及到各种实时的传感器,比如陀螺仪、激光雷达、线激光等等。这些传感器并不都是需要的,而是按照实际设计方案要求添加。比如目前市面上的那些扫地机器人里,廉价的最多只用了陀螺仪,主流的用了激光雷达,高档新潮的可能还加上线激光来达到宣称的三维建图,甚至有的还宣称用了摄像头达到AI识别障碍物。

why & what ?

地图数据里边一般会包含分辨率,长宽方向的点数和每个点的位置特征。分辨率用来表明每个点占据多大空间,代表着物理世界位置的尺寸单元。点的位置特征,通常表示为点的类型,用来分辨每个点代表什么东西,比如这个点是障碍物,悬空点或者正常的可通行位置。

地图里也会包含其它的一些位置信息,比如充电桩的坐标等。现在的自主式移动机器人都是使用电池供电的,因此充电桩也需要配套有。

其它需要包含的信息视乎需求而定。

由于地图数据包含了每个点的特征,因此数据量的总大小视乎地图的面积大小,面积越大地图数据也会越大。

既然地图数据大,那么就有必要在同步之前对数据进行压缩了。一般业内都采用LZ4的格式来压缩地图数据。

关于LZ4,看看官方的介绍

LZ4 is lossless compression algorithm, providing compression speed > 500 MB/s per core (>0.15 Bytes/cycle). It features an extremely fast decoder, with speed in multiple GB/s per core (~1 Byte/cycle). LZ4 library is provided as open source software using a BSD license.

https://lz4.github.io/lz4/

意思就是LZ4压缩和解压的速度非常快,而且是无损压缩哦。压缩每秒可以去到500MB,解压每秒可以去到GB等级,用来处理一般的地图数据而言,绰绰有余了。LZ4源代码工程遵循BSD授权,所以是免费使用的。

外部节点需要做的事情无非就是提供个可视化的界面给用户,用户再从中了解接收到地图的相关信息,重点是看得到的地图信息。那么,算法模块产生的地图数据就可以划分为两部分,一部分是只包含了图形化的信息(方便绘制地图),另一部分就包含了算法重定位的信息。

为了分离数据与外部节点的同步过程,地图数据的外发需要交给一个单独的模块处理,这里使用网络代理模块来称呼。

1.实时地图更新上传

自主移动式机器人在移动过程中,根据传感器的实时数据,算法模块生成地图数据,然后传递给网络代理模块,网络代理模块负责实时发往手机app等用户终端程序。

由于数据量大,如果数据经过任何第三方转发,比如IOT云,势必会挤占IOT云的带宽,导致IOT云的负担过重,所以这种大数据的传输只会从点到点,也就是我们常常用到的P2P传输方法。

2962155-20221103020243075-2137767581.jpg

地图数据在压缩后通常使用文件的形式来暂存,传输也以文件为单位把内容发送出去。

虽然地图数据走P2P的通道传送,但是传送的数据量毕竟比较大,一直传输地图数据会占用大量的本地带宽,而且接收端还得不断更新和对比接收到的数据。如果用户端在某些时段压根就不想要接收地图数据,比如使用的手机app页面切换到了和地图无关的设置界面,app这时就不需要接收任何的地图数据和浪费算力在这些无用的数据上面。

那么,可以通过设计一套心跳机制,只要app在一定的时间范围内有下发心跳包给到机器,机器的网络代理模块就知道在什么时候需要上传地图数据。

2962155-20221103020231514-1082151548.jpg

这种思路不会影响到算法模块对地图数据的生成。

2.云端多地图

有些用户希望可以在不同的地方,比如不同的楼层各有一份地图,并且保存下来方便在终端app随时调用。这就引出了对多地图的管理需求。

无论是云端还是本地,地图存在哪里都是可以的。不过,由于嵌入式的片内或者板上存储资源比较紧张,机器在本地一般只会存一份当前的临时地图数据文件。而其它的地图数据需要存放在云端,然后通过终端app调用管理。

鉴于有多份地图,那么终端app怎么区分哪一份云端地图和机器当前地图是对应的呢?这就需要在地图数据中引入地图ID的信息,这个ID由机器自分配和云端无关。

云端管理多地图,包括保存、删除、切换等。

将机器本地中的当前地图,以文件的形式上传到云端,上传的目的地址URL由云端分配。上传的数据包括图形化的地图数据以及用于地图重定位的信息,共两份。

但是,如果机器建图还没完成就触发了保存到云端,这样岂不是不合理?所以又有必要在地图数据中引入一个量来表示地图是否稳定,终端app可以根据这个量来判断是否允许保存到云端。

删除保存在云端的地图数据,操作过程仅涉及云端,无需机器参与。

通过下发指定的云端地图URL给到机器,由机器自主下载使用。由于云端保存的地图数据有两部分,机器其实只需要用到地图重地位的信息,那么下发的URL也只需指向用于地图重定位的数据文件即可。


其实,上面的内容也适合扫地机之外的移动机器人,关于地图还有很多可以聊,不过暂时聊到这,下次见...


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK