Skip to content
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

Add goal pose to CriticData #4812

Open
wants to merge 1 commit into
base: humble
Choose a base branch
from

Conversation

redvinaa
Copy link
Contributor


Basic Info

Info Please fill out this column
Ticket(s) this addresses (add tickets here #4809 )
Primary OS tested on Ubuntu
Robotic platform tested on custom gazebo simulation, custom hardware
Does this PR contain AI generated software? No

Description of contribution in a few bullet points

  • Added goal pose to MPPI CriticData
  • Now all critics can activate based on distance from global goal pose instead of pruned

Description of documentation updates required from your changes

  • Bugfix, usage doesn't change

Future work that may be required in bullet points

For Maintainers:

  • Check that any new parameters added are updated in docs.nav2.org
  • Check that any significant change is added to the migration guide
  • Check that any new features OR changes to existing behaviors are reflected in the tuning guide
  • Check that any new functions have Doxygen added
  • Check that any new features have test coverage
  • Check that any new plugins is added to the plugins page
  • If BT Node, Additionally: add to BT's XML index of nodes for groot, BT package's readme table, and BT library lists

Signed-off-by: redvinaa <redvinaa@gmail.com>
Copy link
Contributor

mergify bot commented Dec 20, 2024

@redvinaa, all pull requests must be targeted towards the main development branch.
Once merged into main, it is possible to backport to @humble, but it must be in main
to have these changes reflected into new distributions.

@redvinaa redvinaa force-pushed the mppi-goal-to-critic-humble branch from 4465836 to 2d61b3f Compare December 20, 2024 14:40
@redvinaa
Copy link
Contributor Author

Please check implementation and when everything is correct, I'll port to rolling

Copy link
Member

@SteveMacenski SteveMacenski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks good to me

@@ -92,13 +92,15 @@ geometry_msgs::msg::TwistStamped MPPIController::computeVelocityCommands(
last_time_called_ = clock_->now();

std::lock_guard<std::mutex> param_lock(*parameters_handler_->getLock());
geometry_msgs::msg::Pose goal = path_handler_.getTransformedGoal().pose;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we get the goal as transformed_plan.poses.back()? There's no reason to do another TF operation I don't think and we can find it on L98 below transformPath() instead

@@ -119,7 +119,7 @@ void CostCritic::score(CriticData & data)

// If near the goal, don't apply the preferential term since the goal is near obstacles
bool near_goal = false;
if (utils::withinPositionGoalTolerance(near_goal_distance_, data.state.pose.pose, data.path)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I much prefer this API so that its explicit about what information that withinPositionGoalTolerance is working on instead of handing it everything and then having to reference the implementation to know what data its using. I think you can just update the existing withinPositionGoalTolerance() method instead - it seems like a pretty trivial change

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants