ROS2 multiple middlewares support

[Thibault Kruse]

Trying to run a talker / listener example on my machine, I started wondering how many middlewares ROS2 can support.

I started following the installation instructions here: https://github.com/ros2/examples/wiki

What worries me here is that these instructions suggest users to go to choose between vendors, go to some vendor website, where they have to register an account to download a license file that they have to put on their machine and expose via an environment variable.

That process feels very wrong, I don't even know where to start explaining. Basically the entry to ROS should ideally be smooth, to run turtlesim I should have one install command, source the setup.bash, then start the simulation.

Anyway, it seems the whole license thing is optional if we set aside legal issues, at least I got the workspace build with opensplice only without it.  (Note: ament using --isolated did not complete, example_interfaces: rmw/rmw.h: No such file or directory)
I also note the talker/listener example does not use any rosrun equivalent, the executables "talker" and "listener" end up on the PATH, not sure if that was just for a demo, or whether that is another new ROS2 design decision.

But I still wonder how the middleware switching works. I read through http://design.ros2.org/articles/ros_middleware_interface.html, but I did not find out where the user switch between running their node using one or the other middleware layer. I see some alternatives listed at "Switch between different implementations", but not what the current or intended implementation does. The section "User land code decides at link time" suggests link time, but not how the user specifies it. To run the talker/listener, I merely installed the opensplice dependencies, not sure if ament linked against opensplice because that was the only middleware found.

But if that were a link time decision, how does it work with packaging binaries?

In any case that made me wonder if it was possible to run ROS2 without DDS, but with some other middleware. As an example, could a modified fork of ros1 be used as a middleware implementation of ROS2? Possibly even as the default/reference implementation?

[Cedric Pradalier]

Further questions in the same spirit: 

- Why would we need to link with a single middleware as a transport mechanism? Couldn't we select which one is more appropriate in the hand-shaking phase?

- Why would we need to link at all? wouldn't a plugin mechanism be more flexible?

- What about selecting the preferred transport channels and priorities in the launch remap command? 

Just thoughts...

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Cedric Pradalier

[Dirk Thomas]

On Tue, Aug 4, 2015 at 2:10 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

Trying to run a talker / listener example on my machine, I started wondering how many middlewares ROS2 can support.

I started following the installation instructions here: https://github.com/ros2/examples/wiki

What worries me here is that these instructions suggest users to go to choose between vendors, go to some vendor website, where they have to register an account to download a license file that they have to put on their machine and expose via an environment variable.

That process feels very wrong, I don't even know where to start explaining. Basically the entry to ROS should ideally be smooth, to run turtlesim I should have one install command, source the setup.bash, then start the simulation.

We are talking to the DDS vendors to improve the process.

The fact that it currently is that way does not imply that it will stay that way.

We already do have a Debian package of OpenSplice.

For Connext we also have a Debian package ready and are waiting for the license questions to be resolved in order to be allowed to distribute it,

So in the future you can expect the same ease of installation.

Anyway, it seems the whole license thing is optional if we set aside legal issues, at least I got the workspace build with opensplice only without it.  (Note: ament using --isolated did not complete, example_interfaces: rmw/rmw.h: No such file or directory)

This is a known issue: https://github.com/ros2/rmw_opensplice/issues/39

Please build without the --isolated option for now.

I also note the talker/listener example does not use any rosrun equivalent, the executables "talker" and "listener" end up on the PATH, not sure if that was just for a demo, or whether that is another new ROS2 design decision.

Since we currently don't have a `rosrun` command we don't install binaries into lib/<pkgname>.

Once we do support Python and have implemented `rosrun`it is very likely that the executables will be moved to that location.

But I still wonder how the middleware switching works. I read through http://design.ros2.org/articles/ros_middleware_interface.html, but I did not find out where the user switch between running their node using one or the other middleware layer. I see some alternatives listed at "Switch between different implementations", but not what the current or intended implementation does. The section "User land code decides at link time" suggests link time, but not how the user specifies it. To run the talker/listener, I merely installed the opensplice dependencies, not sure if ament linked against opensplice because that was the only middleware found.

