-
Notifications
You must be signed in to change notification settings - Fork 327
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
[JTC] Add Parameter to Toggle State Setting on Activation #1231
[JTC] Add Parameter to Toggle State Setting on Activation #1231
Conversation
Hi, I wanted to kindly ask if there’s a chance for this pull request to be reviewed. Any feedback would be greatly appreciated. Thank you! |
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.
Thank you!
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.
Makes sense. Please just add a tiny note in the https://github.com/ros-controls/ros2_controllers/blob/master/doc/release_notes.rst
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.
Thanks for the fix!
Wait, I am not sure about this. Can you detail the scenario more. Are you using open loop? |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1231 +/- ##
==========================================
+ Coverage 80.34% 80.36% +0.01%
==========================================
Files 105 105
Lines 9384 9388 +4
Branches 826 825 -1
==========================================
+ Hits 7540 7545 +5
Misses 1570 1570
+ Partials 274 273 -1
Flags with carried forward coverage won't be shown. Click here to find out more.
|
@destogl We are not using open-loop control. We are creating a closed-loop controller called
Scenario:
|
…ctivation to release_notes. Updated the parameters.yaml description to match the same wording.
@christophfroehlich |
@christophfroehlich , are we good? |
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.
LGTM
@bmagyar @christophfroehlich |
f96d2fc
into
ros-controls:master
@Mergifyio backport iron humble |
✅ Backports have been created
|
* [JTC] Add param to setting last command interface value as state on activation * [JTC] add a note about set_last_command_interface_value_as_state_on_activation to release_notes. Updated the parameters.yaml description to match the same wording. --------- Co-authored-by: Bence Magyar <[email protected]> Co-authored-by: Christoph Fröhlich <[email protected]> (cherry picked from commit f96d2fc)
* [JTC] Add param to setting last command interface value as state on activation * [JTC] add a note about set_last_command_interface_value_as_state_on_activation to release_notes. Updated the parameters.yaml description to match the same wording. --------- Co-authored-by: Bence Magyar <[email protected]> Co-authored-by: Christoph Fröhlich <[email protected]> (cherry picked from commit f96d2fc) # Conflicts: # joint_trajectory_controller/src/joint_trajectory_controller_parameters.yaml
) * [JTC] Add param to setting last command interface value as state on activation * [JTC] add a note about set_last_command_interface_value_as_state_on_activation to release_notes. Updated the parameters.yaml description to match the same wording. --------- Co-authored-by: Bence Magyar <[email protected]> Co-authored-by: Christoph Fröhlich <[email protected]> (cherry picked from commit f96d2fc) Co-authored-by: Kenta Kato <[email protected]>
This pull request introduces a new parameter in the JointTrajectoryController that enables toggling whether the last command interface value should be set as both the current_state and last_commanded_state upon activation.
Motivation
Consider a scenario where there is a transition from a JTC to another controller and back to a JTC. Due to the implementation specifics of the intermediary controller, it is possible that the command interface values from the first JTC remain. This can lead to dangerous situations where, upon reactivation, the second JTC inadvertently uses these stale command values to command the hardware.
To mitigate this risk, I have added an option within the JTC that ensures command values are reliably reset to reflect the current state upon activation, enhancing system safety.