Question: why not introduce a <webots> tag?

[reinzor]

When diving a little bit more into webots and this urdf2webots parser I started wondering the following:

Why not introduce a <webots> xml tag instead of parsing the <gazebo> tags? Webots is a different simulator and also your sensor and actuator components are differently reflected in your resulting file (.proto file). Wouldn't it be easier (and more complete) to introduce a custom <webots> tag that describes the webots specific information regarding actuators and sensors?

Looking forward to your thoughts.

[omichel]

Yes, this is a very good idea. We should probably start drafting it here to define its content and see how this would help overcome a number of problems.

[reinzor]

My first thought would simple be to translate all proto props to xml; so:

Lidar {
  #fields that inherit from the Solid node:
  vrmlField SFVec3f    translation         0 0 0
  vrmlField SFRotation rotation            0 1 0 0
  vrmlField SFVec3f    scale               1 1 1
  vrmlField MFNode     children            []          # shape and solids fixed to that solid
  field     SFString   name                "lidar"     # used by wb_robot_get_device()
  field     SFString   model               ""          # generic name of the solid (eg: "chair")
  field     SFString   description         ""          # a short (1 line) of description of the solid
  field     SFString   contactMaterial     "default"   # see ContactProperties node
  field     MFNode     immersionProperties []          # see ImmersionProperties node
  field     SFNode     boundingObject      NULL        # for collision detection
  field     SFNode     physics             NULL        # physical properties (Physics node)
  field     SFBool     locked              FALSE       # to avoid moving objects with the mouse
  field     SFFloat    translationStep     0.01        # step size used by translation manipulator
  field     SFFloat    rotationStep        0.261799387 # step size used by rotation manipulator
  field     SFFloat    radarCrossSection   0.0         # radar cross section of this solid
  field     MFColor    recognitionColors   []          # colors returned for this Solid by Cameras with a Recognition node

  #fields specific to the Lidar node:
  field     SFFloat                         tiltAngle                0.0     # tilt angle of the lasers with respect to the sensor
  field     SFInt32                         horizontalResolution     512     # number of point per revolution per laser
  field     SFFloat                         fieldOfView              1.5708  # horizontal field of view of each laser
  field     SFFloat                         verticalFieldOfView      0.2     # vertical field of view covered by the lasers
  field     SFInt32                         numberOfLayers           4       # number of laser-layers
  field     SFFloat                         near                     0.01    # OpenGL near clipping plane (meters)
  field     SFFloat                         minRange                 0.01    # minimum range (meters)
  field     SFFloat                         maxRange                 1.0     # maximum range
  field     SFBool                          spherical                TRUE    # to switch between a plane/sphere projection
  field     SFString{"fixed", "rotating"}   type                     "fixed" # defines whether this is a rotating lidar or not
  field     SFFloat                         noise                    0.0     # add a noise to the distance values
  field     SFFloat                         resolution              -1.0     # distance resolution
  field     SFFloat                         defaultFrequency         10      # default rotating frequency of the lidar in Hz
  field     SFFloat                         minFrequency             1       # minimum rotating frequency of the lidar in Hz
  field     SFFloat                         maxFrequency             25      # maximum rotating frequency of the lidar in Hz
  field     SFNode                          rotatingHead             NULL    # Solid rotating head of the lidar

  # hidden fields
  hiddenField SFVec3f linearVelocity  0 0 0   # (m/s) Solid's initial linear velocity
  hiddenField SFVec3f angularVelocity 0 0 0   # (rad/s) Solid's initial angular velocity
}

Could be something like this

<webots>
  <lidar>
    <tiltAngle>0.0</tiltAngle>
    <horizontalResolution>512</horizontalResolution>
    <fieldOfView>1.5708</fieldOfView>
    <verticalFieldOfView>0.2</verticalFieldOfView>
    <numberOfLayers>4</numberOfLayers>
    <near>0.01</near>
    <minRange>0.01</minRange>
    <maxRange>1.0</maxRange>
    <spherical>true</spherical>
    <type>fixed</type>
    <noise>0.0</noise>
    <resolution>-1.0</resolution>
    <defaultFrequency>10</defaultFrequency>
    <minFrequency>1</minFrequency>
    <maxFrequency>25</maxFrequency>
  </lidar>
</webots>

Just a first example and maybe we need some reference to urdf links but this way the user can configure all webots parameters in urdf and if desired keep their original gazebo configuration alive so that the urdf can be used with both simulators.

[omichel]

Yes, that's a very good approach, simple and scalable. Feel free to go ahead and start the implementation. We will be happy to review it.

[reinzor]

Thanks! Will try to find time for this within our team in the next sprint. Will get back to you.

[Timple]

Ideally one can also reference back to an urdf link like this: https://github.com/cyberbotics/urdf2webots/issues/31#issuecomment-544848739

[jgueldenstein]

A different option would be to have a config file which specifies additional components to be added to the proto file. What do you think about this option?

We thought about implementing this for allowing to specify the appearance of the meshes of our robot better than in an URDF since it is limited to a flat color or a texture.

[reinzor]

@jgueldenstein this could still be done when using <webots> tags with a reference like @Timple mentioned right? By introducing additional tags; we could have something like this:

<webots reference="link_name">
  <sensor type="lidar">
    <param1>..</param1>
  </sensor>
</webots>

and for a material:

<webots reference="link_name">
  <material>
    <!-- optional resources to external resources here -->
  </material>
</webots>

[jgueldenstein]

I think those are two different ways to solve the same problem. The advantage of putting everything into the URDF is that it is all in one place. The advantage of putting it in a separate file is that we do not have to worry about breaking any other software by modifying the urdf. I think in terms of flexibility both would be similarly well working since xml should be powerful enough. Our problem with this would be that there are multiple visual models in the same link which have different materials.

[martimorta]

This is a great idea, I would use it with xacro, so you could have a single model with a parameter to determine which simulators to render in the urdf.

<robot name="robot" xmlns:xacro="http://www.ros.org/wiki/xacro">
  <xacro:arg name="webots" default="true" />
  <xacro:if value="$(arg webots)">  
    <xacro:include filename="robot_webots.xacro" />  
  </xacro:if>
</robot>

[astumpf]

I would love to see a XML tree implemented. This would give us the freedom to address Webots specific features without interfering with existing code. The new Webots tag should be ignored by other xml parsers by default, therefore I would not worry about too much having these in the urdf. In general, it is a good practice to split Webots specific definitions (as well as gazebo stuff) into a different file.

[HaoLiuHust]

have any plan to implement this?

[omichel]

Not on the short term, but feel free to propose a contribution in this way.