看了B站你们发布的MUI-TARE，我有关于多车slam的问题和仿真器的问题！！！

[weixin_39463633]

1.首先是我没找到论文 ，若是已经发布了希望发个链接，拜读一下，就不需要大佬回答以下问题了。

2.我的毕业论文其中有一部分就是改你们的单车 tare  到多车上，但是太菜了，只做了需要初始化定位（通过统一的网格编号而全局共享网格状态）的版本。

之前有想过使用  disco_slam（一个多车slam算法） 做多车探索不需要初始化的方案，但有些关键节点没想通，放弃了，这就是和大佬的差距吧。

所以我想问一下你们是开发出了 多车slam 的算法再结合到规划上么？校园的那个仿真场景非常适合识别到相同场景拼接后返回探索，在森林场景有过测试么（若是中间使用的slam  森林场景应该是个大考验，拼接上）？

3.据我对你们仿真套件的了解，你们获取的点云地图是全局坐标点，并不是使用某个slam算法做的（若是以以前的仿真器，多个小车不同位置出发，他们获取的点云坐标是全局的坐标系（已经统一了所以我做的初始化定位版本在以前的仿真器上很好做）），你们在多车的算法上是丢弃了这种仿真思路？使用了某个多车slam算法？ 还是在规划算法里面，做了场景识别并拼接？

4.关于拼接后规划问题：   如果是各个小车的key-graph的融合应该很麻烦，是使用的各个小车的轨迹融合么？

[weixin_39463633]

@maxtomCMU 刚刚看了你们的论文，对于地图拼接那里，想法很精妙，牺牲一定的探索时间，去重复一段距离的轨迹判定是否是重叠的区域，结合automerge的拼接，到达阈值就判定是相同的位置。思路学习了，但没有能力开发一个多车slam算法。。。你们参考的基线SMMR-Explorer，是2D地图拼接（ros之前的一个包），在多层环境是失效的吧（我不知道我下载版本问题还是怎么说，SMMR-Explorer的子图通过计算特征向量比较分数再拼接的想法，在他们的开源代码里是关闭的那个参数，即所有的子图都做了拼接，所以非常激进的拼接），我之前找了一圈，没有合适比较的3D多车探索的基线。。。不过思路学习了！！！

[maxtomCMU]

@weixin_39463633 DiSCo-SLAM的局限性太大了，他基于的Scancontext本身对于场景识别的鲁棒性就比较差。如果放在大规模环境下做多机器人协作，轨迹的拼接一旦出错就会导致整个系统崩盘。可以简单参考一下我们刚放出来的论文 https://arxiv.org/abs/2209.10775 在真实环境中，由于机器人轨迹的不同，视角不同，动态环境影响等，会导致相同位置的识别率很低；如果再考虑重复性环境（走廊等），这都会给拼接带来巨大挑战。

[weixin_39463633]

@maxtomCMU 谢谢大佬的回复，之前看你们组织那个多车slam的比赛，就猜到是要融合到这里，太快了！！！期待论文！！期待大佬在解决无初始化定位的思路，之前在仿真器上改多车，获取的数据就是全局的坐标系，一步到位，没有多车slam 的问题了，就顺着做了下去，之后想无初始化定位时，找了那个多车slam的算法 ， 感觉在中途拼接成功时 ，不同小车不同起点编号的全局网格需要共享状态，各个小车的key-graph 的也需要拼接（只有轨迹拼接应该好做一些），感觉要改动的东西太多了（有初始定位的可以实时做拼接和共享，方便很多），有大概思路但不成熟。 当时大概思路是：每个小车以自己为坐标中心，每次规划贡献小车的局部网格状态，和当前位置。所有小车都接受其他小车的局部网格状态信息和位置， 假设有3个小车，在拼接成功前每个小车都维护3个网格，都维护三条轨迹，都是以各自起点位置为坐标轴，然后一旦拼接成功，就会出现各个坐标系的转换关系，这时启动融合，就这里出现问题，由于随机放置那么网格进行坐标系转换后不一定是准确的对应，很可能是错开的，以最低的状态进行定义（不确定会不会有问题） ，小车的轨迹融合比较简单，就是图上添加结点，并添加边（拼接成功的地方肯定有其他小车的轨迹点，扫描判定再连接就好），后序的协同分配，全局规划 按照之前的 TSP 思路 就抽象为 多站点路由问题 用那个or-tools包解决。 但想到仿真环境和算力和改动程度，就直接放弃了。期待论文！！！

[maxtomCMU]

1. Paper会很快上传到Arxiv，这两天就可以下了。后续相关的文章和程序会在以下github repo挂出来
   https://github.com/MetaSLAM/MUI-TARE_Server

2. MUI—TARE的特点是结合了TARE的强大单agent exploration能力，和我们之前的AutoMerge大规模地图拼接融合能力实现的。
   这一点也是一般Multi-Agent算法无法具备的，想进一步了解的话，请参考
   https://github.com/MetaSLAM/AutoMerge_Server

3. 我们以往的仿真环境主要是为了测试单个agent的exploration能力，但是在实际系统中比如需要稳定的激光里程计（LOAM，Leg哦LOAM，FastLIO等等）。后续我们会提供一个更大的仿真平台，进一步改进Multi-Agent性能，具体可以参考
   https://metaslam.github.io/softwares/playground/
   但是在large-scale环境下，就需要类似于AutoMerge这样的支持系统。

4. 是的，需要实时在线的地图融合，需要在精度和性能之间平衡。