Ask Your Question
3

How to create a world link outside of robot's urdf?

asked 2011-09-27 12:14:28 -0500

seanarm gravatar image

After running the pr2_object_manipulation demo, I'm trying to create something similar. I have a urdf for my robot, who's topmost link in the tree is "baseFootprint". The urdf file launches the robot in an empty gazebo world just fine.

However, when filling out multi_dof_joints.yaml for configuring the environment_server, the environment_server expects baseFootprint to be the child_frame_id to some joint. For example, the pr2's multi_dof_joints.yaml contains:

multi_dof_joints:
name: base_joint
type: Floating
parent_frame_id: odom_combined
child_frame_id: base_footprint

Neither "base_joint" nor "odom_combined" exist in the pr2's urdf, but they're accepted by the KinematicModel because someone else is broadcasting their transforms (???) or that they exist (???). Furthermore, when running the pr2 demo, a world link (and transform to/from it) exists.

How then do I create my world, base_joint, and odom_combined in a similar manner?

Thanks, Sean

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
3

answered 2011-09-27 12:57:28 -0500

egiljones gravatar image

updated 2011-09-28 10:42:21 -0500

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.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2011-09-27 12:14:28 -0500

Seen: 1,352 times

Last updated: Sep 28 '11