ComputeIK does not automatically set "target_pose" to INTERFACE anymore

[v4hn]

Since https://github.com/ros-planning/moveit_task_constructor/commit/157caac38527677a44b2c5de603939322718608a#diff-32b368f8353f812a564f161db5e3f48fL68 , "target_pose" is not automatically read from interface state anymore.

This entails that pretty much every use of the stage has to include props.configureInitFrom(Stage::INTERFACE, {"target_pose"}); now. E.g. here.

Was there a particular reason for this change @rhaschke ?

I don't see a motivation for this change and would like to get the default back.

That being said, I just forwarded master to your latest rhaschke-master with subsequent minor changes.

[v4hn]

ping.

Is this something that requires a more structural change or do we just revert this line? I would be fine with the latter.

[rhaschke]

ping.

Sorry, this got out of my sight...

Actually, you were asking for explicit configuration of all properties ;-) It should be valid to use ComputeIK with a fixed, hard-coded target_pose. In this case you would need to "unconfigure" if there is the default set. And this is actually not (yet) possible.

[v4hn]

Actually, you were asking for explicit configuration of all properties ;-)

I know what I said and I asked for not defaulting to automatic lookup of every property from PARENT. This makes it much harder to debug and understand problems, even if it might make correct code "more beautiful". That's not the same as not having INTERFACE defaults where intended - unless you make it look that way of course. ;)

It should be valid to use ComputeIK with a fixed, hard-coded target_pose.

That's true.

In this case you would need to "unconfigure" if there is the default set. And this is actually not (yet) possible.

So would you support the idea of default-settings for property sources if the individual stage specifies them?

off-topic: not reading mails sadly also makes it very easy to miss replies such as this one...

[rhaschke]

In this case you would need to "unconfigure" if there is the default set. And this is actually not (yet) possible.

So would you support the idea of default-settings for property sources if the individual stage specifies them?

I'm not sure what this shall mean. Are you talking about the individual stages (e.g. ComputeIK here) defining sensible defaults for property initialization? This will not solve the mentioned issue, or will it?