Fix OP error

[alesof]

Joints are not in OP state and controller is sending things. The approach is just a wait proportional to the number of drives, to wait for all OP.

[alesof]

A cleaner way would be to wait a log status instead of a defined number of sec.

[ZeroErrControl]

Joints are not in OP state and controller is sending things. The approach is just a wait proportional to the number of drives, to wait for all OP.
I attempted to address this issue by modifying the underlying code of ethercat_driver_ros2. The results of these attempts are detailed in the [following sections] (ICube-Robotics/ethercat_driver_ros2#154).

[ZeroErrControl]

Joints are not in OP state and controller is sending things. The approach is just a wait proportional to the number of drives, to wait for all OP.

Joints are not in OP state and controller is sending things. The approach is just a wait proportional to the number of drives, to wait for all OP.

Some users reported issues where the ethercat_ros2 interface could not bring eRob into the OP (Operational) state. To address this, I have provided a solution in this project. Please refer to the detailed steps here: Solution Link.

I have tested this solution on a six-axis robotic arm, and the results are as follows:

• Successfully entered DC mode: The EtherCAT Distributed Clock (DC) is functioning correctly.
• Successfully entered OP state: All EtherCAT slave devices transitioned to the operational state, and the robotic arm operates as expected.
  Feel free to try it out and share your feedback! If you encounter any issues during implementation, please open an issue here, and I’ll assist you as soon as possible.