Add helper functions to locate yarp configuration files

[xela-95]

The yarpConfigurationFile way to specify a configuration file for yarp plugins must support the specification of paths using the model:// syntax.

https://github.com/robotology/gz-sim-yarp-plugins/issues/77#issuecomment-1936527309

How gazebo vs. gazebo classic search for models and other sdf elements: https://gazebosim.org/api/sim/8/migrationsdf.html

[xela-95]

Gazebo SystemPaths reference: https://gazebosim.org/api/common/5/classgz_1_1common_1_1SystemPaths.html#a25a70e40ab87f2bcb419a91ccaf15642

gazebo-yarp-plugins helper class to deal with configurations: https://github.com/robotology/gazebo-yarp-plugins/blob/master/libraries/singleton/src/ConfHelpers.cc

[xela-95]

By using the findURI function provided by Gazebo, if the string is actually an absolute or relative path without the use of URI (defined as scheme[//authority]path[?query][#fragment] ), the function gives the following output:

[Err] [SystemPaths.cc:364] The passed value [/home/acroci/repos/gz-sim-yarp-plugins/tests/commons/conf/laser.ini] is not a valid URI, trying as a file

and then it correctly defaults to searching the file.

@traversaro should I match the string against a regex to determine what function to call (findFile or findURI)?

[xela-95]

Note for future users (and myself): while writing the unit test to check the loading of the configuration of gz-sim-yarp-plugins, I noted that the <plugin> tag must be inserted into the <model> element. When I tried to put this directly inside the <sensor> element of the SDF I got errors since the scoped name was empty. To my experience this is true for all plugins we have, not only for what in Gazebo classic were model plugins.

I found on http://robotology.github.io/gazebo-yarp-plugins/master/embed_plugins.html documentation that:

For model plugins such as the gazebo_yarp_controlboard, a plugin can be loaded by adding a SDF tag as a child of the SDF tag that describes the model.

but it does not says anything about sensor plugins.

@traversaro does this align with your knowledge?

[traversaro]

@traversaro should I match the string against a regex to determine what function to call (findFile or findURI)?

Good point. I guess that was the behaviour also in the old Gazebo. Passing the absolute path in general is undesirable, as it creates non-portable models. However, if something is supported, it should not print an error. I guess we can either discriminate absolute files by check if they are absolute path with std::filesystem , or check if a value is a URI by checking if it starts with an URI. However, this is not trivial as on Windows absolute paths may start with C:\ or D:\, so for now we can also leave this aside if we do not know how to do it properly, and just stay with the error in case of absolute path.

[traversaro]

Note for future users (and myself): while writing the unit test to check the loading of the configuration of gz-sim-yarp-plugins, I noted that the <plugin> tag must be inserted into the <model> element. When I tried to put this directly inside the <sensor> element of the SDF I got errors since the scoped name was empty. To my experience this is true for all plugins we have, not only for what in Gazebo classic were model plugins.

I found on http://robotology.github.io/gazebo-yarp-plugins/master/embed_plugins.html documentation that:

For model plugins such as the gazebo_yarp_controlboard, a plugin can be loaded by adding a SDF tag as a child of the SDF tag that describes the model. but it does not says anything about sensor plugins.

@traversaro does this align with your knowledge?

Yes, that was indeed a limitation we realized while first working on the plugins in this repo, and we decided to proceed like that as we were not be able to get it to work by putting the plugins as children of the sensor tag. We may eventually want to fix this, but for now we can just document this as a change between gazebo-yarp-plugins and gz-sim-yarp-plugins (for example if we prepare a migration document).

[xela-95]

@traversaro should I match the string against a regex to determine what function to call (findFile or findURI)?

Good point. I guess that was the behaviour also in the old Gazebo. Passing the absolute path in general is undesirable, as it creates non-portable models. However, if something is supported, it should not print an error. I guess we can either discriminate absolute files by check if they are absolute path with std::filesystem , or check if a value is a URI by checking if it starts with an URI. However, this is not trivial as on Windows absolute paths may start with C:\ or D:\, so for now we can also leave this aside if we do not know how to do it properly, and just stay with the error in case of absolute path.

I think I can discriminate the paths using the is_absolute and is_relative methods, that should work on both Windows and Linux https://en.cppreference.com/w/cpp/filesystem/path/is_absrel

[xela-95]

Ok with https://github.com/robotology/gz-sim-yarp-plugins/pull/116/commits/db30ff2e911c106571c42ec140d63ba3eb6fb77f we can manage three ways to specify configuration files:

• URIs
• Absolute paths (discouraged but working)
• Relative paths