I don't know what the current status is, but there is some work ongoing to add "asynchronous controller" support to ros2_control. See ros-controls/ros2_control#806, ros-controls/ros2_control#932, ros-controls/ros2_control#927 and ros-controls/roadmap#56 (this last one documents/describes the intended functionality). Perhaps you could comment on them or try the functionality (as much as it's functional at the moment).

Having written that, I'm curious what your motivation is for using ros2_control with RMI. The protocol has quite some limitations when it comes to real-time control, which is primarily what ros2_control is targetting.

If you're still mostly going to use event-based interaction (ie: read/write IO, start/stop programs), [..]

[..] a stand-alone node would work just as well it seems. The ROS API (ie: topics, services, actions, etc) wouldn't be any different (same message types and semantics), you just wouldn't be (easily) able to reuse the ros2_control interface abstractions.

I ask because wrapping the RMI interface in a ros2_control set of interfaces does not immediately allow reuse of existing controllers (due to the difference in operational constraints/assumptions between RMI and ros2_control), which would seem to reduce the advantage of using ros2_control (perhaps except leaving the use of a semi-established framework, and the ability to (re)use your own, in-house, written controllers).

Note btw the PRs linked in my first comment are not a necessity to implement communication with an 'asynchronous' system. They might just make it more consistent / embed your work in a larger framework.

Thank you for your quick reply. I am new to ROS and the FANUC world and maybe I am in wrong, but the idea to use RMI is that such protocol, probably, will be the standard way to control FANUC robots from a third party software, moreover if I have correctly understood, apart the real-time aspect, ros2_control will be the standard way to interface the hardware components to ROS2, is it? So, I am trying to plan my work in a way that will be easily to maintain in the following future, and avoid the risks of obsolescence, but seeing your comments, maybe I need to look into the matter better.

the idea to use RMI is that such protocol, probably, will be the standard way to control FANUC robots from a third party software

you can find my comments (and opinion) on RMI in other Q&As on this site. In short: RMI is fine for high(er)-level coordination like interaction with a FANUC controller. It's not suited for actual real-time control (by which I mean: high-bandwidth, low-latency, low-jitter with control over position, velocity and acceleration every N milliseconds).

That's the kind of control ros2_control is mostly used for right now.

FANUC's Stream Motion (J519) would be the option for that, but that's hard to buy from them (outside the US).

And that's why I wrote: "due to the difference in operational constraints/assumptions between RMI and ros2_control".

RMI is essentially a drip-feed for TP programs. ros2_control tries (to be precise: many of its controllers try) to accurately control state of your robot at X Hz. Those two are rather different. [..]

[..] I just wanted to draw attention to the apparent gap that exists between "execute a TP program please which I feed you line-by-line" vs "let me control position, velocity and acceleration of all joints in real-time at tenths or hundreds of Hz".

That doesn't mean you can't use ros2_control with RMI. You'll just have to carefully construct your hardware components and be aware of the limitations.

ros2_control will be the standard way to interface the hardware components

this will probably depend on the kinds of "hardware components" you'd like to interface with. Cameras are one good example where you probably wouldn't use ros2_control. For robots, it would probably make sense, but it depends heavily on the kinds of interfaces you have to those robots.

Personally, I'm not sure RMI is a good fit. At least not with the standard ros2_control controllers.

Edit: see https://github.com/ros-industrial/fanuc/discussions/339 for a recent-ish discussion.

You gave me a clear overview.

FANUC's Stream Motion (J519) would be the option for that, but that's hard to buy from them (outside the US).

I will make an attempt whit Fanuc about the J519.

The application I need to develop is similar to a pick and place with a variable starting point, a fixed target one and steady obstacles in the middle, there is only a stage were the operator will be free to move the payload by means of a joystick and where I need an higher update rate of the hardware status. However, I think I can avoid collisions limiting the maximum speed during this latter stage.

At this point I think I can start with ros_control and the "standard" fanuc driver and lather move to a more customized solution to improve the smoothness, maybe uploading the entire path with RMI and playing with CNT and CR.

Thank you again

I will make an attempt whit Fanuc about the J519.

good luck. I don't expect them to have changed their minds.

I would also probably say that for what you describe, J519 would not be needed. For simple jogging, RMI should suffice.