Additional Resources

Table of Contents

• FAQ
  • Can I create a single library for both TPP and GUI plugins?
  • Why does my plugin compile but it can't be found?
    • Noether plugins environment variables
    • Undefined symbols in the plugin library
• ROSCon 2024 Workshop

FAQ

Can I create a single library for both TPP and GUI plugins?

Generally, no. A given TPP component and its associated GUI widget typically share the same plugin alias, and a plugin alias can only exist once in a library. See Shared YAML Configuration File for more information. Therefore, one library should be created for TPP plugins and a second library should be created for the corresponding GUI plugins.

The exception to this answer is when the TPP and GUI plugins do not share the same alias name(s). In this case, they can both be declared in the same library.

Why does my plugin compile but it can't be found?

First read the Plugins and Widget Plugins sections to understand the structure and requirements for plugins. Then, check the following topics if your plugin still cannot be found:

Noether plugins environment variables

The plugin loader looks for the names of plugins in the environment variable NOETHER_PLUGIN_LIBS. Check that this environment variable contains the name of your plugin library, without OS decorators (e.g,. the prefix lib and suffix .so in Linux). For example, a library called libmy_noether_plugins.so should be added to NOETHER_PLUGIN_LIBS as my_noether_plugins.

Multiple plugin library names can be specified and must be separated by a colon (:). Plugins can also be specified by absolute paths.

The plugin loader looks for these named plugins in two locations:

• In "system" folders (e.g., /usr/lib, /usr/local/lib, folders specified in the LD_LIBRARY_PATH environment variable)
• In folders specified in the NOETHER_PLUGIN_PATHS environment variable.

Make sure the location of your plugin library can be found in either of these locations.

Undefined symbols in the plugin library

Undefined symbols in a library will prevent that library from being loaded by the plugin loader and typically cause the plugin loader to report that the library has a "bad file descriptor". This issue is tricky to catch when compiling a plugin library (opposed to an executable) because the symbols get resolved at run-time rather than compile-time.

One way to ensure your plugin library does not have undefined symbols is to compile an executable in which you instantiate your custom tool path planning components. Typically this executable will fail to compile while undefined symbols exist.

Here is an example of what an executable could look like to test the noether::NormalsFromMeshFacesMeshModifier component:

#include <noether_tpp/mesh_modifiers/normals_from_mesh_faces_modifier.h>
 
int main(int argc, char** argv)
{
  noether_tpp::NormalsFromMeshFacesMeshModifier mod;
  return 0;
}

ROSCon 2024 Workshop

See this repository for a workshop that was put on at ROSCon 2024. The repository includes exercises and demonstrations for creating custom implementations of Noether interfaces, including integration with the GUI.