As I mentioned in the other thread, tesseract presents the user with a list of discovered 3D meshes which can be imported. Some of these meshes are shipped in tesseract itself, but the user can also have their own installed, in which case they will most likely be contained in
/opt/ros on the host or in the user’s home directory (the latter of which is covered by the existing
To be clear, tesseract does not own
/opt/ros. That said, no single thing really does, that’s just where ROS workspaces are conventionally installed (e.g. all upstream ROS components gets installed there). One could say it’s owned by ROS, but ROS is just a collection of software (that includes tesseract) much like Ubuntu is a collection of software.
In many cases for a ROS snap, the snap is self-sufficient and it doesn’t make sense for it to care if ROS is installed on the host. Even if it did, if it tried to load a library from there it would probably fail as it wouldn’t be able to link to other libs. In this case, however, this snap is a utility that operates on a given ROS workspace and only loads meshes out of it. As a result, granting it access to the default ROS workspace on the host seems useful and reasonable to me, but I provide this background to make it clear that the precedent we’re setting is narrow.
I’m +1 to granting access to the following interface (though I’m flexible on the name, @jdstrand will have more thoughts):
@Levi-Armstrong you did not request that this interface be automatically connected upon install. I’m pointing this out in case you wanted it that way. If so, my initial thought is that having access to the host-installed ROS workspace doesn’t seem to be a core, required feature (i.e. tesseract still seems useful without it), but that’s not a tremendously informed opinion and I’d like your thoughts on it.