Export
Model data can be exported with Phobos in a number of TODOLformats. The most important being YAML, URDF, SMURF.
When finished with editing, you can export the model by again selecting all relevant layers (which in this case will be the first five), then select all objects (hitting A twice will do the trick) TODO why not use select robot? and then click on the Export Robot Model button on the very bottom of the tools panel on the left. 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 into URDF) you should definitely update the mesh files.
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, which is used throughout Phobos' code, or some properties that we have not yet changed for reasons of backwards-compatibility (such as mass). However, in general, plain simple properties are simply annotations to objects in Blender only.
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, attaching a motor to a joint works by creating the motor's properties as custom properties of the armature with the prefix motor/. 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. As of version 0.5 TODO still true?, we have not tested this use case extensively and 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. We have not invested a lot of time in dealing with such inconsistencies as for the moment, our standard use case is to create a robot in Blender and then export it in URDF, thus using URDF mostly downstream from Blender. 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 is 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 prefix upon import, for instance the camera sensor in the above example would be called 'sensor:camera' TODO still true?. Upon export, any prefixed in the shape of '*:' are sliced from the rest of the name. If you're not importing a model, this is something you have to do manually. Alternatively, it might be a good idea to avoid duplicate names alltogether.
Similar to the TODOLobject prefixes, links and joints present a naming problem in the sense that they are two objects in URDF derived from one object in Blender. It is entirely possible to export them with the same name, however if you wish to have different names, you can explicitly specify them as type-specific custom properties, i.e. joint/name and link/name.
While not supported as a basic object type by URDF, capsules may be desired to be used as collision objects. During export, a capsule will be treated as a cylinder plus to spheres, named 'name_cylinder', 'name_sphere1' and 'name_sphere2'. Additionally, the capsule's data will be added to the capsules list inside the 'model_collision.yml' file. In this way, a program loading the URDF file can either treat the capsule as the three basic objects specified in the URDF file, or use the additional SMURF information to import a true capsule if it supports this.
Back to top.
