Low level joint access for ROS control hardware interface

[uahic]

I am currently working on the Doosan ROS Control HW Interface to get the dsr_joint_trajectory_controller running. However, it seems that there are only APIs in Python and C++ available that offer "motion primitives" with interpolation (e.g. moveJ, moveJAsync).

The ROS Control HW-Interface is expecting low-level access to the joint-value buffers on the robot in a streaming-like fashion, in particular without having the robot to do interpolations on its own since the ROS-Controllers are expected to do this work.

Do you see any chance for me to send target joint values using the current interfaces that the m1013 is offering but without interpolation? If this is not the case, do you think this is a feature that could be provided by Doosan in the near future?

Thank you very much for your help!

[doosan-robotics]

Doosan Robotics does not provide an interface to command joints at a low level.

The API provided by Doosan ROS package communicates with the robot controller through TCP/IP communication. Due to the limitations of TCP/IP communication speeds, even if we provide an interface to command the joint at a low level, it is not a satisfactory performance level.

For satisfactory performance, we must fundamentally change the way we communicate, but there are limitations in ROS1 and our SW architecture.

In developing ROS2, we will consider this issue in depth.

[gavanderhoorn]

@doosan-robotics wrote:

For satisfactory performance, we must fundamentally change the way we communicate, but there are limitations in ROS1 and our SW architecture.

I respect your choice to not offer more performant interfaces right now, but it is perfectly possible to implement a ros_control based driver in ROS 1 capable of hard real-time, up-to-kHz low-level access to an external motion interface. ROS 2 is not needed for this, nor will it solve all challenges related to such performance.

Various drivers for various robot brands (and other types of hw) prove this.

What shouldn't be attempted is to use regular ROS 1 topics to carry control and state data for which determinism, minimum communication delays, jitter and bandwidth are important.

[uahic]

I agree with @gavanderhoorn , the ROS HW-Interface is purely intendent to access the robot via low-level protocols (transmitted through sockets). A low-level TCP/IP socket is not dramatically slower than a UDP socket and for the communication between a controller and hardware I think TCP is the right choice to ensure package delivery

[doosan-robotics]

I agree with the idea that TCP / IP communication can provide a sufficiently low level interface in a ROS1 environment. (not a problem with ROS1) However, it is currently difficult to provide this feature to users due to our policy and SW architecture. Even if this function is provided, Doosan Robot cannot be controlled at optimum performance. Optimal control of Doosan robots is our mission.

[doosan-robotics]

ROS users can be classified into two types. The first type is a robot developer using ROS, and the second type is an engineer who wants to develop robot application easily and quickly using ROS. We are focusing on the second type of user.

[gavanderhoorn]

I agree with the idea that TCP / IP communication can provide a sufficiently low level interface in a ROS1 environment. (not a problem with ROS1)

If you're considering adding such an interface, I'd suggest using UDP instead though.

Even if this function is provided, Doosan Robot cannot be controlled at optimum performance. Optimal control of Doosan robots is our mission.

I understand. It does preclude using your robots for certain applications for which they are very interesting.

KUKA, UR, ABB, Mitsubishi and others appear to be able to focus on quality of their products while still offering a performant external motion interface.

ROS users can be classified into two types. The first type is a robot developer using ROS, and the second type is an engineer who wants to develop robot application easily and quickly using ROS.

There would appear to be a third type of user (and possibly many more): those that would like to create applications which are not possible with the standard high-level programming interfaces.

We are focusing on the second type of user.

that's fair, but then it would seem somewhat strange to offer a ros_control hardware interface which purports to support the regular types of (low-level) controllers.

[doosan-robotics]

Thank you for your good feedback. I will use your feedback when setting future development directions. We look forward to your continued interest in our ROS package.

[gavanderhoorn]

Just a clarification: please don't take my comments as criticism. It's perfectly OK for you to not offer certain interfaces.

I just wanted to post a few responses to some of the comments you posted @doosan-robotics.

[doosan-robotics]

We are currently developing a low level interface with 1ms.

[AngeloIapichino]

@doosan-robotics any updates? Is it possible to share with us your develpment roadmap? I want to schedule some activities using your robot. Actually our m0609 is gathering dust in a dark corner at our lab.

@gavanderhoorn and @uahic do you find any solution? Are you waiting doosan as well?

Thank you in advance for answering

[doosan-robotics]

We plan to complete the development of a 1ms low-level interface within this year.

[gavanderhoorn]

@doosan-robotics: have you made any progress you can share in the meantime?

[gavanderhoorn]

Friendly ping

[NJBlackman]

Is there any update to using the low-level interface with ROS 1?