Structure of Robot Models
To understand how Phobos represents robots in Blender, it's informative to take a look at URDF first, the format to which the kinematic data of our Phobos models will ultimately be exported. URDF is a very well-documented format and wherever the information provided here may be missing something or not make intuitive sense, you can have a look at URDF's documentation to get a better idea of how it works.
In fact, we highly recommend that you take a look at URDF. There is less text than on this page.
Seriously, go check it out now! We mean it!
Blender as a 3D modeling software provides elements allowing to store all the data required to represent a robot model. This includes for instance bone objects to define a kinematic skeleton as well as objects containing mesh data for visual representation. While bones allow to directly store relevant information such as joint constraints, not all information required for robots is directly representable with pre-existing elements of Blender. Luckily, Blender allows to assign custom properties to every object in a scene, enabling to store any piece of information in an object. Phobos makes use of this by adding custom properties to existing objects as well as by creating helper objects to explicitly store additional data.
A complete robot model is thus composed of several layers of information, containing numerous kinds of objects, like so:
TODO Check image
Decomposition of the different elements from which Phobos models are composed in Blender. These elements can be arranged in Blender on different layers, thus avoiding confusion or obstruction of view when editing very complex models.
These information layers are realized as actual layers in Blender, similar to layers in graphical software. Phobos has a default setting to arrange objects of different types on different layers. These are specified as
| Layer | Type |
|---|---|
| 0 | links (joints) |
| 1 | inertials |
| 2 | visuals |
| 3 | collisions |
| 4 | sensors / controllers |
The type will determine on which layer objects are placed upon, import to or created by various operators. While you can arrange your model on layers as you wish, this might interfere with the function of some operators in a way hardly predictable. We are planning to give users more flexibility in their layer management in future versions. Nevertheless, if your model is nicely layered by types, it's possible to isolate certain types of objects by clicking on the layers below the viewing window (hold down SHIFT to select multiple layers). To move selected objects to a different layer, hit M.
URDF models consist of links defining coordinate frames relative to which objects for visualisation and collision detection can be arranged. These links themselves are placed relative to one another as defined by joints, each joint connecting two links.
Links are represented in Blender as armatures containing one single bone. Blender's armatures are designed for building a skeleton of an animated character, consisting of multiple bones which can be linked to one another and constrained in their movement. Phobos in contrast uses one armature object per link, with each armature containing one single bone, which simplifies copying and pasting of entire limbs with their attached visual and collision objects. More info in armatures and bones can be found in the Blender manual.
As URDF joints only define the transformations between links and their constraints of movement, they don't need to be represented as separate objects in Blender, as objects already contain a transformation (to their parent objects). Thus, links in Phobos contain their parent joint's information. Each such armature contains a single bone which in turn stores the constraints defined for the parent joint. In a way it could be said that the armature represents the link whereas the bone represents the joint. This is because armature and bone have their own coordinate systems, which coincide when an armature is newly created, but can be changed later. This is important as URDF allows to specify the axis of a joint independent of the transform the joint defines to get from its parent to its child link. By changing the orientation of the bone in relation to the armature, the axis orientation in relation to the joint space can be accompanied. This is especially so as the joint axis in Phobos equals the long axis of a bone, making it possible to visualize the axes in a model.
Phobos links (i.e. Blender armatures) can be connected - with joints - by setting up parent-child relationships between them, thus building a tree forming a hierarchical, branching kinematic chain (thus the name link). This way, the model in Blender allows a WYSIWYG (What-you-see-is-what-you-get) approach when emulating URDF.
Blender knows a number of different parenting types depending on the objects to be related. For Phobos, it is essential that you always use the Bone Relative parenting type. The reason for this is the following: As stated before, the axis of rotation of a joint is determined by the orientation of a bone. However Blender treats bones as essentially two objects in one: a pose bone and an edit bone. You might be thinking "Come on, not ANOTHER object!", but this is actually a pretty cool feature. It allows to define a rest position of an armature that equals the transform of the edit bones, and a pose position that defines an actual pose. Consequently, if you're turning the pose bone, all objects attached to it will turn with it. Not so with the edit bone: If this is changed, you simply change the bone itself and the relations to all attached objects are altered by Blender so they can remain where they are. This, however, only works in the Bone Relative parenting mode. Consequently, if you wish to change the rotation axis of a joint after your model has been completed, you simply change the edit bone and that's that - the bone's children will NOT get moved and the rest of your model stays intact. This is pretty handy when constantly having to adapt your robot model to ongoing mechanical design. When an armature is selected in blender, you can switch from "Object Mode" to "Edit Mode" or "Pose Mode" in the toolbar below the 3D view, allowing you to change the edit bone and pose bone.
Hitting CTRL + P will show a context menu for parenting which presents the available parenting types, with the one we want to choose at the very bottom. Note that the two types Bone and Bone Relative are not discriminated between in the Relations section of the properties panel on the right. Thus, the only way of making sure two objects use the correct parenting type is to parent them again to one another with the correct type.
In URDF, there are a number of different joint types, listed as follows (taken from the URDF website on joints):
- revolute - a hinge joint that rotates along the axis and has a limited range specified by the upper and lower limits.
- continuous - a continuous hinge joint that rotates around the axis and has no upper and lower limits
- prismatic - a sliding joint that slides along the axis, and has a limited range specified by the upper and lower limits.
- fixed - This is not really a joint because it cannot move. All degrees of freedom are locked. This type of joint does not require any axis, calibration, dynamics, limits or safety_controller.
- floating - This joint allows motion for all 6 degrees of freedom.
- planar - This joint allows motion in a plane perpendicular to the axis.
These joint types can be represented in Blender using the constraint definitions available for bones. Remember that every link is defined using one armature. Each of these armatures contains exactly one bone, which is oriented along the axis that defines the joint. Along or around this axis (depending on the type of joint), constraints can be set to limit the movement of the joint, so that it is not possible to set a joint position in Blender that the real robot is not capable of.
The Define Joint Constraint(s) operator allows to choose the type of joint and type in the desired joint limits. As all constraints are defined in the local coordinate frames of the individual bones, multiple identical joints can be set at the same time.
The concept of WYSIWYG using Blender's object hierarchy also extends to visual and collision objects, which in URDF define how a model looks like in a visualization and how it behaves colliding with other objects or itself. These objects are defined as children of links in URDF and thus in Phobos, they are Blender objects parented to links. Each link can contain multiple visual and/or collision objects, as illustrated in the following figures.
TODO Check image
An armature with one bone representing a link and two attached visual objects (we used Blender's mascot Suzanne here). The dashed lines indicate parent-child relationships.
TODO Check image
The same link as above, this time with the attached collision objects.
TODO Check image
Overlaying both object types illustrates how Blender simplifies approximating the actual robot with a reasonably detailed collision model.
To differentiate between objects we define as visual and collision, Phobos adds a new property to Blender objects named phobostype ('link', 'visual', 'collision' ...) When working with Phobos, it's important that each object has a correctly defined phobostype.
Visual and collisionTODOL objects are much simpler than links and joints. They are mere 3D-objects containing meshes. Like they were meant to in Blender, you can assign colored and textured materials to visual objects. You can also assign materials to collision objects if you wish, which often makes it easier to identify which visuals they relate to.
There still remain some important details, though. While you can create cubes and spheres etc. in Blender, Blender only keeps track of their geometrical shape upon creation and then forgets about it: all such objects are essentially meshes built from vertices. In order to write the correct geometry type to URDF when exporting your robot, we need to assign custom properties to the objects defining their type. This is specified in the custom property geometry/type, which holds strings naming the geometry types in URDF ('box', 'sphere'...).
<<<<<<< HEAD URDF allows to define the mass, center of mass (COM) and inertia tensor (at the COM) of links. To represent this data, Phobos uses inertial helper objects, which contain the data on mass and inertia explicitly and through their transformation store the COM of a link implicitly. Phobos allows to calculate the link inertia information and thus create the inertial objects semi-automatically, as described in the [Mass and Inertia](Mass and Inertia) section.
URDF allows to define the mass, center of mass (COM) and inertia tensor (at the COM) of links. To represent this data, Phobos uses inertial helper objects, which contain the data on mass and inertia explicitly and through their transformation store the COM of a link implicitly. Phobos allows to calculate the link inertia information and thus create the inertial objects semi-automatically, as described in the [Mass and Inertia](Mass and Inertia) TODOL section.
phobosV1
Motor specification always relates to an existing joint in Phobos and is thus stored together with that joint's data in a link object. Remember that each link object contains the information on its parent joint.
TODOL
Joint and motor data is stored in link objects using bone constraints (right) and custom properties (middle) with 'joint/' and 'motor/' prefixes.
For link objects, there is the problem that multiple categories of data must be stored in them. To avoid confusion, prefixes are added to property names, specifying which element the property belongs to, i.e. 'link/', 'joint/' and 'motor/'.
Sensors are realized in Phobos as objects of phobostype 'sensor'. This is due to them coming in very different forms and thus using (helper) objects is the easiest way to keep sensors consistent as a category while at the same time not limit the flexibility of how they can be realized. For instance, a camera sensor is an actual virtual camera in Blender and a laser scanner is represented as a translucent beam/disc. All data necessary to specify a sensor are stored in its custom properties, with the exception of such data for which Blender has a representation, such as the opening angles for cameras.
Back to top.
