offinliu
commented
2 hours ago Hi @tjeerdvandijk,
This function exist. Refer to https://github.com/Mitsubishi-Electric-Asia/melfa_ros2_driver/blob/humble/doc/melfa_ros2_driver.md, Example 4.2. You can use the service to write directly. However, there are some limitations to ROS services.
There are two ways to implement this depending on the type of gripper.
1. gripper with no return input
- MELFA Hand I/O is not limited to output:900. input:900 is commonly used as a gripper state return input. However, not all grippers have this function. Such grippers are open loop.
- I would recommend using the topic to write to hand_io and use the service to monitor address output:900 with "READ_OUT". This will allow the flexibility of ROS2 topics especially in OOP nodes.
- logic: MELFA ROS2 sends a packet with 1. a write command to output:900, 2. a request to read data at output:900.
- logic: MELFA robot controller receives this packet, modifies output:900, reads output:900 after it is written and sends a packet with the latest state of output:900. All done within 1 control cycle which is 3.5ms. If CR800-Q is used, it's 7.11ms.
- you can find this implementation in https://github.com/Mitsubishi-Electric-Asia/melfa_ros2_masterclass_2024/blob/main/melfa_rv5as_masterclass/src/plc_.cpp,
- line 101 void gripper_state_callback(const melfa_msgs::msg::GpioState& msg) monitors the hand states.
- line 163 void gripper_command_callback(const melfa_masterclass_msgs::msg::GripperState& msg) writes to MELFA hand_io.
2. gripper with return input
- in this case, you will read from input:900 using "READ_IN".
- the logic is the same but the reply packet sends the state of input:900 instead.
Only no.2 ensures a close loop control on MELFA gripper.
Please let me know if this helps.
Problem:
Currently, the hand/GPIO state can only be controlled through a ROS topic, which has some limitations. Specifically:
Lack of Confirmation: When publishing a command to change the hand/GPIO state, there is no built-in mechanism to confirm that the command was successfully received and acted upon. This is an inherent limitation of ROS topics, even with optimal QoS settings. In contrast, ROS services will return a confirmation, allowing the caller to know whether the command was successfully processed.
Safety Concerns: The lack of confirmation has its risks. For example, if the gripper is not confirmed to be in the desired state, it may attempt to pick up an object while closed, which could result in hardware damage.
Proposed Solution:
To give developers more flexibility and ensure safer operation, I suggest adding a service for changing the hand/GPIO state in addition to the existing topic. This would allow developers to choose the most suitable method based on their requirements.