How to handle unreleased test dependencies?

[JeroenDM]

The tests currently have a run dependency on [kuka_test_resources]() that is not released (and probably should not be released). This means the test will fail on the build farm.

Should we solve this problem? And if so, these are some ideas:

• Refactor the tests and load the urdf files directly from the test directory. Replace all meshes with primitive shapes.
• Use robots that have released moveit_config packages.
• Add kuka_test_resources to the external directory (not my favorite solution, but the easiest).

[JeroenDM]

For future reference:

• ROS answers question.
• moveit_resources issue

I'm really not sure anymore what would be a good solution.

The option mentioned above that would avoid much of the issues raised is to create a minimal version of the urdf of the fanuc and kuka robot that only uses primitive shapes for links. These can then be but in the test folder and loaded to run tests. (Only the kinematic structure is relevant for the tests, so there should not even be a collision geometry in the urdf.)

This is of course quite some manual work to recreate resources that already exist anyway.

[gavanderhoorn]

So what would be needed to run the tests?

Could you "simply" test_depend on fanuc_m10ia_support fi?

[JeroenDM]

At the moment we use the moveit config package here.

And looking at it again, I think this should stay this way. Only loading the urdf for a test might not be a good test. By using the moveit config package we also test whether the plugin is loaded correctly, exactly replicating how it will mostly be used by users.

I think this package should test whether the plugin is loaded correctly and works from a variety of robots. What we should not specifically test:

• Checking the kinematics calculations (responsibility of the opw_kinematics library).
• Checking the geometric parameters for a specific robot (responsibility of the robot support package).

In conclusion, I think it can be useful to release the moveit_configurations for some robots, as is done now with panda_moveit_config. This is not only good for the tests here, but also for tests and tutorials in general.

Searching through the ROS index, there are apparently already a whole bunch of these released (mostly fanuc and some abb). So, maybe I can just change the tests to use some of these robots... (Ideally while adding the opw geometric parameters to their support package.)

[gavanderhoorn]

In conclusion, I think it can be useful to release the moveit_configurations for some robots, as is done now with panda_moveit_config. This is not only good for the tests here, but also for tests and tutorials in general.

that was going to be my next question: there are plenty of MoveIt configurations released.

You could use those.

You could also opt to release a specific test moveit configuration package you put together yourself. It would not need any meshes, nor other fancy stuff, so really only be minimal.

Given the requirement of having test_depends to be released -- or at least when working with the ROS buildfarm -- you could then release that package and be done with this.

How much value there would be in testing whether the plugin loads I'm not sure though: there are various scenarios in which such a test would succeed in your test, but could still fail on users' machines.