Modeling Robots in ROS

model

This is the primary way you describe the geometry of your robot. Typically, the model tag has many child tags that are primarily link and joint tags (described below). For almost every URDF that you'll encounter, the outermost tag will be the model tag.

link

Describe the kinematic and dynamic properties of links (distances, coordinates, inertias). You can also include kinematic and dynamic properties of all of the links, visual representations of the links, and collision models that can be used in motion planning and simulation.

joint

This tag is used for connecting links together. Has a variety of primitive motions available (prismatic, revolute, etc.).

gazebo

If you want to use your URDF in Gazebo for simulating your robot, you'll need to provide some basic attributes in this tag. Read more here on the Gazebo tutorial on using a URDF in Gazebo.

transmission

This is not used all that often unless you are using the ros_control package. The ros_control package can use this tag to understand how to simulate and implement low-level controllers.

sensor

Support for this tag has basically completely disappeared. These days if you need to model a sensor, it should be done entirely through Gazebo.

model_state

Also an idea that was never really finished, and is not used very often. Supposed to be used for specifying the robot at a particular configuration and time. However, this functionality has been completely supplanted by the SRDF.

sensor/proposals

This was supposed to be the future way of specifying sensors. It was never finished because of the creation of the SDF format.

• Describes a rigid body with inertial, visual, and collision features
• One required attribute (name)
• Three optional elements for every link

  inertial

  Defines the mass and rotational inertia properties of the link

  visual

  Display visual properties of the link. Can use several standard geometric primitives (box, cylinder, sphere), and can also use standard 3D body mesh representations (*.stl and *.dae)

  collision

  Define the collision model for the link using the same options as the visual tag. The collision model is used by many ROS motion planning tools (MoveIt!) and for simulations in Gazebo. Each link can have more than one collision tag

• Joints are used to describe the kinematics, dynamics, and limits of joints connecting links
• Every joint has two required attributes name and type

  name

  This is just the name of the joint

  type

  This described the type of motion between the link tags that the joint is dealing with. Available types include:

  revolute

  Single rotational DOF between the links with upper and lower limits on range of motion.

  continuous

  Single rotational DOF between the links with no limits.

  prismatic

  Single DOF prismatic joint with upper and lower limits.

  fixed

  Zero DOF between the links

  floating

  All 6 DOF free between the links

  planar

  2 DOF prismatic joint that allows motion in a plane

• Every link has two required elements:

  parent

  which link is the parent

  child

  which link is the child

• There are many optional elements most of which are fairly self-explanatory.
• Note that the safety_controller element is not used by anything except ros_control and the pr2_controller_manager
• If your joint has motions that are not described by one of the types above, then you'll need to compose multiple, co-located joints to build up your motion. For example, let's say you are trying to model a spherical joint between to links i.e. there are three mutually-orthogonal rotational degrees-of-freedom between your two links. Then, you would need to specify three consecutive continuous joints to build this behavior. These consecutive joints would require several "dummy" children-parent pairs of links that have no inertia, collisions, or visual properties.

One of the ways I've most commonly used this node is during the creation of URDFs. I'll add a few <joint> and <link> tags to my URDF, and then add that URDF to the parameter server as the /robot_description parameter, then I'll run the joint_state_publisher with ~use_gui set to true. Then I'll open rviz and use the joint_state_publisher GUI to drag the joint values around and ensure that the robot model in rviz behaves as I expect it to.

Imagine you have a robot with two arms (e.g. Baxter or Robonaut), and also imagine that the controllers for each arm are running as separate nodes. So you might end up with the /left_arm/joint_states topic providing the state of the left arm joints and /right_arm/joint_states topic providing the right arm joint states. Then you could run a single robot_state_publisher in the root namespace (/) along with a single instance of the joint_state_publisher in the root namespace. If you set the ~source_list private parameter of the joint_state_publisher to be ["/left_arm/joint_states", "/right_arm/joint_states"] then the joint_state_publisher could publish the /joint_states topic for the /robot_state_publisher node, and this topic would contain the combined information for both arms.

The Baxter robot has the ability to detect when grippers are attached/detached to/from his arm, and then automatically, the /joint_states topic will either include or exclude gripper position information. One issue, however, is that the original version of the robot_state_publisher doesn't allow for dynamic loading of the URDFs. So, if you take off a gripper, the only way to get the robot_state_publisher to properly acknowledge that the gripper is gone and not expect information about the gripper position is to restart the robot. This is not very convenient! So, we could just start up an instance of the joint_state_publisher that publishes default values for the gripper states. So the ROS world would still reflect that the gripper is there (even though it isn't), but at least we would still have a nice /tf tree (which is very important). Note that since V1.2 of the Baxter Research SDK, Baxter now runs a custom, patched version of the robot_state_publisher called the mutable_robot_state_publisher that subscribes to a special topic that allows you to add/remove parts of the URDF without restarting Baxter.