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

Nav2 route server start pose orientation scorer #4950

Open
wants to merge 13 commits into
base: nav2_route_server
Choose a base branch
from

Conversation

alexanderjyuen
Copy link
Contributor


Basic Info

Info Please fill out this column
Ticket(s) this addresses N/A
Primary OS tested on Ubuntu 20.04
Robotic platform tested on Polymath Robotics' Ackermann agriculture client
Does this PR contain AI generated software? No

Description of contribution in a few bullet points

Presently there is no edge scorer that restricts or penalizes routes that start with an orientation that is very different from the robot start pose. A new edge scorer has been added to do that comparison and return false if a route pose is very different from the start pose

In order to do this, two major additions were made outside of including start_pose_orientation_scorer.cpp and start_pose_orientation_scorer.hpp` this includes:

  • Adding a function to check if the node ID is the start node
  • Passing the bool identifying an edge being the start edge all the way from the route server to the edge scorers
  • Passing the tf buffer from route planner down to the edge scorers
  • Modifying all edge scorers to take new arguments

Description of documentation updates required from your changes

Need to add configuration guide on full release of route_server

Description of how this change was tested

Unit tests were written to cover the major use case

Future work that may be required in bullet points

  • Documentation and more comprehensive testihng

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: Alexander Yuen <[email protected]>
Signed-off-by: Alexander Yuen <[email protected]>
…e in score method for all existing edge scorers

Signed-off-by: Alexander Yuen <[email protected]>
…, added tf_buffer as a protected variable

Signed-off-by: Alexander Yuen <[email protected]>
… added isStart method to identify initial node for route_planner.hpp

Signed-off-by: Alexander Yuen <[email protected]>
…ions to take a start edge bool, added test for start_pose_orientation_scorer

Signed-off-by: Alexander Yuen <[email protected]>
…ns, bool for start edge also passed down to plugins

Signed-off-by: Alexander Yuen <[email protected]>
Copy link
Contributor

mergify bot commented Feb 25, 2025

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

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.

Some medium sized items, but all should be technically easy (just touches a few files). Overall, looks good in concept

@@ -63,7 +66,8 @@ class EdgeScorer
* @return If edge is valid
*/
bool score(
const EdgePtr edge, const geometry_msgs::msg::PoseStamped & goal_pose, bool final_edge,
const EdgePtr edge, const geometry_msgs::msg::PoseStamped & goal_pose, bool start_edge,
Copy link
Member

Choose a reason for hiding this comment

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

If we're going to add things like this, I think we should create an enum so more than be added without breaking API in the future. We can have an enum for SpecialEdgeType with start, final as current ones. If neither, then the default can be NONE.

const std::string & name) = 0;

/**
* @brief Main scoring plugin API
* @param edge The edge pointer to score, which has access to the
* start/end nodes and their associated metadata and actions
*/
virtual bool score(const EdgePtr edge, const geometry_msgs::msg::PoseStamped & goal_pose, bool final_edge, float & cost) = 0;
virtual bool score(
Copy link
Member

Choose a reason for hiding this comment

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

Then propagated here as well

@@ -58,11 +60,13 @@ EdgeScorer::EdgeScorer(nav2_util::LifecycleNode::SharedPtr node)
throw ex;
}
}

tf_buffer_ = tf_buffer;
Copy link
Member

Choose a reason for hiding this comment

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

Does the edge scorer manager need the tf buffer? I think this can be removed (and in the hpp file)

@@ -0,0 +1,91 @@
// Copyright (c) 2024, Polymath Robotics Inc.
Copy link
Member

Choose a reason for hiding this comment

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

Update to 2025 (with cpp file too)


/**
* @class StartPoseOrientationScorer
* @brief Scores initial edge edge by comparing the orientation of the robot's current pose and the orientation of the edge
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
* @brief Scores initial edge edge by comparing the orientation of the robot's current pose and the orientation of the edge
* @brief Scores initial edge by comparing the orientation of the robot's current pose and the orientation of the edge

Please also provide additional information about how it scores. I don't think it actually scores as much as it rejects if > than a tolerance. (also the goal orientation one needs to be populated as well

)

namespace nav2_route
{

void StartPoseOrientationScorer::configure(
Copy link
Member

Choose a reason for hiding this comment

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

I wanted to mention that this could cause you some real headaches with non-liberal values of the tolerance. If localization updates mess with your orientation, initial orientation is very wrong, initial orientation is not aligned with the graph when the robot starts up, or robot drives off the route for some reason, your orientation could not align well with any of the edges and cause them all to fail.

I wonder if you really want to apply a continuous cost function proportionate to the orientation instead of a straight-up rejection. It would then allow for much shorter paths to be able to use the reverse direction, which maybe isn't something you want. I think there should be modes (or separate plugins?) for both options. I could see both being useful and I think you would also have applications of this work that you would want to use either/or (such as for omni, differential, or small ackermann platforms)

robot_frame_ = node->get_parameter(getName() + ".robot_frame").as_string();

tf_buffer_ = tf_buffer;

Copy link
Member

Choose a reason for hiding this comment

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

Remove empty line

nav2_util::declare_parameter_if_not_declared(
node,
getName() + ".orientation_tolerance", rclcpp::ParameterValue(M_PI / 2.0));
nav2_util::declare_parameter_if_not_declared(
Copy link
Member

Choose a reason for hiding this comment

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

Shouldnt thins and the robot frame exist for the server itself (rather than the plugin)? If so, you don't need to duplicate parameters, you can simply get the server's values itself from get_parameter without declaring

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