ROS 2 alpha8

[mik...@osrfoundation.org]

We're happy to announce the release of ROS 2 alpha8, aka Hook-and-loop!

Installation instructions and tutorials can be found on the wiki: https://github.com/ros2/ros2/wiki

To get an idea of what's in (and what's not in) this release, be sure

to read the overview page:: https://github.com/ros2/ros2/wiki/Alpha8-Overview

A key change in this release is that Fast-RTPS is now the default ROS 2 middleware.

The list of all features available in this alpha can be found here: https://github.com/ros2/ros2/wiki/Features

~~~

As the "alpha" qualifier suggests, this release of ROS 2 is far from complete. You should not expect to switch from ROS 1 to ROS 2, nor should you expect to build a new robot control system with ROS 2. Rather, you should expect to try out some demos, explore the code, and perhaps write your own demos.

~~~

As always, we invite you to try out the new software, give feedback, report bugs, and suggest features (and contribute code!): https://github.com/ros2/ros2/wiki/Contact

The ROS 2 team

[Mikael Arguedas]

marguedas October 5

We're happy to announce the release of ROS 2 alpha8, aka Hook-and-loop! Installation instructions and tutorials can be found on the wiki: https://github.com/ros2/ros2/wiki To get an idea of what's in (and what's not in) this release, be sure to read the overview page:: https://github.com/ros2/ros2/wiki/Alpha8-Overview A key change in this release is that Fast-RTPS is now the default ROS 2 middleware. The list of all features available in this alpha can be found here: https://github.com/ros2/ros2/wiki/Features

~~~As the "alpha" qualifier suggests, this release of ROS 2 is far from complete. You should not expect to switch from ROS 1 to ROS 2, nor should you expect to build a new robot control system with ROS 2. Rather, you should expect to try out some demos, explore the code, and perhaps write your own demos.

~~~ As always, we invite you to try out the new software, give feedback, report bugs, and suggest features (and contribute code!): https://github.com/ros2/ros2/wiki/Contact

The ROS 2 team

---

Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

[Thibault Kruse]

tkruse October 5

The release notes seem to indicate that PrismTech's OpenSplice will (for now) not be supported by OSRF anymore (which seems a god thing to me). The only justification given is "To streamline our efforts", which reveals not that much. Any chance to get a few more sentences about this? I could not find any discussion about this, if there is one publicly available, a link should suffice.

[Dirk Thomas]

dirk-thomas October 5

We have support for four different RMW implemenations at the moment: RTI Connext (using message specific code generation) RTI Connext "dynamic" (using generic message introspection) OpenSplice (using message specific code generation) FastRTPS (using generic message introspection) While we have been developing the RMW interface, the type support system as well as the ROS client libraries we were using multiple implementation to ensure that our design decision are solid and not specific to a single vendor. Since these interfaces have matured by now we have revisited how many different RMW implementation we should actively support. Since maintaining support for a RMW implementation takes quite some effort and we are a very small team we decided to reduce the set to two implementations for now. That will allow us to spend our time on other things. To the question why we chose FastRTPS and Connext: For a long time OpenSplice was out default since it comes with an open license (LGPL). But recently FastRTPS has catched up and provides all the feature we need to implement the RMW interface with it as well as changed their license to Apache 2. FastRTPS is actively developed and we have a health relationship with the company behind it (eProsima). For OpenSplice the situation is less optimal atm. The latest release of their DDS implementation is not available as an open source edition. And that is not likely to change within the next twelve month. Also any ticket / pull request is being ignored - their GitHub repo of the open source edition is basically a one-time-code-dump. Therefore we decided that it is time to switch our focus on FastRTPS and not actively work and test with OpenSplice for the mid-term future. Connext support is still very important to us despite the fact that its license is not that open. It is the major vendor in the DDS market driving standardization (e.g. the upcoming security spec) and is being used by several parties which support OSRF with funding. Therefore we will continue to actively support the Connext RMW implementation. The dynamic variation will for now also not be actively supported since it is more of a case study and the introspection type support system is sufficiently exercised by FastRTPS. So the set for the mid-term future will be: RTI Connext (using message specific code generation) FastRTPS (using generic message introspection)

[Humpelstilzchen]

Humpelstilzchen October 5

Out of interest, was there any reason against OpenDDS or did just nobody look at it? It seems pretty mature to me and the license is also Open Source. For OpenSplice I can confirm the ignore on any github activity...

[Dirk Thomas]

dirk-thomas October 5

Quite some time ago we looked at all the available options and decided that OpenSplice was the "best bet" at the time. One argument at the time against OpenDDS was its internal implementation (TAO, ACE, CORBA). In comparison FastRTPS is a modern implementation of RTPS without building it on top of existing communication libraries. Arguable reuse is a good thing but I would point out that FastRTPS is much more lightweight and with less dependencies because of that "clean rewrite". If someone would like to look into OpenDDS more and implement the RMW interface using it that would be great. We would certainly help in the effort by answering questions and helping to troubleshoot. But we can't effort the time to work on another RMW implementation - especially without any clear benefits over already supported implementations.

[Thibault Kruse]

tkruse October 5

Thanks, that was informative. Also out of curiosity, at some Point Morgan Quigley mentioned that OSRF had been working on a minimalist RTPS implementation (https://groups.google.com/d/msg/ros-sig-ng-ros/9VBTiYJO090/MA4q8OK8EAAJ ), does this effort still go on?

[Morgan Quigley]

codebot October 5

Since I gave that talk at ROSCon 2015, FastRTPS moved to an Apache 2 license and has been significantly improved (large message support, etc.). We expect that it can serve as a reasonable liberally-licensed default middleware capable of running on "full-size" platforms. Resource-constrained platforms continue to be of great interest! We love them. But development in that direction has been temporarily paused while we try to hammer out Beta 1 for "full-size" machines (aka things capable of running ROS 1, plus Windows). We hope to revive it at some point, but as always tough choices have to be made as to where to allocate engineering hours for the highest impact at various timescales. Cheers, Morgan

[Rohan Agrawal]

rohbotics October 6

@codebot Just to be clear FreeRTPS https://github.com/ros2/freertps is the minimalist implementation right?

[Morgan Quigley]

codebot October 6

Yes, that's right; FreeRTPS is a starting point for a minimalist implementation of the RTPS spec that is capable of running without an operating system (e.g. a microcontroller). It has a long way to go, but that's what we demo'ed at ROSCon 2015. Current work is on the history_cache branch, but that is in somewhat of a paused disarray at the moment.

[Thibault Kruse]

tkruse October 6

Thanks for the update. I for one am happy whenever OSRF makes a tough choice for ROS2 against personal preferences to achieve realistic goals, even if I feel sorry for you not being able to pursue what you would love to do best under ideal circumstances.