iCub Model naming conventions
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.
For more info on the process used to generated URDF and SDF models of the iCub, please check this page
Joints
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 here . 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 |
Links
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 |
|---|---|---|
| root_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_upper_arm |
| 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 iCub 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\) |
Sensors
The names of the sensors mounted on iCub follows this convention:
<link>_<type>_<nr>
Where link is the name of the link the sensor is attached to (e.g., head), type is the type of sensor (e.g., imu), and nr is a number starting from 0.
Frames
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 ICubForwardKinematics |
| imu_frame | head | Inertial sensor (XSens MTx) reference frame, as defined in ICubForwardKinematics |
| l_hand_dh_frame | l_hand | Left hand frame, as defined in ICubForwardKinematics |
| r_hand_dh_frame | r_hand | Right hand frame, as defined in ICubForwardKinematics |
| l_foot_dh_frame | l_foot | Left foot frame, as defined in ICubForwardKinematics |
| r_foot_dh_frame | r_foot | Right foot frame, as defined in ICubForwardKinematics |
| l_eye_frame | — (missing at the moment) | Left eye frame, as defined in ICubForwardKinematics |
| r_eye_frame | — (missing at the moment) | Right eye frame, as defined in ICubForwardKinematics |
| l_arm_ft_frame | l_upper_arm,l_arm | Left Arm FT sensor frame, as defined in FT_sesors |
| r_arm_ft_frame | r_upper_arm,r_arm | Right Arm FT sensor frame, as defined in FT_sesors |
| l_leg_ft_frame | l_hip_2,l_hip_3 | Left Leg FT sensor frame, as defined in FT_sesors |
| l_foot_ft_frame | l_upper_foot,l_foot | Left Foot FT sensor frame, as defined in FT_sesors |
| r_leg_ft_frame | r_hip_2,r_hip_3 | Right Leg FT sensor frame, as defined in FT_sesors |
| r_foot_ft_frame | r_upper_foot,r_foot | Right Foot FT sensor frame, as defined in FT_sesors |
Skin Frames
An interesting set of frame is the frame defined by the iKin convention ( ICubForwardKinematics ). 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 http://www.ros.org/reps/rep-0120.html .
| 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. |
| l_upper_leg_back_contact | l_upper_leg | Frame oriented with Z front, Y left, X down. Origin placed on the back of the upper leg link. Useful to express the contact force between the leg and the chair for the `sitting configuration`. |
| r_upper_leg_back_contact | r_upper_leg | Frame oriented with Z front, Y left, X down. Origin placed on the back of the upper leg link. Useful to express the contact force between the leg and the chair for the `sitting configuration`. |