Ros3djs does not load 3D models (both .dae or .stl), does not display any errors.

[bvobart]

Hi. I'm currently doing a university project where I want to visualise the robot system we've designed in its accompanying monitor and control web application, built with ReactJS.

The first problem I ran into, was that importing ros3djs through NPM did not work, but that's another issue (#197). I went around this by simply sourcing the scripts in my index.html file as follows, of which I'm not entirely sure it's completely correct.

<script src="http://static.robotwebtools.org/threejs/current/three.js"></script>
<script src="http://static.robotwebtools.org/threejs/current/ColladaLoader.js"></script>
<script src="http://static.robotwebtools.org/threejs/current/STLLoader.js"></script>
<script src="https://static.robotwebtools.org/ros3djs/0.18.0/ColladaLoader.js"></script>
<script src="http://static.robotwebtools.org/EventEmitter2/current/eventemitter2.min.js"></script>
<script src="http://static.robotwebtools.org/roslibjs/current/roslib.js"></script>
<script src="https://static.robotwebtools.org/ros3djs/current/ros3d.min.js"></script

Now when the page that should show the 3D visualisation loads, it executes the following code. Note that ROSLIB here comes from an ES6 import of roslib's NPM module.

componentWillReceiveProps(props) {
    if (props.ros && this.props.ros !== props.ros) {
        const ROS3D = window.ROS3D;
        const getParam = new ROSLIB.Param({ ros: props.ros, name: 'robot_description' });
        getParam.get(string => console.log(string));

        const viewer = new ROS3D.Viewer({
            divID: '3d-view',
            width: this.viewDiv.offsetWidth,
            height: this.viewDiv.offsetHeight,
        });
        viewer.addObject(new ROS3D.Grid());

        const tfClient = new ROSLIB.TFClient({
            ros: props.ros,
            angularThres: 0.01,
            transThres: 0.01,
            rate: 10
        });

        const urdfClient = new ROS3D.UrdfClient({
            ros: props.ros,
            tfClient: tfClient,
            path: 'http://localhost/',
            rootObject: viewer.scene,
            loader: window.THREE.ColladaLoader
        });

        this.setState({ viewer });
    }
}

The viewer correctly attaches itself to the div it's supposed to attach to and an empty grid is shown. However, my robot's 3D model does not show and there are no errors or warnings to indicate why... RViz correctly able to show the entire system though. As you can see, as a test I tried to retrieve the robot_description parameter, which it is successfully able to print.

I've been looking for a solution and here's what I've tried so far:

• Checking whether the filenames in the URDF start with package:// instead of file://:
  All filenames are in the form of package://pacbot_description/meshes/base_link.dae
• Since I was previously using .stl files for my robot model, I tried converting them to .dae files using Meshlab. While doing so, I tried different kinds of loaders for the loader option in UrdfClient, none seemed to work, not for .stl nor for .dae files.
• The path http://localhost/ is proxied to http://localhost:5000/ by my ReactJS development server. Before I had set up this proxy, I would get CORS header warnings, which indicates that ros3djs does indeed try to fetch the robot's 3D models. After I set up the proxy, these warnings disappeared. The robot's 3D models are statically served by serve. I've checked that http://localhost:5000/pacbot_description/meshes/base_link.dae is a valid location.
• I went through your source code and found that the loading of the models is done by the MeshResource class, so I decided to try the following code snippet, with warnings set to true:

console.log("Loading mesh resource");
const mesh = new ROS3D.MeshResource({
    resource: 'pacbot_description/meshes/base_link.dae',
    path: 'http://localhost/',
    warnings: true
});
console.log("Loaded mesh: ", mesh);

However, no warnings are printed in between the two console.log statements, nor after.

• There are probably more things I tried that I may have forgotten, but nothing ever gave any errors or warnings whatsoever, neither in the browser console, nor the rosbridge console. However, I can also not seem to find any evidence of the 3D files ever actually being loaded.

What is going on here? Is there something I'm missing? How can I further debug my problem?

[T045T]

Thanks for providing such a detailed description! That helps rule out quite a few possible causes already.

