Making an existing Python program work as a ROS 2 node: Is there an easier way?

Question

I have a web backend written in Python—call it backend—that I would like to function as a ROS 2 node. That backend has its own dependencies on Python versions and libraries, its own virtualenv (it's managed by Poetry), and I don't see it as a possibility to change it into a ROS 2 package built using colcon and thus, unless I misunderstand something, switch it to whatever versions of Python packages the ROS 2 installation happens to mandate.

Now, nevertheless, I'd need that backend to effectively function as a ROS 2 node, publishing a topic and subscribing a topic.

My current plan is to make a separate ROS 2 package, call it backend_helper, with an executable that backend executes and communicates with, probably via standard input and output, using something simple like JSON.

This does seem a bit involved for what I want to do. Are there other solutions? Has someone done something like this?

I know rosbridge exists; in addition to not running currently on jazzy without changes, a full JSON serialization of the ROS protocol seems like an overkill and a liability for my simple use case, unless maybe it was very mature and had a good Python client library.

Answer 1

My current plan is to make a separate ROS 2 package, call it backend_helper, with an executable that backend executes and communicates with, probably via standard input and output, using something simple like JSON.

This is a pretty good way to start off with, without having to rework much of your backend code. You can work with JSON-formatted strings, passed in as std_msgs.String messages, and then parse the string to get back the JSON objects.

If you want to offload the communication with the external world and the handling of specific functions related to your backend, I propose an architecture where each general behaviour of your backend gets its own handler(dedicated node, which can have long running tasks), and all of these "handlers" are connected to a "bridge" node which simply receives the incoming JSON requests, and forwards them to the respective handler. This architecture helps to abstract a lot of the functionality from the end user, while offering the modularity to choose what form of communication you want to carry out (HTTP/Serial/Websocket, etc.)