Revision history [back]

The purpose of the world joint mechanism is to allow you to position your robot's base in the world. This joint isn't contained in the URDF as it's not really an aspect of your robot, but rather a product of whatever odometric system you are using. If you don't plan on moving your robot's base, or don't care about locating objects or the robot in some kind of world frame it's perfectly ok to set the parent_frame_id and the child_frame_id to 'base_footprint', in your case. The world joint will just produce an identity transform, and you'll just do everything relative to the current position of your robot, even if you move your robot around.

In the case of the PR2 we prefer to use the frame published by the odometric system - this is 'odom_combined', and the transform from 'odom_combined' to 'base_footprint' is determined using tf. This is mostly such that we can refer to things not just in the local frame of the robot but in a frame independent of the current position of the robot. Say, for instance, that we've run an object detection algorithm that has determined that there's a mug 3 meters in front of the robot and 1 meter up on a table, and that the PR2 is starting at (0,0,0) in the odometric frame. We can then place the mug at (3,0,1) in the odometric frame, and it's also at (3,0,1) in the base_footprint frame. Now we drive the base a meter closer to the mug - now the mug is (2,0,1) in the base_footprint frame, but it's position hasn't changed in the odometric_frame. If we were purely reasoning in the local robot frame we would need to re-run the object detection algorithm every time we moved the base. pr2_object_manipulation should work ok if you change the parent_frame_id to 'base_footprint'.

If you want to set up an odometric publisher for your robot you should look at packages like robot_pose_ekf.

Short answer: The world joint and link are implicit and implicitly the parent of any toplevel urdf link.

Long answer: The purpose of the world joint mechanism is to allow you to position your robot's base in the world. This joint isn't contained in the URDF as it's not really an aspect of your robot, but rather a product of whatever odometric system you are using. If you don't plan on moving your robot's base, or don't care about locating objects or the robot in some kind of world frame it's perfectly ok to set the parent_frame_id and the child_frame_id to 'base_footprint', in your case. The world joint will just produce an identity transform, and you'll just do everything relative to the current position of your robot, even if you move your robot around.

In the case of the PR2 we prefer to use the frame published by the odometric system - this is 'odom_combined', and the transform from 'odom_combined' to 'base_footprint' is determined using tf. This is mostly such that we can refer to things not just in the local frame of the robot but in a frame independent of the current position of the robot. Say, for instance, that we've run an object detection algorithm that has determined that there's a mug 3 meters in front of the robot and 1 meter up on a table, and that the PR2 is starting at (0,0,0) in the odometric frame. We can then place the mug at (3,0,1) in the odometric frame, and it's also at (3,0,1) in the base_footprint frame. Now we drive the base a meter closer to the mug - now the mug is (2,0,1) in the base_footprint frame, but it's position hasn't changed in the odometric_frame. If we were purely reasoning in the local robot frame we would need to re-run the object detection algorithm every time we moved the base. pr2_object_manipulation should work ok if you change the parent_frame_id to 'base_footprint'.

If you want to set up an odometric publisher for your robot you should look at packages like robot_pose_ekf.