I don't think it's relevant to your problem, but you only need to import one ColladaLoader (https://static.robotwebtools.org/ros3djs/0.18.0/ColladaLoader.js - that one's patched to maintain compatibility with RViz).

One thing that's missing is the ROS side, though. What nodes are you running, and are they configured correctly? Specifically, are you running tf2_web_republisher?

Also, can you check your server logs to see if http://localhost:5000/pacbot_description/meshes/base_link.dae was ever accessed?

[bvobart]

Thanks for your quick reply @T045T ! I've removed the other ColladaLoader so the one you mentioned is now the only ColladaLoader being loaded.

On the ROS side, I'm running:

• A MoveIt configuration of my robot, set up along their tutorials (roslaunch pacbot_moveit_config pacbot_moveit_planning_execution.launch)
• Rosbridge websocket (roslaunch rosbridge_server rosbridge_websocket.launch)
• tf2_web_republisher (rosrun tf2_web_republisher tf2_web_republisher, although this one was launched automatically by the rosbridge server on receiving a TFClient connection before I explicitly launched it in a separate terminal).
• The static file server (serve .). While this server does not really log any requests, I went into its source code and added a console.log statement when it receives a request. Now, when I go to localhost:5000 in my browser, the following lines are printed:

Request:  GET /
Request:  GET /hmwvpgvsfi/styles.css

Similar lines are printed when a specific file is accessed. However, no such lines are printed while both snippets of code I posted earlier are executed, which means that the models are never even accessed...

I did another test to confirm that the proxy is working fine: in that same componentWillReceiveProps method, I added this code snippet to see what it would do:

fetch('/pacbot_description/package.xml').then(response => {
    console.log(response);
});

The fetch request is able to complete without any problem at all, and serve prints a line showing that the file was retrieved.

I just noticed this as well, it says "Blocked" for each of the .dae files. Why could that be?

[jihoonl]

Which type of image format does your collada include? If your image format is something like tif, can you convert it to png and try again?

[bvobart]

@jihoonl The Collada files were converted from STL files in Meshlab, and the models didn't even have textures to begin with. But I don't see how that has anything to do with why the XHR requests for each of the meshes are being blocked.

[T045T]

From what I understand, "blocked" here means the time the browser princess was blocked trying to make the request, not the request itself being blocked.

That said, I'm sorry, but I'm out of ideas what might be broken here :(

[bvobart]

Right @T045T and @jihoonl, I did some further testing and I think I have been able to find the cause of the problem. I'll describe here what I did to test it and what I can conclude from that.

The fetch request I used in my previous comment was done from one of my own source files, so the transpilation process makes sure that the request respects and follows the proxy. Since Ros3djs and its dependencies are loaded through <script> tags, I thought either their permissions, or their behaviour in regards to those requests would be different, so I decided to test this hypothesis.

I created a file test.js, placed it in a location that was also served by the aforementioned serve, and added it into the index.html file as another <script> tag:

<script src="http://localhost/monitor-control/test.js"></script>

Firefox's network monitor showed the same status for this script request as it did for the XHR requests for the models and the console complained that the script failed to load. I then thought I'd add the port number:

<script src="http://localhost:5000/monitor-control/test.js"></script>

Now the script was able to load. It started to seem as though anything in these <script> tags would not be able to respect the proxy used. Maybe it was because it was handling http://localhost/... as an absolute link (inferring port 80, maybe), so I tried using a relative link:

<script src="/monitor-control/test.js"></script>

Once again, the script was able to load. Relative links apparently do respect my proxy.

In the test.js script, I placed the following code:

var xhr = new XMLHttpRequest();
xhr.open('GET', '/pacbot_description/CMakeLists.txt', true);
xhr.addEventListener('load', event => {
    console.log(event.target.response);
});
xhr.addEventListener('error', event => {
    console.log("Error: ", event);
});
xhr.send();

Playing around with the URL just as above taught me that the relative link worked without a hitch, as well as the http://localhost:5000/... link with serve set up to include CORS headers. However, with the original http://localhost/... link, the 'error' event would be triggered.

tl;dnr
Changing the path option for the initialisation of UrdfClient to '/' fixed the problem of the requests never reaching my static server. Such a simple fix for such a simple problem I've been struggling with for the past 5 days, simply because there is no error or warning at all when any of the requests to the model's files fail...

[bvobart]

Solving this problem, however, threw me into another problem. While my robot's .dae models are in fact getting accessed and read by the ColladaLoader, nothing shows up in the actual viewer. The ColladaLoader does print a number of lines with timing information while loading the models though:

THREE.ColladaLoader: DOMParser: 2.68ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 20.06ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 6.18ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 30.72ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 2.18ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 17.16ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 5.1ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 25.36ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 2.94ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 16.06ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 1.6ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 21.4ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 1.94ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 9ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 1.78ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 13.44ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 10.18ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 70.86ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 8.14ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 90.2ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 5.08ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 29.34ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 2.84ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 38.26ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 0.76ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 1.58ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 0.62ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 3.6ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 0.92ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 2.2ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 0.86ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 4.82ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 20.82ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 105.92ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 6.88ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 134.74ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 33.82ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 317.16ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 21.62ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 374ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 33.16ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 211.26ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 13.86ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 259.7ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 90.72ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 421.02ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 39.24ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 551.74ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 96.16ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 397.98ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 39.3ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 534.2ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 65.16ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 272.6ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 23.7ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 362.28ms ColladaLoader.js:3464:3
THREE.ColladaLoader: DOMParser: 93.62ms ColladaLoader.js:3376:3
THREE.ColladaLoader: File version 1.4.1 ColladaLoader.js:3383:3
THREE.ColladaLoader: Parse: 509.06ms ColladaLoader.js:3429:3
THREE.ColladaLoader: Build: 55.34ms ColladaLoader.js:3444:3
THREE.ColladaLoader: 658.8ms ColladaLoader.js:3464:3

What could be going wrong this time?

[T045T]

Thanks for keeping us posted on your progress - I added in some error reporting in MeshResource that will hopefully make it faster to debug to at least the point you've got to for others with similar problems in the future.

Unfortunately, it's hard to remotely diagnose what's still going wrong - the only advice I can think of is using the non-minified versions of all libraries (just remove .min from the paths) and using your browser's JavaScript debugger to set break points and inspect what's going on.

[Igarashi-G]

Hello,
I have a problem that no model is displayed.
I run robot blockly with webserver at http://127.0.0.1:1036 . And I want my ros3djs access the dae and stl models from that path. I put pr2_description pacakge in the frontend folder which contains the html pages. I can see the blockly page, but I cannot see the pr2 robot model.
The error is as follows:

Can someone help me please?

[bvobart]

@IgarashiToure That's quite a lot of errors... While practically the same, your browser may think that localhost:1036 is a different host than 127.0.0.1:1036, so you may want to try replacing every instance of 127.0.0.1 with localhost. Otherwise try setting up CORS headers on the webserver that hosts the pr2_description files. These CORS headers include the Access-Control-Allow-Origin header that the error speak about. Most webservers have an option to include these headers.

In the mean time, I have not yet had any time to do more debugging, but I'm happy with the changes made to MeshResource 👍

[louisgv]

I was able to setup a React project and load a .dae mesh. Example project is provided here:
https://github.com/louisgv/sandbox/tree/master/packages/ros3djs-model-import

@bvobart feel free to study the example provided in sandbox and if you still have problem, feel free to reach out.

[msjulio00]

@bvobart Did you solved the problem?

[bvobart]

@msjulio00 No, I'm sorry. I ran into this problem during a project that ended in the beginning of February. Since then I have not looked at the source code anymore, and I did fresh install of Ubuntu, meaning I no longer have ROS installed. My code should still be in a repository somewhere, but I do not think I'll be able to take the time to revisit the code and confirm whether I still have the same problem.

If you have a similar problem, maybe you can try to get @louisgv's example project working.

P.S. Should I close this issue?

[beatrizleon]

I am trying to use this but I run into the same problem in this issue and getting to this point as reported by @bvobart: "Solving this problem, however, threw me into another problem. While my robot's .dae models are in fact getting accessed and read by the ColladaLoader, nothing shows up in the actual viewer. The ColladaLoader does print a number of lines with timing information while loading the models though"

I have also tried the example of @louisgv but same result: empty viewer. @louisgv could you give me info of what system are you using to visualize this? indigo/kinetic? Also, are there any steps I need to take before visualizing the html?

[Solrac3589]

Hello everybody. I had this problem (at least one similar) a few moths ago and recently it came back to me. Fortunatelly in my case was solved. if I am not wrong is the same problem, but just in case I will describe.

I am with ubuntu 16.04, ROS Kinetic, and I am working with ur_10 robot and two ensensos. The main problem was that every time i wanted to visualize the robot in my webpage, the collada models were not loaded. and only appeared in the visualizer the basic shapes sended.

Checking in the debugger of the browser, I found a similar error like the one seen in
#209 (comment)

my way to solve the problem was simple replacing http://localhost in my browser direction by http://192.168.1.240

I am not quite sure is the same error, but hope it helps somebody!

The curious fact is that it worked on this project with several computers and this issue only appeared in one of them.

[louisgv]

Hi all, If you tried my example project, please zoom in. Thr model is very small, thus it seems that there was no model, but in fact it is there. I will try to update my example with a better model soon.

…

On Wed, Aug 1, 2018, 01:12 Solrac3589 ***@***.***> wrote: Hello everybody. I had this problem a few moths ago and recently it came back to me. Fortunatelly in my case was solved. if I am not wrong is the same problem, but just in case I will describe. I am with ubuntu 16.04, ROS Kinetic, and I am working with ur_10 robot and two ensensos. The main problem was that every time i wanted to visualize the robot in my webpage, the collada models were not loaded. and only appeared in the visualizer the basica shapes sended. Checking in the debugger of the browser, I found a similar error like the one seen in #209 (comment) <#209 (comment)> [image: screenshot from 2018-08-01 10-07-45] <https://user-images.githubusercontent.com/20369132/43509426-f219cb72-9572-11e8-8a15-27f8611391af.png> my way to solve the problem was simple replacing http://localhost in my brewser direction by http://192.168.1.240 I am not quite sure is the same error, but hope it helps somebody! The curious fact is that I worked on this project with several computers and this issue only appeared in one of them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#209 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGaX9iu1ZZqdbc3iQ0kFGrg-6cBOezG8ks5uMWLxgaJpZM4RfIs5> .

[louisgv]

@beatrizleon Hi, this is my specs:

# uname -a                            

Linux VAIO 4.15.0-29-generic #31~16.04.1-Ubuntu SMP Wed Jul 18 08:54:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

And I'm running ros lunar on my machine.

Can you please show me how you run my example project? A screenshot as well as the command you used would be very helpful. I'm so sorry about the lack of dedicated readme. I will be working on replacing the model with a better one next week and I will make sure it is visible on first load.

Thanks in advance!

[louisgv]

@Solrac3589 The problem you are seeing is because the browser refuse to load your model from a foreign service. To fix that, you can either ask the server to accept CORS, or simply download the model and use it locally. This is a browser security feature.

[louisgv]

@Solrac3589 I have replaced the model in sandbox with a better one that's 2 meter in height, which should show up immediately without the need to zoom-in like so:

I have also updated the readme with hopefully better instruction on how to run the app. (Please check the Link to Project section.

Please let me know if you need further assistance :)

[InsidiousClu]

Hey everyone, got the same issue. I am using ur10 model of robot and trying to debug things, but actually it seems like model has been loaded, but 3D scene is empty. Log from the devtools is the same as in example above.
Is there any solution already or it's a dead end?

[Solrac3589]

Hello @InsidiousClu! I am also working on ur10 and for me works properly (so, we should find a solution for you!). Can you tell me your configurations?

[InsidiousClu]

@Solrac3589 , thanks for your quick response. Unfortunately ROS instance is running on a separate private server where I can only connect via websockets. For the robot parts I am using combined repositories for that particular robot.
Codebase is looking like this:

And the directory structure with the robot model which I combined by myself, probably there is an issue:

[Solrac3589]

@InsidiousClu I have checked your code and seems okay for me (actually there is not much secret).

About the directory, in my case, i put after the adress the root directory of the colladas (something like "http://127.0.0.1/colladas" and inside colladas, everything) i cannot give you right now the structure because i just finished my job until monday, but if your want we can talk about, then. Anyway, i do no think that's the issue, if the directories not okay, if I am not wrong, it should give an error (missing collada or something) can you check that?

What actually i think is happenning is that you have a collada version or a ros3djs version which gives your this problem. If you did not find the issue on monday, if you want we can try with my files.

btw did you tried with different browsers?

[InsidiousClu]

@Solrac3589 the problem is that I am using electron, and it's using chromium under the hood over there, so it's not possible to use different browser, but I have also checked that in Safari (created a separate web build for that), FF is not working, cuz there is being used hash-router for SPA application. All files are being successfully loaded, what was displayed on a screenshot of a comment above. Right now I am out of clues, because viewer has Urdf scene defined in it's children array. But actual 3D view is empty 😞

Btw, I am feeling so dumb at the moment, I will keep you up to date if I will make it work. Thanks!

[Solrac3589]

Good morning.

I have been thinking on your issue a little, I think maybe somewhat there is an issue between your connection and the server. Are you completely sure that roslib node and tf2_web_republisher are loaded right?

Try using my files just in case ( i don't think is that, but just to discard).

If it is not any of those elements I am quite sure that it is problem with the connection as is said (the colladas seems to be readen correctly so It seems to me to not be the issue there). Can you check in the network tab in devtools if there is any possible clue?

BTW don't feel so dumb! i lost many time on that also (and seems we are not alone).

I think maybe will be better if to do several checks you talk me directly to mail (carlosrodoreda@gmail.com) and later we give here the solution we achieve or a new state of the art to allow others to help

[InsidiousClu]

@Solrac3589 Hey,

I have tried to install fresh ubuntu, installed ROS with all dependencies by myself and ran every command what is listed in README of this repo: https://github.com/InsidiousClu/ros-example
And then everything worked as a charm, probably there is an issue with the remote server conifg, and custom options provided to the ROS environment. Thanks for your help!
In that case I should punish devs who is responsible for configuring ROS env on remote server 😆

[Solrac3589]

@InsidiousClu glad to hear that! Anything more, here we are!

Just last tought. Maybe you should configure correctly the hosts in your computer in order to recognise the ros from another computer at /etc/hosts !

[ashBabu]

In the tf2_web_republisher terminal window above, there's this error "base_link" passed to lookupTransform argument target_frame does not exist. I think this is the reason why the robot is broken down. Did anyone manage to find a solution for this? Thanks

[MatthijsBurgh]

@ashBabu This issue is closed. And as you mention you have an error in tf2_web_republisher. Please solve any general TF issues, before maybe opening an issue in the tf2_web_republisher repo.