[SOLVED] Ros service-call SetVisualProperties overrides old changes


When calling the ROS service SetVisualProperties multiple times for different links in the same model in quick succession only the change from the last call are applied permanently. Changes from earlier calls are reverted by the next call.

Use case:
I have a robot arm an would like to change the color of every link. Currently this is only possible by calling SetVisualProperties once for each link separately. However as described above, only one link visual is changed at the end.

Bug Origin:
The SetVisualProperties function in gazeborospackages/src/gazebo_ros_pkgs/gazebo_ros/src/gazebo_ros_api_plugin.cpp line 2892 currently works as follows:

  1. The model is loaded into a modelMsg:
gazebo::msgs::Model modelMsg;
  1. The requested link and visual are searched for in the message and changed as requested:
auto visuals = modelMsg.mutable_link(link_idx)->mutable_visual();
for (unsigned int i = 0; i < visuals->size(); i++) {
  if (visuals->Get(i).id() == visual_id) {
    *(visuals->Mutable(i)) = visualMsg;
  1. The modelMsg is published on ~/model/modify (and ~/recording/model/modify)

  2. The service success is set to true.

However, the service does not wait for the model modification to have taken place. As such, if the function is called again, the old model is loaded into the modelMsg again, such that the next publication of ~/model/modify does not include the changes of the first call of the function, thus overriding them with the old value again.

Possible Fixes:

  1. Wait for change to happen before exiting from service call.
  2. Change function to allow for multiple visual changes before publishing the modified model on ~/model/modify. This would also improve performance as the model is only changed once in this case.


Dear Jacob,

Your bug report has been added to the dev team’s backlog as
Thank you for reporting.

Best regards


The fix is done and is waiting for deployment. It’s available already in dev installations or as a patch in the following pull-request:


The fix has been deployed and is included in NRP 3.2.0.