【发布时间】:2010-06-18 10:56:26
【问题描述】:
我正在使用一个机器人进行一个项目,该机器人必须找到通往物体的路,并在前往它必须拾取的物体时避开一些障碍。
问题在于机器人和机器人需要拾取的物体在探路者中都是一个像素宽。实际上,它们要大得多。 A* 探路者通常会选择将路线放置在障碍物的边缘,有时会使其与障碍物发生碰撞,我们不希望这样做。
我尝试在障碍物上添加更多不可步行的场地,但效果并不总是很好。它仍然会与障碍物发生碰撞,并且添加了太多不允许它行走的点,导致它没有可以运行的路径。
您对如何解决这个问题有什么建议吗?
编辑:
所以我按照贾斯汀 L 的建议做了,在障碍物周围增加了很多成本,结果如下: Grid with no path http://sogaard.us/uploades/1_grid_no_path.png
在这里你可以看到障碍物周围的成本,最初中间的两个障碍物应该看起来就像角落里的那些,但是在运行我们的探路者之后,成本似乎被覆盖了:
Grid with path http://sogaard.us/uploades/1_map_grid.png
Picture that shows things found on the picture http://sogaard.us/uploades/2_complete_map.png
上图显示了图片上发现的东西。
Path found http://sogaard.us/uploades/3_path.png
这是我们之前遇到的问题也是遇到障碍的路径。
The grid from before with the path on http://sogaard.us/uploades/4_mg_path.png
还有一张带有路径的成本图的图片。
所以我觉得奇怪的是为什么 A* 探路者会压倒这些非常高的现场成本。
是否会在用当前字段评估打开列表内的节点时,查看当前字段路径是否比打开列表内的路径短?
这是我用于探路者的代码:
Pathfinder.cs:http://pastebin.org/343774
Field.cs 和 Grid.cs:http://pastebin.org/343775
【问题讨论】:
-
澄清一下,这是一个实体机器人吗?你有一个机器人所在的物理场地图,你想通过软件地图 A* 的方式也允许你的物理机器人以相同的方向在物理地图中移动?
-
是的,没错,我们有一个网络摄像头挂在机器人上方,然后我们粘贴图像,将图像转换为可唤醒和不可唤醒的地图,然后我们将此地图提供给我们的 A*带有开始和结束坐标。目前我们是否在障碍物周围添加 ekstra none walkable fields,但这非常慢。
-
是的,正如 DoomStone 所说,我们在障碍物、物体和机器人所在的球场上方的三脚架上悬挂了一个网络摄像头。我们为这门课程拍照,解析它,以便我们找到物体和障碍物以及机器人,然后尝试从机器人到它必须拾取的物体建立一条路径。所以 A* 算法会返回我们可以运行的每个像素,正如我所说的,它经常会拥抱障碍物,如果说物体在机器人的另一侧。
标签: c# path-finding a-star