URDF to VRML conversion is broken

[haudren]

Hello,

I recently tried to export a URDF simple model to a VRML one. As there is no specific release, I installed from master.

However, when using:

simtrans -f urdf -i test.urdf -t vrml -o test.wrl

I get this error:

ERROR cannot read links at all (probably the model refers to another model by tag)

There is NO include tag in this model. It is in fact very simple.

I saw that the URDF model was in fact using SRDF (And that required a dependency on Gazebo...). If I use read2() from URDFReader, I get a wrl file, where all transforms are set to identity i.e. all links are in the same place.

It seems that the joints transforms are lost during the calls to:

self.convertChild(bm, c)

Both input and output files are here:
https://gist.github.com/haudren/826e297c3cfd9dbdb389

Thanks,
Hervé Audren (JRL)

[yosuke]

Hi,

URDFReader previously used read2() function but now use read(). This is because we have recently switched internal data structure to absolute position based from relative position based to gain high compatibility with SDF format.

Current function calls "gz sdf" utility command to convert urdf file to sdf and go directly to SDFReader to parse the model.

When I used gz sdf command on your data, I got following output.

$ gz sdf -p test.urdf
<sdf version='1.5'>
  <model name='test'/>
</sdf>

The urdf model is converted to empty sdf model. This is probably because there is no inertial, visual collision elements defined in your link item.

[haudren]

Hello,

I found this on the gazebo page:

An element within each element must be properly specified and configured.
This is why the sdf conversion fails spectacularly.

In my opinion, this behaviour is not really flexible, because we have a lot of environments that are described as fixed robots with no dynamic properties (obviously). I guess if SDF compliance is your primary goal it cannot be helped unless the Gazebo people change their mind...

On the other hand, as read2() itself is broken, consider adding an exception/deprecation warning or removing it entirely if you have no plans to support it in the future.

Finally, I guess having an accessible test suite would be useful in this project.

Could you at least update the error message ?

Then, the conversion still fails... This is because I used "file://" tags for the visual uri. Those are apparently not supported by resolveFile.

Please consider fixing this function:

• Add file support
• Make the logger.debug('resolveFile unresolved[...]') a warning instead.

For file support:

if f.count('file://') > 0:
  ff = os.path.expanduser(f.replace('file://', ''))
  return ff

Should do the trick. We could also try to implement more complex strategies but I think the point of file tags is usually for one-time experiments.

[yosuke]

Thanks for the feedback (and sorry for the very late response).

Now, some improvements are done.

And, yes. We do have a testsuite.

https://github.com/fkanehiro/simtrans/blob/master/convertall.sh

https://travis-ci.org/fkanehiro/simtrans

But the problem is, it only test whether the conversion succeeds, but we have to check the model by our eyes. So this is not perfect obviously, but may be still useful.