Export robotlist

[mathias-luedtke]

addresses #577

[mathias-luedtke]

should be used in cob_calibration_dataas well.

[fmessmer]

Wow, sweet....that will help keep things consistent quite a lot!

We should do the same for ENVLIST in cob_default_env_config and then use cob_hardware_config_ROBOTLIST and cob_default_env_config_ENVLIST wherever it is used!

[mathias-luedtke]

wherever it is used!

this is tricky as not all robots are configured for high-level packages.

[fmessmer]

Sorry, I introduced a merge conflict when merging #578
But I can take over and try to apply the new cob_hardware_config_ROBOLIST to further repositories....

However, when using this for cob_calibration_data, we are introducing a cyclic dependency...as cob_calibration_data is used within cob_hardware_config

[mathias-luedtke]

Sorry, I introduced a merge conflict

rebased

However, when using this for cob_calibration_data, we are introducing a cyclic dependency.

New package cob_supported_robots?
Or keep list in cob_calibration_data?

[fmessmer]

rebased

Also already did that in #582

New package cob_supported_robots?
Or keep list in cob_calibration_data?

I would keep the robotlist in cob_calibration_data as it is very unlikely that we forget to configure this for a new robot 😉

[mathias-luedtke]

I would keep the robotlist in cob_calibration_data

This even reduces the dependencies (just xacro). I wasn't aware that cob_hardware_config depends on so many packages.

A cob_supported_robots package would not have any dependencies apart from catkin..

[floweisshardt]

nice solution to mimimise maintenance effort. But I don't like the fact that we introduce dependencies to cob_hardware_config from every package (also simulation related and possibly high-level packages).

So I vote for introducing a new package cob_supported_robots. The question is where to place the package?

• in cob_robots: Bad because of cyclic dependency from/to cob_calibration_data
• as a standalone repository: will solve dependency structure, but will increase amount of overlays
• in cob_calibration_data: good, we just have to make that a multi-package-repo and rename the repository

Alternative would be to use the list out of cob_calibration_data. Pro: no cyclic dependencies because cob_calibration_data has no further dependencies and it doesn't hurt if all packages depend on cob_calibration_data

[mathias-luedtke]

I vote for keeping the list cob_calibration_data, because it is easier to maintain.
A dependency on xacrodoes not hurt that much.

We can migrate to cob_supported_robots later if necessary.

in cob_robots: Bad because of cyclic dependency from/to cob_calibration_data

this is not cyclic!
cob_robot -> cob_supported_robots
cob_robot -> cob_hardware_config -> cob_calibration_data -> cob_supported_robots

cyclic (with this PR):
cob_hardware_config -> cob_calibration_data -> cob_hardware_config

[mathias-luedtke]

added cob_supported_robots

[mathias-luedtke]

@ipa-fmw: added your changes

[fmessmer]

Once this is merged we need to update ipa320/cob_simulation#130
Do we want a cob_supported_environments package? See ipa320/cob_environments#116
Also, we want to make use of it in cob_calibration_data

[fmessmer]

So, we are going to keep the robotlist in cob_default_robot_behavior and cob_moveit_config because those are not implemented for all supported robots, correct?

[floweisshardt]

why build_depend? other packages have test_depend defined

[floweisshardt]

due to using robotlist in install tags

[floweisshardt]

why build_depend? other packages have test_depend defined

[floweisshardt]

due to using robotlist in install tags

[fmessmer]

cob_calibration_data is done in ipa320/cob_calibration_data#115