foxglove / ros-foxglove-bridge

Foxglove WebSocket bridge for ROS 1 and ROS 2
MIT License
168 stars 75 forks source link

Meshes not being pulled #264

Closed lkeselman closed 1 year ago

lkeselman commented 1 year ago

Description Foxglove studio connected to foxglove bridge. Turning on the robot_description on the 3D panel, and no visual meshes are displayed. There is an error message on the robot_description display that one of the meshes could not be loaded. I know the reason for this, it doesn't exist. Is it expected that if one mesh is missing none would show up? Is there any size limit on the meshes?

Steps To Reproduce

Expected Behavior All available meshes would be shown.

foxhubber[bot] commented 1 year ago

Internal tracking ticket: FG-4924

achim-k commented 1 year ago

There is an error message on the robot_description display that one of the meshes could not be loaded. I know the reason for this, it doesn't exist. Is it expected that if one mesh is missing none would show up?

I just tried this, and the robot visualization still works even if one mesh could not be found: image

Does your robot consist of only one mesh?

Is there any size limit on the meshes?

No, there is not. But only certain mesh file paths are allowed, you can customize this via the asset_uri_allowlist parameter. The default is: https://github.com/foxglove/ros-foxglove-bridge/blob/58b6712ab37486e435650927805d00bc7a78bbbf/ros1_foxglove_bridge/launch/foxglove_bridge.launch#L16

lkeselman commented 1 year ago

Thanks for the tips, but I still can't explain why my meshes aren't showing up. There are many meshes and they are in this form: package://fanuc_r2000ic125l_support/meshes/visual/balancer.stl so I think they should work. I wonder if it could be related to the scale or material?

Here's an example link definition.

<link name="robot_1_base_link">
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://fanuc_r2000ic125l_support/meshes/visual/base_link.stl" scale="0.0254 0.0254 0.0254"/>
      </geometry>
      <material name="">
        <color rgba="0.15 0.15 0.15 1.0"/>
      </material>
    </visual>
  </link>
achim-k commented 1 year ago

There are many meshes and they are in this form: package://fanuc_r2000ic125l_support/meshes/visual/balancer.stl so I think they should work.

Yes, that should work. Are the urdf / mesh files available somewhere? Would like to try this out on my machine.

I wonder if it could be related to the scale or material?

Unlikely, but maybe try it out by removing the scale and custom material.

lkeselman commented 1 year ago

@achim-k I don't think I can share the meshes and urdfs unfortunately due to IP issues.

I did get meshes to show up when running the bridge locally instead of in a docker, although it took them a long time to show up. However, the meshes were not in the correct spots and orientations. Everything looks great in RViz, I assume Foxglove should conform to the same interpretation of urdf and meshes as RViz?

lkeselman commented 1 year ago

Separate question - are meshes from file:\\ paths supported by the bridge? Couldn't quite get that to work despite updating the regex in the launch argument you mentioned. I see this in the browser console:

image

achim-k commented 1 year ago

I did get meshes to show up when running the bridge locally instead of in a docker, although it took them a long time to show up. However, the meshes were not in the correct spots and orientations. Everything looks great in RViz, I assume Foxglove should conform to the same interpretation of urdf and meshes as RViz?

Foxglove Studio uses the Blender mesh-up-axis convention by default, you can change that to Z-up in the 3D panel scene settings

Separate question - are meshes from file:\\ paths supported by the bridge? Couldn't quite get that to work despite updating the regex in the launch argument you mentioned. I see this in the browser console:

The bridge supports it (if you adapt the regex as you mentioned) but Foxglove Studio currently only requests package:// URL meshes from foxglove bridge. Could you change the mesh file:// URLs to package:// URLs? It also seems that your file paths are wrong, or are your meshes located under /meshes (in the root directory) ?

lkeselman commented 1 year ago

Foxglove Studio uses the Blender mesh-up-axis convention by default, you can change that to Z-up in the 3D panel scene settings

Thanks that fixed it!

The bridge supports it (if you adapt the regex as you mentioned) but Foxglove Studio currently only requests package:// URL meshes from foxglove bridge. Could you change the mesh file:// URLs to package:// URLs? It also seems that your file paths are wrong, or are your meshes located under /meshes (in the root directory) ?

It's the right place. Without getting too much into the details of our setup, file paths are much more convenient but we can consider this as a feature request rather than an issue. I'll try to work it into a package path.

lkeselman commented 1 year ago

@achim-k I'm able to see the meshes if I run foxglove-bridge locally on my machine but not when I run it within a docker using --network=host. I know this likely isn't your problem but I wonder if you have any experience with some reason sending meshes over websocket might not work from within a docker? Is there some relevant docker setting?

The workspaces are the same inside and outside the docker. Some deps might be different though.

achim-k commented 1 year ago

Do you see any related error logs on the foxglove bridge side? Regarding the docker setup, it could be that your paths are wrong in case you mount the mesh files into the docker container? Otherwise there should not be a problem if you use --net=host and you are able to visualize ros topics in studio