Global Message Subscription (akin to ROS) #54
Replies: 1 comment
-
I would argue that the current system enforces clear dependency management where you can easily see what each module needs and processes. When we started with RoSys we had a
True. Do we have an example where this is problematic and how it would improve with a global message subscription?
I would like to not mix these topics. RoSys is based on NiceGUI/FastAPI/Starlette/Asyncio and by design uses a single process with event loop concurrency. That makes most coding very easy because you do not have to care about thread-safety and get linear readable code etc. If multiprocessing, threading or network communication is necessary the modules should encapsulate and hide this with Python and web technologies.
ROS needs to do this because it is inherently a micro service architecture. I think one of RoSys great advantages is the shared memory where a lot of this infrastructure is not required. If beneficial developers could simply launch RoSys as a ROS node to gain access to such features. |
Beta Was this translation helpful? Give feedback.
-
We have had an internal discussion about the benefits of offering a global system for publishing and subscribing to messages.
This GitHub Issue is meant to document the results of that discussion and facilitate it further.
None of the features are currently planned to be implemented.
Current State
Right now, rosys offers event channels through
rosys.event.Event
.An event can be emitted and subscribed to directly through the event object.
Potential Issues with the Current State
The need to have direct access to the object might make the code less modular and flexible since every subscriber must have a reference to the object.
If events from multiple sources need to be handled by the same handler, they need to all be explicitly subscribed to.
Similarly, if new publishers may be created at runtime, they must be subscribed to each time.
Furthermore, access to the object requires access to the same memory, which might not be available in a multi-processing or even multi-machine setup.
Proposed Changes
The proposal is to expand the current functionality by allowing events to be emitted and subscribed to through some abstract reference.
Examples for such a reference include:
"image"
tuple[Image, str]
'This reference would be saved globally by the event class and could then be published or subscribed to by anyone.
The abstraction could also allow subscribing to multiple publishers at once even if subscribers are not available from the start.
Current alternative Solutions
The issue of collecting and adding multiple publishers is solved by the
CameraProvider
class and its child classes.A
CameraProvider
manages multiple cameras and publishes all images through itsNEW_IMAGE
event.Each time a camera is added,
CameraProvider
subscribes tocamera.NEW_IMAGE
withself.NEW_IMAGE.emit
.ROS
The discussed functionality was inspired by the major feature of ROS topics. ROS calls its references topics and manages the distribution of messages on topics through IP sockets which are established through the ROS Master process. One criticism of this ip-based mechanism is its overhead per packet leading to siginificant performance problems when handling a large number of messages.
Beta Was this translation helpful? Give feedback.
All reactions