Giters

skasperski / navigation_2d

ROS nodes to navigate a mobile robot in a planar environment

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Question about TF between Stage simulator and nav2d_karto

bairuofei opened this issue · comments

commented

Hi, when running nav2d for navigation, I find it is difficult to understand how frame_id in Stage and in nav2d_karto are related.

  1. Stage simulator publishes the message "/base_pose_ground_truth" with a frame_id "odom". The "odom/" frame is fixed according to .world file, typically being the initial position of the robot when setting localization as "odom" in .inc file.
  2. nav2d_karto publishes grid map "/map" and robot pose "/others" with a frame_id "map".

It seems that in rviz, the frame "odom" and "map" is closer each other, and changes slightly as SLAM operates. After checking the rqt_graph, I find the /Mapper node only subscribe the topic "base_scan" from the /Stage node. It seems there is no direct relationship between the two frame "odom" (in Stage) and "map" (in Karto SLAM). May I know at the very beginning how these two frames are related to each other?

Selection_007

commented

All frame-handling is done via topic /tf, if you enable tf in rqt_graph you will see that the mapper is connected via tf as well.

The mapper publishes the transform map->odom, so that the odometry frame slowly moves away from the origin, this is the expected behavior. (This is the correction of the odometry, which is calculated from the underlying SLAM)

You can use "rosrun tf view_frames" to generate a PDF with all frame information in the system.

commented

That's right, thank you for the explanation. The problem is really confusing and I also encounter a similar question here. Could you please check whether the following statements are right?

  1. The "map" frame is set equal to "odom" frame at the very beginning.
  2. When SLAM node receives a new "/base_scan", the scan is first positioned following the tf chain: map -> offset -> odom -> base_laser_link.
  3. SLAM node registers the "/base_scan" in current map, and gets an optimized pose estimation, which is different from the odometry estimation. The frame "offset" is adjusted to mitigate the difference, so that the "base_laser_link" is aligned with the optimized pose estimation given by SLAM node. Accordingly, the frame "odom" is slightly moving around the frame "map" because of the tf chain: map -> offset -> odom.
  4. So, to recover the ground truth pose of the robot, and the odometry pose of robot (both with frame_id being "odom", comes from Stage), one can just simply change the frame_id of these two topics as "map", which is actually the inital origin of the "odom" frame.

Am I right? Thank you for your time!

commented
  1. correct
  2. correct
  3. You can ignore the offset frame, this is only needed for a multi-robot scenario to account for the different starting positions of the robots. In a single-robot scenario, odom and offset will always be identical.
  4. I don't understand this point. Of course if you have a ground-truth, you don't need a SLAM but could use it directly. However this example is to demonstrate a setup that would also work on a real robot. So we use the ground-truth as if it were an odometry that introduces errors and use the map pose (map->offset->odom.>robot) for navigation.

PS: As a side note about 1: this is only true if you start the mapping and the robot directly, that is the odometry starts at origin. If the robot has already moved around before you start the mapping, then map and odom will not be aligned but set in such a way, that the robot is placed at the map origin. So the actual fact is: At start, robot and map are always identical.