Robot and Environmental Model Define Format

Overview of VRML Model

In OpenHRP, models that forms the robot and environmental objects, are defined by using the language called VRML2.0 (Virtual Reality Markup Language) which used to define 3D models. Each entity in the environment required an individual model file. Which means, to express a situation of a robot standing on the floor, you will need two VRML files(***.wrl); one for the floor and another for the robot, which would make two VRML files in total.

Basic layout of a VRML file is as follows.

Header:

PROTO declaration part (Declare the PROTO Structure)

The rest:

Real-model definition part (Declare the instances that uses PROTO)

PROTO declaration part is used to define new nodes that were not originally defined in VRML97. Therefore we use a node called "PROTO", which is similar to the concept of structure C language(For more details, please refer "PROTO Node").
The basic layout of real-model definition part is as follows:

    Humanoid sample(The root node of the whole model)
     + Joint WAIST (The center of the robot. A free point floats in the space)
     | ...
     |  + Joint Chest
     |    + Joint Head
     |    + Joint Left Arm
     |    + Joint Right Arm
     |
     + Joint Left Leg
     |
     + Joint Right Leg

This means, "Left leg", "Right leg" and the "Chest" are connected to the "Waist" which is floating in the space, and so as "Left arm", "Right arm" and the "Head" are connected to the "Chest".

The PROTO Node

In OpenHRP, the model is made by assembling instances of the following PROTO nodes. The PROTO node used here is based on PROTO node enacted by h-anim1.1, which is originaly used to describe human figure, and we extended/modified it to be use with OpenHRP model description. These OpenHRP PROTO nodes we will be using are Humanoid, Joint and Segment. We create models by combining instances of the these nodes and making a layered structure.

Apart from the three PROTO nodes mentioned above, we have prepared PROTO nodes to define various sensors. Camera, 6 axis ForceSensor, GyroSensor, AccelerationSensor and RangeSensor can be simulated by including each sensor in to the hierarchy.

Here, we explain the items defined by each node.

• Nodes that define link structure and dynamics/mechanism parameter.
  
  1. Humanoid Node
  2. Joint Node
  3. Segment Node
  4. ExtraJoint Node


• Nodes that define each sensor
  
  1. AccelerationSensor node
  2. GyroSensor node
  3. VisionSensor node
  4. ForceSensor node
  5. RangeSensor node

If the user have not defined values for each node, the default values in the fourth column of the list below, will be applied.

Humanoid

Humanoid is the root node of the model.

PROTO Humanoid [
  field         SFVec3f     bboxCenter        0 0 0
  field         SFVec3f     bboxSize          -1 -1 -1
  exposedField  SFVec3f     center            0 0 0
  exposedField  MFNode      humanoidBody      [ ]
  exposedField  MFString    info              [ ]
  exposedField  MFNode      joints            [ ]
  exposedField  SFString    name              ""
  exposedField  SFRotation  rotation          0 0 1 0
  exposedField  SFVec3f     scale             1 1 1
  exposedField  SFRotation  scaleOrientation  0 0 1 0
  exposedField  MFNode      segments          [ ]
  exposedField  MFNode      sites             [ ]
  exposedField  SFVec3f     translation       0 0 0
  exposedField  SFString    version           "1.1"
  exposedField  MFNode      viewpoints        [ ]
]
{
  Transform {
    bboxCenter       IS bboxCenter
    bboxSize         IS bboxSize
    center           IS center
    rotation         IS rotation
    scale            IS scale
    scaleOrientation IS scaleOrientation
    translation      IS translation
    children [
      Group {
        children IS viewpoints
      }
      Group {
        children IS humanoidBody 
      }
    ]
  }
}

Only one Humanoid node that becomes the root node of the model can be exist. Moreover, all the Joint/Segment names that you used are enumerated in the joints/segments field of the Humanoid node.

Joint

The Joint node specifies the Link Structure.

PROTO Joint [
  exposedField     SFVec3f      center              0 0 0
  exposedField     MFNode       children            []
  exposedField     MFFloat      llimit              []
  exposedField     MFFloat      lvlimit             []
  exposedField     SFRotation   limitOrientation    0 0 1 0
  exposedField     SFString     name                ""
  exposedField     SFRotation   rotation            0 0 1 0
  exposedField     SFVec3f      scale               1 1 1
  exposedField     SFRotation   scaleOrientation    0 0 1 0
  exposedField     MFFloat      stiffness           [ 0 0 0 ]
  exposedField     SFVec3f      translation         0 0 0
  exposedField     MFFloat      ulimit              []
  exposedField     MFFloat      uvlimit             []
  exposedField     SFString     jointType           ""
  exposedField     SFInt32      jointId             -1
  exposedField     SFVec3f      jointAxis           0 0 1

  exposedField     SFFloat      gearRatio           1
  exposedField     SFFloat      rotorInertia        0
  exposedField     SFFloat      rotorResistor       0
  exposedField     SFFloat      torqueConst         1
  exposedField     SFFloat      encoderPulse        1
]
{
  Transform {
    center           IS center
    children         IS children
    rotation         IS rotation
    scale            IS scale
    scaleOrientation IS scaleOrientation
    translation      IS translation
  }
}

