-
Notifications
You must be signed in to change notification settings - Fork 644
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
fix(pose_initializer): add topic subscription to direct initialization #8941
fix(pose_initializer): add topic subscription to direct initialization #8941
Conversation
Thank you for contributing to the Autoware project! 🚧 If your pull request is in progress, switch it to draft mode. Please ensure:
|
101508c
to
daf7949
Compare
Signed-off-by: Melike Tanrıkulu <[email protected]>
f4d9220
to
3db8ce1
Compare
/review |
PR Reviewer Guide 🔍
|
de8073d
to
e7d83c9
Compare
/improve --extended |
auto pose = req->pose_with_covariance.empty() ? get_gnss_pose().pose.pose | ||
: req->pose_with_covariance.front().pose.pose; |
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.
Suggestion: To improve readability and avoid potential confusion, consider renaming the variable pose
to something more descriptive like initial_pose
. [readability, importance: 6]
auto pose = req->pose_with_covariance.empty() ? get_gnss_pose().pose.pose | |
: req->pose_with_covariance.front().pose.pose; | |
auto initial_pose = req->pose_with_covariance.empty() ? get_gnss_pose().pose.pose | |
: req->pose_with_covariance.front().pose.pose; |
@@ -27,13 +27,15 @@ LocalizationNode::LocalizationNode(const rclcpp::NodeOptions & options) | |||
adaptor.relay_message(pub_state_, sub_state_); | |||
adaptor.init_cli(cli_initialize_); | |||
adaptor.init_srv(srv_initialize_, this, &LocalizationNode::on_initialize, group_cli_); | |||
|
|||
initialization_method_ = declare_parameter<int>("initialization_method"); |
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.
Suggestion: To ensure the parameter initialization_method
is within the expected range, add a validation check after declaring the parameter. [validation, importance: 9]
initialization_method_ = declare_parameter<int>("initialization_method"); | |
initialization_method_ = declare_parameter<int>("initialization_method"); | |
if (initialization_method_ < 0 || initialization_method_ > 1) { | |
throw std::invalid_argument("initialization_method must be 0 (AUTO) or 1 (DIRECT)"); | |
} |
if (initialization_method == 0) | ||
internal->method = tier4_localization_msgs::srv::InitializeLocalization::Request::AUTO; | ||
else if (initialization_method == 1) | ||
internal->method = tier4_localization_msgs::srv::InitializeLocalization::Request::DIRECT; |
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.
Suggestion: To enhance readability and maintainability, use a switch
statement instead of multiple if-else
statements for setting the initialization_method
. [readability, importance: 7]
if (initialization_method == 0) | |
internal->method = tier4_localization_msgs::srv::InitializeLocalization::Request::AUTO; | |
else if (initialization_method == 1) | |
internal->method = tier4_localization_msgs::srv::InitializeLocalization::Request::DIRECT; | |
switch (initialization_method) { | |
case 0: | |
internal->method = tier4_localization_msgs::srv::InitializeLocalization::Request::AUTO; | |
break; | |
case 1: | |
internal->method = tier4_localization_msgs::srv::InitializeLocalization::Request::DIRECT; | |
break; | |
default: | |
throw std::invalid_argument("Invalid initialization_method"); | |
} |
{ | ||
return convert_response(client->call(convert_request(req))->status); | ||
return convert_response(client->call(convert_request(req, initialization_method))->status); |
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.
Suggestion: To ensure the convert_call
function is robust, add a check to handle the case where the client call fails and returns a null response. [robustness, importance: 10]
return convert_response(client->call(convert_request(req, initialization_method))->status); | |
auto response = client->call(convert_request(req, initialization_method)); | |
if (!response) { | |
throw std::runtime_error("Client call failed"); | |
} | |
return convert_response(response->status); |
Signed-off-by: Melike Tanrıkulu <[email protected]>
Signed-off-by: Melike Tanrıkulu <[email protected]>
e7d83c9
to
b2235ec
Compare
Signed-off-by: Melike Tanrıkulu <[email protected]>
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 the ndt_enable and yabloc_enabled parameters meaningless. Please revise the implementation.
This PR parameter change is based on the addition of DIRECT initialization. However, instead of this, it seems more logical to decide whether the pose will be DIRECT initialized by checking if the covariance of the gnss poses is 0.For this reason I want to close this and opened a new PR. Here is the mentioned PR --> #8948 However, the covariance values of the GNSS poses that come in the autoware_pose_initializer package are automatically changed . This parameter decide the covariance values of GNSS poses --> autoware.universe/localization/autoware_pose_initializer/config/pose_initializer.param.yaml Line 16 in d25e9a1
Here is the GNSS poses covariance replaced here --> https://github.com/autowarefoundation/autoware.universe/blame/d25e9a1bbedc176d4e29c70b3ed9586808bdf813/localization/autoware_pose_initializer/src/pose_initializer_core.cpp#L221 |
It's not that we want the covariance of the GNSS, but rather, we want to determine the kind of distribution to use when spreading the particles. |
I don't think this method is a good approach. |
@YamatoAndo -san, Why do you think so? If all the covariances are 0, or lower than some threshold we define, it means, the pose is very reliable and we can use it for direct initialization. Overriding the original covariances should be an optional feature, not the default. The GNSS already provides this information. |
Why shouldn't you distribute it along the covariance ellipse? |
In the first place, the position output by the GNSS receiver often does not match the correct position on the point cloud map. While GNSS positioning errors are one factor, it is difficult to perfectly align the point cloud map with GNSS positioning. Despite this, relying on the dispersion output by the GNSS receiver to determine the particle distribution is not a good idea. |
Let's discuss here: |
Description
You need to call service to initialize directly now. Documentation
However, if you trust the GNSS pose, you may want to initialize directly with the GNSS pose. For example, we think that the pose coming from GNSS for the simulation environment can be used for initialization directly. We think that the feature of using GNSS poses should be added to activate the direct initialization feature for such cases.
This PR allows you to directly initialize the position from GNSS poses with a parameter change.
Related links
Parent Issue:
#8940
How was this PR tested?
Test Steps:
1. Checkout autoware.universe
2. Compile updated packages:
3. Update Parameters
To enable the direct initialization feature using GNSS poses, the parameters must be adjusted accordingly.
4. Run autoware
4. Run bag file
Instead, you can test PR in any sensor model or simulation environment and observe it with the GNSS pose to see the results.
Notes for reviewers
What do we expect to see?
If we set initialization method as 1 (DIRECT Initialization method), we expect to see the vehicle initialize at exactly the same point and with the same orientation as the GNSS pose.
Interface changes
None.
Effects on system behavior
None.