-
Notifications
You must be signed in to change notification settings - Fork 188
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
adjust example 1 to use hardware_spawner. #277
adjust example 1 to use hardware_spawner. #277
Conversation
I'm not sure about the plans on this: will the old way of activating still be possible in the future? If yes, i wouldn't make this detail to be the default of the very first example. Another issue: Will this work with humble release too? if no -> we have to generate a humbe branch here. |
I think the plan is to adjust every example. As far as I know, the old way of activating the hardware is not going to be supported anymore in the future. I don't know when this is going to happen though... I don't think back porting is planned but @destogl should know more about this. You are probably right with your concerns about the humble branch. |
Ok, then I'm fine with your changes. Should we change that for all examples at once? And I'm not reluctant to create a humble branch here, especially because this repo is not released as package. Could you please comment on ros-controls/control.ros.org#77, what else I have to do to get the sphinx doc working? ;) |
I remembered #239 and tried to deactivate the hw_interface with $ ros2 run controller_manager hardware_spawner RRBot --configure
[INFO] [1682761448.258076586] [hardware_spawner]: configured component 'RRBot'. Hardware now in state: lifecycle_msgs.msg.State(id=2, label='inactive'). The |
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 think we should add a section on that topic in the docs as well, e.g. why and how to activate/deactivate hw components after spawning.
This is a feature for now. We don't have support for configuration interfaces yes, so some time ago, we decided to make those calls also in inactive state. The reason for this is the requirement to set some configuration interface before activation. This issue is related to ros-controls/roadmap#51 |
Yes, exactly, and also add notes about this into migration notes. I am tending toward disabling automatic activation in Iron. |
I see, this makes more sense now. Maybe we should go on with the proposal from ros-controls/roadmap#51 , ros-controls/ros2_control#931 because with the proposed changes of the hw component lifecycle this will get to attention (and confuse) more people. |
Let simplify this:
|
do you mean ros2 control list_hardware_components
ros2 control list_hardware_interfaces |
you are right! We should add this to discussion agenda and make this clear |
Example of how to use the new way of configuring/activating the hardware.
One should note however: Currently the hardware gets still activated by default (legacy support). Only workaround would be to add something like:
to the
example_1/bringup/config/rrbot_controllers.yaml
file. Which I think is kind of ugly and miss leading. Would not do this as hardware_spawner prints successful activation anyways... (returns current state of hardware which is activated)