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

Codecov Report

Attention: Patch coverage is 80.18018% with 22 lines in your changes missing coverage. Please review.

Project coverage is 47.21%. Comparing base (e8eb9c1) to head (3e348b6).
Report is 21 commits behind head on master.

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

@@            Coverage Diff             @@
##           master    #3618      +/-   ##
==========================================
+ Coverage   47.16%   47.21%   +0.05%     
==========================================
  Files         603      604       +1     
  Lines       59196    59238      +42     
  Branches     7024     7021       -3     
==========================================
+ Hits        27915    27964      +49     
+ Misses      30863    30856       -7     
  Partials      418      418              

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

FYI, @LeroyR

Very Nice! Always wanted to benchmark against Pilz :)

I tested on my setup, and it now works reliably with short trajectories. But for larger distance (see photos below), I often get min_fraction Achieved = 0.0. The same goals works with Pilz.

Here is my config (manually set in MTC cartesian_path.cpp). Using a version of Track-IK which is deterministic.

// image 1
moveit::core::CartesianPrecision precision;
precision.translational = 0.001;
precision.rotational = 0.01;
precision.max_resolution = 1e-5;

moveit::core::MaxEEFStep max(0, 0.0349066);

// image 2
moveit::core::CartesianPrecision precision;
precision.translational = 0.01;
precision.rotational = 0.01;
precision.max_resolution = 1e-5;

moveit::core::MaxEEFStep max(0, 0.0349066);

Do you have any insight on why this could happen ? I would assume that the min_fraction would be greater then 0 for these cases.

I suggest using a non-zero MaxEEFStep(0.1, 0.035). Trying to jump to the target with a single IK call, might lead to unavoidable jumps. Did you use zero translational step in the past?

Wow this is a game changer :)

With the proposed config, this PR passes my huge Task which consist of + 1000 stages and generates 5200 waypoints ! Some limited benchmark (5 runs each).

Did you use zero translational step in the past?

Never used in the past as it failed for short trajectories.

Wow this is a game changer

I'm curious: where do you see a dramatic change? I was just expecting some more robustness when generating linear Cartesian trajectories. Particularly, I wasn't expecting faster computation.

Robustness is the key + same configuration for a wide variety of poses. Like I said, the solver went from a no go (from my perspective and project needs) to a potential alternative to Pilz.

It seems faster, but would have to change my configuration to match Pilz. Gotta check if it passes through the same planning plugins also.

EDIT : With MTC I can now use the min/max distance to stop early on collisions, which cannot be used with Pilz.

Wow this is a game changer

I'm curious: where do you see a dramatic change? I was just expecting some more robustness when generating linear Cartesian trajectories. Particularly, I wasn't expecting faster computation.

If you have successive points where a joint interpolation is sufficient (and within tolerance), you can avoid having to solve IK at that point. So I can totally see the speedups that way!

I have observed some weird bot motion after the changes in this P.R. I have opened an issue here : #3657

I don't understand why any changes have been made to the API so close to the noetic EOL.

I don't understand why any changes have been made to the API so close to the noetic EOL.

Reaching EOL doesn't mean stopping development. ROS1 is to be continued: https://github.com/ros-o/ros-o

Yes, but the binaries are going to be frozen, and there are probably packages that use moveit that will not have time to update its binaries before that.