IPC in ros2

[kydos]

Hello @gbiggs,

@gbiggs

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.

And you see this as a positive aspect? Our model is simpler and more user friendly. For instance, how many people can digest DDS partitions? That said, we have a well defined mapping between XRCE resources and DDS topics.

@gbiggs

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?

Are you an OMG member? If so I’ll forward you the reviews. Both submissions went to the AB and the reviews were posted both on ab@omg.org and mars@omg.org. If you have access to those mailing list you’ll be able to see them. I also recommend you take a look at those.

@gbiggs

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.

It was impossible as the other vendors did not want to agree on such a low bound. The 24 bytes was the least we could agree on. This is why there is an evaluation on wire-efficiency. This matters were discussed at length, but again I don’t think you attended those meetings, thus you are missing part of the history and the context. In any case, all of those documents are on the OMG archives, thus if of interest you to reconstruct it. Just search for presentation I did on XRCE for almost a year. starting from 2015!

@gbiggs

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.

Yes, that is correct as it is since the very beginning that we are trying to do a joint submission. They’ve refused with futile arguments – if you ask me. We have put lots of effort to trying to join but that has not been corresponded. A pity that you were not in the Bruxelles meeting, otherwise you would have had a taste of it.

@gbiggs

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.

Again, you did not attend the end-less arguments we had during the RFP drafting. RTI does not want peer-to-peer in XRCE because they fear it could become as substitute for DDSI-RTPS. Again, this is not something I am inferring, but something that was openly debated during the RFP drafting. We don’t have any issue with that as we think that having a more efficient protocol than DDSI-RTPS for some use cases would be extremely useful.

@gbiggs

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?

For me that disqualifies completely the submission as in LowPAN environments nobody can afford to use TCP/IP…

@gbiggs

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.

I am glad that this helped clarifying the situation, please don’t hesitate to ask any other question. Concerning the code availability we are working on that. I’ll keep you posted.

A+