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

adjust example 1 to use hardware_spawner. #277

Conversation

mamueluth
Copy link
Member

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:

controller_manager:
  ros__parameters:
    ......
    configure_components_on_start:
      - ""
    activate_components_on_start:
      - ""

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)

@christophfroehlich
Copy link
Contributor

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.

@mamueluth
Copy link
Member Author

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...
Don't see much of a burden added to the user here. The demo stays more or less the same and the only thing to realize for a user is that there is a way of activating the hw.

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.

@christophfroehlich
Copy link
Contributor

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? ;)

@christophfroehlich
Copy link
Contributor

christophfroehlich commented Apr 29, 2023

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 on_deactivate method is called with the expected output in the terminal, but after the deactivation read and write is still called. Why? Is this an issue of this hw-interface or is this not implemented properly in ros2_control?

Copy link
Contributor

@christophfroehlich christophfroehlich left a 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.

@destogl
Copy link
Member

destogl commented May 1, 2023

The on_deactivate method is called with the expected output in the terminal, but after the deactivation read and write is still called. Why? Is this an issue of this hw-interface or is this not implemented properly in ros2_control?

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

@destogl
Copy link
Member

destogl commented May 1, 2023

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.

Yes, exactly, and also add notes about this into migration notes. I am tending toward disabling automatic activation in Iron.
The user-base will not be huge for the moment and we have the opportunity to test it well.

@christophfroehlich
Copy link
Contributor

christophfroehlich commented May 2, 2023

The on_deactivate method is called with the expected output in the terminal, but after the deactivation read and write is still called. Why? Is this an issue of this hw-interface or is this not implemented properly in ros2_control?

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

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.

@destogl
Copy link
Member

destogl commented May 3, 2023

Let simplify this:

controller_manager:
  ros__parameters:
    hardware_components_state_after_start:
      not_loaded:
        - ""
      unconfigured:
        - "arm1"
        - "arm2"
      inactive:
        - ""

@christophfroehlich
Copy link
Contributor

Let simplify this:

controller_manager:
  ros__parameters:
    hardware_interface_state_after_start:
      not_loaded:
        - ""
      unconfigured:
        - "arm1"
        - "arm2"
      inactive:
        - ""

do you mean hardware_interfaces or hardware_components here? I think the latter, and we should be more precise in our docs about this. Maybe we should even rename the hardware_interfaces class to hardware_components, thinking of the difference of

ros2 control list_hardware_components
ros2 control list_hardware_interfaces

@destogl
Copy link
Member

destogl commented May 3, 2023

you are right! We should add this to discussion agenda and make this clear

@destogl
Copy link
Member

destogl commented Aug 9, 2023

we add this functionality in the multi robot examples #334#187

@destogl destogl closed this Aug 9, 2023
@destogl destogl deleted the example_1_hardware_spawner branch August 9, 2023 17:45
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.

3 participants