Added IO Gripper Control and Configuration Messages, Services, and Actions #164
Conversation
github-actions
bot
requested review from
ARK3r,
arne48,
bijoua29,
christophfroehlich,
destogl,
livanov93 and
mcbed
control_msgs/action/Gripper.action
Outdated
| @@ -0,0 +1,6 @@ | |||
| bool open | |||
There was a problem hiding this comment.
What if you want to control the percentage of the closure?
There was a problem hiding this comment.
That's a good idea. I will update it.
There was a problem hiding this comment.
@saikishor in this case you cannot control the percentage of the closure. As there are IOs controlled behind it and usually pneumatic gripper that might have different states, but those are then different IOs, in most cases those have only 2 states, open and close and not a chance to detect anything in between.
What here might be interesting, that we have different states besides open and close as we have 2 closed states and then we can set the target state of the gripper - bit this smells a lot to the configuration, so I am not sure if we should go this way, but rather we should keep only two states that we can command: open and close.
control_msgs/msg/IoGripperSensor.msg
Outdated
| @@ -0,0 +1 @@ | |||
| bool state | |||
There was a problem hiding this comment.
If it's just state, why not a percentage of closure instead of binary state
There was a problem hiding this comment.
We don't know the percentage, usually don't. We can typically have discrete sensors for open/close, but not other sensors. Assuming that there is a case where this can be detected we would need to add additional interface for it. So I would wait until we have this use-case.
control_msgs/srv/SetConfig.srv
Outdated
| @@ -0,0 +1,4 @@ | |||
| string config_name | |||
There was a problem hiding this comment.
How do you configure just based on string?. I think It is missing some documentation
There was a problem hiding this comment.
@sachinkum0009 please add in general documentation about all fields in the message. Add those as comments at the begin of the message.
There was a problem hiding this comment.
general documentation about all fields in the message added.
There was a problem hiding this comment.
In my experience almost every single field in messages should be documented thoroughly otherwise we are asking for trouble.
uint8 state should be documented further by adding an "enum" to the message, of states to represent.
I'd also like some justification as to why this is needed and cannot be covered by existing messages.
control_msgs/action/Gripper.action
Outdated
There was a problem hiding this comment.
This custom Gripper action maybe should be renamed to IOGripperCommand.
@bmagyar the reason to have a separate action here is that this kind of gripper has only open/close states, and nothing can be controlled much. Usually, those are the pneumatic ones so some cylinders are moving somehow, but we can not control intermediate states, i.e., "positions".
Looking at the existing Actions and having, e.g., JointState as input to the action (as done in ParallelGripperAction could be possible, but confusing and inconvenient. Possibly as a secondary interface, but as of now I don't see the usability of it, as we would command something implicitly that we cannot control.
There was a problem hiding this comment.
Thanks for the suggestion. I have updated the interface names.
There was a problem hiding this comment.
@bmagyar
There is no similar Action as of now. The IO Gripper might be quite complex, to have different configurations that are independent of open/close functionality. For example, configuration to grasp narrower and wider objects. In this case, the configuration has to be set before the grasping (and planning) as the collision model of the gripper changes by moving a degree of freedom through configuration.
Independently of configuration, the open/close stays the same, i.e., moving some other joints, but overall kinematics changes depending on the gripper configuration.
control_msgs/srv/SetConfig.srv
Outdated
|
@sachinkum0009 Can you fix the pre-commit? |
|
Sorry forget to run pre-commit. |
destogl
changed the title
| @@ -0,0 +1,7 @@ | |||
| # Name of the gripper open close state. Note that it can have multiple "closed" states. If empty, then transition is happening and check the state of the transition. | |||
| string open_close | |||
There was a problem hiding this comment.
Can this be clarified. Looking at this message I expect the contents of this string to be open or close. If it's that, it could be number of some kind. But I think I'm misinterpreting it. Maybe open_close_configuration and naming the other string in the message current_configuration
There was a problem hiding this comment.
The complexity is here that we don't know how man “closed” states there are. Some grippers has multiple ones depending on the object they actually grasp or when grasp is failed to determine this with sensors. For the configuration we are using strings, so it makes sense to have it here as a string too.
|
This PR is stale because it has been open for 45 days with no activity. Please tag a maintainer for help on completing this PR, or close it if you think it has become obsolete. |
configuration of a gripepr for gripper_io_controller
Co-authored-by: Dr. Denis <[email protected]>
Co-authored-by: Dr. Denis <[email protected]>
Co-authored-by: Dr. Denis <[email protected]>
|
This PR is stale because it has been open for 45 days with no activity. Please tag a maintainer for help on completing this PR, or close it if you think it has become obsolete. |
There was a problem hiding this comment.
Something in here doesn't seem right. I understand that there's a plethora of states that the gripper can be in, and they all fall under engaged or disengaged. There's two design issues I'm seeing.
- In the command action you're requesting engage/disengage but in the result you don't know which kind of engage/disengage the gripper ends up in.
GPIOToolControllerStatehas a string state. How do you know if that's an engaged or disengaged state?
The solution to both might be breaking down the way the engaged state is described into a main state (engaged/disengaged) and the variant state.
Lastly, can we get some links to the implementation or an example of the problem trying to be solved here?
Co-authored-by: Xavier Guay <[email protected]>
Co-authored-by: Xavier Guay <[email protected]>
|
This pull request is in conflict. Could you fix it @sachinkum0009? |
|
So here the answers:
This is good, thanks, I have added this as string output. And you always know which one you end up in because you request a certain state so that either succeeds or not. But this is the logic of the controller itself. (see ros-controls/ros2_controllers#1439)
The user is defining these states in the controller, so they will know the meaning of each state. As this is not only for grippers, there is a freedom for users to define the names. Having this solved with a boolean or similar is a problem, as there are multiple engaged states possible (in case of gripper empty or full).
I don't understand what you mean here.
See the PR linked above. Documentation is missing, but the test controllers configurations are given for the two use-cases. There is much more use basically; you can control anydevice that is controlled using GPIOs (digital or analog). |
This pull request introduces new msgs, srvs and actions for control_msgs package. These changes are aimed at enhancing gripper control and configuration functionality.