wolfv
commented
3 years ago thanks for the very nice bug report! unfortunately I don't know what's going on here yet.
Closed danzimmerman closed 3 years ago
wolfv
commented
3 years ago thanks for the very nice bug report! unfortunately I don't know what's going on here yet.
wolfv
commented
3 years ago just wondering if you also have RViz open (at the same time?) and if you see any issues in RViz, too?
traversaro
commented
3 years ago I vaguely remember some similar issue on vcpkg-based build on Gazebo (the one from https://github.com/robotology/robotology-superbuild-dependencies-vcpkg) when the same iCub model was removed and then re-inserted in the simulation, but in that case spawning a new Gazebo was solving the problem, so it was not particularly problematic.
I think the problem is related due to a behavior change from Ogre 1.9 to Ogre 1.10, that changed a lot of aspects related to the resource handling (see https://github.com/ros-visualization/rviz/issues/1251 and https://github.com/ros-visualization/rviz/issues/1049 for a related bugs on the RViz side or even https://github.com/osrf/gazebo/issues/2321 and https://osrf-migration.github.io/gazebo-gh-pages/#!/osrf/gazebo/pull-requests/2718/page/1?slug=remove-duplicate-material-block-in for related Gazebo issues). The strange thing is that ROROnWindows/Chocolatey Melodic is not affected by this bug, as Ogre 1.10 is used also there (see https://github.com/ms-iot/ros-windows-build/blob/17c45551a500230674bad77c951989e0747c2d6b/ros/melodic/CHANGELOG.md).
However, I investigated a bit and it seems that ROSOnWindows/Chocolatey Melodic is using a fork of Gazebo ( https://github.com/ms-iot/ros-windows-build/blob/17c45551a500230674bad77c951989e0747c2d6b/ros/melodic/CHANGELOG.md ) and checking in that branch it seems that the gazebo/rendering/Visual.cc fix in contained in this commit https://github.com/ms-iot/gazebo/commit/667a1d3bd23717abf4c6e62e3ef947a659e085b7 is definitely related to that bug and should fix it.
traversaro
commented
3 years ago The related change is documented in Ogre 1.10 Release Notes ( https://github.com/OGRECave/ogre/blob/master/Docs/1.10-Notes.md ) as:
using a duplicate resource name is an error now and throws an exception
danzimmerman
commented
3 years ago @wolfv I don't use RViz yet but it seems to have visual issues as well when I add RobotModel or when I roslaunch ur_description view_urXX.launch which just brings the robot up in RViz
It does not seem to throw any errors.
RViz messages:
However, the all-white-links issue is uncorrelated from whether or not the same robot appears correctly in Gazebo. The UR10, which works properly in Gazebo, is afflicted the same as the UR5 which doesn't work in Gazebo.
I dumped the UR10 URDF from the parameter server in this gist
Gazebo UR10 visualization:
RViz UR10 visualization by adding RobotModel:
I think this visualization issue is a separate known issue mentioned here, and I suppose that affects RViz on Focal equally. I'll check that on Monday and get back to you.
(Obviously the ur_ packages need to address the transform issues too before Noetic is fully supported there)
Tobias-Fischer
commented
3 years ago Hi @danzimmerman - please give the new version a go and let us know if that fixed your problem (will take a few hours to build + propagate in the CDN). If not, please re-open the issue :)
danzimmerman
commented
3 years ago Yes, works here. Thanks so much everyone!
danzimmerman
commented
3 years ago The RViz issue is not an issue at all, I'm just unfamiliar with RViz. It boots up in the map frame, which is invalid in the context of running aside Gazebo. This causes the arm to be collapsed and white. It seems like this is all working correctly with RViz/Gazebo now.
Tobias-Fischer
commented
3 years ago Great, thanks for letting us know @danzimmerman :)
I'm having an issue with missing Collada (
.dae) link visuals on conda-installed Gazebo 11.5.1 (also affects conda-installed Gazebo 11.3 before I updated everything this afternoon) on Windows 10.I've observed this so far on certain robots from the
melodic-devel-stagingbranch of https://github.com/ros-industrial/universal_robot/The universal_robot robots otherwise work without issues with Gazebo 11.3 from
ros-noetic-desktop-fullon my coworker's Focal machine and all of my Melodic installations (Bionic and Chocolatey Windows 10, bothros-melodic-desktop-fullbinary installs), so I thought I'd raise it here first.Issue Description If I try to visualize the UR5 robot described by:
ur_descriptionur_description/configur_gazeboI run
roslaunch ur_gazebo ur5_bringup.launchand I'm missing the forearm and upper-arm visuals. The URDF and STL collision geometries (visualized in orange) are fine, and the robot moves properly.Passing
verboseto Gazebo through the launch file gives errors like:I can get the link visuals to appear by opening the
.daefiles in Meshlab and re-exporting, but this appears to simply strip all the visual materials out of the file so that there's nothing to trigger the Ogre material error above.Anyone else having an issue with this? Any ideas?
Environment,
conda listoutput:Details about
condaand system (conda info):