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

RJD-1335 Fix requestSpeedChange sets target_speed only when it's reached #1410

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

gmajrobotec
Copy link
Contributor

@gmajrobotec gmajrobotec commented Oct 3, 2024

Description

Abstract

The statement target_speed_ = target_speed.getAbsoluteValue(getCanonicalizedStatus(), other_status_); in firs example sets the target speed only in cases where the target speed has already been reached, which seems counter intuitive. This statement’s position is inconsistent with second example.

[this, target_speed](double) {
if (other_status_.find(target_speed.reference_entity_name) == other_status_.end()) {
return true;
}
if (isTargetSpeedReached(target_speed)) {
target_speed_ = target_speed.getAbsoluteValue(getCanonicalizedStatus(), other_status_);
return true;
}
return false;
},

[this, target_speed](double) {
if (other_status_.find(target_speed.reference_entity_name) == other_status_.end()) {
return true;
}
target_speed_ = target_speed.getAbsoluteValue(getCanonicalizedStatus(), other_status_);
return false;
},

Details

Described statement is moved down, outside of the “if” statement. This way the most up to date target speed will be set on each iteration until the target speed is reached. This is consistent with continuous case.

References

Jira ticket: internal link

Destructive Changes

There are no destructive changes.

Copy link

github-actions bot commented Oct 3, 2024

Checklist for reviewers ☑️

All references to "You" in the following text refer to the code reviewer.

  • Is this pull request written in a way that is easy to read from a third-party perspective?
  • Is there sufficient information (background, purpose, specification, algorithm description, list of disruptive changes, and migration guide) in the description of this pull request?
  • If this pull request contains a destructive change, does this pull request contain the migration guide?
  • Labels of this pull request are valid?
  • All unit tests/integration tests are included in this pull request? If you think adding test cases is unnecessary, please describe why and cross out this line.
  • The documentation for this pull request is enough? If you think adding documents for this pull request is unnecessary, please describe why and cross out this line.

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.

1 participant