Closed lkeselman closed 1 year ago
Internal tracking ticket: FG-4924
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:
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
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>
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.
@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
?
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:
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 asRViz
?
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) ?
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.
@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.
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
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 therobot_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.