No, that is not taken into account. Or at least, not automatically (how could it, this is behaviour that is rather specific to this particular piece of hardware).

So in order to account for this offset, I would need to calculate the gripper kinematics myself basing on the return value from the gripper, and feed add/subtract it from the planned value, right?

This is all just speculation (and I don't know anything about the robotiq drivers/pkgs, but: if there are JointStates, a urdf and correctly modelled kinematics, TF frames for the fingers could be published "automatically". If you then define a toolframe that lies between the fingers, and ..

.. make this dependend on the location(s) of the TFs of the fingers, you should be able to have MoveIt plan for those, instead of for tool0 (of the UR). I can't remember right now whether MoveIt is able to plan to goals that are expressed in frames other than the ones that are part of the ..

.. group it's planning for, but that would make things even easier.

Doing it manually is also an option, but doesn't seem too 'nice'.

But let's wait for some other posters, perhaps they have better suggestions.

This question is not specific enough to give a real answer. Please add screenshots to illustrate the behavior (I don't have the gripper). What do you mean by "compensated"? Will moveit avoid collisions correctly? yes, probably. Will the grasp frame automatically adapt to the size of the object ...

the gripper should grasp? No. But you have to compute your grasp poses yourself/via some external module anyway. So it is actually better that MoveIt does no "magic" here to compensate for something, because it would interfere with your grasp computation.

Altogether I don't like gvdhoorn's answer "no". It depends on the exact question.

I agree with @v4hn that the question was slightly vague, but I do believe that @Fiddle was asking whether "grasp poses" would be automatically 'updated' to factor in changing gripper geometry. Especially his comment:

and feed add/subtract it from the planned value

made me think that.

I think gvdhoorn's answer with making additional toolframe seems like the most reasonable way to handle this case. Additionally, I've put images of the gripper

Perhaps @v4hn has a suggestion that would work better. My suggestion was really just something I think could work, not necessarily the best way to approach this.

It might help if you could clarify what you actually want to see 'updated' or 'taken into account' by moveit. And when.

I guess the additional toolframe representing the mean position of the gripper's tips was what I need. But is there a way to make it relative to both of the gripper's tips in moveit? I guess creating one link with two parents is not possible.

Not in a urdf and with the robot_state_publisher, no. But a custom node broadcasting a TF frame could do whatever it wanted.

And that tf frame could be read by MoveIt? I have currently robot with gripper attached as two different planning groups, could I add another link to it that could listen for those tf transforms? The question now is: Can I add/modify this end effector for Moveit to use dynamically?

No, MoveIt currently cannot plan for frames that are not part of the robot description. (patches are welcome)

And even if it could do that, this would not help you. You would like to predict the new frame for planning. This is not what tf does.

Instead you should compute your input Grasp definitions / pose targets for the pipeline to account for the dynamic frame.