dfki-ric / phobos Goto Github PK

Exporting light sources from blender would be a nice addition.

Phobos allows to define "type/name" custom properties, thus enabling the export of custom names for objects (instead of using the default names derived from the Blender object names).
It seems this functionality collides with the lists of objects created and exported for node/joint sensors as well as motors and in some cases one ends up with different names referring to objects in different contexts.
The solution is to always use the custom-defined name property when it exists.

Default behaviour of Phobos should be to export mesh data of a model to a subfolder of that model called meshes. It should be possible for the user to change that folder, for which the GUI should provide a text field (that be default contains 'meshes/'.

We should unify the units between both operators and we should read the joint values for when adding new motors functionality in case they are present (in case a motor is present, the existing values should be used, of course).

MARS scenes do not necessarily only contain one entity, can consist of many independent objects (like heightmaps, robots, lights...). These should all be correctly imported and arranged in such a way that an export of a SMURF scene is possible with minimum effort.

Texture export uses the name set in Object->Texture->Image->First Line ("Image Datablock...") instead of the filename set in "Source" below. When the source image name changes (by selecting a new image with a different name), the "Image Datablock" name above stays the same and references a wrong or deleted image.

Every joint get a motor, even if it is fixed and/or passive.

There are a few points about inertial objects and masses that I noticed might not always work how we intended them to work or that we at least have to rethink for consistency reasons:

• synchronization of visual/collision masses does not seem to work in some cases
• inertias get exported even though they are not selected - how do we want the default?
• when masses of objects are updated, should we re-create any inertial objects present?
• export of masses to SMURF if there is no inertia (and thus no inertial export to URDF) ?

There have been quite a few changes in how data is handled since the last release, as well as additional features such as sensors. Thus for 0.6, we need to update our example robot model in order for it to serve as a helpful "cheat sheet" for people.

The Phobos GUI elements have become quite numerous and we should seriously consider a new layout that will make Phobos easier to use while keeping in mind which functionality is still planned to be added in future releases, avoiding another layout reset further down the road.

If we manage this in time, an include in the upcoming release 0.6 would be nice, but 0.7 would be fine in my book.

The robot dictionary should be checked with predefined YAML files to verify the robot model before exporting it.

Many tools out there are not compatible with .obj or .stl, but with collada (.dae). Blender allows to export collada files, and we should implement this to be compatible.

Hi @kavonszadkowski,

when trying to load an old .scn file phobos crashes saying:

Unknown model format, aborting import...
Traceback (most recent call last):
  File "/Users/bergatt/Library/Application Support/Blender/2.73/scripts/addons/phobos/importer.py", line 2070, in execute
    importer.parseModel()
UnboundLocalError: local variable 'importer' referenced before assignment

I had to extract the .scn into a folder and was then able to load the .scene
but it shouldn't be too hard to also support the unpacking the .scn before
importing the .scene files.

Best regards,
Constantin

Links that are NOT centered in the pivot of the child object (e.g. a door hinge) are still exported to SMURF at the pivot, so that e.g. a door swings around its middle instead of one of its edges.

Some categorical data files such as _collision.yml always get exported, even if they are empty. This causes problems with the MARS import and is not very sensible to begin with.

As smurfs for a scene get exported into subdirectories, the probably shared textures have to be copied into each subfolder. A nice feature would be the possibility to choose a relative path for the textures which should be immune to changing between exporting single robots from a scene and the whole scene. This means that the textures should be found by MARS no matter if the single smurfs are loaded from their subdirectories or from a SMURFS-file from their parent directory.

This kind of problem probably also happens with other phobos operators:
When selecting a bone that already has joint constraints set and then acivating the "Define joint constraints" operator, the current values of the joint immediately get overwritten by the last values set in the operator. Maybe this is how operators work, however, I think it would be nicer if the current values get read first and can then be adapted only where necessary.

Currently, not all Phobos-internal properties (using $) are purged from the robot dictionary before export to SMURF (I noticed when I found a $controller in _motors.yaml).

Phobos exports meshes into a "meshes" subfolder, but does not add that directory as a prefix to <mesh filename="XYZ.abc".

Thus the meshes are only found when they have previously been exported by an older phobos version that did not put the meshes into this subfolder, so in many such cases this error will not be detected.

Phobos does not adhere to a consistent (e.g. alphabetical) order of URDF elements on export which makes it hard to compare different versions with one another using diff tools such as Meld or Diffuse and which makes committing to git repositories etc. that much harder. We should fix this.

In a scene I have multiple robots which are positioned differently to one another in the MARS simulation compared to the original scene in Blender. Only the position of root links is wrong, the position of child links within a robot is OK.

I am currently looking into the issue. Might be something relating to the root links being a special case as their positions are not stored in joints but in the scene's smurfs-file. (Although everything seems to be correct so far.)

I am excited by your tool, have been looking for something like this for some time to model robots. While I do have it installed successfully, I have to confess I am having some trouble following the tutorials as it applies to creating simple links. I get URDF exports that are garbage where my links do not reflect a hierarchy. It may be my lack of familiarity with blender or I am not understanding how to use "create links" correctly...

Can I request a very very simple video on youtube demonstrating the creation and treatment of a super-simple URDF structure? Just take two cubes, make them links, and put a joint between them. And export. It would be enormously helpful to see the steps and sequence. A 2 minute video can take the place of many documentation pages.

Sincere thanks...

Exporting of meshes etc. to subfolders does not seem to work correctly, yet, especially if multiple models are exported.

Camera sensors are attached to a link to determine their position and orientation in the model. Importing a model in MARS, the camera points in X direction, with Z up. We must ensure in Phobos that a camera is always oriented accordingly to its parent link, so that the camera perspective shown in Phobos is the one used in MARS.

There seems to be a problem with the new implementation of the phobos defs using YAML files. When you run the operator and want to choose the sensor type, a really long repetitive list gets displayed.

The export and import of meshes is still hacky and should be cleaned up (and verified against MARS).

Exporting meshes with modifiers tends to crash Blender and MARS when using .obj and only MARS when using .bobj. Applying the modifiers before solves the problem, so when exporting (which to my knowledge includes making a copy of the object), applying all the modifiers to the copy should solve the problem.

Another problem is probably active here: The copy is moved to [0,0,0], right? If it uses a boolean operation with another object "A" or is for example deformed by a lattice "A", then the object will get corrupted by moving it away from its current position (as the other object "A" will stay in place). So the object should be

1. copied in place
2. get all modifierts applied
3. be set to [0,0,0] or wherever necessary
4. then get exported

Joint and Motor maximum speeds currently have no consistent units. We should provide two units for angular speed in Phobos (rad/s and Hz) and one for linear (m/s). As for the output written in URDF, we should use the standard unit defined there for angular speed and use the same in SMURF for the motors. We should double-check which unit is expected by MARS (Should be the one currently written to SMURF).

It's possible to export an invalid joint, namely Phobos is happy to export a joint with out maximum effort, thus creating an invalid URDF. We should check again for all joint parameters and notify the user if there is information missing and therefore the URDF created is not valid.

We should not prevent export though, as it might be the case that some people want to edit effort and other parameters manually or via some scripts later on.

Joint limits translate to strange values in blender bone constraints. A joint limit like for example max 90° is stored in the blender bone constraints as 5156.62d, which makes no sense to me, even when goint from rad to degrees or back.

However, it is correctly exported as max 90° into URDF and motors.yml, however, I can still move a door with min 0° and max 90° by more than 90° (which is probably more a problem on the mars side).

The functionality to share meshes between Blender objects needs final testing and documentation before the next release. We also need to double-check whether it works nicely together with the pre-existing functionality to avoid mesh re-export when importing and exporting URDF.

Scene export exports sub-smurfs into subfolders, while robot export does not. It would be better if for example robots were always exported into subdirectories so that no redundant copies are created.

Masses are seemingly ignored, when setting them (in visual, collision and inertial object) to e.g. 2, the mass of the node stays 0, the density stays always 1.

Silvio raised a very valid point in #5 about the way sensor information is encoded in Phobos. I quote:

Hi, congratulations for the great software.
I read here that you plan to add sensors information to your model editor. Which kind of format you
plan to use for encoding sensors information in the URDF ?

In the urdfdom repository there is an open discussion [1] for new URDF specifications regarding
sensors. Do you think it could be worth to share your proposal for simplify integration and
interoperability of different software using sensor information from URDF?

[1] : ros/urdfdom#28

My short take on this issue is that we are aware of this problem, but have so far have been working with our historic restrictions and the need to get things done without waiting for URDF to be extended.

The long version would be that we mainly use Phobos with the MARS simulation and have thus adapted the description of our sensors to the one previously used in MARS for quick integration of our new description format SMURF. It would absolutely be worthwhile to integrate URDF sensor definitions as soon as they are decided upon, the main problem being that URDF thus far is not meant to be particularly extensible, which is something we definitely strive for and somewhat rely upon. What I do not fancy is a scenario where some sensors are encoded in URDF and other still have to be added in our SMURF extensions if URDF does not provide definitions for them similar to the problem that now already exists with URDF and SRDF both defining collision data.

Either way, we should obviously be keeping tabs on URDF's solution to sensors.

I had a situation where mesh "doorKnobStart.000" was shared for objects named like "doorKnobEnd.000" and only "doorKnobStart.008.bobj" was exported.
Also this is not easy to undo.
It should be choosable what the shared mesh name will be.

Being able to edit collision groups within phobos would be a nice addition.

At least for version 1.0 it would be nice to have a logo for Phobos, but preferably earlier.
Anyone's got any ingenious ideas?

When having multiple copies of a robot in a scene sharing the same robot name, they all get exported but are set to the same position in the ".smurfs"-scene-file although they have different positions in Blender.

Related to #5, we need to update the modeling tutorial to include all changes since the last release.

We should also seriously get round to getting our hands dirty on videos (#3), though this is something we could add after the release.

"Name Robot" should work on multiple selected robots. Then it would be possible to for example export a large number of similar objects that are expected to move independently (e.g. spheres roughly representing water particles).

It often be the case that a URDF is derived from the CAD files of a robot and imported by Phobos to serve as a starting point to create the SMURF. It will also often be the case that this happens early during design of a robot and as the ongoing construction changes, the URDF exported from CAD changes.

At the moment, this means that someone working with Phobos has to import the updated URDF and manually add all the information such as motors and sensors that was previously added. To avoid such hassle, we should implement an "update URDF" operator that updates the Blender model by moving and reorienting links, updating meshes (optional) etc.

One important issue concerning this functionality is that the names of links imported from URDF will most likely be changed when editing the SMURF. Thus we need a name-mapping functionality to still be able to later update existing, renamed links and joints. This could be done for instance by storing the imported URDF names for links and joints in the respective bones as custom properties that don't get exported or by saving them in a YAML dictionary in a text file (the former is probably easier, but also clutters the model). We might need a rename operator for that, as I we probably cannot catch renaming events in the Blender GUI.

This issue is something that will take time and should be thoroughly debugged, thus I'd propose that we push this to the end of Milestone 0.6.5. If we don't get it done in time, it will be included in 0.7 instead.

We have to decide how to treat Boolean custom values. The problem is that Blender interprets Booleans in dictionaries as 1 and 0, not as True and False. We could maybe use strings instead (lowercase true and false in YAML I think) if we want to make the exported files more readable. Otherwise we have to double-check whether the import in MARS always works correctly (C++ is of course happy with 1s and 0s, but there may be type issues with our ConfigMaps).

For beeing able to construct closed loops of joints and bodys (parallel kinematics), objects have to be adjustable to have more than one parent, otherwise a wrong physical representation for this purpose is generated in Phobos

If you download the phobos repository via zip file it is named phobos-master. Even after renaming it to phobos, the blender installation routine via zip file extracts the archive to phobos-master.
This causes errors by loading the yaml module, because the script expects the folder to be named phobos. That means installation via zip file is not working in the moment unless you do some stuff manually (renaming the extracted archive after installation).

Is there any known way to alter the name of the donwloaded folder on github or should we rename the path in the script (not recommended)? Or should we dismiss zip installation at all and create a windows installation script too?

URDF allows identical names for objects as long as they are of different types, i.e. you could have a visual object called head and a collision object called head. Phobos does not currently support this, as all object in Blender need to have unique names.

We already have a mechanism allowing objects of different types to be exported using type-specific prefixes that are sliced upon export. We could automatically assign those when importing, either always or only when necessary. Not sure which of the two makes more sense.

By default, joint constraints and motor constraints should be the same, i.e. when a motor gets attached to a joint with defined constraints, the invoke function of the operator should set the parameters accordingly.

The check robot model function should test for inconsistencies between joint and motor constraints.

When using the bobj-export option, all modifiers are applied before exporting. However, then the UV-coordinates get messed up. Even if the modifier is manually applied before. The texture is repeated over e.g. new faces added by a subdivision modifier.

When exporting with the obj-option however, the UVs stay correct, even if e.g. new faces where generated with a subdivision modifier. However, the modifiers are not automatically applied, so that the results of the modifiers are only present in the obj if they have been manually applied before.

The best of both worlds would be that both formats keep the UVs intact and apply all modifiers before export.

It seems that (at least in some cases) motors get exported to _motors.yml for joints irrespective of there being an actual motor definition for the joint.

Adding sensors is not yet as nice as we would like it. For instance, Joint6DOF sensors need to be added to fixed joints connected to the joints where forces and torques should be measured and sensors attached to that fixed link, cameras are simply anchored to a link while NodeVelocity/NodePosition Sensors can have long lists of nodes they are measuring and don't need to be attached to any link in particular. We need think of a way to make that distinction clearer in the GUI and also document everything properly (though this also relates to MARS documentation itself).

URDF does not really support capsules. To still be able to create them and use them in MARS, we can emulate a capsule using a cylinder and two spheres in URDF and annotate that it really should be a capsule in SMURF.
Currently, capsules are treated as meshes in Phobos.

This should be implemented properly at the same time as it is implemented in the MARS import.