Separate URDF XML Parsing

[gkjohnson]

Separate the URDF XML parsing to provide a clean, fully defaulted json representation of the URDF data so it can be used to implement loaders in other engines including Babylon.js. The structure from the 3DTilesRenderer could be reused -- ie a base and three folder to denote reusable and platform/engine-specific code.

Related to #168.

[jhurliman]

I'm interested in helping with this since I'd like to use the URDF loader with Worldview (https://webviz.io/worldview/) instead of three.js. I noticed that three.js math types such as Vector3 and Quaternion are used during loading, what would you recommend in place of those for removing the three.js dependency from the core loader?

[gkjohnson]

Hello @jhurliman! If the parser is going to be restructured to separate some of the parser logic I think I'd like to see a URDFLoaderBase class that just implements the XML parsing and returns a simpler JS object with defaults filled in and file paths resolved so rendering-engine-specific implementations can be simplified. The returned object could be structured like so:

{
  namedMaterials: [ /* material data ... */ ],
  links: [ /* link data ... */ ],
  joints: [ /* joint data ... */ ],
  // ... etc
}

And the current URDFLoader can be split into two files:

// src/base/URDFLoaderBase.js
class URDFLoaderBase {
  load( url ) {
    /* ... */
  }

  // returns parsed URDF XML as javascript object
  parse( xmlOrString ) {
    /* ... */
  }  
}

// src/three/URDFLoader.js
class URDFLoader extends URDFLoaderBase {
  parse( ...args ) {
    const urdfData = super.parse( ...args );
    /* ... generate three.js URDFRobot, etc */
  }
}

See the 3DTilesRendererJS B3DMLoaderBase and three.js-specific B3DMLoader for a rough model of how I'm imagining this being structured. To that end I don't think any math functions will be required in the base parser and will just be required for engine-specific implementations which is probably for the best so we can keep the dependency list low.

With that approach I don't believe the result of the current URDFLoader should have to change and it should make it easier to produce other engine-specific urdf model loader implementations.

Let me know how that sounds to you!