ICub Model naming conventions

From Wiki for iCub and Friends
Revision as of 18:18, 6 November 2015 by Straversaro (talk | contribs) (→‎Joint additional information: fixed sign of torso_roll)
Jump to navigation Jump to search

For sharing models of the iCub kinematics and dynamics structure (for example in URDF and SDF format) we try to agree on a a set of names for links, joints, degrees of freedom and frames. At the moment this convention does not handle the eyes and the hands, because this degrees of freedom are not currently modeled in the URDF/SDF models of the iCub.


1-DOF Joints

Note: it could be useful to distinguish between the two different concepts of degree of freedom and joint. For simplicity we decide to ignore for the time being this difference, that is relevant for multi-DOF joints and closed kinematic structures.

The joints are mechanism that connect two different links (as defined in the following section) of the robot. 1-DOF joints allow motion only along one direction between the two connected links.

For joints an existing convention is introduced in . For the models we adopt this existing convention, disregarding eyes and hands.

Yarp ControlBoard name Joint name
left_leg l_hip_pitch
left_leg l_hip_roll
left_leg l_hip_yaw
left_leg l_knee
left_leg l_ankle_pitch
left_leg l_ankle_roll
right_leg r_hip_pitch
right_leg r_hip_roll
right_leg r_hip_yaw
right_leg r_knee
right_leg r_ankle_pitch
right_leg r_ankle_roll
torso torso_pitch
torso torso_roll
torso torso_yaw
head neck_pitch
head neck_roll
head neck_yaw
left_arm l_shoulder_pitch
left_arm l_shoulder_roll
left_arm l_shoulder_yaw
left_arm l_elbow
left_arm l_wrist_prosup
left_arm l_wrist_pitch
left_arm l_wrist_yaw
right_arm r_shoulder_pitch
right_arm r_shoulder_roll
right_arm r_shoulder_yaw
right_arm r_elbow
right_arm r_wrist_prosup
right_arm r_wrist_pitch
right_arm r_wrist_yaw

Fixed (0-DOFs) Joints

When dealing with 6-axis FT sensors, it is convenient to model them as joints that do not allow any motion between the two connected links.

In the iCub can be mounted up to 6 6-axis ft sensors.

Yarp AnalogSensor name Fixed joint name
left_arm l_arm_ft_sensor
right_arm r_arm_ft_sensor
left_leg l_leg_ft_sensor
left_foot l_foot_ft_sensor
right_leg r_leg_ft_sensor
right_foot r_foot_ft_sensor


The links are the physical rigid bodies that constitute the robot. Each link is characterised by a mass (represented in models by the inertial parameters) and a physical shape (represented in models by meshes).

For defining the links we are representing the robot as a directed tree, where the root_link is the body that can be attached to the pole, and the meaning of the other links can be deduced by their parent joint, as defined in the previous section.

The main idea behind this naming scheme is that “big” links (roughly speaking, the one that can reasonably interact with the user) are named with intuitive names such as upper_arm, forearm, upper_leg, lower_leg, chest, head, foot, hand. All the little links that instead are part of more complex linkages, take their name from the articulation, such as torso_1, torso_2.

Link Name Parent Joint Parent Link
l_hip_1 l_hip_pitch root_link
l_hip_2 l_hip_roll l_hip_1
l_hip_3 l_leg_ft_sensor l_hip_2
l_upper_leg l_hip_yaw l_hip_3
l_lower_leg l_knee l_upper_leg
l_ankle_1 l_ankle_pitch l_lower_leg
l_ankle_2 l_ankle_roll l_ankle_1
l_foot l_foot_ft_sensor l_ankle_2
r_hip_1 r_hip_pitch root_link
r_hip_2 r_hip_roll r_hip_1
r_hip_3 r_leg_ft_sensor r_hip_2
r_upper_leg r_hip_yaw r_hip_3
r_lower_leg r_knee r_upper_leg
r_ankle_1 r_ankle_pitch r_lower_leg
r_ankle_2 r_ankle_roll r_ankle_1
r_foot r_foot_ft_sensor r_ankle_2
torso_1 torso_pitch root_link
torso_2 torso_roll torso_1
chest torso_yaw torso_2
l_shoulder_1 l_shoulder_pitch chest
l_shoulder_2 l_shoulder_roll l_shoulder_1
l_shoulder_3 l_shoulder_yaw l_shoulder_2
l_upper_arm l_arm_ft_sensor l_shoulder_3
l_elbow_1 l_elbow l_forearm
l_forearm l_wrist_prosup l_elbow_1
l_wrist_1 l_wrist_pitch l_forearm
l_hand l_wrist_yaw l_wrist_1
r_shoulder_1 r_shoulder_pitch chest
r_shoulder_2 r_shoulder_roll r_shoulder_1
r_shoulder_3 r_shoulder_yaw r_shoulder_2
r_upper_arm r_arm_ft_sensor r_shoulder_3
r_elbow_1 r_elbow r_arm
r_forearm r_wrist_prosup r_elbow_1
r_wrist_1 r_wrist_pitch r_forearm
r_hand r_wrist_yaw r_wrist_1

Joint additional information

For some tasks (e.g. model building), it may be necessary to have additional joint information, such as the joint axis direction and the range of motion of the axis. To identify the axes' directions, however, a particular robot joint configuration must be set, since the positions of these axes depend upon the joint angles. To this purpose, we assume joint angles equal to zero (i.e. legs and arms straight down), implicitly assuming that the fine calibration has been carried on so that these zeros are properly defined Manual#Three._Calibration. Then, in this configuration, the joint axis is expressed with respect to the iCub's root frame, as defined in ICubForwardKinematics. One shall observe that the arm joint axes with joint angles equal to zero do not coincide perfectly with any of the root frame axes. Yet, the directions listed below help the user understand the arm axis directions. The range of motion can be extracted from the configuration files of the iCubGenovaXX robot.

