-
Notifications
You must be signed in to change notification settings - Fork 544
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
added possibility to optionally optimize time during compute cartesian path ️🔥 #2874
base: humble
Are you sure you want to change the base?
Conversation
Ping. |
Someone there ? ping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
Please target the |
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.