Export
Model data can be exported with Phobos in a number of formats. The most important being YAML, URDF, SDF and SMURF.
When finished with editing, you can export either the full model or specific parts.
Exporting only a subset of the model might lead to unexpected behaviour, as the model hierarchy needs to be considered. To make this easier, use the export configurations.
If you want to export only the selected parts (instead of the whole model in the Blender scene), check the Selected only box in the Export panel of Phobos.
Make sure to check the options that you need, that is, whether or not the meshes should be exported and if yes, in which format. It is not necessary to export the meshes every time you export the robot. However, after changing the mesh type (which is used to write the file names in the robot description formats) you should definitely update the mesh files.
Exporting a robot to URDF, SDF and YAML at the same time. The small boxes
below allow special adjustments for the SDF and OBJ export.
Make sure you check the logs for errors or warnings in your model!
After the export is finished you can find the exported files in the specified
export folder. The formats are split into subfolders (such as
exportfolder/sdf or exportfolder/urdf) and the mesh formats are placed in
subfolders within the exportfolder/meshes directory.
Depending on your export format, files may also have been written to somewhere else (e.g. the Gazebo model folder).
When exporting a model to SMURF, it is not intrinsically obvious what to do with all the custom properties defined in the model's objects. This is why we introduced a category system in the names of custom properties.
Generally speaking, custom properties with simple names such as 'level' or
'left_side' are simply ignored by the export operator. This is so you may
define custom properties to be used only in Blender, for instance in
custom-made scripts. There are a few exceptions to this rule, like the
predefined phobostype property. However, in general, plain simple properties
are simply annotations to objects in Blender only, which will end up in the
internal export dictionary of Phobos.
The second category of custom properties is type-specific information. The
simplest example occurs in armature objects representing links. As the object
represents multiple output objects, type-specific information is encoded with
a corresponding prefix. For instance, joint-specific information such as the
maximum effort and velocity of the joint get encoded as joint/maxeffort and
joint/maxvelocity respectively. This information will only be written to the
joint, but not to the link. Similarly, adding a custom property material/...
to a material of a visual object will result in that property being written to
the material data of the SMURF model.
Finally, there is custom information. Any custom property named in the
format category/property where category is not one of the phobostypes
associated with an object, will get written to a custom YAML file of the SMURF
output named 'category.yml'. This file will contain a list of dictionaries
called 'category', with every dictionary having 2+n items: name and type of
the object, as well as n entries named after the specified properties,
containing the respective values. Thus, custom properties of the same category
defined in any object of a robot model will end up in the same YAML file.
As always when dealing with complicated constructs, there are numerous special cases that need to be covered, at least for providing some form of workaround to avoid problems.
A common use case for Phobos in the ROS world might be to import an existing URDF, edit the model, and export it again. This works in principle, but you will find that Phobos will make a number of changes to your URDF file, as it is essentially digested upon import and created completely from scratch (i.e. from the Blender scene) upon export. This means there may be some changes that you don't want in your model. To name but two, visual and collision elements will always be given a name and it might be that some joint axes are defined explicitly which were previously defined implicitly via the orientation of the joint.
However, this can be resolved by using a git maintained export directory and checking the changes in your model before commiting.
Our standard use case is to create a robot in Blender and then export it in URDF, thus using URDF mostly downstream from Blender. We have tried our best to eliminate the inconsistencies, but presumably we are still not finished. Please report any issues arising from using Phobos to edit existing URDF files and we will try to take care of them.
If the custom property filename exists in a visual or collision object and
the object is of geometry/type mesh, then that filename is written to the
URDF output, but the mesh is not exported even if the other meshes are. The
reason for this behavior is that it allows to import an existing URDF, make
some changes and export it without overwriting existing meshes - consequently
filenames of meshes are written in this custom property upon import. Thus, if
your particular desire is to edit the actual mesh and you would like to do so
in situ, you have to delete this custom property before exporting your model.
It is perfectly acceptable in URDF to give a link, a joint and a sensor all the
same name, 'camera' for instance. URDF does not run into conflicts here as
objects of different types exist in their mutual exclusive type spaces. When
trying to represent all these objects in Blender, the obvious problem occurs
that suddenly several objects may be supposed to have the same name. Blender
quite creatively deals with this by attaching .xyz to the name of an object
whose designated name already existed when it is created (xyz being a running
number). To avoid such rather awkward names (which would be exported, of
course), duplicate objects receive a custom property phobostype/name to
contain the object name. For instance a collision object would have
collision/name. On export this name will supersede the Blender object name if
applicable. You do not need to deal with this kind of management if you always
use the Change object name button in the Phobos Object Information panel.
Currently, we have no capsule support in Phobos. The old code is still there, but needs to be adapted to the new structure and internal representation of Phobos.
Back to top.