P.S. The parenthesis around some of the numbers in the table below are only for formatting concerns, and should be ignored.

Joint name Joint type Axis (x) Axis (y) Axis (z) Min Max
l_hip_pitch Revolute 0 1 0
l_hip_roll Revolute (-1) 0 0
l_leg_ft_sensor Fixed * * * * *
l_hip_yaw Revolute 0 0 1
l_knee Revolute 0 1 0
l_ankle_pitch Revolute 0 (-1) 0
l_ankle_roll Revolute (-1) 0 0
l_foot_ft_sensor Fixed * * * * *
r_hip_pitch Revolute 0 1 0
r_hip_roll Revolute 1 0 0
r_leg_ft_sensor Fixed * * * * *
r_hip_yaw Revolute 0 0 (-1)
r_knee Revolute 0 1 0
r_ankle_pitch Revolute 0 (-1) 0
r_ankle_roll Revolute 1 0 0
r_foot_ft_sensor Fixed * * * * *
torso_pitch Revolute 0 (-1) 0
torso_roll Revolute (1) 0 0
torso_yaw Revolute 0 0 (-1)
l_shoulder_pitch Revolute 0 (-1) 0
l_shoulder_roll Revolute (-1) 0 0
l_shoulder_yaw Revolute 0 0 (-1)
l_arm_ft_sensor Fixed * * * * *
l_elbow Revolute 0 1 0
l_wrist_prosup Revolute 0 0 (-1)
l_wrist_pitch Revolute 1 0 0
l_wrist_yaw Revolute 0 (-1) 0
r_shoulder_pitch Revolute 0 (-1) 0
r_shoulder_roll Revolute 1 0 0
r_shoulder_yaw Revolute 0 0 1
r_arm_ft_sensor Fixed * * * * *
r_elbow Revolute 0 1 0
r_wrist_prosup Revolute 0 0 1
r_wrist_pitch Revolute (-1) 0 0
r_wrist_yaw Revolute 0 (-1) 0
neck_pitch Revolute 0 (1) 0
neck_roll Revolute (-1) 0 0
neck_yaw Revolute 0 0 (1)


In literature and in robotics software, the links and frames concepts are often confused, because every link is usually associated with a frame rigidly attached to it. However this link frame definition is dependent on the formalism that one uses for describing the robot. For example, if the Denavit Hartenberg convention is used the link frame origin is required to be placed on the axis of the child joint, while if the Modified Denavit Hartenberg convention or the URDF format the link frame origin is required to be place on the axis of the parent joint. To avoid inconsistency, we clearly separate frame and link concepts.

iKin Frames

For the iCub, it could be useful to explicitly state the frame used for defining the kinematic chains used in the iKin library. In particular a useful set of frames could be:

Frame Name Link Explanation
root_frame root_link Root reference frame, as defined in
imu_frame head Inertial sensor (XSens MTx) reference frame, as defined in
l_hand_dh_frame l_hand Left hand frame, as defined in
r_hand_dh_frame r_hand Right hand frame, as defined in
l_foot_dh_frame l_foot Left foot frame, as defined in
r_foot_dh_frame r_foot Right foot frame, as defined in
l_eye_frame — (missing at the moment) Left eye frame, as defined in
r_eye_frame — (missing at the moment) Right eye frame, as defined in
l_arm_ft_frame l_upper_arm,l_arm Left Arm FT sensor frame, as defined in
r_arm_ft_frame r_upper_arm,r_arm Right Arm FT sensor frame, as defined in
l_leg_ft_frame l_hip_2,l_hip_3 Left Leg FT sensor frame, as defined in
l_foot_ft_frame l_upper_foot,l_foot Left Foot FT sensor frame, as defined in
r_leg_ft_frame r_hip_2,r_hip_3 Right Leg FT sensor frame, as defined in
r_foot_ft_frame r_upper_foot,r_foot Right Foot FT sensor frame, as defined in

Skin Frames

An interesting set of frame is the frame defined by the iKin convention ( ). This reference frames are used by the skin system to express contact points, force and torques (in skinDynLib data structures) and taxel positions. The one currently used by the skin system are:

Frame Name Link Explanation
l_foot_dh_frame l_foot Frame of LEFT_FOOT SkinPart
r_foot_dh_frame r_foot Frame of RIGHT_FOOT SkinPart
l_upper_arm_dh_frame l_upper_arm Frame of SKIN_LEFT_UPPER_ARM SkinPart
l_forearm_dh_frame l_forearm Frame of SKIN_LEFT_FOREARM SkinPart
l_hand_dh_frame l_hand Frame of SKIN_LEFT_HAND SkinPart
r_upper_arm_dh_frame r_upper_arm Frame of SKIN_RIGHT_UPPER_ARM SkinPart
r_forearm_dh_frame r_forearm Frame of SKIN_RIGHT_FOREARM SkinPart
r_hand_dh_frame r_hand Frame of SKIN_RIGHT_HAND SkinPart

URDF frames

Some frames are defined to be compatible with certain convention used for URDF files, for example .

Frame Name Link Explanation
l_sole l_foot Frame oriented with X front, Y left, Z up. Origin placed on the intersection of the projection of l_ankle_roll and l_ankle_pitch axis on the plane of the lower side of metal sole (not the skin) of the foot.
r_sole r_foot Frame oriented with X front, Y left, Z up. Origin placed on the intersection of the projection of r_ankle_roll and r_ankle_pitch axis on the plane of the lower side of metal sole (not the skin) of the foot.