More general initialization of state from command#2294
Conversation
all tests pass! includes some refactoring that isn't strictly needed
christophfroehlich
left a comment
There was a problem hiding this comment.
Your description seems fair for me. Can you please also improve the parameter description in the yaml file, and add a line to the release_notes?
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2294 +/- ##
==========================================
+ Coverage 85.16% 85.19% +0.03%
==========================================
Files 145 145
Lines 15407 15394 -13
Branches 1322 1322
==========================================
- Hits 13121 13115 -6
+ Misses 1797 1794 -3
+ Partials 489 485 -4
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
saikishor
left a comment
There was a problem hiding this comment.
Is there a way to add a test to this usecase?
|
Thanks for the quick replies everyone! In thinking about these features more, I wonder whether it really makes sense to initialize |
|
Not sure about the CI failures, looks related to this but not sure if I did something wrong or need to somehow update something to get CI to pass. |
tl;dr not related ;) You are right. I already released ros2_control, but the build farm had an outtake this week and the binaries are still not available on ros-testing. Windows build fails because of the removal done by #2016 until we have released this. |
add link to PR Co-authored-by: Christoph Fröhlich <christophfroehlich@users.noreply.github.com>
|
@destogl since it seems you wrote the initial implementation, maybe you want to check that this logic change makes sense |
|
should I rebase on master? or will that trigger needless CI and/or dismiss your approval? |
|
Please never do a rebase if there was already any review in the PR, see the hint in the PR template you certainly have read ;) |
|
friendly ping in hopes of a review @saikishor |
saikishor
left a comment
There was a problem hiding this comment.
Apologies for not getting to this PR before
The changes in general look good to me. Just 2 minor nitpicks.
Let me know what you think.
Co-authored-by: Sai Kishor Kothakota <saisastra3@gmail.com>
|
@saikishor thanks! Changes included. |
|
I clicked "rerequest review", since it looked like the new commit means old approvals are dismissed. Sorry if that generated extra emails/notifications! |
|
@saikishor is there a bot that can backport to Jazzy/Kilted...? I am planning to do a backport to Humble but I am pretty sure that has to be manual since the code has changed a lot. |
I think there shouldn't be problem backporting it, as it only affects the case when the interface is only available as a command but not as a state. @christophfroehlich what do you think? |
|
Hmm slight correction -- I believe it effects also the case where you have the interface only as state and not command. That's how I discovered this in the first place. At least in humble, if you had |
|
do you need it on humble? if it is too much effort, I would not backport it |
|
I would like it in humble. It shouldn't take more than an hour for me to do the backport. My current workaround, unbelievably, is to remove my velocity state interface 😆 Compiling rolling on humble is possible, yes, but I think I wouldn't do it. It involves also bringing many other repos (ros2 control, ros2 control cmake, pal statistics, ...) from rolling as well. |
Description
When operating a robot which does not always track desired positions accurately (e.g. torque controlled) you may sometimes want the JTC to initialize based on the current/latest command from the hardware interface, rather than the current measured state. This will ensure the "command" is unchanged when activating the controller. Otherwise, if you use measured state, the arm can move unexpectedly (usually, it will droop).
To handle this, JTC has
set_last_command_interface_value_as_state_on_activationparameter. However, it's implementation is weird to me. Specifically,bool read_state_from_command_interfaceswill returnFalseif you have avelocitystate interface but novelocitycommand interface. For me, this restriction seems unnecessary. You simply should need a state interface for eachcommandinterface, but not the other way around. Extra state interfaces are simply ignored.Explanation of changes
Now, we always first call
read_state_from_state_interfacesinon_activate.Then, if the parameter is set, we update this state from the command interfaces.
Thus, we renamed
read_state_from_command_interfacestoupdate_state_from_command_interfaceand change its behavior to only update fields that have command interfaces.To minimize code duplication, I refactored out
interface_has_valuesandassign_point_from_command_interface. This is the reason we have more deletions than additions :)Also I updated the tests to reflect the desired change in behavior.
Fixes # (issue)
https://discourse.openrobotics.org/t/handling-missing-command-interfaces-in-read-state-from-command-interface/53551
Is this user-facing behavior change?
Yes!
Did you use Generative AI?
A bit of copilot autocompletion.