关于在CMU开源自主探索平台的仿真环境上运行

[113niko]

感谢你们工作的开源 ， 我看到你们在论文中对比了在四个场景下与TARE算法的性能差异 但为什么没有在TARE所提供的仿真环境中和TARE展开性能对比 然后我现在就是想要把FAEL部署到对应的仿真环境中 想请问下 你们是否有尝试过这方面的工作

[113niko]

还有就是想请问下 跑demo的时候一直卡在preparing your world 应该是卡在下载模型了 想问下 您在readme中也提到可以提前下载 是要把那个网页的所有模型都下载下来吗 还是下载指定的 就是这块不太明确

[hjlstudy]

这个不需要全部下载，随便下载一个放入gazebo对应目录中即可快速打开，最好是全都下载，我的仿真环境中用了里面的几个模型，具体是哪个我也不确定；由于之前我使用电脑配置较低，gazebo无法加载TARE开源的那几个大规模仿真场景，勉强能加载的仿真时也容易卡死，就自己制作了几个轻量版的场景，TARE中那个indoor的场景印象中有做过尝试，但是里面存在一个有栏杆的房间，我们这个开源工作中可能无法适应那种场景。

[113niko]

好的好的 我已经解决了gazebo加载的问题 感谢您的回答！就还是想再问下 为什么您这篇工作选取衡量探索效率的指标是探索面积 这个面积是怎么定义的 因为以您这里的场景scene1中 论文中是9274 然后对应的map_area参数是4582，这个4582也不是9274的95% 就这个为啥不用和tare一致的 通过点云体素降采样 计算建图体积来衡量呢 然后您这里探索终止的条件是达到95％面积就终止探索 但感觉这是建立在已知环境面积大小的情况 在未知条件下 是不是也不好这样设置 TARE中是没有待探索的子空间后 回到起点为探索终止的标志 您这里的探索终止条件不知道是不是我上面所描述的这样 也有可能是我的理解有问题 望您解答 谢谢！

[113niko]

同时在运行demo时 source devel/setup.bash && roslaunch exploration_manager sim_env.launch使用这条命令 出现了上图的问题 然后我在issue里找到了类似的问题 根据他的操作 修改了gazebo文件的配置 但还是有这四个报错 想问下您 有没有出现过这样的问题

[hjlstudy]

您好，由于针对的是大规模场景中的地面探索，我们认为使用已探索面积作为指标应该更合适一点。配置中的地图面积这个参数是提前测量的的仿真地图可探索的面积大小，地图命名顺序可能与论文中的可能不一致，另95%这个阈值参数在统计节点那个代码文件中。仿真中几个对比的探索算法的终止条件不一样，到了后期可能会因为小部分frontier的存在而继续探索，造成时间和路径长度的大量增加，为了使各个对比算法的终止条件统一，考虑到大规模场景的探索任务，快速获取95%的环境区域已经可以体现算法的性能，因此统一设置95%已探索区域为终止条件。对比时的终止条件可由您自由设置，合理即可，如果您想让其回到起点，也可以将对比算法都加入回起点这个功能。真实的未知场景中往往采用别的终止条件，比如没有可视的frontier，剩余能量阈值，最大探索时间等。