The pose is fed to the IK solver,which gives the corresponding joint values for achieving the target pose.
Depending on whether you use setJointValueTarget or setPoseTarget IK is performed before the planning or (in the latter case) as part of the planning.
How does the IK ensures that the joint angle value obtained in step 2 ( angles corresponding the target pose) are collision free?
MoveIt maintains the planning scene and hands the IK plugin a function to do collision checking on that scene.
If the plugin does not find a non-colliding scene, it might restart or return false. It is up to the caller whether to give up or re-run IK with different settings when the plugin returns false.
--- update to comment below
As indicated above, things are different depending on the request you perform.
The RViz panel, performs IK on its own before forwarding any request to MoveIt.
The "Use-Collision-Aware IK" check seems to be used only once here. Each IK response resulting from a request by the interactive marker is fed into this function and solutions for which it returns false are marked as invalid.
I believe, the RViz plugin continuously reruns IK anyway as long as you drag around the marker,
so I don't think it reruns on failed ik requests. (Didn't look through the whole code base here).
If you use the setJointValueTarget functions, the function will return false it didn't find a solution. Because the MoveGroupInterface is not aware of the PlanningScene, it does not perform collision checking.
However, it will forward the generated target joint state to the move_group/ ompl and these will fail because of a collision. So if you use this interface, you should be aware that it's your responsibility to ensure collision-free joint states, e.g. by checking against a PlanningScene you maintain within your node.
If you use setPoseTarget instead, the interface will actually create constraint regions around your requested configuration and forward these to the move_group instead of a joint configuration. On the other side the move_group creates a ompl_interface::ConstrainedGoalSampler and hands it to OMPL.
In this case it's up to the planning library how often it will call for a valid joint goal.
If this fails too often, OMPL will actually complain about it on the command line I believe.
