ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

I believe I have solved this issue. I believe your core problem is this line in your CMakeLists.txt:

pluginlib_export_plugin_description_file(my_panel_plugin plugin_description.xml)

It should be

pluginlib_export_plugin_description_file(rviz_common plugin_description.xml)

Otherwise it will not be detected by pluginlib loader. When loading rviz plugins, it looks for files named "rviz_common__pluginlib__plugin" and does some discovery mechanics from there - the first part of that string is the first argument in pluginlib_export_plugin_description_file

The second potential issue may be that you are not resourcing your workspace with your custom plugin after building. If you don't resource, the ament path will not include the built plugins, which prevents the above discovery mechanism from working.

Somewhat unrelated sidenote: as I was trying to reliably replicate issues/solutions, I was producing various subsets of my workspace in new workspaces. It took me a while to figure out it was still including non-sourced workspaces in my Ament path because of the way colcon chains workspaces together in each workspace's install/setup.bash file. Make sure to check $COLCON_PREFIX_PATH only lists your expected user workspaces (it should not include /opt) - if something is wrong, look at the $COLCON_CURRENT_PREFIX definitions in each sourced workspace's setup.bash. This drives the Ament path.

I believe I have solved this issue. I believe your core problem is this line in your CMakeLists.txt:

pluginlib_export_plugin_description_file(my_panel_plugin plugin_description.xml)

It should be

pluginlib_export_plugin_description_file(rviz_common plugin_description.xml)

Otherwise it will not be detected by pluginlib loader. This talks about that briefly. When loading rviz plugins, it looks for files named "rviz_common__pluginlib__plugin" and does some discovery mechanics from there - the first part of that string is the first argument in pluginlib_export_plugin_description_filepluginlib_export_plugin_description_file.

The second potential issue may be that you are not resourcing your workspace with your custom plugin after building. If you don't resource, the ament path will not include the built plugins, which prevents the above discovery mechanism from working.

Somewhat unrelated sidenote: as I was trying to reliably replicate issues/solutions, I was producing various subsets of my workspace in new workspaces. It took me a while to figure out it was still including non-sourced workspaces in my Ament path because of the way colcon chains workspaces together in each workspace's install/setup.bash file. Make sure to check $COLCON_PREFIX_PATH only lists your expected user workspaces (it should not include /opt) - if something is wrong, look at the $COLCON_CURRENT_PREFIX definitions in each sourced workspace's setup.bash. This drives the Ament path.

I believe I have solved this issue. I believe your core problem is this line in your CMakeLists.txt:

pluginlib_export_plugin_description_file(my_panel_plugin plugin_description.xml)

It should be

pluginlib_export_plugin_description_file(rviz_common plugin_description.xml)

Otherwise it will not be detected by pluginlib loader. This talks about that briefly. briefly - I made a PR to fix the error in the rviz2 documentation you linked. When loading rviz plugins, it looks for files named "rviz_common__pluginlib__plugin" and does some discovery mechanics from there - the first part of that string is the first argument in pluginlib_export_plugin_description_file.

The second potential issue may be that you are not resourcing your workspace with your custom plugin after building. If you don't resource, the ament path will not include the built plugins, which prevents the above discovery mechanism from working.

Somewhat unrelated sidenote: as I was trying to reliably replicate issues/solutions, I was producing various subsets of my workspace in new workspaces. It took me a while to figure out it was still including non-sourced workspaces in my Ament path because of the way colcon chains workspaces together in each workspace's install/setup.bash file. Make sure to check $COLCON_PREFIX_PATH only lists your expected user workspaces (it should not include /opt) - if something is wrong, look at the $COLCON_CURRENT_PREFIX definitions in each sourced workspace's setup.bash. This drives the Ament path.