Solution properties

[rhaschke]

• Augment solutions with a PropertyMap
  • condition to start a trajectory delayed (e.g. for finger closing)
  • callbacks to trigger suction on/off
• Provide two exec() variants:
  • exec(SolutionMsg) -> send to move_group node
  • exec(const SolutionBase&) -> use MoveItCpp to execute a solution directly, allowing to evaluate stored properties

[v4hn]

Another prominent use-case for the properties is to specify controllers/controller parameters to switch before execution of the segment starts, e.g., increase force limits to grasp stronger, switch to velocity-based controllers or switch to an entirely different custom (ros_)controller to adjust the executed trajectory on the fly depending on system state. Part of that was implemented by PickNik, though I don't know how much they actually use it.

exec(SolutionMsg) -> send to move_group node

Last time we looked into this that was the main blocker due to the serialization or "arbitrary" objects and the need to implement the interpretation of all these properties on the move_group side.
I would be perfectly happy with the second approach only, to keep the property data structures in the same process and leave the interpretation of custom properties mostly to user code.

[rhaschke]

Hey @v4hn, you are monitoring my internal fork?

Part of that was implemented by PickNik.

Interesting. Is that publicly available?

Last time we looked into this that was the main blocker due to the serialization or "arbitrary" objects.

Yes, given that we have MoveItCpp for execution now, we can easily use that.
I would still offer the old method (with its limitations).

[v4hn]

you are monitoring my internal fork?

You tend to write interesting things here too. 😼
I monitor lots of things but my inbox is also always flooded because of that.

Part of that was implemented by PickNik.

Interesting. Is that publicly available?

I was referring to moveit#123 which Lucas implemented with you and which was picked up as a PickNik work package in ros2 moveit#355 .
I'm not sure whether they actually use the patch from there anywhere, but I wouldn't be surprised if they had a customer asking for it.
Anyway, I was not happy with that approach because it focused only on controller names.

I would still offer the old method (with its limitations).

I think it makes sense to simply leave out properties altogether from that interface and just print an appropriate (configurable) warning if someone serializes such a solution.