Webots Reference Manual - chapter 3 - section 37

Webots Reference Manual


3.37 Physics

Physics {
  SFFloat     density             1000      # (kg/m3) -1 or > 0
  SFFloat     mass                -1        # (kg) -1 or > 0
  SFVec3f     centerOfMass        0 0 0     # (-inf,inf)
  MFVec3f     inertiaMatrix       []        # empty or 2 values
  SFNode      damping             NULL      # optional damping node
}

3.37.1 Description

The Physics node allows to specify parameters for the physics simulation engine. Physics nodes are used in most Webots worlds with the exception of some purely kinematics-based simulations. The Physics node specifies the mass, the center of gravity and the mass distribution, thus allowing the physics engine to create a body and compute realistic forces.

A Physics node can be placed in a Solid node (or any node derived from Solid). The presence or absence of a Physics node in the physics field of a Solid defines whether the Solid will have a physics or a kinematic behavior.

In older Webots versions, coulombFriction, bounce, bounceVelocity and forceDependentSlip fields used to be specified in Physics nodes. Now these values must be specified in ContactProperties nodes. For compatibility reasons, these fields are still present in the Physics but they should no longer be used.

3.37.2 Field Summary

3.37.3 How to use Physics nodes?

If it contains a Physics node, a Solid object will be simulated in physics mode. The physics simulation mode takes into account the simulation of the forces that act on the bodies and the properties of these bodies, e.g., mass and moment of inertia. On the contrary, if its physics field is NULL, then the Solid will be simulated in kinematics mode. The kinematics mode simulates the objects motions without considering the forces that cause the motion. For example in kinematics mode an object can reach the desired speed immediately while in physics mode the inertial resistance will cause this object to accelerate progressively. It is usually not necessary to specify all the Physics nodes in a Webots world. Whether to use or not a Physics node in a particular case depends on what aspect of the real world your want to model in your simulation.

In passive objects

If a passive object should never move during a simulation then you should leave its physics field empty. In this case no contact force will be simulated on this object and hence it will never move. This is perfect for modeling walls or the floor. Furthermore the floor should always be designed without Physics node anyway, because otherwise it would fall under the action of gravity.

On the contrary, if a passive object needs to be pushed, kicked, dropped, etc. then it should have a Physics node. So for example, if you want to design a soccer game where the ball needs to be kicked and roll, then you will need to add a Physics node to the ball. Similarly, in a box pushing or stacking simulation, you will need to specify the Physics nodes for the boxes so that the friction and gravity forces are applied to these objects.

In robots

Articulated robot, humanoids, vehicles and so on, are built as hierarchies of Solid nodes (or subclasses of Solid). The contact and friction forces generated by legs or wheels are usually a central aspect of the simulation of robot locomotion. Similarly, the contact and friction forces of a grasping robotic hand or gripper is crucial for the simulation of such devices. Therefore the mechanical body parts of robots (eg., legs, wheels, arms, hands, etc) need in general to have Physics nodes.

The DifferentialWheels robot is a special case: it works even if it does not have Physics nodes. That's because Webots uses a special kinematics algorithm for DifferentialWheels robots without Physics. However, if the Physics nodes are present then Webots uses the regular physics simulation algorithms.

In servos

When designing the robot tree structure, there is one important rule to remember about the Physics nodes: If a Solid node has a Physics node then its parent must also have a Physics node (1). A consequence of this rule is that, in a robot tree structure, only leaf nodes can have a NULL physics field. In addition top nodes (Robot, DifferentialWheels or Supervisor) do usually have Physics because this is required to allow any of their children to use the physics simulation.

Note that each Physics node adds a significant complexity to the world: as a consequence the simulation speed decreases. Therefore the number of Physics nodes should be kept as low as possible. Fortunately, even with a complex wheeled or articulated robot some of the physics fields can remain empty (NULL). This is better explained with an example. Let's assume that you want to design an articulated robot with two legs. Your robot model may look like this (very simplified):

Robot {
  ...
  children [
    DEF LEG1 Servo {
      ...
      physics Physics {
      }
    }
    DEF LEG2 Servo {
      ...
      physics Physics {
      }
    }
  ]
  physics Physics {
  }
}

The legs need Physics nodes because the forces generated by their contact with the floor will allow the robot to move. If you would leave the legs without Physics, then no contact forces would be generated and therefore the robot would not move. Now, according to rule (1), because the legs have Physics nodes, their parent (the Robot node) must also have a Physics node. If the Physics node of the Robot was missing, the simulation would not work, the legs would fall off, etc.

Now suppose you would like to add a Camera to this robot. Let's also assume that the physical properties of this camera are not relevant for this simulation, say, because the mass of the camera is quite small and because we want to ignore potential collisions of the camera with other objects. In this case, you should leave the physics field of the camera empty. So the model with the camera would look like this:

Robot {
  ...
  children [
    DEF CAM Camera {
      ...
    }
    DEF LEG1 Servo {
      ...
      physics Physics {
      }
    }
    DEF LEG2 Servo {
      ...
      physics Physics {
      }
    }
  ]
  physics Physics {
  }
}

Now suppose that the camera needs to be motorized, e.g., it should rotate horizontally. Then the camera must simply be placed in a Servo node that controls its horizontal position. This time again, the physical properties of the camera motor are apparently unimportant. If we assume that the mass of the camera motor is small and that its inertia is not relevant, then the Physics node can also be omitted in this Servo. So we obtain a model without Physics node in the Camera and in the camera Servo:

Robot {
  ...
  children [
    DEF CAMERA_SERVO Servo {
      ...
      children [
        DEF CAM Camera {
          ...
        }
      }
    DEF LEG1 Servo {
      ...
      physics Physics {
      }
    }
    DEF LEG2 Servo {
      ...
      physics Physics {
      }
    }
  ]
  physics Physics {
  }
}

Devices

Most device nodes work without Physics node. But a Physics node can optionally be used if one wishes to simulate the weight and inertia of the device. So it is usually recommended to leave the physics field of a device empty, unless it represents a significant mass or volume in the simulated robot. This is true for these devices: Accelerometer, Camera, Compass, DistanceSensor, Emitter, GPS, LED, LightSensor, Pen, and Receiver.

The InertialUnit and Connector nodes work differently. Indeed, they require the presence of a Physics node in their parent node to be functional. It is also possible to specify a Physics node of the device but this adds an extra body to the simulation. The TouchSensor is also a special case: it needs a Physics node when it is used as "force" sensor; it does not necessarily need a Physics node when it is only used as "bumper" sensor.
release 7.0.2
Copyright © 2012 Cyberbotics Ltd. All right reserved.