@LeroyR: Can you please test this for your grasping pipeline?

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 83.33333% with 2 lines in your changes missing coverage. Please review.

Project coverage is 47.23%. Comparing base (c174715) to head (17353f2).
Report is 44 commits behind head on master.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@            Coverage Diff             @@
##           master    #3655      +/-   ##
==========================================
+ Coverage   47.15%   47.23%   +0.09%     
==========================================
  Files         603      604       +1     
  Lines       58999    59291     +292     
  Branches     6969     7039      +70     
==========================================
+ Hits        27814    28001     +187     
- Misses      30773    30872      +99     
- Partials      412      418       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Having dropped "jump testing", I observed jumps in trajectory again. So, I reintroduced it. The problem with Cartesian interpolation in principle remains, which is a dilemma of the current design:

• We do need Cartesian interpolation to reduce the risk of state rejection due to a failing path constraint, which currently cannot be checked during interpolation.
• Ideally, we would do joint interpolation and only resort to Cartesian interpolation if the path constraint is violated, i.e. follow a similar approach as in New implementation for computeCartesianPath() #3618. However, this would require access to the path constraint...

I tried seeding IK from the from state or from a state retrieved via joint-space interpolation between from and to.
Additionally, I switched jump-testing on or off:

IK seed	no jump testing	jump testing
start
middle

Most Cartesian interpolation approaches yield jumps. Seeding from start state even results in invalid trajectories - having collisions. (Why the hell?) The most smooth approach results from middle seeding + jump testing. However, I'm afraid we cannot fully reject jumps.

@LeroyR: Can you please test this for your grasping pipeline?

I tested it for @LeroyR. Since our robot is used in a study, I tried it out in a simulation. With this pull request the planning is stuck and seems to be calculating indefinitely (I stopped after waiting ~15 minutes). The searchPositionIK in the kinematic solver is being called repeatedly as can be seen in the moveit_kinematics debug logs. This does not always happen but still very often. This is already the case with the first commit in the PR.

In principle, this PR should use Cartesian interpolation like before #3615.
Did you have issues with Cartesian interpolation there already? Did you change parameters since then?

This is already the case with the first commit in the PR.

Did you test the final commit too?

Maybe we should make the interpolation mode configurable via a ROS parameter?

In principle, this PR should use Cartesian interpolation like before #3615. Did you have issues with Cartesian interpolation there already? Did you change parameters since then?

We didn't had this issues before and we changed no parameters.

Did you test the final commit too?

Yes, and the problem remains.

Please try then the last commit before #3615. I think you have misconfigured your IK solver somehow.

Please try then the last commit before #3615. I think you have misconfigured your IK solver somehow.

Just tried it, seems to work fine with the same configuration.

Using other configurations for the IK solver as well as the default one does not solve the issue.

This is weird. Could you give f126e35 a final try? This uses the same old Cartesian interpolation but disables jump checking, which might reject too many states. Seeing calls to searchPositionIK means that getPositionIK already failed:

This is weird. Could you give f126e35 a final try?

Unfortunately, the issue remains.

I'm going to merge this. In the current state PoseModelStateSpace and ModelBasedStateSpace are identical (both using joint-space interpolation and distance measure), which doesn't make sense. One can easily enforce joint-space behavior via the ROS parameter enforce_joint_model_state_space.