Which stage to generate start/end poses and Cartesian motion for welding?

[gautz]

I'm trying to figure out the best way to use MTC standard stages for welding. And which one should be extended/added (Following #243).
Let's take a simple welding task example:

• Approach to start pose: linear in the axis of the welding wire => MoveRelative to start pose frame ? MoveTo?
• Welding (gun) start pose:
  • Optimal/desired Cartesian pose given but may collide.
  • Allowed variations given.
  • Cost for variation from optimal given
  • => MoveTo? fixed_state ? fixed_cartesian_pose ? generate_welding_pose ?
• Start welding: send IO signal at task execution
• Cartesian welding motion:
  • Cartesian Constrained.
  • Optimal/desired welding orientation given but may collide.
  • Allowed variations given.
  • Cost for variation from optimal given
  • => connect ? move_to end pose? move_relative ?
• Welding (gun) end pose: idem start pose => ?
• Stop welding
• Retrieve from end pose

[rhaschke]

Both MoveRelative and MoveTo (as well as Connect) can realize straight-line Cartesian motions. This essentially depends on the PlannerInterface you are providing to those stages. The main difference between MoveTo and MoveRelative is that the former requires an absolute goal pose, while the latter takes a relative goal, i.e. a motion relative w.r.t. the start/end pose. MoveRelative further allows moving only a fraction of the overall distance to the target, which MoveTo doesn't allow for.
In general, there exist multiple stage trees to solve a particular problem. But always try to prefer a propagator stage (MoveTo/MoveRelative) over a combination of generator+connector.

[felixvd]

I assume that is to avoid combinatorial explosion, but if the generator only spawns one possibility (or very few), I think it shouldn't be a concern?

[rhaschke]

Yes, this is about combinatorial explosion, because all possible pairs of start-end states are considered in a Connect stage.

[v4hn]

Maybe to follow up on this (and close it for now) some thoughts from my side.

In general, there exist multiple stage trees to solve a particular problem. But always try to prefer a propagator stage (MoveTo/MoveRelative) over a combination of generator+connector.

If you know you will spawn only one state on at least one end, there is no big difference in functionality between GEN-MoveTo & GEN-Connect-GEN. Both can be setup with Cartesian, PTP or sampling planners. In general, the second approach might seem more modular, but it also has disadvantages.

• Unless you can ensure multiple states on each end will not be compatible except for the intended 1:1 mapping, you will end up with more attempted combinations in the combinatorial case - and even if the will be incompatible you get the slight overhead of checking compatibility.
• MoveTo allows for Pose goals, and can easily be extended to any target type supported by the solvers. The -Connect-GEN approach is bound to work with a joint state (inside the InterfaceState). I could imagine an extension that works on a "prototypical" joint state of a target volume that is later smoothed to the state that was actually planned to, but that's likely not worth the effort for now.
• MoveTo/MoveRel provide visual markers (arrows) that don't make sense for the generic Connect stage. So if you use the connect-based approach you would actually loose introspection support. Of course you could implement such markers in your own custom Connect stage, but that's overhead again.