-
Notifications
You must be signed in to change notification settings - Fork 310
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
[CLI] Add set_hardware_component_state
verb
#1248
[CLI] Add set_hardware_component_state
verb
#1248
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1248 +/- ##
===========================================
- Coverage 75.51% 48.02% -27.49%
===========================================
Files 41 41
Lines 3328 3525 +197
Branches 1921 1912 -9
===========================================
- Hits 2513 1693 -820
- Misses 421 442 +21
- Partials 394 1390 +996
Flags with carried forward coverage won't be shown. Click here to find out more. |
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.
Thanks a lot.
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.
Few smaller comments and one bigger to discuss
ros2controlcli/ros2controlcli/verb/set_hardware_component_state.py
Outdated
Show resolved
Hide resolved
if args.state == "inactive": | ||
inactive_state = State() | ||
inactive_state.id = State.PRIMARY_STATE_INACTIVE | ||
inactive_state.label = "inactive" | ||
|
||
if matched_hardware_components.state.label == "unconfigured": | ||
response = set_hardware_component_state( | ||
node, args.controller_manager, args.hardware_component_name, inactive_state | ||
) | ||
if not response.ok: | ||
return ( | ||
"Error configuring hardware component, check controller_manager logs" | ||
) | ||
|
||
print( | ||
f"Successfully set {args.hardware_component_name} to state {response.state}" | ||
) | ||
return 0 | ||
|
||
elif matched_hardware_components.state.label == "active": | ||
response = set_hardware_component_state( | ||
node, args.controller_manager, args.hardware_component_name, inactive_state | ||
) | ||
if not response.ok: | ||
return "Error stopping hardware component, check controller_manager logs" | ||
|
||
print( | ||
f"Successfully set {args.hardware_component_name} to state {response.state}" | ||
) | ||
return 0 | ||
|
||
else: | ||
return ( | ||
f'cannot put {matched_hardware_components.name} in "inactive" state ' | ||
f"from its current state {matched_hardware_components.state}" | ||
) | ||
|
||
if args.state == "active": | ||
if matched_hardware_components.state.label != "inactive": | ||
return ( | ||
f"cannot activate {matched_hardware_components.name} " | ||
f"from its current state {matched_hardware_components.state}" | ||
) |
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 logic is also written in the ResourceManager, should we just let any request come through and then return here error or success with a message. Not sure if doubling logic is good for maintainability, but it is good for efficiency. Still, not sure that this degree of efficiency is needed here.
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.
I also think that we shouldn't duplicate the logic,
But what I want to avoid is something like with other controller-manager services, where one log-line is an error from controller-manager but the service returns OK. I'll have a look if response.ok
is fine for giving useful feedback with the CLI
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.
I removed the logic now..
d8bf1d1
to
5e42962
Compare
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.
Just a minor minor fix
Co-authored-by: Dr. Denis <[email protected]>
Co-authored-by: Mateus Menezes <[email protected]>
83eb0da
to
6fa3492
Compare
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
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!
Co-authored-by: Dr. Denis <[email protected]> Co-authored-by: Mateus Menezes <[email protected]> (cherry picked from commit a902e27)
Co-authored-by: Dr. Denis <[email protected]> Co-authored-by: Mateus Menezes <[email protected]> (cherry picked from commit a902e27)
Co-authored-by: Dr. Denis <[email protected]> Co-authored-by: Mateus Menezes <[email protected]> (cherry picked from commit a902e27) Co-authored-by: Christoph Fröhlich <[email protected]>
Co-authored-by: Dr. Denis <[email protected]> Co-authored-by: Mateus Menezes <[email protected]> (cherry picked from commit a902e27) Co-authored-by: Christoph Fröhlich <[email protected]>
I updated the hardware lifecylce demo as part of the multi robot example ros-controls/ros2_control_demos#417 and realized that there is no cli verb for changing hardware lifecycle.
This PR adds the verb
set_hardware_component_state
to our CLI.