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

“Configuration/Movement/Safety-critical" interfaces definition #51

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

destogl
Copy link
Member

@destogl destogl commented Feb 9, 2022

resolves #50

Please add your comments as review.

@destogl destogl self-assigned this Feb 9, 2022
@destogl destogl requested a review from bmagyar February 9, 2022 17:48
@destogl destogl changed the title “"onfiguration/Movement/Safety-critical" interfaces definition “Configuration/Movement/Safety-critical" interfaces definition Feb 9, 2022
@gavanderhoorn
Copy link

I suggest to be careful labelling something as safety-critical or suitable for safety critical situations.

It implies quite a few things, and I don't believe ros2_control is currently really suitable for such use-cases.

@christophfroehlich
Copy link
Contributor

A little off-topic but relevant here: Is there any documentation about the lifecycle implementation within ros2_control which I couldn't find? Up to now it was not clear to me that read/write methods of the hardware components are called in inactive state, too.

I understand now the motivation here, but I'm not sure if this really solves the problem for every hardware architecture (but honestly, I do not have a lot of experience with industrial robots with ROS):

  • if the resource manager deactivates the handles only, no one guarantees that there isn't still "energy flow" from the last command sent, without explicitly deactivating power electronics etc.
  • to only deactivate new commands being sent to the hardware, one could do this already by implementing this into the read/write methods of the hardware components, depending on its lifecycle status?
  • if some global enable flag (power electronics..) is necessary, one would have to implement this in the hardware component's methods anyways. Or should we extend this proposal with default values for the commands, depending on the components lifecycle?

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.

“Configuration/Movement/Safety-critical" interfaces definition and use
3 participants