Added IO Gripper Control and Configuration Messages, Services, and Actions #164
Conversation
configuration of a gripepr for gripper_io_controller
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. |
| # - IDLE (0): The reconfiguration process is idle, not performing any action. | ||
| # - FIND_CONFIG (1): Finding the configuration settings. | ||
| # - SET_COMMAND (2): Setting the command based on the configuration. | ||
| # - CHECK_STATE (3): Checking the state after setting the command. |
There was a problem hiding this comment.
Please adjust as above.
Also, do we really need “find” state, I mean this takes a few microseconds so we will never get this feedback or see this. Or am I understanding something wrong?
There was a problem hiding this comment.
Yes, I agree the "find" state should not take long and can be removed.
Co-authored-by: Dr. Denis <[email protected]>
Co-authored-by: Dr. Denis <[email protected]>
Co-authored-by: Dr. Denis <[email protected]>
destogl
changed the title
This pull request introduces new msgs, srvs and actions for control_msgs package. These changes are aimed at enhancing gripper control and configuration functionality.