Mass and Inertia
It is important for simulation models to have a mass distribution close to the original robot, which can be tricky to achieve. The obvious and surely simplest method is to assign the masses to the visual objects of the robot as custom properties. In most setups, the visual objects will represent the actual parts of a real robot and thus it is straightforward to weigh those parts and set the masses in Blender accordingly.
Now URDF, in which we want to export, does not support masses for visual objects. It does not even support masses for collision objects which are, after all, a representation of physical objects for simulation purposes. What URDF does is demand the specification of one mass value per link, specified in a separate inertial element, so that masses of several physical objects belonging to that link have to be combined. URDF further demands that if there is an inertial object in the link, it also needs to define the resulting inertia tensor (as well as optionally a shifted center of mass location). Phobos takes care of all this and saves you from calculating all the masses and inertias of your links yourself. At least, a handful of different solutions to these issues are provided (beyond the obvious solution of not exporting mass and inertia information at all, which is of course possible).
Masses can be stored as custom properties in both visual and collision objects. The safest way to set these is using the Set Mass operator, which also assigns a time stamp of when the mass was changed, which comes in handy later.
Contrary to first intuition, there need not be equal numbers of collision and visual objects. For instance, to better represent the internal mass distribution of the main body of a robot, one might want to place an additional object with a large mass to simulate the battery inside the collision object which represents the outer casing. There may be other occasions when one wants to simulate a massless collision object, for instance to simulate a tactile fiber.
Thus, to cover all possible cases, Phobos lets you assign masses not only to visual, but also to collision objects, which makes it necessary to define which pairs of visual and collision objects belong together in order to correctly sum up the masses for a link. Phobos does this via their names: if a visual object called visual_foot_front_left and a collision object called collision_foot_front_left are both children of the same link, they will be automatically paired for purposes of synchronisation. This naming convention is used by default for collision objects generated by Phobos from visual objects.
Important Note: If you fail to name pairs of visual and collision objects correctly, yet still set the mass property in both objects, Phobos will fail to identify them as a pair and simply sum up the masses, resulting in a doubled mass value in the link.
The mass synchronisation within paired objects can be done in three ways: visual to collision, collision to visual and - in case you really lost track - latest to oldest. For this last variety, we need the timestamps set by the "Edit mass" operator mentioned before.
Inertia information is stored in Phobos' Blender models using inertial objects. There are two types of such objects: link inertial objects and visual inertial objects / collision inertial objects. All these objects are represented as orange cubes, with link inertial objects being larger than their visual and collision cousins. All collision objects relevant for a link are directly parented to that link (inertial objects parented to visual or collision objects are ignored).
Inertial objects will normally be found on the second layer and their required custom properties are 'inertial/inertia' and 'inertial/mass' for link inertial objects and simply 'inertia' and 'mass' for visual / object inertial objects. While 'inertial/mass' and 'mass' are float numbers, 'inertial/inertia' and 'inertia' are lists of floats formatted as:
[ixx, ixy, ixz, iyy, iyz, izz]
with i* representing the upper half of a 3x3 inertia tensor. This tensor can be calculated automatically from the mass and geometry data present in the visual and collision objects of a model and is saved along with the mass in the respective visual inertial objects and collision inertial objects.
So let's assume we have assigned and synchronized all masses, leaving the problem of handling the inertia. The first option to deal with it is to not deal with it: if only mass but no inertia information is provided, the masses are still exported to SMURF in the form of simulation-relevant annotations to visual and collision objects. In case you use the MARS simulation software, MARS will let ODE (the physics engine used) calculate inertia values from the geometry information provided for the objects, which is a reasonable approximation as long as real and simulated geometry are similar and the mass distribution of the real objects are rather homogenous (and the meshes are of decent quality). The drawback of this method is that different physics engines or simulation software might handle such cases differently and thus compatibility between simulations becomes an issue (or rather even more of an issue than it already is).
Phobos can calculate inertia for visual and collision objects using their mass and geometry information and integrate this data for a link. To do this, select the links for which you want the inertia data to be calculated and execute Create Inertial Object(s), which will delete existing inertial objects and create new ones based on the objects of a link.
Inertial objects thus created follow a similar naming convention as visual and collision objects, i.e. an inertial derived from object collision_foot_front_left will be named inertial_collision_foot_front_left. Explicitly creating these objects in Blender lets the user review the inertia tensors resulting from the collision geometry. Note that the inertia tensors are calculated in local coordinate space for each individual object and then integrated for the coordinate space of the link. The link inertial object created last is named "inertial_linkname" and contains the data that will be exported to URDF.
Important Note: Currently (Phobos 0.7) Phobos does not support calculating inertia tensors for mesh geometries, but instead assumes mesh objects to behave like ellipsoids. The current version on the master branch changes this to actual mesh inertia calculation which will likely be included in the next release.
Finally, if an approximation based on collision geometry - assuming homogenous density - won't do, the user can specify inertia explicitly. For this reason, both visual/collision-level inertial objects or link-level inertial objects can be created manually (or disabling the calculate automatically option of the Create Inertial Object(s) operator) and filled with inertia data that was precalculated, exported from CAD or measured on the real robot parts. This method can also be combined with the aforementioned one by creating inertial objects for every relevant visual and collision object, filling in the correct inertias and then letting Phobos calculate the combined inertia of the link. For this option, you have to mark the preserve child inertials option of the operator.
If an inertial object has to be moved - this is the case if it is not created at the COM of a link - it can be moved simply as any other object in Blender would be moved, by selecting it, hitting G and then moving it around. Movement can be restricted to certain axes by hitting X, Y or Z after hitting G respectively. You can even type in a certain distance, like so: G X 0.3 will move the object 0.3 units in X direction. If the axes keys are hit twice, Blender will choose the axes according to the object's local space rather than global space.
Back to top.
