ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

ROS 2 alpha8

#1

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 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

3 Likes
#2

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.

Circular dependency within rmw_implementation and rmw_opensplice_cpp
#3

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)
#4

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…

#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.

#6

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?

#7

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

1 Like
#8

@codebot

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

#9

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.

1 Like
#10

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.

#11

Just out of curiosity, when is the “official release date” of the ROS2 ? We know that you’re working so hard fot upcoming Beta 2, and is that the final version for the beta version of ROS2?

#12

hi Kei,

Last year we did a series of ~6-week Alpha releases, with each release adding new core features. That process culminated with Beta 1 in December. Now we’ll be making less frequent Beta releases, with each one adding a combination of new features and new demos. Our next Beta is targeted for this summer, with the evolving feature list (subject to change) coming together here:

The question of when it’s “final” or “done” really depends on what you’re looking for. If you need core middleware features like pub/sub, services, and params, then Beta 1 might have what you’re looking for. If you need more, then you should keep an eye on the roadmap for when new features are planned to be included. At some point, once we feel that there’s enough functionality included, we’ll stop using the “Beta” label.

In the meantime, we’d love to have your and others’ help! Here’s a starting point for new contributors:

brian.

1 Like
#13

Thanks you for explanation.I just want to know when we exist beta status,
because I have asked from several people very recently. I would answer
that Beta means It’s almost ready, you can use from today, but still space
to add new features.
As for contribution, please assign me if here is anything that i can help
:wink:

#14

Agreed, “Beta” means that it may almost (or already) be ready for you, depending on your specific needs, and that it will continue to accrue features and get better in other ways (docs, packaging, etc.).

Thanks for the offer to help! Based on the roadmap, is there something that is interesting to you? Or is there something not listed there that you see as important as a near-term addition to the system?

It’s an open source project, so of course everybody is free to work on whatever they like, but we’ll have an easier time merging contributions if we do a little coordination up front, at least to know who’s working on what and to agree on general design considerations.

#15

‘Support for non-ASCII strings in messages / services’ seems interesting for me, but quick example shows

  • it seems working. Am I missing something?
  • cpp publisher is ok
I heard: [Hello World: 130]
I heard: [Hello World: 131]
I heard: [Hello World: 132]
I heard: [こんにちわ: 1]
I heard: [こんにちわ: 2]
I heard: [こんにちわ: 3]

But python publisher is not working

user@ubuntu-16:~/ros2_ws$ listener
I heard: [S0�0k0a0:]
I heard: [S0�0k0a0:]
I heard: [S0�0k0a0:]
^Csignal_handler(2)
user@ubuntu-16:~/ros2_ws$ listener_py 
python3: /home/user/ros2_ws/build/std_msgs/rosidl_generator_py/std_msgs/msg/_string_s.c:54: std_msgs_string__convert_to_py: Assertion `pydata != NULL' failed.
Aborted

Reported on https://github.com/ros2/rosidl/issues/208

I do not think this is short term goal, but IDE/UML/Documentation integration would be an important feature on ROS2 as it support life-cycle management of the component, and I’m just thinking about start discussion with @gbiggs because he should have experience on this topic with OpenRTM, which I did not realize the importance of this feature 5 years ago.
https://translate.google.com/translate?sl=ja&tl=en&js=y&prev=_t&hl=ja&ie=UTF-8&u=http%3A%2F%2Fwww.openrtm.org%2Fopenrtm%2Fja%2Fcontent%2Frtctemplate-1&edit-text=

#16

Hi @k-okada,
No, you are not missing anything. You can already pass non-ASCII strings through the string type on ROS2 (and ROS1, for that matter).
The downsides of the current approach, however, are that the publishers and subscribers don’t know the encoding of the data they are sending/receiving. If you have a system where everything is UTF-8, then things are just fine, but if you might have strings with different encodings, it can be hard to determine which encoding is coming from which source.
Additionally, C++ has pretty poor support for dealing with Unicode strings. It would be nice to have ROS2 have better API support for dealing with Unicode.
All of the above is laid out in this PR: https://github.com/ros2/design/pull/117 . I am looking for feedback on what parts of this are useful, what kinds of problems people have had with Unicode and ROS1 in the past, etc. Any feedback you (and others) could provide would be great.

#17

I have made a start with support for OpenDDS but I found out that ROS2 does some tricky things with DDS Guids and InstanceHandle types which are outside of the DDS specification. Adding OpenDDS needs some more structural work but the work done until now is online at https://github.com/jwillemsen/rmw_opendds and https://github.com/jwillemsen/rosidl_typesupport_opendds.

#18

I hope you are aware that the ROS 2 alpha 8 version (of this thread) has been superseded by several new versions. So you might want to make sure to build on top of the latest release which is ROS Crystal.

It would be good to point to specific code snippets when making a statement like that to clarify what exactly you are referring to.

Also any DDS specific API usage is encapsulated in the RMW implementation for that specific vendor. So each RMW implementation chooses how it wants to implement the RMW interface. If you think some of the implementation could be updated please feel free to fill a ticket (or even better a pull request) in the corresponding repository.

#19

It is the functionality of DDS_InstanceHandle_to_GUID, that is not something which comes from the DDS specification. I haven’t found a way to do this with OpenDDS (there DDS::InstanceHandle_t is a long) and I need to dive much more in the details of ROS2 to see if this can be done in a different (and spec compliant) way. I reported this as issue https://github.com/ros2/rmw_connext/issues/326.

As part of my work I already made several pull requests to rmw_connext, these are all integrated in that RMW implementation, thanks for accepting my proposed changes.

#20

@dirk-thomas, I’d like to take you up on this offer to have a discussion about OpenDDS use in ROS2. Please let me know the best way to get ahold of you.