Sensor message types for eCAL? about ecal HOT 9 CLOSED

Hi,

thank you for your nice feedback. Simplicity is one of the major API design decision of eCAL. Regarding the messages type support eCAL is quite different to ROS/ROS2. It's not providing any kind of message collection at all. It's middleware only, not focusing on a specific use case like robotics or AD.

To create a google protobuf message file based on a ROS message file should be an easy task. And using google protobuf is not the only option, there are other message protocols (CapnProto, Flatbuffers) that you can utilize for your use case too. But protobuf is a good choice for many use cases, it's like a swiss army knife ;-).

If there is a general interest to have a standardized collection of messages for the robotic use case, maybe it would be a good idea to collect them in a separate repository.

from ecal.

Hi,

yes this is completely independent. You can choose different kind of publisher / subscriber (raw data blobs, protobuf, capnproto, flattbuffers, strings) and how the data is transferred from a publisher to a matching subscriber is by default shared memory on the same machine and udp multicast if they are running on different hosts,

So if you publish in protobuf format then

• the message will be serialized into a binary representation by the protobuf publisher
• a binary publisher will check if there is a local or network connection to a matching subscriber
• the data transfer starts by shared memory and / or udp multicast to one or more matching subscriber
• a matching binary subscriber will receive the binary payload
• the payload is serialized back into a protobuf message object
• the message object is forwarded to the protobuf subscriber

As you can see .. on the lower communication levels data will always transferred as binary representation. The kind of transport is independent from the chosen message protocol.

ReX

from ecal.

Hi rex-schilasky,

Thank you for your replay!

But is the eCAL protobuf message transport possible using shared-memory (zero copy) among processes that are on the same physical machine?

from ecal.

Hi Rex,

Thank you for your detailed explanation. I think it is really a good choice of using eCAL in the case that only pub/sub and services are needed.

If eCAL can also be used for inter-threads communication, that could be even desired.

from ecal.

Hi,

you are welcome ! eCAL works fine for inter-thread (innerprocess) communication too. It's using the same mechanisms (shared memory) for that kind of connection but can also be configured that way that it is calling the subscribers receive callback directly without using the process external memory.
But imagine the use case that you have one innerprocess and one or more interprocess connections. Then it makes sense to use the external memory for both paths from performance perspective.

ReX

from ecal.

Great!

Any example for inner-process communication? Or maybe it is the same as you already showed in those main.cpp?

Using eCAL in multi-threads feels more "thread-safe", I think.

from ecal.

Hi,

there are some unit tests testing inner process communication. You can check that one pubsub_inproc_test. From the users viewpoint there is no different how to setup publisher, subscriber, client, server as innerprocess, interprocess or interhost .. if the entities are located in the same process it's managed as inner process connection, that's it. Concentrate on your logic cores, the distribution, time synchronization, data flow is managed by eCAL :)

ReX

from ecal.

Can we close this issue?

from ecal.

Yes

from ecal.