主要總結內容
在costmap里是怎么判斷機器人和障礙物碰撞了
stage_ros包輸入輸出，stage是怎么回事
rviz 中footprint和stage中position怎么聯系到一起
voxel grid和voxel layer怎么在costmap里起作用
costmap map type
在costmap里是怎么判斷機器人和障礙物碰撞了
圖片網址：http://wiki.ros.org/costmap_2d?action=AttachFile&do=get&target=costmapspec.png
在這幅圖片里可以看到左下角有兩個圓，一個機器人輪廓外切圓一個機器人內切圓
機器人在costmap里就能夠簡化成為這兩個圓
Inflation is the process of propagating cost values out from occupied cells that decrease with distance. For this purpose, we define 5 specific symbols for costmap values as they relate to a robot.
- "Lethal" cost means that there is an actual (workspace) obstacle in a cell. So if the robot's center were in that cell, the robot would obviously be in collision.
- "Inscribed" cost means that a cell is less than the robot's inscribed radius away from an actual obstacle. So the robot is certainly in collision with some obstacle if the robot center is in a cell that is at or above the inscribed cost.
-
"Possibly circumscribed" cost is similar to "inscribed", but using the robot's circumscribed radius as cutoff distance. Thus, if the robot center lies in a cell at or above this value, then it depends on the orientation of the robot whether it collides with an obstacle or not. We use the term "possibly" because it might be that it is not really an obstacle cell, but some user-preference, that put that particular cost value into the map. For example, if a user wants to express that a robot should attempt to avoid a particular area of a building, they may inset their own costs into the costmap for that region independent of any obstacles. Note, that although the value is 128 is used as an example in the diagram above, the true value is influenced by both the inscribed_radius and inflation_radius parameters as defined in the code.
- "Freespace" cost is assumed to be zero, and it means that there is nothing that should keep the robot from going there.
- "Unknown" cost means there is no information about a given cell. The user of the costmap can interpret this as they see fit.
- All other costs are assigned a value between "Freespace" and "Possibly circumscribed" depending on their distance from a "Lethal" cell and the decay function provided by the user.
The rationale behind these definitions is that we leave it up to planner implementations to care or not about the exact footprint, yet give them enough information that they can incur the cost of tracing out the footprint only in situations where the orientation actually matters.
這段話大概意思是
膨脹代價值隨着機器人離障礙物距離增加而減少
想象一幅圖都是格子，每個格子里有代價值：
"Lethal" cost代價值 一定有障礙物，這個格子上
"Inscribed" cost代價值說明這個格子離障礙物距離小於機器人內切圓半徑
"Possibly circumscribed"代價值說明這個格子離障礙物距離小於機器人外切圓半徑，但是大於內切圓半徑
當機器人中心在一個有着"Lethal" cost代價值格子上，看圖是256，則機器人肯定和障礙物相碰了
當機器人中心在一個有着"Inscribed" cost代價值格子上則機器人也肯定和障礙物相碰
當機器人中心在一個有着大於或者等於"Possibly circumscribed"代價值的格子上。則機器人不一定與障礙物相碰，這個取決於機器人方位
Note: In the picture above, the red cells represent obstacles in the costmap, the blue cells represent obstacles inflated by the inscribed radius of the robot, and the red polygon represents the footprint of the robot. For the robot to avoid collision, the footprint of the robot should never intersect a red cell and the center point of the robot should never cross a blue cell.
這段話說明機器人輪廓不能與紅色格子相交
機器人中心不能與藍色格子相交，藍色格子就是代價值為"Inscribed" 格子
stage是怎么回事
stage是一個仿真器提供了許多虛擬器件比如聲吶，激光，和移動平台
這些都定義在.world文件里
.world怎么寫：
http://playerstage.sourceforge.net/doc/stage-cvs/group__window.html
stage_ros包輸入輸出，是怎么回事
stage_ros封裝了stage一些model
laser, position and camera models
poition定義了移動小車
laser定義了激光數據
並且將數據用topic引出來
比如laser有/base_scan topic
這些topic被navigation接受，用於move_base進行local costmap創建
然后move_base路徑規划器在costmap上進行路徑規划輸出cmd_vel
cmd_vel是stage_ros訂閱的主題，驅動虛擬小車移動
rviz 中footprint和stage中position怎么聯系到一起
rviz是顯示用，stage會提供
tf transforms provided
base_link → base_laser
- transform from robot base to attached laser
base_footprint → base_link
- identity transform
odom → base_footprint
- transform from odometric origin to base
base_link → camera
- transform from robot base to attached camera
而move_base用的就是map->base_link在yaml文件里可以設定
所以當在rviz中指定一個目標后，move_base就會發布相應cmd_vel，stage就會接受這個topic，移動機器人，發布
odom → base_footprint變換，然后move_base就知道機器人到哪里了，發布/move_base_node/local_costmap/footprint
然后rviz讀取這個topic，實時改變rviz上footpront位置。
voxel grid是什么
voxel grid與occupancy grid不同
http://answers.ros.org/question/186783/difference-between-octomap-and-voxel-grid/
從上面那幅圖可以看出voxel是直接投影成二維圖像的，然后機器人在二維costmap上進行導航
Map Types
There are two main ways to initialize a costmap_2d::Costmap2DROS object. The first is to seed it with a user-generated static map (see the map_server package for documentation on building a map). In this case, the costmap is initialized to match the width, height, and obstacle information provided by the static map. This configuration is normally used in conjunction with a localization system, like amcl, that allows the robot to register obstacles in the map frame and update its costmap from sensor data as it drives through its environment.
The second way to initialize a costmap_2d::Costmap2DROS object is to give it a width and height and to set the rolling_window parameter to be true. The rolling_window parameter keeps the robot in the center of the costmap as it moves throughout the world, dropping obstacle information from the map as the robot moves too far from a given area. This type of configuration is most often used in an odometric coordinate frame where the robot only cares about obstacles within a local area.
costmap有兩種地圖，一種是用戶定義地圖，如激光網格地圖，提前建好
還有一種是設置rolling_window為true則機器人位於local costmap中心，機器人只能夠看到一定范圍內障礙物，比如5米5米，這個可以設定，超過這個距離機器人就放棄這個數據dropping obstacle information from the map as the robot moves too far from a given area