[Python] Add RetimeTrajectory to RobotTrajectory

[JensVanhooydonck]

Description

This adds the RetimeTrajectory to the RobotTrajectory binding. This was available in the ROS1 movegroup python interface. This feature allows to plan a trajectory and change the trajectory speeds (velocity and acceleration values).

Currently the two algoritms inside trajectory_processing where added: Ruckig Trajectory Smoothing and Time Optimal Trajectory Generation.

Checklist

• Required by CI: Code is auto formatted using clang-format
• Extend the tutorials / documentation reference
• Document API changes relevant to the user in the MIGRATION.md notes
• Create tests, which fail without this PR reference
• Include a screenshot if changing a GUI
• While waiting for someone to review your request, please help review another open pull request to support the maintainers

[codecov]

Codecov Report

Attention: 8 lines in your changes are missing coverage. Please review.

Comparison is base (38668bf) 50.37% compared to head (8833f75) 50.37%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2411      +/-   ##
==========================================
- Coverage   50.37%   50.37%   -0.00%     
==========================================
  Files         385      385              
  Lines       31815    31829      +14     
==========================================
+ Hits        16025    16031       +6     
- Misses      15790    15798       +8     

Files	Coverage Δ
.../moveit_core/robot_trajectory/robot_trajectory.cpp	77.15% <100.00%> (+4.73%)	⬆️
...ore/trajectory_processing/src/trajectory_tools.cpp	0.00% <0.00%> (ø)

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

[sjahr]

Thank you for your contribution! While I like the idea of having this functionality I think there a are some things that should be reconsidered:

• Rather than having a single retimeTrajectory() function that does not expose specific paramters of the individual algorithms + you can give it a non-existing algorithm name, I'd prefer having two more specific functions for example:

addTOTGTimeParameterization(std::shared_ptr<robot_trajectory::RobotTrajectory>& self, const std::string& algorithm,
                      const double& velocity_scaling_factor, const double& acceleration_scaling_factor);
                      
applyRuckigSmoothing(std::shared_ptr<robot_trajectory::RobotTrajectory>& self, const std::string& algorithm,
                      const double& velocity_scaling_factor, const double& acceleration_scaling_factor, const bool mitigate_overshoot = false,
                                     const double overshoot_threshold = 0.01);

• These functions shouldn't be implemented in the python bindings package but as free functions in moveit_core/trajectory_processing (to avoid a circular dependency between RobotTrajectory and the time parameterization algorithms) e.g. here

[v4hn]

I do like the idea to abstract away trajectory_processing in python, so per se I don't think it's wrong to have the functionality as methods of RobotTrajectory. It's important to provide full support for the involved parameters though and the moveit method was quite a hack in the MoveGroupInterface wrapper class.

No strong feelings on free functions in separate namespace vs the methods, though some maintainers clearly prefer the functional style.

[sjahr]

Looks good, thank you!

[v4hn]

Looks good assuming it's tested.

[JensVanhooydonck]

Looks good assuming it's tested.

Tested both functions already in my python script.