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

[Geoffrey Biggs]

It looks like I started something of a minor storm moments before starting a holiday...

I'm thankful that the DDS vendors, PrismTech, RTI, Twin Oaks and eProsima, are all engaged enough in the ROS community to be present on the Discourse board. It is encouraging to future adopters of ROS 2.

[quote="kydos, post:11, topic:2619"]
We are Engineer and Mathematicians not priests. Thus we dont believe we measure
[/quote]

I wasn't implying religious believe. It's an simply expression to describe someone making an assertion. :) I fully agree that PrismTech's submission has much smaller messages than the RTI/Twin Oaks/eProsima submission based on the two presentations alone.

[quote="kydos, post:11, topic:2619"]
The RFP (which I wrote) asks for a protocol not for an API.
[/quote]

While this is true, the other submission has managed to define an object model as well, and in addition kept it close to the existing DDS one.

[quote="kydos, post:11, topic:2619"]
First off, the protocol has a single byte header of which only 3 bits are used for flags and the remainder 5 bits for message-id. There are two flags that are used consistently to identify Reliable and Synchronous messages and another few flags used to mark the presence or absence of some information in the message. Personally I dont find that daunting complex,  it is quite normal in protocol to use flags to this end.
[/quote]

It is quite common to use flags. TCP is full of them. My concern is that the protocol is, in my opinion, undoubtedly complex and, based solely on the presentations, more complex than the other submission. Complexity and size are often a balance and in this situation we appear to have one submission at each end of the balance.

[quote="kydos, post:11, topic:2619"]
Finally, what I can tell you is that with this protocol we have measured performances that  literally blow away RTPS! If you are curious well share the numbers Or better make available the code for you to see with your eyes
[/quote]

With the sorts of overhead you are achieving, I'm not surprised performance is amazing. I'd still like to see numbers, though. :slight_smile:

[quote="kydos, post:11, topic:2619"]
And BTW, if our complex specification can fit in 1KB and RTI&Co simple protocol fits in 43KB There is something wrong Thus either our is not so complex or their is not so simple
[/quote]

As was stated elsewhere in this thread, eProsima's implementation wasn't optimised. Since you said you are trying to bring yours to market already and eProsima claimed theirs was a tech demo, I'm not surprised yours is more optimised and thus smaller. Of course, the numbers are definitely in your favour for RAM usage. But I'm curious how much program memory each implementation requires, too. This is often the limiting factor on embedded microprocessors rather than the RAM usage.

[quote="kydos, post:11, topic:2619"]
As Ive explained several times during previous OMG meeting we have customers count bytes, and in some use cases they are not willing to spend more than 7 bytes wire overhead for data samples.
[/quote]

I didn't catch that even once during the presentation. Next time, put such an important motivating factor in your slides. ;) RTI and co were much better at motivating their design decisions, and that put a positive spin on their submission.

You probably also should have put that requirement in the RFP, if it's that important. The other submission cannot aim for a requirement they are not aware of.

[quote="kydos, post:11, topic:2619"]
But this is far from being true. The AB review should be public and I can ask permission from the AB to post those.
[/quote]

Since the submissions have not gone to the AB yet, as far as I know, then there should not be any official AB reviews, which suggests to me that RTI asked for unofficial reviews from AB members. This may be why they are not public?

[quote="kydos, post:11, topic:2619"]
The truth is that the two reviews of the AB raised questions concerning whether the submission was actually answering the RFP.
[/quote]

In that case I am very interested in seeing what these AB members wrote.

[quote="kydos, post:11, topic:2619"]
The reason why RTI did not want to vote is that their submission  if selected would have been killed by the AB. That is as simple as that.
[/quote]

That may have been RTI's reason, but the reason the rest of us present voted no is because we still have two vastly different submissions with no apparent readiness to work towards a single one. PrismTech even behaved in their presentation as if they are expecting RTI, Twin Oaks and eProsima to through away their submission and go with PrismTech's.

[quote="kydos, post:11, topic:2619"]
What do you think is our submission cutting out?
[/quote]

"Cutting down", not "cutting out". I meant that you are trying to reduce the size of the messages on the wire as much as possible, at the expense of possibly needing more complex parsing code. I didn't mean to say that you are cutting out features. It was clear from the presentation that PrismTech supports more features and has more flexibility than the other submission. But there are trade-offs involved.

[quote="kydos, post:11, topic:2619"]
Dynamic Discovery (RTI does not, please read their spec!)
Peer to Peer Communication (RTI does not)
[/quote]

Neither of these are required by the RFP. The RFP heavily directs the submitter towards the style of architecture that RTI/Twin Oaks/eProsima provided.

