added possibility to optionally optimize time during compute cartesian path ️🔥 #2874
Conversation
|
Ping. |
|
Someone there ? ping |
Duke194
changed the title
There was a problem hiding this comment.
This makes sense to me, thanks! Rather than calling it time_optimize, I'd propose calling the option compute_time_stamps or generate_trajectory to highlight that if this option is false, the output of the capability is just a path an not a trajectory. What do you think?
| time_param.computeTimeStamps(rt, 1.0); | ||
| if (req->time_optimize) | ||
| { | ||
| auto orig_point_count = rt.getWayPointCount(); |
There was a problem hiding this comment.
| auto orig_point_count = rt.getWayPointCount(); | |
| const auto orig_point_count = rt.getWayPointCount(); |
| auto orig_point_count = rt.getWayPointCount(); | ||
| trajectory_processing::TimeOptimalTrajectoryGeneration time_param; | ||
| time_param.computeTimeStamps(rt, 1.0); | ||
| RCLCPP_INFO(LOGGER, "Optimized trajectory with %u points to %u points", (unsigned int)orig_point_count, |
There was a problem hiding this comment.
| RCLCPP_INFO(LOGGER, "Optimized trajectory with %u points to %u points", (unsigned int)orig_point_count, | |
| RCLCPP_DEBUG(LOGGER, "Optimized trajectory with %u points to %u points", (unsigned int)orig_point_count, |
|
Instead of using a simple boolean flag, did you considered to specify the time parameterization plugin via a string? |
I see your point. But I think we should then go for |
I didn't considered that because for our specific use case it is sufficient to get a path out of this capability. We do the time optimization aka. trajectory generation afterwards ourselves. I do not know if the parametrization needs to be configurable. Probably depends on the use case. |
|
@Duke194 Just realized your targeting the humble branch with your PR. Do you mind changing it to main? We'll backport it to humble with a github bot afterwards immediately. I think this is ready to be merged once you addressed my review |
|
I suggest implementing the more generic selection of time parameterization suggested in #2874 (comment). |
I'll do it on main this week. |
|
This PR is stale because it has been open for 45 days with no activity. Please tag a maintainer for help on completing this PR, or close it if you think it has become obsolete. |
github-actions
bot
added
the
stale
Description
Added the ability to opt out of time optimization during Cartesian path computation.
This change requires a corresponding update in moveit/moveit_msgs#179, which is related to this PR.
This feature is necessary for our project to plan trajectories with multiple waypoints and turning points. We have tested the planning with and without this feature. Without this feature, time optimization removes some essential points, resulting in incorrect trajectories. With this feature enabled, the trajectory is planned correctly without any issues.