[ros-users] [Discourse.ros.org] [Next Generation ROS] IPC in ros2

[Erik Boasson]

Let me join in the fray. Im the other author of the PrismTech submission and the one who built our tiny prototype. I wasnt present at the OMG meetings, and I wont waste any words on what may or may not have happened there.

Firstly, I dont think a contest of bytes of RAM adds real value to the discussion, although of course it is an honourable contest in itself :) I am surprised that you, @Jaime_Martin_Losa, had never even had a proper look at the memory use of your implementation given the purpose of the exercise in the first place, but if it is 8kB now then it is much better already  if still 7kB overweight ;) In any case, memory use is determined more by the implementation than by the protocol messages.

The precise overhead on the wire is of more interest, as this is fundamental to the protocol. BLE gives you 20 bytes to play with, and a difference of a few bytes of header adds up in that context. Furthermore, as Angelo pointed out, we have customers to whom 8 bytes is too many already. Yet even that is not of such great interest to me in this discussion.

What really matters in my opinion is a difference in philosophy. The two proposals suggest very different views of what one would ideally want to accomplish.

The RTI/TwinOaks/eProsima proposal is limited to providing a means for performing DDS operations remotely, and it dont see how it can do anything other than that. In a sense, it is just a hand-crafted alternative to CORBA with a lower overhead. (Simply using CORBA actually just works if the DDS implementation is faithful to the IDL interface mappings, even if it is ugly.) To me, this route is a pragmatic way of going about satisfying the RFP, but at the same time, an uninteresting one. (Sorry @Jaime_Martin_Losa and others )

We chose to design a compact protocol that can support what amounts to performing DDS operations remotely, but doesnt limit itself to it. Instead, it also supports a DDS-like peer-to-peer network with vastly lower overhead, and, in many ways a level of flexibility in specifying what data is of interest (through URIs and selections) that DDS doesnt natively support.

All of that would be of little value if it doesnt perform well or doesnt scale well. Just like the code size and memory use are mostly determined by the implementation, so is maximum sustainable performance more determined by implementation than by the details of the protocol headers. Size-wise, my prototype can run as a client on an Arduino Uno (8-bit CPU, 2kB RAM). A small test application using the same implementation configured as a peer easily sends ~700k 8-byte msgs/s from one RPi3 to 3 others (CPU is << 100%, network load ~75% of Fast Ethernet, so I really should investigate why it isnt faster), and goes another order of magnitude faster when run over local loopback on my MBP. Thats better than your typically DDSI implementation. Is this relevant? That depends on whether you have high rate, tiny messages 

Now my test application doesnt implement all of DDS  not even close  and this is another significant reason why it can do this with only a few kB of code and RAM. At the same time, this is, I believe, where it gets interesting for ROS2.

As ROS2 has its own middleware abstraction layer that uses only a fraction of the DDS feature set, putting ROS2 directly on our protocol would get you a smaller and a faster system. Smaller and faster usually allows doing more interesting things, even if I cant say what exactly those interesting things will be.

Disclaimer: I cant do run ROS2 over it today, theres more work to be done on my prototype before it supports all that is required. And I wish none of you would have to take my word for the data I mentioned, but that is not something that is in my power to solve today.





---
[Visit Topic](https://discourse.ros.org/t/ipc-in-ros2/2619/15) or reply to this email to respond.