ColladaLoader2.js: Cannot read property 'zeroPosition' of undefined

[ferrolho]

Description of the problem

I am trying to load a robot model into my scene, e.g. KUKA LBR iiwa: https://github.com/ros-industrial/kuka_experimental/tree/indigo-devel/kuka_lbr_iiwa_support

I am trying to avoid ros3djs and I am basing my attempt on this example: https://threejs.org/examples/#webgl_loader_collada_kinematics

So, the first thing I am doing is converting the .urdf into a .dae using the urdf_to_collada command-line tool: rosrun collada_urdf urdf_to_collada lbr_iiwa_14_r820.urdf lbr_iiwa_14_r820.dae

And this is the error I get once I run the example with the generated .dae model:

Uncaught TypeError: Cannot read property 'zeroPosition' of undefined
    at ColladaLoader2.js:2534
    at Group.traverse (three.js:10660)
    at Group.traverse (three.js:10666)
    at Group.traverse (three.js:10666)
    at Group.traverse (three.js:10666)
    at connect (ColladaLoader2.js:2526)
    at setupKinematics (ColladaLoader2.js:2511)
    at THREE.ColladaLoader.parse (ColladaLoader2.js:3396)
    at ColladaLoader2.js:27
    at XMLHttpRequest.<anonymous> (three.js:30090)

Here is the ColladaLoader2.js source, for your convenience: https://github.com/mrdoob/three.js/blob/master/examples/js/loaders/ColladaLoader2.js

Adding if (!joint) return immediately after line 2521 of ColladaLoader2.js skips the code causing the error (well, of course). Furthermore, the loader seemingly seems to work and this is the result:

I guess that the textures are missing for some other reason. Besides that, the only weird thing is the repeated print of the message:

THREE.ColladaLoader: X does not exist.

Am I missing something? Is this from the loader? Or maybe even because of the urdf_to_collada converter?

UPDATE

Never mind the repeated printing of the THREE.ColladaLoader: <joint> does not exist. message... The Three.js example uses Tween to move around the joints and that's what's causing the prints. This confirms that the loader did not completely succeed, otherwise the robot would be moving.

Three.js version

• [ ] Dev
• [x] r87
• [ ] ...

Browser

• [ ] All of them
• [x] Chrome
• [ ] Firefox
• [ ] Internet Explorer

OS

• [ ] All of them
• [ ] Windows
• [ ] macOS
• [x] Linux
• [ ] Android
• [ ] iOS

[Mugen87]

Can you upload the dae file, please?

[ferrolho]

Of course, here you go: lbr_iiwa_14_r820.dae.zip

[Mugen87]

The first thing i can see in your file is that the naming conventions of the axis do not match to the current parsing logic. Our example (kawada-hironx.dae) uses values like this in order to define the axis for the tag bind_joint_axis:

kscene_kmodel1_inst_body1_kinematics_kmodel1_inst_joint8.axis0

Your model uses a different style:

kscene_kmodel0_inst_robot0_kinematics_kmodel0_inst_joint_a3_axis0`

Because the loader expects a dot before the axis name (like .axis0), it is unable to parse your dae file. Unfortunately, I did not find any naming conventions in the collada spec for this issue. It won't be easy to adjust the current logic so the loader supports arbitrary models that make use of kinematics.

[ferrolho]

Found the bug at line 2455 of ColladaLoader2.js: https://github.com/mrdoob/three.js/blob/master/examples/js/loaders/ColladaLoader2.js?utf8=%E2%9C%93#L2455

The kinematics scene parser makes use of parseInt(), thus assuming the joint indices are integers.

I will have a try on adding support for non-integer joint indices. Any suggestions on this?

[Mugen87]

I will have a try on adding support for non-integer joint indices.

Sounds good :+1: . Maybe this makes the loader more robust.

Any suggestions on this?

Not really :innocent:. The kinematics spec of Collada is quite comprehensive and i'm not familiar with any details.