⁽¹⁾ : These values are not used for simulation. These are for controller to read and control as appropriate not to go over the limits. Default value will be applied if not specified.

Joints are defined by using Joint Nodes. Joint Node contains information about the link frame. Child-Parent relationships of Joints, are applied to the Joint Nodes in same way. For instance, let`s consider a human arm; joints of a human arm exists in the order of "Shoulder > elbow > wrist". This can be represented by Joint Nodes as follows;

Fig 1. Arm Link Structure

DEF shoulder Joint {
  children [
    DEF elbow Joint {
      children [
        DEF wrist Joint {
            :
            :
            :
      ]
    }
  ]
}

A Joint having n DOF (n≥2) means, that the Joint is composed of n number of Joints, that are sharing same origin. In this case, define n number of Joints, placing all Link Frames at common origin. For example, human elbow can be consider as a Joint having 2 DOF, as shown below.

Fig 2. Elbow Link Structure

In this case, our Joints definition would be as follows.

DEF Elbow0 Joint {      //bending motion 
  children [
    DEF Elbow1 Joint {  //twisting motion

        :
        :
        :
    }
  ]
  translation 0 0 0  // Place all joints at origin
}

Segment

Segment node defines the Link shape.

PROTO Segment [
  field         SFVec3f   bboxCenter        0 0 0
  field         SFVec3f   bboxSize          -1 -1 -1
  exposedField  SFVec3f   centerOfMass      0 0 0
  exposedField  MFNode    children          [ ]
  exposedField  SFNode    coord             NULL
  exposedField  MFNode    displacers        [ ]
  exposedField  SFFloat   mass              0 
  exposedField  MFFloat   momentsOfInertia  [ 0 0 0 0 0 0 0 0 0 ]
  exposedField  SFString  name              ""
  eventIn       MFNode    addChildren
  eventIn       MFNode    removeChildren
]
{
  Group {
    addChildren    IS addChildren
    bboxCenter     IS bboxCenter
    bboxSize       IS bboxSize
    children       IS children
    removeChildren IS removeChildren
  }
}

Link Configuration is defined in the Segment Node. Two or more Segment nodes can be set up as a child node of a Joint node.It can also be described as a child node of a Transform node.

DEF JOINT1 Joint {
  children [
    DEF SEGMENT1 Segment {
      children [
          :
      ]
    }
    Transform {
      translation 0 0 0.5
      rotation 1 0 0 1.57
      children DEF SEGMENT2 Segment {
        children [
          :
        ]
      }
    }
  ]
}

For instance, let`s say you want to define the configuration of a human arm from shoulder to elbow. And since this configuration belongs to the shoulder link frame(parent node), the Link structure can be defined as follows;

Fig 3. Link Configuration from Shoulder to Elbow

DEF Shoulder Joint {
  children [
    DEF Shoulder2Elbow Segment {
      children [
        :
        :    <- Specify the actual link shape
        :
      ]
    }
    DEF Elbow Joint {
        :
        :
        :
    }
  ]
}

Parameters that define link characteristics, should be defined under the children field of the Segment node. To define these parameter values, we recommend you to use a modeling tool. However, simple shapes can be edit even manually, by using text editor.

ExtraJoint

ExtraJoint node defines closed link mechanism. Constraint force is generated so that two links may not separate, noting that one joint of a closed link is connected with ball joint.

PROTO ExtraJoint [
  exposedField SFString link1Name 	""
  exposedField SFString link2Name 	""
  exposedField SFVec3f  link1LocalPos 	0 0 0
  exposedField SFVec3f  link2LocalPos 	0 0 0
  exposedField SFString jointType 	"xyz"
  exposedField SFVec3f  jointAxis 	1 0 0
]
{
}

AccelerationSensor

AccelerationSensor node defines 3-axis acceleration sensor.

PROTO AccelerationSensor [
  exposedField SFVec3f    maxAcceleration -1 -1 -1
  exposedField SFVec3f    translation     0 0 0
  exposedField SFRotation rotation        0 0 1 0
  exposedField SFInt32    sensorId        -1
]
{
  Transform {
    translation IS translation
    rotation    IS rotation
  }
}

Various sensor nodes are placed under the Joint node in which the sensor is installed. For instance, when attaching an acceleration sensor to the WAIST of the sample model, it can be described as follows.

DEF WAIST Joint
{
     :
  children [
    DEF gsensor AccelerationSensor
    {
        :
    }
     :
  ]
}