What will ROS1 and ROS2 share...

[Thibault Kruse]

... other than the name?

So looking around a bit, it seems that so far, all pieces of ROS2 have independent sources / implementations, no part or tool of the ROS1 ecosystem is needed to build and use ROS2:

Buildsystem: catkin vs ament
C++ Client API / message generation: ros1 vs ros2 DDS
Node Runtime: ROS1 nodes + nodelets vs. ROS2 processes
VCS support: wstools vs. vcstool  (seen used here: https://github.com/ros2/examples/wiki )

It seems that ROS2 is planned to share not a single line of code with ROS1.

What about the other tools

rviz, roslaunch, rosrun, rqt_..., rosmsg, rospack, rosbag, rosnode, rostopic, rosparam

Will those all also be copied and maintained in their own repositories for ROS2, with new ideas being added for ROS2 but not backported, in order not to disturb ROS1? Because at a glance it seems that it would be difficult to make those tools work nicely with ROS2 as they are.

And then the same question goes for the most prominent non-core packes (http://www.ros.org/news/2014/04/ros-user-survey-the-results-are-in.html)
navigation, moveit, tf, ..._drivers, image_pipeline

[Jack O'Quin]

I share many of Thibault's concerns.

Viewed in isolation, the ROS 2 design is wonderful. Things are much more modular, dependencies are minimal. The developers have done excellent work. 

Unlike Thibault, I don't mind the core implementation being different. There are advantages, as well as dangers, with a cleaner implementation. 

But, for the mass of shared, community-maintained packages, ROS 1 -> ROS 2 migration reminds me too much of the python2 -> python3 disaster. The Python developers decided to take a purist approach, came up with a cleaner design, and released it to "see if the dogs eat the food".

The result is that many "dogs" still are not eating it. At first, Python did not even provide any way to maintain common code for both dialects. Yet, most programmers still had their own work to do, which did not include re-writing thousands of programs that already worked well.

The ROS 1 community is a good example of these problems. The core developers were mostly able to deal with both dialects, but the rest of us never had a credible plan to migrate our ROS Python packages. The reasons mainly relate to circular dependencies and difficulties testing code in both python2 and python3 environments. 

With ROS 2 being python3-only, we now have a plan for that, but the earlier migration issues have not disappeared. They are now inextricably stuck in the whole ROS 1 -> ROS 2 migration swamp.

I anticipate many years of overlap between ROS 1 and ROS 2. The Python developers originally estimated five years to migrate most of their code base. That was optimistic. Those of us who maintain ROS device drivers, perception, navigation, localization, and other essential packages are going to have to support both versions for longer than I really want to imagine.

The decision to retain the ROS 1 message file format with DDS was a good one. It gives us an opportunity to make migration and co-existence much easier. But now, dozens of low-level implementation decisions seem to be "snatching defeat from the jaws of victory", a clean-slate mentality undoing many of the potential benefits.

Please forgive me for focusing on some negatives. I really like ROS 2 a lot, but this group needs to discuss these problems before it's too late. 

--

 joq

[William Woodall]

On Thu, Jul 16, 2015 at 7:17 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

... other than the name?

So looking around a bit, it seems that so far, all pieces of ROS2 have independent sources / implementations, no part or tool of the ROS1 ecosystem is needed to build and use ROS2:

Buildsystem: catkin vs ament
C++ Client API / message generation: ros1 vs ros2 DDS

The C++ client and the message generation of ROS 2 are based in part on the implementations in ROS 1. We just don't depend on them directly in order to avoid undesired dependencies which would make it more difficult to change ROS 1 (for fear of breaking ROS 2) and limit the systems on which ROS 2 could be run (like Windows where ROS 1 doesn't work in practice without something like cygwin).

 

Node Runtime: ROS1 nodes + nodelets vs. ROS2 processes

That's a conceptual change which I think is a selling point of ROS 2, though ROS 1 and ROS 2 nodes can be pretty similar at the moment.

 

VCS support: wstools vs. vcstool  (seen used here: https://github.com/ros2/examples/wiki )

Well wstool is really nice for some styles of development (especially for merging complex rosinstall files into existing workspaces and updating versioned copies of items in the workspace), but the stateless style of vcstool is sometimes a better fit for our development. There's no reason you couldn't use wstool to checkout the code for ROS 2. My defense is that I feel I'm using the right tool for the job atm, but that doesn't mean I don't use wstool when creating a single workspace with ros_comm and rviz + their dependencies.

 

It seems that ROS2 is planned to share not a single line of code with ROS1.

It shares lots of code, but you're right that sharing mostly takes the form of copy, adjust to fit surrounding code, and update to use C++11 where appropriate. But this is mostly an artifact of the amount of changes that need to be made in these low level core packages.

 

What about the other tools

rviz, roslaunch, rosrun, rqt_..., rosmsg, rospack, rosbag, rosnode, rostopic, rosparam 

Will those all also be copied and maintained in their own repositories for ROS2, with new ideas being added for ROS2 but not backported, in order not to disturb ROS1? Because at a glance it seems that it would be difficult to make those tools work nicely with ROS2 as they are.

There are a lot of tools there that we haven't even started to look at yet, but generally it will be a question of the ration of the cost to factor out functionality into a ROS 1/2 agnostic library vs time saved by not reinventing something that already exists.

For rviz, I'll likely be the one to do that, and to start I'll almost certainly start with a fork and replace ROS 1 stuff with ROS 2 stuff in place. Long term I'd like to share rendering code with Gazebo and make rviz middleware agnostic (as much as possible) and then right plugins for ROS 1 and ROS 2 alike. But the reality is that will take quite some time and effort. For the first version of ROS 2 rviz will be used only through a bridge.

For roslaunch, we haven't decided what's going to happen there. We have a simple Python API called launch in ROS 2 at the moment for running our tests which require more than one program to run (similar to the purpose of rostest). We haven't migrated roslaunch, but it may well be what we do. Some things will need to be changed and whether or not we share a code base between ROS 1 and ROS 2 will depend on how intrusive those changes are. Either way in ROS 2 we want to have a more dynamic option for launching, probably in the form of a Python script. There's still a lot of uncertainty around this at the moment.

rqt is likely a similar story to rviz.

rosrun, rosmsg, rosnode, rostopic, and rosparam will probably have completely new implementations since the bulk of their work will be using the ROS 2 interfaces. The only common code between the two would be CLI stuff. It's not clear to me if sharing between them would be a good idea, but gut reaction is that it would not. Also we're thinking about ways to avoid overloading of the tool names on the command line. In systems where you have ROS 1 and ROS 2 in play, then either rostopic from ROS 1 or ROS 2 will be first on the PATH, but both cannot be accessed if they have the same name. This could be avoided by never having one terminal with both sourced, but I imagine it could get confusing. Maybe we'll end up with ros2topic and ros2run and so on as aliases to avoid some of the overloading and confusion, but I always disliked that pattern since it sounds like you're converting something called ros to something called topic, for example. In that case maybe we end up with a verb system like catkin_tools, more like ros2 topic and ros2 run, or just ros topic and ros run.

 

And then the same question goes for the most prominent non-core packes (http://www.ros.org/news/2014/04/ros-user-survey-the-results-are-in.html)
navigation, moveit, tf, ..._drivers, image_pipeline

I think there will be a lot more code sharing at this level. moveit, tf, and many of the drivers already have a ROS agnostic component and thin ROS 1 wrapper. So it will just require cross releasing the ROS agnostic part, so ROS 2 can depend on it, and writing the ROS 2 wrapper. In each case there will be opportunities to improve on the wrapper part by using new features of ROS 2. For example, I'm excited to get tf2 migrated and see what we can do to make sharing tf state much more efficient with the new transport (with multicast support) and intra-process communication options.

Other items like the navigation stack and the image_pipeline have more ROS specific parts in them, but again these are prime candidates (in my opinion) for major improvements in terms of modularity and performance by using new features in ROS 2.

 

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

[Michael Ferguson]

And then the same question goes for the most prominent non-core packes (http://www.ros.org/news/2014/04/ros-user-survey-the-results-are-in.html)
navigation, moveit, tf, ..._drivers, image_pipeline

I think there will be a lot more code sharing at this level. moveit, tf, and many of the drivers already have a ROS agnostic component and thin ROS 1 wrapper. So it will just require cross releasing the ROS agnostic part, so ROS 2 can depend on it, and writing the ROS 2 wrapper. In each case there will be opportunities to improve on the wrapper part by using new features of ROS 2. For example, I'm excited to get tf2 migrated and see what we can do to make sharing tf state much more efficient with the new transport (with multicast support) and intra-process communication options.

Other items like the navigation stack and the image_pipeline have more ROS specific parts in them, but again these are prime candidates (in my opinion) for major improvements in terms of modularity and performance by using new features in ROS 2.

I think tf2 does in fact do the library + thin wrapper. Sadly, even moveit_core is littered with ROS1 messages (even in the public APIs in many cases). Same goes for navigation. Much of image_pipeline is really nodelet wrappers around opencv features -- so that particular instance should be fairly easy to move forward.

-Fergs

[Austin Hendrix]

For me and my use case, rviz is one of the biggest selling points of
ROS. This includes the ease of writing rviz plugins for custom display
types.

If rviz is on the other side of a ROS2<->ROS bridge, or if it's
otherwise difficult to get messages from ROS2 into rviz, then it could
lose a significant amount of its usefulness.

I'm also worried about how much code logic or metaprogramming it will
take to share plugins between an rviz for ROS and an rviz for ROS2; if
writing plugins for rviz on ROS2 isn't like writing normal subscribers,
for example, it makes custom tools that much more difficult to write.



Sorry if that sounds like a lot of complaining; I think what I'm trying
to argue for here is a native ROS2 version of rviz from day 1.

-Austin

> <mailto:ros-sig-ng-ro...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> William Woodall
> ROS Development Team

> wil...@osrfoundation.org <mailto:wil...@osrfoundation.org>
> http://wjwwood.io/

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

> <mailto:ros-sig-ng-ro...@googlegroups.com>.

[William Woodall]

On Thu, Jul 16, 2015 at 9:00 AM, Jack O'Quin <jack....@gmail.com> wrote:

I share many of Thibault's concerns.

Viewed in isolation, the ROS 2 design is wonderful. Things are much more modular, dependencies are minimal. The developers have done excellent work. 

Unlike Thibault, I don't mind the core implementation being different. There are advantages, as well as dangers, with a cleaner implementation. 

But, for the mass of shared, community-maintained packages, ROS 1 -> ROS 2 migration reminds me too much of the python2 -> python3 disaster. The Python developers decided to take a purist approach, came up with a cleaner design, and released it to "see if the dogs eat the food".

The result is that many "dogs" still are not eating it. At first, Python did not even provide any way to maintain common code for both dialects. Yet, most programmers still had their own work to do, which did not include re-writing thousands of programs that already worked well.

The ROS 1 community is a good example of these problems. The core developers were mostly able to deal with both dialects, but the rest of us never had a credible plan to migrate our ROS Python packages. The reasons mainly relate to circular dependencies and difficulties testing code in both python2 and python3 environments. 

With ROS 2 being python3-only, we now have a plan for that, but the earlier migration issues have not disappeared. They are now inextricably stuck in the whole ROS 1 -> ROS 2 migration swamp.

I anticipate many years of overlap between ROS 1 and ROS 2. The Python developers originally estimated five years to migrate most of their code base. That was optimistic. Those of us who maintain ROS device drivers, perception, navigation, localization, and other essential packages are going to have to support both versions for longer than I really want to imagine.

I agree with your comparison to the Python2 => Python3 migration for the most part. I think the migration of the community from ROS 1 to ROS 2 will be slow and by attrition. But I don't see a better way, the only alternative with less effort is to avoid changes that really should be made, and I don't know of a way that Python could have made the changes it needed to make while avoiding the cost of transition for its community. However, I think there are some important differences. For instance, with Python2 => Python3 the runtime is completely incompatible, so using a library which only supports Python2 asserts that your code either has to support both Python2 and Python3 or is forced to use Python2 only. This has forced a lot of projects to delay supporting Python3 until their dependencies support it, e.g. lots of things waited on NumPy before transitioning. That won't necessarily be the case for ROS 1 => ROS 2. The bridge will allow for hybrid systems. And the burden this puts on people with hybrid systems will be based on how good the bridge could be made to work. So understandably we've put a lot thought into the bridge, allowing it to even warp our design decisions in ROS 2 already (which I would avoid in principal, but recognize that the bridge maybe worth the cost).

 

The decision to retain the ROS 1 message file format with DDS was a good one. It gives us an opportunity to make migration and co-existence much easier. But now, dozens of low-level implementation decisions seem to be "snatching defeat from the jaws of victory", a clean-slate mentality undoing many of the potential benefits.

I understand what you mean. And I agree that changes to messages like removing seq are in a different category than changing the names of the message packages or changing the Time and Duration types. But it seems we're discussing those in another thread so I'll pick that up there.

 

 

Please forgive me for focusing on some negatives. I really like ROS 2 a lot, but this group needs to discuss these problems before it's too late. 

I appreciate you bringing up the questions, they need to be discussed, and what's in ROS 2 right now is just what we see as the best option. Our intention has always been that this first iteration to be used as a lens through which our discussions could be focused.

 

--

 joq

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

[William Woodall]

On Thu, Jul 16, 2015 at 3:20 PM, Austin Hendrix <namn...@gmail.com> wrote:

For me and my use case, rviz is one of the biggest selling points of ROS. This includes the ease of writing rviz plugins for custom display types.

If rviz is on the other side of a ROS2<->ROS bridge, or if it's otherwise difficult to get messages from ROS2 into rviz, then it could lose a significant amount of its usefulness.

Yes, this is why we want to make the bridge as efficient and automatic as possible. There are a lot of cases where people "bridge" data from completely alien systems just to use rviz. I think it should be the same with bringing data in from ROS 2, if only to visualize it with rviz. I'd only spend lots of time making a ROS 2 version of rviz if this pattern was particularly painful for some reason. Eventually there should be a way to have rviz without a dependency on ROS 1, but that's probably not a high priority at the moment. Maybe instead a ROS 1 rviz plugin which can directly subscribe to ROS 2 topics (basically an embedded bridge with a UI to control it in rviz)?

 

I'm also worried about how much code logic or metaprogramming it will take to share plugins between an rviz for ROS and an rviz for ROS2; if writing plugins for rviz on ROS2 isn't like writing normal subscribers, for example, it makes custom tools that much more difficult to write.



Sorry if that sounds like a lot of complaining; I think what I'm trying to argue for here is a native ROS2 version of rviz from day 1.

No those are all fair points. Maybe there is a path forward where plugins are abstracted away from the middleware in the simplest cases, keeping them from becoming ROS version agnostic, but that probably won't scale to all cases. The truth is that I just don't know right now.

 

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/

[William Woodall]

Yes, I was afraid that moveit might be more tangled up in ROS 1, but I wasn't familiar enough to know for sure. Thanks for pointing it out. So in the case of moveit, there would be a lot of work that would need to be done to refactor out the non-middleware stuff and properly abstract it before it could be largely shared between systems (I think this would make it more useful anyways). However, I dare say we're a long way off from considering migration of moveit or the navigation stack. So I'd imagine that most robots will start by using ROS 2 on the fringes where its better suited (small devices, niche communication links, high performance algorithm pipelines, etc..) and continue to use the nav stack and moveit through a bridge.

It's easy to get depressed by the amount of work that is ahead to migrate something like the navigation stack, but I personally would love to dig into the nav stack, figure out how it could be better/faster/more modular using ROS 2, and implement something incrementally better than what's there. The question is always resources to do so, but I believe those will come eventually. So I try to be excited about the possibilities.

 

-Fergs

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

[Michael Ferguson]

Oh, I am totally not depressed by the amount of work -- I already have plenty of plans with the navigation stack -- this is a great opportunity to clean up and combine the multiple different local and global planners we have into proper implementations, and also drop some of the older packages that really have been largely replaced (for instance, let robot_pose_efk die in favor of robot_localization). The costmap_2d package, with the exception of the pluginlib stuff, is already pretty ROS agnostic and should be fairly easily moved forward.

-Fergs

[Jack O'Quin]

My experience is similar to Mike's. The messages are the crux of the problem.

When nodelets came along several years ago, I refactored several drivers to have a device-dependent core, with separate node and nodelet front-ends. I now consider that best practice. It was relatively painless, and introducing a ROS 2 front-end would probably not be particularly difficult (assuming no unnecessary screw-ups).

But, there was never any apparent advantage in defining abstract data types for the ROS messages. It was always cleaner, clearer and more efficient to use them directly throughout the code. So, breaking the messages and their interfaces is a big deal to me.

--

 joq

[Jack O'Quin]

On Thu, Jul 16, 2015 at 5:50 PM, William Woodall <wil...@osrfoundation.org> wrote:

It's easy to get depressed by the amount of work that is ahead to migrate something like the navigation stack, but I personally would love to dig into the nav stack, figure out how it could be better/faster/more modular using ROS 2, and implement something incrementally better than what's there. The question is always resources to do so, but I believe those will come eventually. So I try to be excited about the possibilities.

My question is: who is going to maintain all that old, crufty, but absolutely essential, code while all this fun, creative, new work is being done? 

In most major projects, maintenance outweighs new development by a considerable margin.

--

 joq

[William Woodall]

Personally, I've spent much more time maintaining existing stuff in ROS 1 since joining WG almost exactly three years ago to "work on ROS 2" and that's part of the reason ROS 2 has been long talked about with little done on it. So from my perspective ROS 1 has been a much higher priority than ROS 2 for as long as I've been doing this. I don't expect that to change for a long time yet, except for in spurts where we try to sprint new stuff into ROS 2 (like we're currently doing). There are, and will continue to be, lots of people using ROS 1, so I don't expect there to be a lack of need to keep it working. I believe that motivation and resources (volunteer and financial) will come based on the need, but maybe I'm naive (I'm an engineer not a businessman).

We're dedicated to keeping core ROS 1 packages working and up-to-date as well as maintaining infrastructure used by the community. I don't think our ROS 2 work has to get in the way of this.

 

--

 joq

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

[Jack O'Quin]

On Thu, Jul 16, 2015 at 6:29 PM, William Woodall <wil...@osrfoundation.org> wrote:

On Thu, Jul 16, 2015 at 4:04 PM, Jack O'Quin <jack....@gmail.com> wrote:

On Thu, Jul 16, 2015 at 5:50 PM, William Woodall <wil...@osrfoundation.org> wrote:

It's easy to get depressed by the amount of work that is ahead to migrate something like the navigation stack, but I personally would love to dig into the nav stack, figure out how it could be better/faster/more modular using ROS 2, and implement something incrementally better than what's there. The question is always resources to do so, but I believe those will come eventually. So I try to be excited about the possibilities.

My question is: who is going to maintain all that old, crufty, but absolutely essential, code while all this fun, creative, new work is being done? 

In most major projects, maintenance outweighs new development by a considerable margin.

Personally, I've spent much more time maintaining existing stuff in ROS 1 since joining WG almost exactly three years ago to "work on ROS 2" and that's part of the reason ROS 2 has been long talked about with little done on it. So from my perspective ROS 1 has been a much higher priority than ROS 2 for as long as I've been doing this. I don't expect that to change for a long time yet, except for in spurts where we try to sprint new stuff into ROS 2 (like we're currently doing). There are, and will continue to be, lots of people using ROS 1, so I don't expect there to be a lack of need to keep it working. I believe that motivation and resources (volunteer and financial) will come based on the need, but maybe I'm naive (I'm an engineer not a businessman).

We're dedicated to keeping core ROS 1 packages working and up-to-date as well as maintaining infrastructure used by the community. I don't think our ROS 2 work has to get in the way of this.

The main difference with device drivers is that we mostly work on supporting new models and fixing problems with existing hardware. For years, that work will need both ROS 1 and ROS 2 support. So, forking the code and providing only passive fixes in old releases is not a good option. 

For the past five years or so, I've mostly been able to maintain a unified implementation that works with all current releases. The only significant exception was the catkin transition, which was painful. I released several catkin packages with significant bugs. The usual root cause was some kind of install error, exacerbated by the fact that unit tests cannot verify that everything needed has been installed. Maybe ament will handle that better by testing the install space. I really hope so. 

--

 joq

[William Woodall]

On Thu, Jul 16, 2015 at 4:52 PM, Jack O'Quin <jack....@gmail.com> wrote:

On Thu, Jul 16, 2015 at 6:29 PM, William Woodall <wil...@osrfoundation.org> wrote:

On Thu, Jul 16, 2015 at 4:04 PM, Jack O'Quin <jack....@gmail.com> wrote:

On Thu, Jul 16, 2015 at 5:50 PM, William Woodall <wil...@osrfoundation.org> wrote:

It's easy to get depressed by the amount of work that is ahead to migrate something like the navigation stack, but I personally would love to dig into the nav stack, figure out how it could be better/faster/more modular using ROS 2, and implement something incrementally better than what's there. The question is always resources to do so, but I believe those will come eventually. So I try to be excited about the possibilities.

My question is: who is going to maintain all that old, crufty, but absolutely essential, code while all this fun, creative, new work is being done? 

In most major projects, maintenance outweighs new development by a considerable margin.

Personally, I've spent much more time maintaining existing stuff in ROS 1 since joining WG almost exactly three years ago to "work on ROS 2" and that's part of the reason ROS 2 has been long talked about with little done on it. So from my perspective ROS 1 has been a much higher priority than ROS 2 for as long as I've been doing this. I don't expect that to change for a long time yet, except for in spurts where we try to sprint new stuff into ROS 2 (like we're currently doing). There are, and will continue to be, lots of people using ROS 1, so I don't expect there to be a lack of need to keep it working. I believe that motivation and resources (volunteer and financial) will come based on the need, but maybe I'm naive (I'm an engineer not a businessman).

We're dedicated to keeping core ROS 1 packages working and up-to-date as well as maintaining infrastructure used by the community. I don't think our ROS 2 work has to get in the way of this.

The main difference with device drivers is that we mostly work on supporting new models and fixing problems with existing hardware. For years, that work will need both ROS 1 and ROS 2 support. So, forking the code and providing only passive fixes in old releases is not a good option. 

It is important for us to make maintaining differences between ROS 1 and ROS 2 as easy as is possible (it saves us time too), but at least for the drivers it might not be as critical to have a ROS 1 and ROS 2 version of every driver. If the bridge is good enough/easy enough to use then using openni2 from ROS 1 for work in ROS 2 might be a perfectly fine arrangement for the time being. Obviously people will want to avoid doing that if at all possible, but if people really need or want drivers for both, then they'll have to help people like you maintain them.

 

For the past five years or so, I've mostly been able to maintain a unified implementation that works with all current releases. The only significant exception was the catkin transition, which was painful. I released several catkin packages with significant bugs. The usual root cause was some kind of install error, exacerbated by the fact that unit tests cannot verify that everything needed has been installed. Maybe ament will handle that better by testing the install space. I really hope so. 

If the tests are built into the build space of the package they're testing then there is alway the chance that they incorrectly use some built artifact rather then something that's supposed to be installed. The only sure fire way to avoid this is to put your tests in a different package, usually something like `test_my_package`. `ament` doesn't really do anything specific to help with this, but at least you don't have to worry about interference from the devel space or differences in the devel space and the install space.

 

--

 joq

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

[Thibault Kruse]

On Friday, July 17, 2015 at 12:05:18 AM UTC+2, William Woodall wrote:

It seems that ROS2 is planned to share not a single line of code with ROS1.

It shares lots of code, but you're right that sharing mostly takes the form of copy, adjust to fit surrounding code, and update to use C++11 where appropriate. But this is mostly an artifact of the amount of changes that need to be made in these low level core packages.

Ok, I do indeed mean "share" as in: If you change the line of code, it will affect both ecosystems, a bugfix fixes both.

(And as far as I am aware, no change *needs* to be done. ROS1 is a success. It's all about what changes OSRF *wants* to do.)
 

What about the other tools

rviz, roslaunch, rosrun, rqt_..., rosmsg, rospack, rosbag, rosnode, rostopic, rosparam 

Will those all also be copied and maintained in their own repositories for ROS2, with new ideas being added for ROS2 but not backported, in order not to disturb ROS1? Because at a glance it seems that it would be difficult to make those tools work nicely with ROS2 as they are.

[...]

rosrun, rosmsg, rosnode, rostopic, and rosparam will probably have completely new implementations since the bulk of their work will be using the ROS 2 interfaces. The only common code between the two would be CLI stuff. It's not clear to me if sharing between them would be a good idea, but gut reaction is that it would not. Also we're thinking about ways to avoid overloading of the tool names on the command line. In systems where you have ROS 1 and ROS 2 in play, then either rostopic from ROS 1 or ROS 2 will be first on the PATH, but both cannot be accessed if they have the same name. This could be avoided by never having one terminal with both sourced, but I imagine it could get confusing. Maybe we'll end up with ros2topic and ros2run and so on as aliases to avoid some of the overloading and confusion, but I always disliked that pattern since it sounds like you're converting something called ros to something called topic, for example.

 
Did you consider choosing a different name than ROS at all? Since most of the implementation is not backwards compatible, ROS2 seems as much a new middleware as MOOS or Orocos. It would compete with ROS1 for contributors time, as in: Every hour spent on ROS2 is an hour not spent on ROS1, since code is generally not shared. So the already tight maintainership situation in ROS will become even tighter, as maintainers will have to split their time, or support only one side of the trench.

A new name (like DDS Industrial Robotics Kit) could yield a new acronym to serve as prefix for all commands. And a new name would make it easier to justify the lack of backwards compatibility.

Having all code in middleware-agnostic modules wrapped with middleware specific code is a good idea, but not a realistic solution.


On Friday, July 17, 2015 at 12:31:24 AM UTC+2, William Woodall wrote:

On Thu, Jul 16, 2015 at 9:00 AM, Jack O'Quin <jack....@gmail.com> wrote:

[...]

But, for the mass of shared, community-maintained packages, ROS 1 -> ROS 2 migration reminds me too much of the python2 -> python3 disaster. [...]

I agree with your comparison to the Python2 => Python3 migration for the most part. I think the migration of the community from ROS 1 to ROS 2 will be slow and by attrition. But I don't see a better way, the only alternative with less effort is to avoid changes that really should be made, and I don't know of a way that Python could have made the changes it needed to make while avoiding the cost of transition for its community.

One thing the Python community did was to follow the PEP process, to let the community distinguish between changes that "really should be made", and changes which are just pet peeves of individuals. Why not introduce something like the PEP process for the ROS community? We could call it, ... let's see... REP?

[Tully Foote]

Thibault,

Please stop trolling. Several of your recent emails have been very provocative. You know the acronym for DDS Industiral Robotics Kit is. The ROS 2.0 effort is not just OSRF's pet peeves. You know about the REP process. You know that we've chosen a similar process to follow using design.ros2.org. Provocative statements and personal digs derail the conversation and make it harder for us to have meaningful discussions.

We would appreciate your constructive contributions to the design and development process of ROS 2.0. I know that you have good insights and would like your input as we are designing and developing ROS 2.0. However if you cannot maintain a professional attitude I ask that you please refrain from participating in the process.

Tully

--

[William Woodall]

On Fri, Jul 17, 2015 at 1:49 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

On Friday, July 17, 2015 at 12:05:18 AM UTC+2, William Woodall wrote:

It seems that ROS2 is planned to share not a single line of code with ROS1.

It shares lots of code, but you're right that sharing mostly takes the form of copy, adjust to fit surrounding code, and update to use C++11 where appropriate. But this is mostly an artifact of the amount of changes that need to be made in these low level core packages.

Ok, I do indeed mean "share" as in: If you change the line of code, it will affect both ecosystems, a bugfix fixes both.

(And as far as I am aware, no change *needs* to be done. ROS1 is a success. It's all about what changes OSRF *wants* to do.)

I agree that ROS 1 is a success, that's part of why we want to preserve its stability so people can build on that, but I think equally true to say that ROS 1 isn't perfect and that there's always room for improvement.

A lot of the things we're doing in ROS 2 are things we at OSRF want to do, but it's worth pointing out that the things we want to do are based on our experience working with robots and feedback from people in the community or people who don't use ROS 1 (usually for one particular reason or another).

 

 

What about the other tools

rviz, roslaunch, rosrun, rqt_..., rosmsg, rospack, rosbag, rosnode, rostopic, rosparam 

Will those all also be copied and maintained in their own repositories for ROS2, with new ideas being added for ROS2 but not backported, in order not to disturb ROS1? Because at a glance it seems that it would be difficult to make those tools work nicely with ROS2 as they are.

[...]

rosrun, rosmsg, rosnode, rostopic, and rosparam will probably have completely new implementations since the bulk of their work will be using the ROS 2 interfaces. The only common code between the two would be CLI stuff. It's not clear to me if sharing between them would be a good idea, but gut reaction is that it would not. Also we're thinking about ways to avoid overloading of the tool names on the command line. In systems where you have ROS 1 and ROS 2 in play, then either rostopic from ROS 1 or ROS 2 will be first on the PATH, but both cannot be accessed if they have the same name. This could be avoided by never having one terminal with both sourced, but I imagine it could get confusing. Maybe we'll end up with ros2topic and ros2run and so on as aliases to avoid some of the overloading and confusion, but I always disliked that pattern since it sounds like you're converting something called ros to something called topic, for example.

 
Did you consider choosing a different name than ROS at all?

At the risk of answering a rhetorical question, yes we did.

 

Since most of the implementation is not backwards compatible, ROS2 seems as much a new middleware as MOOS or Orocos.

In many ways you're right, this is a new middleware, however, I think that it's also fair to say that it is a close iteration on ROS 1, more so than anything else in the group of things you just compared it to. Of course all pub/sub middlewares share many of the core concepts, but I'd argue that ROS 2 is closer in concept and form to ROS 1 than it is to DDS or Orocos or MOOS. Ultimately we decided to stick with the ROS name. 

 

It would compete with ROS1 for contributors time, as in: Every hour spent on ROS2 is an hour not spent on ROS1, since code is generally not shared.

I think that has truth to it, but it is also a bit flawed since it discounts the time people might choose to spend on ROS 2 rather than working on a different hobby or doing a lot of extra work to bridge parts of their system into ROS 1 because ROS 1 doesn't operate well in that use case or even spending time on another robotics platform because ROS 1 doesn't meet their needs.

 

So the already tight maintainership situation in ROS will become even tighter, as maintainers will have to split their time, or support only one side of the trench.

As one of the major contributors and maintainers of ROS 1 (even before doing it full time) I'm keenly aware of this. I, and I'm certain many others, agree with the sentiment, but I'm not sure how else to reconcile this with the fact that we need to continue to make improvement to the core of ROS in order to meet the needs of more users. I think the approach we've taken will be slower and require more effort on our part and on the communities part, but it will also be the least risky and least disruptive to the ROS 1 ecosystem. There will be effort spent on ROS 2 which could have been spent on ROS 1, but I think neglecting some effort like ROS 2 would be short sited. By working on improvements in the core of ROS and increasing the number of applications and users that it can reach, I believe we are improving the viability of the community in the long term. You may believe that time would be better spent else where, but you are also not the only stakeholder in the community.

 

A new name (like DDS Industrial Robotics Kit) could yield a new acronym to serve as prefix for all commands. And a new name would make it easier to justify the lack of backwards compatibility.

I'll take that as sarcasm. Do you have a constructive suggestion?

 

Having all code in middleware-agnostic modules wrapped with middleware specific code is a good idea, but not a realistic solution.

Can you explain why you feel this is an unrealistic solution? Many components in ROS 1 already follow this pattern.

 

On Friday, July 17, 2015 at 12:31:24 AM UTC+2, William Woodall wrote:

On Thu, Jul 16, 2015 at 9:00 AM, Jack O'Quin <jack....@gmail.com> wrote:

[...]

But, for the mass of shared, community-maintained packages, ROS 1 -> ROS 2 migration reminds me too much of the python2 -> python3 disaster. [...]

I agree with your comparison to the Python2 => Python3 migration for the most part. I think the migration of the community from ROS 1 to ROS 2 will be slow and by attrition. But I don't see a better way, the only alternative with less effort is to avoid changes that really should be made, and I don't know of a way that Python could have made the changes it needed to make while avoiding the cost of transition for its community.

One thing the Python community did was to follow the PEP process, to let the community distinguish between changes that "really should be made", and changes which are just pet peeves of individuals. Why not introduce something like the PEP process for the ROS community? We could call it, ... let's see... REP?

I've discussed the point about using REP's in ROS 2 before. To summarize, we plan to create REP's once we have a better idea of what would go in them. Many of the articles on the design website will be good starting points for REP's in the future, but at the moment nothing is concrete enough to form a document so thorough and thought out as a REP. Also the Python community has had a long migration in spite of using the PEP process, so I take the criticism that we could involve the community at a more granular level, but I don't see how it addresses my original question on how we could save migration effort.

Despite what you might think, I really respect your opinion because it is often topical and salient, but I think that when you use sarcasm in a negative way or make comments personal by calling out individuals it detracts from the conversation. I also think that it makes it less likely that people feel like the email thread is a safe place to discuss their ideas and be a part of the conversation for fear of reprisal. I think it would be best for everyone if you could try to keep your comments positive or at least neutral. It's my opinion that your latest comments were not that, though you may disagree.

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

[Thibault Kruse]

On Friday, July 17, 2015 at 12:56:12 PM UTC+2, William Woodall wrote:

On Fri, Jul 17, 2015 at 1:49 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

So the already tight maintainership situation in ROS will become even tighter, as maintainers will have to split their time, or support only one side of the trench.

As one of the major contributors and maintainers of ROS 1 (even before doing it full time) I'm keenly aware of this. I, and I'm certain many others, agree with the sentiment, but I'm not sure how else to reconcile this with the fact that we need to continue to make improvement to the core of ROS in order to meet the needs of more users. I think the approach we've taken will be slower and require more effort on our part and on the communities part, but it will also be the least risky and least disruptive to the ROS 1 ecosystem.

I am a bit tired of hearing this "non-disruptive of ROS1" argument. Basically ROS2 is the preparation for the mother of all disruptions to the ROS1 ecosystem. A slow, large-scale migration of thousands of packages to a different middleware. I believe it would be more honest if OSRF said that OSRF prefers disruption by migration over disruption by evolution, or something.

 

A new name (like DDS Industrial Robotics Kit) could yield a new acronym to serve as prefix for all commands. And a new name would make it easier to justify the lack of backwards compatibility.

I'll take that as sarcasm. Do you have a constructive suggestion?

I would suggest to ask the community on ros-users for name suggestions.

Having all code in middleware-agnostic modules wrapped with middleware specific code is a good idea, but not a realistic solution.

Can you explain why you feel this is an unrealistic solution? Many components in ROS 1 already follow this pattern.

Because most don't. It's an additional hassle that many people feel they are not being paid for. A new release of a package would always require testing of the wrappers in multiple middleware contexts.

On Friday, July 17, 2015 at 12:31:24 AM UTC+2, William Woodall wrote:

On Thu, Jul 16, 2015 at 9:00 AM, Jack O'Quin <jack....@gmail.com> wrote:

[...]

But, for the mass of shared, community-maintained packages, ROS 1 -> ROS 2 migration reminds me too much of the python2 -> python3 disaster. [...]

I agree with your comparison to the Python2 => Python3 migration for the most part. I think the migration of the community from ROS 1 to ROS 2 will be slow and by attrition. But I don't see a better way, the only alternative with less effort is to avoid changes that really should be made, and I don't know of a way that Python could have made the changes it needed to make while avoiding the cost of transition for its community.

One thing the Python community did was to follow the PEP process, to let the community distinguish between changes that "really should be made", and changes which are just pet peeves of individuals. Why not introduce something like the PEP process for the ROS community? We could call it, ... let's see... REP?

I've discussed the point about using REP's in ROS 2 before. To summarize, we plan to create REP's once we have a better idea of what would go in them. Many of the articles on the design website will be good starting points for REP's in the future, but at the moment nothing is concrete enough to form a document so thorough and thought out as a REP.

I believe the community input is what should make a REP thorough and thought out. The initial draft of a REP can be lofty and high level, it can contain ideas to be buried later (mentioned in the REP as duds), and contain alternatives not yet decided upon. The more humble (undecided) the initial draft is, the less people will criticize, seizing instead the opportunity to think about issues andparticipate.

You can have a draft REP about ament, one about the package indexer, one about the symlinked install, one about switching to C++11 and python3-exclusivity, one about topic remapping... If you have a working prototype, I don't think you can argue nothing is concrete enough for an initial REP draft.

Creating an individual REP for each feature would also make it easier to decide on a case-by-case basis what can be introduced into ROS1, and what cannot, by estimating what the disruption would be and gauging if the community is willing to accept that or not (and live with the consequence of large a middleware schism).

Despite what you might think, I really respect your opinion because it is often topical and salient, but I think that when you use sarcasm in a negative way or make comments personal by calling out individuals it detracts from the conversation. I also think that it makes it less likely that people feel like the email thread is a safe place to discuss their ideas and be a part of the conversation for fear of reprisal. I think it would be best for everyone if you could try to keep your comments positive or at least neutral. It's my opinion that your latest comments were not that, though you may disagree.

I shamelessly agree to my last comments not being positive or neutral. But that would be something to discuss via personal communication (off-topic in this thread/group, IMHO).

[Jack O'Quin]

On Sat, Jul 18, 2015 at 5:09 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

On Friday, July 17, 2015 at 12:56:12 PM UTC+2, William Woodall wrote:

On Fri, Jul 17, 2015 at 1:49 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

So the already tight maintainership situation in ROS will become even tighter, as maintainers will have to split their time, or support only one side of the trench.

As one of the major contributors and maintainers of ROS 1 (even before doing it full time) I'm keenly aware of this. I, and I'm certain many others, agree with the sentiment, but I'm not sure how else to reconcile this with the fact that we need to continue to make improvement to the core of ROS in order to meet the needs of more users. I think the approach we've taken will be slower and require more effort on our part and on the communities part, but it will also be the least risky and least disruptive to the ROS 1 ecosystem.

I am a bit tired of hearing this "non-disruptive of ROS1" argument. Basically ROS2 is the preparation for the mother of all disruptions to the ROS1 ecosystem. A slow, large-scale migration of thousands of packages to a different middleware. I believe it would be more honest if OSRF said that OSRF prefers disruption by migration over disruption by evolution, or something.

ROS 1 non-disruption is not an argument. It is a requirement that has been forcefully communicated to OSRF by many (probably most) of the current ROS 1 community.

I believe the impetus for ROS 2 comes mainly from a different, more industrial product development  community, who would like to use ROS but for various reasons cannot in its current form.

This is somewhat over-simplified and just my opinion (OSRF speak quite well for themselves). But, if I am correct, the initial ROS 2 target users are not the research labs who make up much of the existing ROS 1 community. 

The academics I know want stability so they can run their experiments and publish papers. They do not care much about low-level infrastructure, and begrudge every minute spent upgrading. They hated the catkin migration. It was time-consuming, and for them rosbuild actually worked better. 

Many product developers want new features, like DDS, and light-weight C language interfaces with few dependencies. They need their wire-level protocols fully documented, sometimes even verified and certified. They are less interested in ease of migration from ROS 1.

Why not just build separate products for the different user communities? That is generally easier to do. But, both the research and development communities stand to benefit from synergy between the two versions. 

So, what does it take to bridge those worlds well enough to justify calling the new project "ROS 2"? I don't have all the answers. Thibault, William, and others know better than I do. But, I believe the major benefit and the justification for calling both systems "ROS" is well-described in the "ROS on DDS" design document:

There is a great deal of value in the current ROS message definitions. The format is simple, and the messages themselves have evolved over years of use by the robotics community. Much of the semantic contents of current ROS code is driven by the structure and contents of these messages, so preserving the format and in memory representation of the messages has a great deal of value. In order to meet this goal, and in order to make DDS an implementation detail, ROS 2.0 should preserve the ROS 1.x like message definitions and in memory representation.

 http://design.ros2.org/articles/ros_on_dds.html#messages

--

 joq

[Dirk Thomas]

On Sat, Jul 18, 2015 at 10:51 AM, Jack O'Quin <jack....@gmail.com> wrote:

On Sat, Jul 18, 2015 at 5:09 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

On Friday, July 17, 2015 at 12:56:12 PM UTC+2, William Woodall wrote:

On Fri, Jul 17, 2015 at 1:49 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

So the already tight maintainership situation in ROS will become even tighter, as maintainers will have to split their time, or support only one side of the trench.

As one of the major contributors and maintainers of ROS 1 (even before doing it full time) I'm keenly aware of this. I, and I'm certain many others, agree with the sentiment, but I'm not sure how else to reconcile this with the fact that we need to continue to make improvement to the core of ROS in order to meet the needs of more users. I think the approach we've taken will be slower and require more effort on our part and on the communities part, but it will also be the least risky and least disruptive to the ROS 1 ecosystem.

I am a bit tired of hearing this "non-disruptive of ROS1" argument. Basically ROS2 is the preparation for the mother of all disruptions to the ROS1 ecosystem. A slow, large-scale migration of thousands of packages to a different middleware. I believe it would be more honest if OSRF said that OSRF prefers disruption by migration over disruption by evolution, or something.

ROS 1 non-disruption is not an argument. It is a requirement that has been forcefully communicated to OSRF by many (probably most) of the current ROS 1 community.

Thank you, Jack, for stating it that clearly.

I really hope that we (as the whole community) reaches a consensus on this part: that it is a *requirement* and not an argument to discuss about for longer.

I believe the impetus for ROS 2 comes mainly from a different, more industrial product development  community, who would like to use ROS but for various reasons cannot in its current form.

This is somewhat over-simplified and just my opinion (OSRF speak quite well for themselves). But, if I am correct, the initial ROS 2 target users are not the research labs who make up much of the existing ROS 1 community. 

The academics I know want stability so they can run their experiments and publish papers. They do not care much about low-level infrastructure, and begrudge every minute spent upgrading. They hated the catkin migration. It was time-consuming, and for them rosbuild actually worked better. 

Many product developers want new features, like DDS, and light-weight C language interfaces with few dependencies. They need their wire-level protocols fully documented, sometimes even verified and certified. They are less interested in ease of migration from ROS 1.

Why not just build separate products for the different user communities? That is generally easier to do. But, both the research and development communities stand to benefit from synergy between the two versions.

Whenever we separate academia and industry usage we do that based on the "common" use cases of those two domains.

We should keep in mind that academy might very well have use cases that are not well supported in ROS 1 and therefore would like to use ROS 2.

The same goes for industry: for a few applications ROS 1 might be well suited.

In general I agree to your command that initially it is likely that "academia" will stay with ROS 1 for a while and industrial users might start considering ROS 2 if they avoided ROS 1 for good reasons.

But I don't this has to be the case for long.

Wherever "academy" (or any other ROS 1 user) has use cases which are not satisfied well enough in ROS 1 - to name a few:

* communication over unreliable / wireless network

* multi robot scenarios

* real time requirements

* integration with embedded systems

I am certain they will consider to use ROS 2 since it is supposed to fulfill these requirements much better compared to ROS 1.

Simply because it will get them to their goal faster and with less effort.

- Dirk

[Thibault Kruse]

On Saturday, July 18, 2015 at 7:51:52 PM UTC+2, Jack O'Quin wrote:

On Sat, Jul 18, 2015 at 5:09 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

On Friday, July 17, 2015 at 12:56:12 PM UTC+2, William Woodall wrote:

On Fri, Jul 17, 2015 at 1:49 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

So the already tight maintainership situation in ROS will become even tighter, as maintainers will have to split their time, or support only one side of the trench.

As one of the major contributors and maintainers of ROS 1 (even before doing it full time) I'm keenly aware of this. I, and I'm certain many others, agree with the sentiment, but I'm not sure how else to reconcile this with the fact that we need to continue to make improvement to the core of ROS in order to meet the needs of more users. I think the approach we've taken will be slower and require more effort on our part and on the communities part, but it will also be the least risky and least disruptive to the ROS 1 ecosystem.

I am a bit tired of hearing this "non-disruptive of ROS1" argument. Basically ROS2 is the preparation for the mother of all disruptions to the ROS1 ecosystem. A slow, large-scale migration of thousands of packages to a different middleware. I believe it would be more honest if OSRF said that OSRF prefers disruption by migration over disruption by evolution, or something.

ROS 1 non-disruption is not an argument. It is a requirement that has been forcefully communicated to OSRF by many (probably most) of the current ROS 1 community.

I know, I am not tired of the community requesting this. I am tired of OSRF using that as an excuse for creating a new competing middleware.

There are multiple interpretations of what the community means when it says "We want less disruptions in the future":

A) Do not improve ROS1, create a new competing middleware to which we'll have to slowly and painfully migrate.
B) Put all future improvements into ROS1, but make the changes backwards compatible and well-tested.

I believe B reflects better than A what the community wants.

There is also C:
C) Create yet another middleware if you must, but continue to improve ROS1, and make changes to ROS1 backwards compatible and well-tested

But C obviously requires much more effort to everyone, and is not realistic. As as you can see with catkin and ament, it is very tempting for OSRF to just leave ROS1 behind, and make improvement only in the ROS2 world. You can also read it in all the OSRF answers saying: "Improving catkin could have caused regressions, so we did not improve catkin". With that argument, no further improvements will be made to ROS1. The same goes for all other packages maintained outside OSRF with the expectable low level of code sharing.


The alternative that the community could well have expected would be to make the communication layer exchangeable under a common client API (which can be changed/enhanced over time using tic-toc deprecation). That would mean all further improvements would have benefitted the community, but the community would not have to change much or migrate. This is the obvious benefit of maximum code sharing.

Apparently OSRF does not want to do that, and the consequence will be a huge disruption to the ROS community, as opposed to the wish expressed by the community.

Note that this is not fatal to anyone, and maybe in 10 years people will look back and praise OSRF for the courage and wisdom. I only explain that this is the opposite of what the community wants now.

That's what I mean when I say I am tired of the "non-disruptive of ROS1" argument.