[quote="kydos, post:11, topic:2619"]
Non IP Transports (RTI does not)
[/quote]

Yes, this is something that I was disappointed about. Hearing RTI's presentation talk about TCP/IP only seemed to rule out using it on things like Zigbee. But on the other hand, perhaps it's readily adaptable?

[quote="kydos, post:11, topic:2619"]
Generalised Queries (RTI only supports DDS-like queries)
[/quote]

Well, it is *DDS*-XRCE, is it not?

[quote="kydos, post:11, topic:2619"]
I hope this was useful in clarifying a few aspects and I am looking forward to get some feedback once youll have read both submissions.
[/quote]

It was very useful. I wish I had had this information during the presentation. I still have not had time to read the submissions in detail and unfortunately will not be able to do so before November, but fortunately we now have until February next year to try and resolve this situation.

And, as @vmayoral said, having code available would make a difference to how well we can judge things like implementation complexity. ;)

[quote="kydos, post:12, topic:2619"]
everyone knows that consistency in design and elegance is seldom achieved through multi-vendor compromises
[/quote]

While this is true, we are operating at a standardisation organisation, not a rubber stamp provider. There are interested parties beyond just the implementers. We would prefer not to just hold a vote on which submission to go forward with. We would prefer the submitters to actually work together and produce a single submission that combines the best of both without any technological compromises (yes, I'm aware how hard that is).

[quote="kydos, post:12, topic:2619"]
Ill give you another small hint of why our XRCE proposal is an improvement over RTPS Do you know how the RTPS protocol deals with discovery? What happens when you have loads of topics, readers and writers in your system and very asymmetric nodes?

Have you ever tried to do a one shot write in DDS? How much protocol traffic are you going to generate to make that happen And how many entities do you have to create?

Ill  stop here for the time being
[/quote]

Or, you could provide the answers to those questions, along with the equivalent answers for your submission, so we can see and compare the data to back up your claims.

[quote="Jaime_Martin_Losa, post:14, topic:2619"]
Our submission tries to accomplish the following:

Propose a familiar model to the final user, making use of the DDS object model and specifications: Serialization (CDR), representation (XML-DDS), and some ideas of WS-DDS mapping
Neither the protocol or the API is designed to save every possible bit, but to have something robust, flexible and easy to use.
[/quote]

This is the strongest impression I got from the presentation, as I said in my own notes. The data model is similar to DDS, which makes adoption by existing DDS users easier, and the ability to implement the protocol in a relatively simple piece of code (which makes it easier to verify and certify) was considered as important as saving bytes on the wire. I'm not sure where the correct balance is between these two requirements, but the PrismTech implementation really gave the impression of being at one extreme.

[quote="Jaime_Martin_Losa, post:14, topic:2619"]
testing our solution in what we consider typical microcontrollers today
[/quote]

This is something that I think is really relevant but that PrismTech have not addressed at all, and RTI/Twin Oaks/eProsima have not addressed enough. What are the typical microcontrollers in use today? What are the target environments for this protocol to be used in?

The RFP explicitly says this:

[quote]
>From a high level perspective, the key requirements that a DDS-XRCE implementation has to satisfy are (1) extremely low footprint  addressing targets with less than 100 Kbytes of RAM, (2) extremely efficient wire protocol  inducing a protocol overhead of just a few tens of byte over the user data, and (3) support devices that undergo aggressive sleep cycles.
[/quote]

Both submissions fit within both the RAM usage (with much room to spare) and the protocol overhead.

More specifically, the actual mandatory requirement is:

[quote]
6.5.3. DDS-XRCE protocol overhead, when sending or receiving user data, shall not exceed 24 bytes per packet.

Let M be the size of the DDS-XRCE message sent out, and U the size of the user data, then M-U <= 24 bytes.
[/quote]

[quote="eboasson, post:15, topic:2619"]
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.
[/quote]

Again, this should have been in the RFP if it is so important. That would have saved a lot of trouble. All we got was an evaluation criteria:

[quote]
Protocol overhead shall be considered when evaluating submissions. Submissions with smaller overhead are preferable.
[/quote]

This is a miserably small set of criteria for a complex design space. Even you, @eboasson, say that protocol overhead is not as important as the design philosophy.

Which I agree is fundamentally different between the two proposals, and that this is where the root cause lies in the failure to reconcile them.

[quote="eboasson, post:15, topic:2619"]
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.
[/quote]

The RFP not-so-subtly pushes submitters in this direction. You cannot fault them for taking it at face value.

I will read both submissions and when I do, I will report back with more technically-informed comments.





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