The easiest way is to depend on `rmw_implementation` (https://github.com/ros2/rmw_implementation/tree/master/rmw_implementation) which will choose the default for you.

The package also provides CMake functions to list all available rmw implementations: https://github.com/ros2/rmw_implementation/blob/master/rmw_implementation/cmake/get_available_rmw_implementations.cmake

The examples use that to build executables for all of them:

https://github.com/ros2/examples/blob/master/rclcpp_examples/CMakeLists.txt

https://github.com/ros2/examples/blob/master/rclcpp_examples/cmake/add_executable_for_each_rmw_impl.cmake

But if that were a link time decision, how does it work with packaging binaries?

The article you referenced describes that e.g. message packages will build libraries for each available type support.

Therefore all rmw implementations available on the build farm can be used at link time of user land code (if the user has the rmw implementation on his system).

The default rmw implementation for binaries built for Debian packages is determined by the `rmw_implementation` package mentioned above.

In any case that made me wonder if it was possible to run ROS2 without DDS, but with some other middleware. As an example, could a modified fork of ros1 be used as a middleware implementation of ROS2? Possibly even as the default/reference implementation?

The rmw interface can principally be implemented with any middleware system.

But the interface also makes behavior promises which might be difficult to fulfill with ROS 1.

E.g. guaranteed delivery or notification about lost messages.

We are likely not going to implement the rmw interface using ROS 1 because we believe that a lot of value in ROS 2 comes from using DDS.

We don't think that the ROS 1 middleware has these that's why we started the ROS 2 endeavor in the first place.

If you want to give it a try please go ahead.

The rmw API is currently not too complex and we aim to keep it DDS agnostic.

- Dirk

[Dirk Thomas]

On Tue, Aug 4, 2015 at 8:29 AM, Cedric Pradalier <cedric.p...@gmail.com> wrote:

Further questions in the same spirit: 

- Why would we need to link with a single middleware as a transport mechanism? Couldn't we select which one is more appropriate in the hand-shaking phase?

If you are at the "hand-shaking step" already you must have already agreed on some protocol to get that far.

- Why would we need to link at all? wouldn't a plugin mechanism be more flexible?

Currently we only support selecting the rmw implementation at link time.

But it would be possible to create a "dispatcher" rmw implementation which loads any of the available rmw implementation based on a passed in argument.

- What about selecting the preferred transport channels and priorities in the launch remap command? 

It is currently not possible to select different rmw implementations for different topics in a single binary.

The same rmw implementation is being used for all communication in a single executable.

- Dirk

[Thibault Kruse]

On Tuesday, August 4, 2015 at 5:32:37 PM UTC+2, Dirk Thomas wrote:

On Tue, Aug 4, 2015 at 2:10 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

But I still wonder how the middleware switching works. I read through http://design.ros2.org/articles/ros_middleware_interface.html, but I did not find out where the user switch between running their node using one or the other middleware layer. I see some alternatives listed at "Switch between different implementations", but not what the current or intended implementation does. The section "User land code decides at link time" suggests link time, but not how the user specifies it. To run the talker/listener, I merely installed the opensplice dependencies, not sure if ament linked against opensplice because that was the only middleware found.

The easiest way is to depend on `rmw_implementation` (https://github.com/ros2/rmw_implementation/tree/master/rmw_implementation) which will choose the default for you.

The package also provides CMake functions to list all available rmw implementations: https://github.com/ros2/rmw_implementation/blob/master/rmw_implementation/cmake/get_available_rmw_implementations.cmake

The examples use that to build executables for all of them:

https://github.com/ros2/examples/blob/master/rclcpp_examples/CMakeLists.txt

https://github.com/ros2/examples/blob/master/rclcpp_examples/cmake/add_executable_for_each_rmw_impl.cmake

So currently, in the packages cmake file, you have to use macros to select one or more rmw implementations and implement executables for each?

Just to check I get the right idea, are the following then true:
Only if all packages in the workspace do so consistently will they build for the same rmw imlementation, right?
If a user switches the implementation in a half-build workspace, the result would be incompatible executables?

But if that were a link time decision, how does it work with packaging binaries?

The article you referenced describes that e.g. message packages will build libraries for each available type support.

Therefore all rmw implementations available on the build farm can be used at link time of user land code (if the user has the rmw implementation on his system).

The default rmw implementation for binaries built for Debian packages is determined by the `rmw_implementation` package mentioned above.

What I mean is: one day, if I install package ros-nturtle-foo providing node foo, which middleware for messages will it be linked to?

Would that be the default rmw implementation (as in: OSRF provides apt-get packages only for e.g. opensplice, users who want to use Connext must build from source)?

Will the community have to decide the default implementation for each ROS distribution?

And how about dynamic languages then, like Python. If I install ros-nturtle-bar providing a scripted python ros node, I guess this would then have to carefully select the same rmw implementation as the C++ binaries?

[Thibault Kruse]

On Tuesday, August 4, 2015 at 5:32:37 PM UTC+2, Dirk Thomas wrote:

We are likely not going to implement the rmw interface using ROS 1 because we believe that a lot of value in ROS 2 comes from using DDS.

We don't think that the ROS 1 middleware has these that's why we started the ROS 2 endeavor in the first place.

I suggest not to dismiss this too easily. Let's say there was this rmw implementation for ROS2, maybe we can call it ROS2L (L for legacy or light). Then the whole concern or interoperation between ROS2L and ROS1 is solved without nasty bridge hacking. Users would have to decide between using DDS or having interop, but that might be a viable compromise. Also a lot of the ROS1 tools would still work on ROS2L, which makes debugging some regressions easier.

The use-case of bridging DDS on an embedded device with ROS1 running on other parts of the robot is not solved, but maybe that use-case is not that important anyway (Because the users concerned may be able to migrate to ROS2DDS for their purposes).

So the migration from ROS1 to ROS2L is easier. An easier migration means it can be expected that packages will be migrated faster, which is good for ROS2 in general (packages from ROS1 becoming available sooner in ROS2).
And the switch from ROS2L to ROS2DDS could be done as a separate step for each team.

This could also prevent the software and community schism, and the multiplied maintenance effort. A package mantainer can decide to stop maintaining a ROS1 package, but provide the ROS2 package, and for the community using the ROS2L variant may work seemlessly (no new tools required, no DDS related regressions). There would be a single codebase used for both DDS and non-DDS users.

Also note that for many users in academia, having an "unreliable" ROS2L may still be suitable for doing certain kinds of research (being no worse than ROS1).


Maybe OSRF still does not think ROS2L is worth implementing, I just wanted to point out there is more to that decision than mentioned before.

[Cedric Pradalier]

On Tue, Aug 4, 2015 at 5:37 PM, Dirk Thomas <dth...@osrfoundation.org> wrote:

On Tue, Aug 4, 2015 at 8:29 AM, Cedric Pradalier <cedric.p...@gmail.com> wrote:

Further questions in the same spirit: 

- Why would we need to link with a single middleware as a transport mechanism? Couldn't we select which one is more appropriate in the hand-shaking phase?

If you are at the "hand-shaking step" already you must have already agreed on some protocol to get that far.

Agreed. I did not mind the fact that the hand shaking was using a different communication mechanism as the data links. 

 

- Why would we need to link at all? wouldn't a plugin mechanism be more flexible?

Currently we only support selecting the rmw implementation at link time.

But it would be possible to create a "dispatcher" rmw implementation which loads any of the available rmw implementation based on a passed in argument.

In ROS1, making roscpp mostly middleware agnostic was not particularly destructive, so I think we should keep it in the design for future implementations (maybe not ROS2 though).

 

- What about selecting the preferred transport channels and priorities in the launch remap command? 

It is currently not possible to select different rmw implementations for different topics in a single binary.

The same rmw implementation is being used for all communication in a single executable.

Understood, this may not be for this version, but it may be a desirable feature for the future. 

In ROS1, once the transport plugin mechanism was in place, it was a minor change to expose the selection in the remap interface. 

 

- Dirk

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Cedric Pradalier

[Dirk Thomas]

On Tue, Aug 4, 2015 at 11:17 PM, Thibault Kruse <tibo...@googlemail.com> wrote:

On Tuesday, August 4, 2015 at 5:32:37 PM UTC+2, Dirk Thomas wrote:

On Tue, Aug 4, 2015 at 2:10 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

But I still wonder how the middleware switching works. I read through http://design.ros2.org/articles/ros_middleware_interface.html, but I did not find out where the user switch between running their node using one or the other middleware layer. I see some alternatives listed at "Switch between different implementations", but not what the current or intended implementation does. The section "User land code decides at link time" suggests link time, but not how the user specifies it. To run the talker/listener, I merely installed the opensplice dependencies, not sure if ament linked against opensplice because that was the only middleware found.

The easiest way is to depend on `rmw_implementation` (https://github.com/ros2/rmw_implementation/tree/master/rmw_implementation) which will choose the default for you.

The package also provides CMake functions to list all available rmw implementations: https://github.com/ros2/rmw_implementation/blob/master/rmw_implementation/cmake/get_available_rmw_implementations.cmake

The examples use that to build executables for all of them:

https://github.com/ros2/examples/blob/master/rclcpp_examples/CMakeLists.txt

https://github.com/ros2/examples/blob/master/rclcpp_examples/cmake/add_executable_for_each_rmw_impl.cmake

So currently, in the packages cmake file, you have to use macros to select one or more rmw implementations and implement executables for each?

You do not have to use a CMake macro.

Instead you can simply depend on a specific rmw implementation package  or `rmw_implementation` (as mentioned above) which chooses a default for you.

The CMake macros are syntactic sugar - mostly used to build executables for multiple rmw implementations.

Just to check I get the right idea, are the following then true:
Only if all packages in the workspace do so consistently will they build for the same rmw imlementation, right?

Yes, that's what the `rmw_implementation` package is for to define the default in one location.

If a user switches the implementation in a half-build workspace, the result would be incompatible executables?

The executables would use different rmw implementations.

But that does not make them "incompatible".

A Connext talker can communicate with an OpenSplice listener because of the DDS standard.

But if that were a link time decision, how does it work with packaging binaries?

The article you referenced describes that e.g. message packages will build libraries for each available type support.

Therefore all rmw implementations available on the build farm can be used at link time of user land code (if the user has the rmw implementation on his system).

The default rmw implementation for binaries built for Debian packages is determined by the `rmw_implementation` package mentioned above.

What I mean is: one day, if I install package ros-nturtle-foo providing node foo, which middleware for messages will it be linked to?

Would that be the default rmw implementation (as in: OSRF provides apt-get packages only for e.g. opensplice, users who want to use Connext must build from source)?

Yes.

It would be possible to provide multiple sets of packages for different rmw implementations.

But it is likely that we will only provide binary package for a single rmw implementation due to resource constraints.

Will the community have to decide the default implementation for each ROS distribution?

Yes.

And how about dynamic languages then, like Python. If I install ros-nturtle-bar providing a scripted python ros node, I guess this would then have to carefully select the same rmw implementation as the C++ binaries?

Since there is no link step for Python it will be a decision happening at the start time of a Python script.

Likely there will be a similar interface to select the default rmw implementation as in CMake to link C++ libraries.

- Dirk

[Thibault Kruse]

On Tuesday, August 11, 2015 at 11:36:13 PM UTC+2, Dirk Thomas wrote:

On Tue, Aug 4, 2015 at 11:17 PM, Thibault Kruse <tibo...@googlemail.com> wrote:

On Tuesday, August 4, 2015 at 5:32:37 PM UTC+2, Dirk Thomas wrote:

On Tue, Aug 4, 2015 at 2:10 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

But I still wonder how the middleware switching works. I read through http://design.ros2.org/articles/ros_middleware_interface.html, but I did not find out where the user switch between running their node using one or the other middleware layer. I see some alternatives listed at "Switch between different implementations", but not what the current or intended implementation does. The section "User land code decides at link time" suggests link time, but not how the user specifies it. To run the talker/listener, I merely installed the opensplice dependencies, not sure if ament linked against opensplice because that was the only middleware found.

The easiest way is to depend on `rmw_implementation` (https://github.com/ros2/rmw_implementation/tree/master/rmw_implementation) which will choose the default for you.

The package also provides CMake functions to list all available rmw implementations: https://github.com/ros2/rmw_implementation/blob/master/rmw_implementation/cmake/get_available_rmw_implementations.cmake

The examples use that to build executables for all of them:

https://github.com/ros2/examples/blob/master/rclcpp_examples/CMakeLists.txt

https://github.com/ros2/examples/blob/master/rclcpp_examples/cmake/add_executable_for_each_rmw_impl.cmake

So currently, in the packages cmake file, you have to use macros to select one or more rmw implementations and implement executables for each?

You do not have to use a CMake macro.

Instead you can simply depend on a specific rmw implementation package  or `rmw_implementation` (as mentioned above) which chooses a default for you.

So when building a future set of ROS packages from source, every team will need all involved rmw implementations present as requirements, because every package is free to choose it's own implementation.

And if alternative rmw implementations become available (like ROS1 or ZeroMQ), then it will not be possible to switch a large set of packages from one to the other, because each package may have fixed the rmw implementation in it's cmake file (and also have used verndor specific underlying API).

And the problem applies also to licensing. If a user does not wish to use Connext but only OpenSplice, they will have trouble because any number of ROS2 packages might be hard-wired to Connext. There is risk of users being unable to certain packages, or even of users violating Connext licensing restrictions without having been aware that there was a different license involved.

If a user switches the implementation in a half-build workspace, the result would be incompatible executables?

The executables would use different rmw implementations.

But that does not make them "incompatible".

A Connext talker can communicate with an OpenSplice listener because of the DDS standard.

First of all, I believe rmw implementations have no contract of being compatible with each other (ROS1 could be made an rmw implementation, or ZeroMQ).

And even if only DDS-rmw variants were involved, the degree of compatibility can very well be questioned. I understand every two years major DDS vendors meet to demonstrate the exchange of a few messages between the systems. But that is not the same thing as giving any guarantee of compatibility. The integration of n different DDS implementations may still raise any number of bugs.

As an example DDS systems can be configured in a lot of ways via an XML, but I suspect different vendors do this in different ways each.

I believe the different DDS vendors also disagreed on the way to implement service calls over DDS topics in the past. I can only guess they will also do what they can to add features to their implementations that make it difficult to switch vendors, like providing additional vendor-specific APIs for tooling.

The amount of development effort is probably manageable in industry when connecting 2 systems, like a sensor framework using one DDS implementation and an actuation system using another. A team of engineers can probably deal with the problems of combining such 2 systems via a small set of topics. But the engineering problem of maintaining a system of 100s of nodes each having an arbitrary DDS implementation under the hood is on a very different scale.

And debugging robot behavior will come down to debugging the code of multiple DDS vendors.

So ROS2 increases the ROS learning curve not just by requiring to learn the DDS standard, but also by requiring to familiarize oneself with multiple DDS implementations at the code level.

 

And how about dynamic languages then, like Python. If I install ros-nturtle-bar providing a scripted python ros node, I guess this would then have to carefully select the same rmw implementation as the C++ binaries?

Since there is no link step for Python it will be a decision happening at the start time of a Python script.

This means both the dynamic-language nodes as well as nodes with variable cmake code will have to be integration tested with multiple DDS vendors prior to release. And integration tests would basically have to run every possible permutation of nodes using differnt DDS vendors, which of course suffers combinatorial explosion.

This all sounds very scary to me. It sounds like OSRF is treating different DDS implementations as if they were merely different implementations of a simple serialization  protocol provided by entities eager to cooperate.
But it seems to me that on the contrary, DDS implementations are highly complex systems in themselves, provided by vendors in a tough competition with each other, grudgingly providing minimal communication compatibility, but trying very hard in every way they can to tie customers to their own implementation.

There is no business case for any DDS vendor to support ROS and an easy way to switch out their commercially-licensed product by an LGPL-licensed one. It's the classic case of biting the hand that feeds you.

While the DDS standard sounds like a good match for ROS2, I believe the only viable way would be to rely on a single implementation that is MIT-license compatible, and that OSRF could maintain itself when all other maintainers walk away.

[Geoffrey Biggs]

There seem to be a lot of assumptions taken to the extreme in your message. I
hope I can correct some of them.

If you're building from source, then you can change which rmw implementation
the package uses. That's why the actual communications middleware is hidden
behind the rmw API.

> And if alternative rmw implementations become available (like ROS1 or ZeroMQ),
> then it will not be possible to switch a large set of packages from one to the
> other, because each package may have fixed the rmw implementation in it's cmake
> file (and also have used verndor specific underlying API).

This is a valid use case for having an easy way to specify the rmw
implementation used for all packages in a workspace.

> And the problem applies also to licensing. If a user does not wish to use
> Connext but only OpenSplice, they will have trouble because any number of ROS2
> packages might be hard-wired to Connext. There is risk of users being unable to
> certain packages, or even of users violating Connext licensing restrictions
> without having been aware that there was a different license involved.

The above only applies to the binary packages. Anyone will still be free to
build from source using their preferred DDS vendor.

> If a user switches the implementation in a half-build workspace, the result
> would be incompatible executables?
>
> The executables would use different rmw implementations.
> But that does not make them "incompatible".
> A Connext talker can communicate with an OpenSplice listener because of the
> DDS standard.
>
>
> First of all, I believe rmw implementations have no contract of being
> compatible with each other (ROS1 could be made an rmw implementation, or
> ZeroMQ).

rmw implementations only need to comply with the API. If you are using binaries
from a single source, it is reasonable to assume that source built them all
using the same rmw implementation. If they didn't, then they are not providing
useful binaries...

If you are using source, then it doesn't matter. Build using the rmw
implementation suited to your needs.

> And even if only DDS-rmw variants were involved, the degree of compatibility
> can very well be questioned. I understand every two years major DDS vendors
> meet to demonstrate the exchange of a few messages between the systems. But
> that is not the same thing as giving any guarantee of compatibility. The
> integration of n different DDS implementations may still raise any number of
> bugs.

The major DDS vendors actually meet four times a year.

The demonstration (which I have seen twice, simply by being in the same place
at the same time) is simple, but the standard is comprehensive. DDS vendors
claim compatibility with the standard and their customers tend to hold them to
that. In the case of RTI, that's an advantage for us of them selling to the US
military, who demands standards compliance when suitable standards exist. The
rest of the commercial vendors comply to be able to claim compatibility with
RTI.

Certainly, bugs may exist in implementations, but the wire protocol itself is
relatively simple and the serialisation scheme has existed for longer than DDS
(it's CDR). The simple demonstration is actually enough to assume significant
compatibility across the wire.

> As an example DDS systems can be configured in a lot of ways via an XML, but I
> suspect different vendors do this in different ways each.

They do, but I don't see how this is relevant. All that sort of stuff will be
hidden behind the rmw API. ROS developers will not see it directly.

> I believe the different DDS vendors also disagreed on the way to implement
> service calls over DDS topics in the past. I can only guess they will also do
> what they can to add features to their implementations that make it difficult
> to switch vendors, like providing additional vendor-specific APIs for tooling.

RTI and PrismTech disagreed because they both already had their own solutions
to the problem, and obviously neither wanted to make a great deal of changes to
working code. It's a common situation. Fortunately that situation has been
resolved in a way that achieves compatibility. If it were open source projects,
the number of projects would probably have doubled instead...

Sometimes a standard is a useful thing for convincing the involved parties to
resolve differences rather than ignoring each other.

As for adding vendor-specific APIs, the vendors already do so to provide
additional useful functionality. It's a sensible business strategy. The
aforementioned XML configuration method is an example: It's not (yet) in the
standard but it's convenient so vendors provide ways to do it. I don't see the
relevance of this, either, though. If you're using the ROS tooling, what
tooling a DDS vendor chooses to provide is not relevant unless you explicitly
decide to use it. Depending on ROS (rmw) will shield you from a DDS vendor
behaving badly.

> The amount of development effort is probably manageable in industry when
> connecting 2 systems, like a sensor framework using one DDS implementation and
> an actuation system using another. A team of engineers can probably deal with
> the problems of combining such 2 systems via a small set of topics. But the
> engineering problem of maintaining a system of 100s of nodes each having an
> arbitrary DDS implementation under the hood is on a very different scale.

It's only arbitrary if you choose to accept whatever all the different package
maintainers have chosen for their packages. I don't think I've seen anyone
suggest that this will be the only possible outcome. A sensible user of ROS
will probably either use the default that works with the binary packages
provided by the OSRF, or (if they care about which DDS they use, which probably
means they are in industry)) they are going to chose their own preferred DDS
implementation and build all their packages to work with it.

> And debugging robot behavior will come down to debugging the code of multiple
> DDS vendors.

No it won't, unless you want it to.

> So ROS2 increases the ROS learning curve not just by requiring to learn the DDS
> standard, but also by requiring to familiarize oneself with multiple DDS
> implementations at the code level.

I don't know how you reached this conclusion. The OSRF developers have been
quite clear that the DDS implementation will not be used directly, but will be
hidden behind the rmw API. No learning DDS is *required*. It is *optional* for
advanced users who want to, for example, fine-tune the QoS policies of a
particular topic.

Certainly needing to be familiar with multiple DDS implementations at the code
level has never been mentioned as being required to use ROS2. I think we're
getting into hyperbole now.

> And how about dynamic languages then, like Python. If I install
> ros-nturtle-bar providing a scripted python ros node, I guess this
> would then have to carefully select the same rmw implementation as the
> C++ binaries?
>
>
> Since there is no link step for Python it will be a decision happening at
> the start time of a Python script.
>
>
> This means both the dynamic-language nodes as well as nodes with variable cmake
> code will have to be integration tested with multiple DDS vendors prior to
> release. And integration tests would basically have to run every possible
> permutation of nodes using differnt DDS vendors, which of course suffers
> combinatorial explosion.

I don't think this would be necessary. I think a reasonable approach is to test
with the default DDS that the OSRF assumes. Any testing with other DDS
implementations can be left up to the users who choose not to use the default.
It's a reasonable, and common, approach.

> This all sounds very scary to me. It sounds like OSRF is treating different DDS
> implementations as if they were merely different implementations of a simple
> serialization  protocol provided by entities eager to cooperate.
> But it seems to me that on the contrary, DDS implementations are highly complex
> systems in themselves, provided by vendors in a tough competition with each
> other, grudgingly providing minimal communication compatibility, but trying
> very hard in every way they can to tie customers to their own implementation.

DDS vendors are in competition with each other, yes. But they don't provide
"minimal communication compatibility." The DDS wire protocol is completely
specified in the standard, so communication compatibility is complete. Any
vendor-specific additional functionality can only occur on the
application-facing side of their implementation. While the vendors will try to
tie customers to their implementation through extra tooling, ROS is free to
ignore that and stick to the standard API as closely as possible.

> There is no business case for any DDS vendor to support ROS and an easy way to
> switch out their commercially-licensed product by an LGPL-licensed one. It's
> the classic case of biting the hand that feeds you.
>
> While the DDS standard sounds like a good match for ROS2, I believe the only
> viable way would be to rely on a single implementation that is MIT-license
> compatible, and that OSRF could maintain itself when all other maintainers walk
> away.

There is a real (not "community") open-source implementation of DDS available,
which I'm sure you'll be able to use if you choose to do so. I understand that
the OSRF has actually had pushing *from* the two largest DDS vendors to get
their implementation to be the preferred one for ROS2. The vendors see the
potential benefit of already being their when a company wants to start shipping
robots using ROS2.


I hope the above has cleared up some of the misconceptions around using DDS.


Geoff

[William Woodall]

The way I expect the system to be used is that all user code depends on `rmw_implementation` and uses the default implementation.

It will be easy to see what packages, if any, depend on a specific rmw implementation by crawling the package.xml files. So we could categorically exclude them from releases on our build farm and provide this information to users so they can make decisions based on it. I don't see a good reason for a ROS 2 package to require a specific rmw implementation, but I also think preventing people from doing so is an arbitrary constraint.

When building from source or using a custom build farm, a developer can change the default implementation for all packages (that she builds) with a CMake option to the rmw_implementation package. We'll recommend, test against, and provide support for the default implementation. We've yet to pick a default, but one requirement is that it will have an OSI approved license that is LGPL or more permissive. Using other implementations will need to be supported by people interested in using that implementation, but at least they have the choice.

The wire protocol for what we're calling ROS 2 is RTPS. Though it is possible to implement the rmw interface with ZeroMQ or ROS 1 or something else, I would not consider that compatible with ROS 2, but rather it would be something else, maybe "ROS 2 with ZMQ and protobuf". The difference in switching DDS implementations and switching to a non-DDS, non-RTPS vendor like ZeroMQ is that it is possible for the different DDS implementations to continue to interoperate at the wire level. Though non-RTPS based implementations of rmw would not be considered ROS 2 compatible, at least it is an option if someone wants to try it and it's an upgrade path for the future.

We are maintaining implementations to several DDS implementations at the moment to prove our abstraction works, to learn about the differences in the DDS implementations, and to test this assumption that DDS vendors can interoperate at the wire level. But at some point we will spend the majority of our time on one implementation, with a little additional effort maintaining a second implementation to a lesser degree to ensure the abstraction is not accidentally broken. We may help maintain other implementations if there are resources available to do so. We will probably not perpetually cross test all our packages against all possible or existing implementations because of the combinatorial problems mentioned before. I think that's ok though.

I think the idea that users will need to learn about multiple DDS implementations to use ROS 2 because many packages will be using many different rmw implementations is unrealistic. I expect that systems with a non-homogenous set of rmw implementations in use will be the exception, not the rule.

This is just my opinion, but maybe it provides a different perspective to consider.

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

William Woodall

ROS Development Team

wil...@osrfoundation.org

http://wjwwood.io/

[Thibault Kruse]

On Wednesday, August 12, 2015 at 2:45:53 PM UTC+2, Geoffrey Biggs wrote:

>     You do not have to use a CMake macro.
>     Instead you can simply depend on a specific rmw implementation package  or
>     `rmw_implementation` (as mentioned above) which chooses a default for you.
>
>
> So when building a future set of ROS packages from source, every team will need
> all involved rmw implementations present as requirements, because every package
> is free to choose it's own implementation.

If you're building from source, then you can change which rmw implementation
the package uses. That's why the actual communications middleware is hidden
behind the rmw API.

You can only do so if the source package uses the given cmake macro (correctly) and does not include vendor specific headers or tools.

Also just because your package compiles from source, does not mean it will work as expected. If you want to reuse 500 ROS packages using a different rmw implementation, are you then going to manually test, debug and fix 500 packages? And repeatedly do so with every patch to any of those packages? This is not a viable workflow.

It will be more viable to rely on the testing done by maintainers, meaning to have every package use the specific RMW implementation the maintainer uses for that package, and hence end up with a mix of implementations.

I don't see how to expect large ROS2 workspaces to have a homogenous set of implementations other than by sheer utopian idealism. If ROS2 permits users to use easily different vendors, they will do so.

The buildfarm also does not help much with that problem. If a package maintainer makes his package buildable with any rmw, but only supports his preferred rmw by testing and fixing, then the buildfarm will release a package tied to an rmw implementation it has never been tested against. Users might report problems, to which maintainers can just say: "Does not reproduce for us, use our rmw implementation to fix."

And then you have the problem of making sure each package builds with the preferred rmw implementation suggested by the maintainer, a use-case currently not supported by ament, I guess. Maybe what would be required is a cmake macro that allows to use a default rmw implementation, but also allows to use a suggested rmw implementation (because that one might be the lesser evil).

The same problems goes to the buildfarm. If OSRF realizes a package X only works well using a specific non-default rmw implementation, but also compiles to the default rmw implementation, what is OSRF then supposed to do? Provide the binaries for the default known to be faulty (but with the maintainer not caring about the default rmw mplementation)? Or rather provide the binary with the maintainer-suggested rmw implementation? Or both?

> So ROS2 increases the ROS learning curve not just by requiring to learn the DDS
> standard, but also by requiring to familiarize oneself with multiple DDS
> implementations at the code level.

I don't know how you reached this conclusion. The OSRF developers have been
quite clear that the DDS implementation will not be used directly, but will be
hidden behind the rmw API. No learning DDS is *required*. It is *optional* for
advanced users who want to, for example, fine-tune the QoS policies of a
particular topic.

I don't see how anyone could debug a robot behavior problem without looking beyond the rmw API. Sure, you can program against the API without learning about DDS, but the first time your robot arm moves in any way different from what you expect, you'll need to look behind the API. And if multiple rmw implementations are involved, you'll have to look at multiple DDS implementations to debug.

Certainly needing to be familiar with multiple DDS implementations at the code
level has never been mentioned as being required to use ROS2. I think we're
getting into hyperbole now.

OSRF will probably not advertise this requirement if it happens to be an inconvenient truth.

> But it seems to me that on the contrary, DDS implementations are highly complex
> systems in themselves, provided by vendors in a tough competition with each
> other, grudgingly providing minimal communication compatibility, but trying
> very hard in every way they can to tie customers to their own implementation.

While the vendors will try to
tie customers to their implementation through extra tooling, ROS is free to
ignore that and stick to the standard API as closely as possible.

OSRF-maintained ROS packages can be made to ignore that, but the 100s of community-provided packages cannot be forbidden to do what the vendors will try hard to achieve. In particular if the commercial vendors become involved in ROS, they are likely to provide packages tied to their own implementation. But even without that, you can expect ROS package creators to start using vendor specific stuff to get that extra bit of performance, or some extra feature, because package-creators are not altruistic creatures, but have personal agendas.

Another thing likely to happen will be package maintainers starting to conditionally include calls to vendor-specific API (in #ifdef blocks), making this whole topic even worse to think about.

[Geoff]

On Thu, Aug 13, 2015, at 19:10, Thibault Kruse wrote:

 

 

On Wednesday, August 12, 2015 at 2:45:53 PM UTC+2, Geoffrey Biggs wrote:

>     You do not have to use a CMake macro.

>     Instead you can simply depend on a specific rmw implementation package  or

>     `rmw_implementation` (as mentioned above) which chooses a default for you.

>

>

> So when building a future set of ROS packages from source, every team will need

> all involved rmw implementations present as requirements, because every package

> is free to choose it's own implementation.

 

If you're building from source, then you can change which rmw implementation

the package uses. That's why the actual communications middleware is hidden

behind the rmw API.

 

You can only do so if the source package uses the given cmake macro (correctly) and does not include vendor specific headers or tools.

 

Also just because your package compiles from source, does not mean it will work as expected. If you want to reuse 500 ROS packages using a different rmw implementation, are you then going to manually test, debug and fix 500 packages? And repeatedly do so with every patch to any of those packages? This is not a viable workflow.

 

In industry, that is a viable workflow if the budget is large enough and the requirements strict enough. Companies want to know that the software they are using will work as advertised. This means that they want binaries, preferably certified in some way. If they want to use the software in some way that the binaries do not allow, then they invest in compiling and QA-ing it themselves. Obviously that is a far larger burden that most companies don't want to deal with.

 

This is why Red Hat makes so much money.

 

 

It will be more viable to rely on the testing done by maintainers, meaning to have every package use the specific RMW implementation the maintainer uses for that package, and hence end up with a mix of implementations.

 

I don't see how to expect large ROS2 workspaces to have a homogenous set of implementations other than by sheer utopian idealism. If ROS2 permits users to use easily different vendors, they will do so.

 

The buildfarm also does not help much with that problem. If a package maintainer makes his package buildable with any rmw, but only supports his preferred rmw by testing and fixing, then the buildfarm will release a package tied to an rmw implementation it has never been tested against. Users might report problems, to which maintainers can just say: "Does not reproduce for us, use our rmw implementation to fix."

 

And then you have the problem of making sure each package builds with the preferred rmw implementation suggested by the maintainer, a use-case currently not supported by ament, I guess. Maybe what would be required is a cmake macro that allows to use a default rmw implementation, but also allows to use a suggested rmw implementation (because that one might be the lesser evil).

 

The same problems goes to the buildfarm. If OSRF realizes a package X only works well using a specific non-default rmw implementation, but also compiles to the default rmw implementation, what is OSRF then supposed to do? Provide the binaries for the default known to be faulty (but with the maintainer not caring about the default rmw mplementation)? Or rather provide the binary with the maintainer-suggested rmw implementation? Or both?

 

I've been assuming all along that any packages that get included in a ROS distribution produced by the OSRF will have been compiled by the OSRF using the default rmw implementation and will have had passed testing using that implementation. I've also been assuming that if a package maintainer wishes to provide binaries using a different implementation, they will do so themselves, taking on that burden themselves. This also means that if a package maintainer provides a package that does not work with the default rmw implementation or *only* works with a specific, non-default implementation, then the OSRF won't include it in their distribution.

 

Much of this is getting into planned OSRF policies, though, and I have no idea what those are so really I'm just making my own assumptions based on what I see as sensible. ROS package maintainers have a vested interest in their package being widely-usable, and for ROS2 that will probably mean functioning correctly with the default rmw implementation. If a package maintainer doesn't want to put the effort in to achieve that, then I think that they are probably not interested in having their package used by many people. Then it's up to the community to fix the package or ignore it as they see fit.

 

> So ROS2 increases the ROS learning curve not just by requiring to learn the DDS

> standard, but also by requiring to familiarize oneself with multiple DDS

> implementations at the code level.

 

I don't know how you reached this conclusion. The OSRF developers have been

quite clear that the DDS implementation will not be used directly, but will be

hidden behind the rmw API. No learning DDS is *required*. It is *optional* for

advanced users who want to, for example, fine-tune the QoS policies of a

particular topic.

 

I don't see how anyone could debug a robot behavior problem without looking beyond the rmw API. Sure, you can program against the API without learning about DDS, but the first time your robot arm moves in any way different from what you expect, you'll need to look behind the API.

 

Why?

 

And if multiple rmw implementations are involved, you'll have to look at multiple DDS implementations to debug.

 

Certainly needing to be familiar with multiple DDS implementations at the code

level has never been mentioned as being required to use ROS2. I think we're

getting into hyperbole now.

 

OSRF will probably not advertise this requirement if it happens to be an inconvenient truth.

 

This statement is nothing but inflammatory.

 

> But it seems to me that on the contrary, DDS implementations are highly complex

> systems in themselves, provided by vendors in a tough competition with each

> other, grudgingly providing minimal communication compatibility, but trying

> very hard in every way they can to tie customers to their own implementation.

 

While the vendors will try to

tie customers to their implementation through extra tooling, ROS is free to

ignore that and stick to the standard API as closely as possible.

 

OSRF-maintained ROS packages can be made to ignore that, but the 100s of community-provided packages cannot be forbidden to do what the vendors will try hard to achieve. In particular if the commercial vendors become involved in ROS, they are likely to provide packages tied to their own implementation. But even without that, you can expect ROS package creators to start using vendor specific stuff to get that extra bit of performance, or some extra feature, because package-creators are not altruistic creatures, but have personal agendas.

 

Another thing likely to happen will be package maintainers starting to conditionally include calls to vendor-specific API (in #ifdef blocks), making this whole topic even worse to think about.

 

The above may be an issue for industrial users in fields with strict certification requirements. Unused code still needs to be certified, so having loads of #ifdefs in a package would not be good for those users. So this is a valid concern that needs thinking about.

 

Geoff

[Jon Binney]

I don't see how anyone could debug a robot behavior problem without looking beyond the rmw API. Sure, you can program against the API without learning about DDS, but the first time your robot arm moves in any way different from what you expect, you'll need to look behind the API.

 

Why?

 

I do tend to agree with this sentiment, although I don't think it's a dealbreaker. As an example, I helped someone new to ROS1 debug a problem today. They couldn't "rostopic echo" robot topics on their desktop (connected over wifi). It turned out that we had switched routers and the new one wasn't doing hostname->IP mappings, so we needed to either set ROS_HOSTNAME on the robot (in our upstart file) or add the robot's IP to the desktop's /etc/hosts. In my experience people solve this in one of two ways:

- they understand ros/rostcp internals and that gives them intuition that helps when things break. (i walked him through http://wiki.ros.org/ROS/Technical%20Overview )

- they try voodoo incantations of ROS_HOSTNAME/ROS_MASTER_URI/etc.

In any complex system, as Thibault points out, when things break you will want/need to understand what is going on under the hood. In the case of ROS 2, that will involve intermediate users having some understanding of DDS/RTPS. That's not a terrible thing - at least those are well specified protocols. But we should keep in mind that there will definitely be cases when users will need to understand parts of the underlying protocols (even if they don't want to).

Jon

[William Woodall]

I agree with Jon that users will need at least a cursory understanding of the DDS implementation that they're using and that this has more layers than ROS 1 has. This means there is more to understand, but on the other hand it is arguable better described. I also agree with Thibault that if a user is using a mixed system they may need to know about more than one DDS implementation in order to debug a problem. I just don't think that will be a common occurrence for novice users.

I think the most likely occurrence will be if a vendor of a sensor wants to make their device output ROS 2 data natively, they might choose to do so using a smaller DDS implementation than what we choose as the default. Then a ROS user would be using the default rmw implementation in their code and the sensor would be using a different implementation, resulting in two different implementations at play on the wire. In that scenario I think it's on the sensor vendor to make sure their non-default implementation works as expected with the default implementation that the ROS community uses. If it doesn't work right, then people in the community will either work with the vendor to fix it, not use the sensor, or modify the sensor themselves to make it work. I have faith in our communities ability to work together and solve problems like this. If someone wants to use this sensor along with a non-default rmw implementation, then they might run into some trouble, but this is not something we'd recommend nor something that I think we have to explicitly disallow. At least people have the option and can make their own choices.

 

Jon

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bob Dean]

William, I understand form taking with Brian last week that you guys have a small dd or rtsp s implementation for embedded systems. Who will be verifying that? Or is it a vendor supported version?

Sent from my iPhone

[Morgan Quigley]

Hi Bob,

Yes, we've been spending some time developing our own ultra-minimalist
implementation of RTPS for several reasons:

1) to learn more about the inner workings of RTPS and DDS. Those
protocols are complex enough that working on a small implementation
helped to clarify our understanding of the network traffic.

2) to evaluate the potential for creating "deeply embeddable" versions
of ROS2 in bare-metal or "small RTOS" applications on microcontrollers
or other very small systems.

3) even further down the rabbit hole, to evaluate what class of
soft-core CPU would be required to support an FPGA implementation that
would produce or consume RTPS messages in pure Verilog.

4) to sanity-check the rmw abstraction interfaces to make sure it's
possible to use a non-DDS (e.g., RTPS-only) middleware implementation
"under the hood."

This is in a very, very experimental state at the moment. We have a
rudimentary standalone implementation of RTPS running. OK well, at
least it's enough to talk to OpenSplice in some cases, and it can run
either on native POSIX or cross-compiled on "big" STM32
microcontrollers running bare-metal. But this is very much a
work-in-progress. Our next goal is to actually tie this into the rmw
interface (goal #4 above), which we're working on right now. We'll
certainly announce this more loudly when it gets closer to being
useful. Hopefully all of these caveats have made it clear that this
will certainly _not_ be the default rmw implementation for the initial
release(s) of ROS2 :)

Cheers,
-mq

[Thibault Kruse]

On Wednesday, August 19, 2015 at 1:22:45 AM UTC+2, William Woodall wrote:

[...] I have faith in our communities ability to work together and solve problems like this.

This response works for *all* problems.

All problems with catkin_make are addressed by:

"I have faith in our communities ability to work together and solve problems like this."

But in the end, OSRF is dragged down by resulting support chores as much as the rest of the community.