RFC: How should we introduce people to ROS 2?

[Brian Gerkey]

hi,

Historically, we've recommended in documentation (e.g.,
http://wiki.ros.org/ROS/Tutorials/CreatingPackage) that people use ROS
via the ROS developer tools. This means that writing software that
uses ROS involves steps like (blanket caveat: everything here involves
catkin, but it was the same way with rosbuild; I consider them to be
equivalent in the sense that they are both "ROS developer tools"):

* create a catkin workspace
* write a package.xml file
* write a CMakeLists.txt file that calls things like
`find_package(catkin REQUIRED COMPONENTS nodelet)`
* build with catkin_make

Some of the setup steps can be mostly automated by catkin_create_pkg,
but the steps still happen and the resulting directory and file layout
and workflow are the same either way.

The fantastic growth of the ROS community demonstrates that this way
of doing things is not a showstopper for many many people around the
world. But, over the years, we've gotten a lot of feedback from people
who want to use ROS software but don't want to use ROS developer
tools. I can tell you that these days it is the single most common
criticism that I hear when asking people from any kind of organization
what they would change about ROS: don't make me use your build system
/ directory layout / workflow.

Recently, in response to that criticism, a few of us put together some
examples and documentation showing that the use of ROS developer tools
is very much optional:
https://github.com/gerkey/ros1_external_use
In that repo, we demonstrate how to use CMake or even just make (with
pkg-config) in a "normal" manner that doesn't change the user's
workflow or introduce unfamiliar tools. For example, here's a Makefile
that builds a ROS node:
https://github.com/gerkey/ros1_external_use/blob/master/ros1_comms/Makefile
The examples are not exhaustive and some of the steps are a bit rough
due to not being well-exercised, but most of the usual ROS operations
seem to be doable. That "normal" way of doing things has always been
possible, but we've never really promoted it. We're starting to
promote it now. I'm planning to migrate those docs into the wiki as an
alternative method for using ROS software.

I think that this differentiation of ROS *developers* from ROS *users*
is very important and is something that we have overlooked in our
documentation (while at the same time have worked hard to support in
our tools). If you want to write or modify a ROS (1 or 2) package,
then you must use the ROS developer tools; that's fair enough. But if
you just want want to write some code that uses ROS, then you can do
it pretty much whatever way you like. You may, like us, find the ROS
developer tools useful and decide to incorporate them into your
development. But you don't have to.

With this experience in mind, I'm now wondering how we should
introduce users to ROS 2. Specifically, as the primary entry point,
should we:

(a) Tell people to use ROS 2 by creating a ROS 2 package with a
package.xml and calling ament to build it?

or:

(b) Tell people to use ROS 2 by using CMake (or make&pkg-config) in
the normal way, without mentioning package.xml or ament?

or something else?

We'll of course document all reasonable approaches. The question here
is what we recommend to newcomers. If we choose (a), then we'll offer
the normal way as a secondary "external use" alternative like we're
starting to do now with ROS 1. If we choose (b), then we'll offer the
ROS way as the "advanced" or "contributor" workflow.

I'd love to get the feedback of this group on how to best present ROS 2.

thanks,
brian.

[Geoffrey Biggs]

I think that to answer this question, you need to benchmark the workload of each approach. The approach with the lesser workload is probably the best to promote first.

Another way to choose: Which has the lesser learning curve for new users of ROS? If you are targeting people who already have experience with tools like CMake or make, then they will rapidly get up to speed with using ROS that way. If they are new to development tools (or just development) in general, then either approach us going to require some learning, and so probably ament would be easier since it has more native support for RIS concepts like message types. So who are you targeting?

Something else comes to mind. Most large projects tend to have complex build systems that are hard to understand without some work , but are used "normally" externally while only contributors have to learn the project's build system's unique points.

Geoff

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

[Austin Hendrix]

One of the things that I think has made ROS very powerful is not just
the build system, but the package management that goes on within the
build system.

I'm going to argue that it's the addition of package management that is
one of the core selling points of ROS; it provides a unified way to
depend on and use other packages, and a (fairly) simple way to create
packages that others can depend on.

Add to that the ROS release tools and the build farm, and the barrier to
distributing binaries is incredibly low.

All of these tools are tightly integrated with the ROS build system, and
for that reason I think we should try to keep new users on the path of
using the ROS build system.

-Austin

[Bill Morris]

I think the ROS build system lowers the barrier to entry (understanding
cmake, etc) and time to project completion for newer programmers writing
robotics software.
Experienced programmers may find it a little tedious at the beginning,
but I think they will have an easier time finding documentation for
alternate workflows.

It isn't always the case but I wonder how much of this criticism is from
aversion to change?
At this point, I miss the ROS development environment when working on
code for other projects.

[Brian Gerkey]

On Wed, Mar 9, 2016 at 7:02 PM, Geoffrey Biggs <gbi...@killbots.net> wrote:
> I think that to answer this question, you need to benchmark the workload of each approach. The approach with the lesser workload is probably the best to promote first.
>
> Another way to choose: Which has the lesser learning curve for new users of ROS? If you are targeting people who already have experience with tools like CMake or make, then they will rapidly get up to speed with using ROS that way. If they are new to development tools (or just development) in general, then either approach us going to require some learning, and so probably ament would be easier since it has more native support for RIS concepts like message types. So who are you targeting?

That is a great point, and something that William has brought up when
we've talked about this issue. In the very early days of ROS, we
decided to use CMake but wanted to hide the `mkdir build; cd build;
cmake ..; make` process from people for whom it was unfamiliar. That
was pretty much what rosbuild started out doing. Then it grew to do a
lot of stuff magicallly for you.

catkin is a huge improvement over rosbuild in that it uses CMake in a
normal way and does much less magic. That's a good thing, I think, but
it's hiding less from the user, forcing you to at least get familiar
with CMake.

So I wonder: for the novice user, is catkin easier or harder than just
CMake? Using catkin, I still have to write CMake, and I also have to
write package.xml, and I have to call some catkin-specific macros.
Ignore catkin_create_pkg; if the ease-of-use comes from a helper to
generate template build files, we could do that as a standalone tool
that has nothing to do with ROS.

[Brian Gerkey]

On Wed, Mar 9, 2016 at 7:16 PM, Austin Hendrix <namn...@gmail.com> wrote:
> One of the things that I think has made ROS very powerful is not just the
> build system, but the package management that goes on within the build
> system.
>
> I'm going to argue that it's the addition of package management that is one
> of the core selling points of ROS; it provides a unified way to depend on
> and use other packages, and a (fairly) simple way to create packages that
> others can depend on.
>
> Add to that the ROS release tools and the build farm, and the barrier to
> distributing binaries is incredibly low.
>
> All of these tools are tightly integrated with the ROS build system, and for
> that reason I think we should try to keep new users on the path of using the
> ROS build system.

I definitely see that point, and it's something that both William and
Tully have brought up: by having our documentation tell users to
follow the ROS way of doing things, they're all automatically closer
to being able to share and release their code. No doubt that this
approach has led to more reusable and released ROS packages over the
year.

But aren't we being paternalistic by giving that advice? We're hiding
(or at least downplaying the existence of) what many users would find
to be a simpler way of doing things because we believe that we know
better than them, and we think that they'll thank us for it in the
long term.

[Brad Baillio]

As someone who develops a lot on Windows, GUIs form a large part of the build process.  (CMake-gui, Visual Studio/PyCharm/Eclipse et al for compilation, etc)

And there's always something to be said about have a GUI frontend that helps with introduction to new tools and workflows.

Even on Linux I still LOVE using cmake-gui.  Of course I have to edit the cmake files by hand when creating a package, but after that, I like being able to just open the project in cmake-gui and click 2 buttons and see things work.  And if there are failures, it's much clearer to me what failed and why.

So maybe an approach would be to allow the cmake workflow so people like me can continue to use cmake-gui and feel comfortable?

Or maybe an alternate approach is to create a gui frontend on the ament/catkin toolset?

[Jack O'Quin]

On Thu, Mar 10, 2016 at 10:04 AM, Brian Gerkey <ger...@osrfoundation.org> wrote:

On Wed, Mar 9, 2016 at 7:02 PM, Geoffrey Biggs <gbi...@killbots.net> wrote:
> I think that to answer this question, you need to benchmark the workload of each approach. The approach with the lesser workload is probably the best to promote first.
>
> Another way to choose: Which has the lesser learning curve for new users of ROS? If you are targeting people who already have experience with tools like CMake or make, then they will rapidly get up to speed with using ROS that way. If they are new to development tools (or just development) in general, then either approach us going to require some learning, and so probably ament would be easier since it has more native support for RIS concepts like message types. So who are you targeting?

That is a great point, and something that William has brought up when
we've talked about this issue. In the very early days of ROS, we
decided to use CMake but wanted to hide the `mkdir build; cd build;
cmake ..; make` process from people for whom it was unfamiliar. That
was pretty much what rosbuild started out doing. Then it grew to do a
lot of stuff magicallly for you.

catkin is a huge improvement over rosbuild in that it uses CMake in a
normal way and does much less magic. That's a good thing, I think, but
it's hiding less from the user, forcing you to at least get familiar
with CMake.

So I wonder: for the novice user, is catkin easier or harder than just
CMake? Using catkin, I still have to write CMake, and I also have to
write package.xml, and I have to call some catkin-specific macros.
Ignore catkin_create_pkg; if the ease-of-use comes from a helper to
generate template build files, we could do that as a standalone tool
that has nothing to do with ROS.

Our experience over many years with novice undergrads at UTexas was that rosbuild was much easier for them to learn than catkin. I suspect raw CMake would be similarly difficult. Many of them are first-year students.

It's not that they can't do it, just that it takes significant time and attention away from learning robotics. 

I am hoping that ament auto will get us something as easy as rosbuild was. So far, it looks promising.

--

 joq

[Bob Dean]

I think having the information up front and obvious would do a lot. For example, the first paragraph cloud be something like
"we have two approaches. <link>approach 1</link> uses the default ros build system. Use this if you are a) new to robotics b) have no pre-existing robotics software c) are interested in switching your current build system into the ros ecosystem. <link>approach 2</link> is designed for users who wish to include ros into an existing build infrastructure."

[Jack O'Quin]

On Thu, Mar 10, 2016 at 12:59 PM, Bob Dean <bob....@gmail.com> wrote:

I think having the information up front and obvious would do a lot. For example, the first paragraph cloud be something like
"we have two approaches. <link>approach 1</link> uses the default ros build system. Use this if you are a) new to robotics b) have no pre-existing robotics software c) are interested in switching your current build system into the ros ecosystem. <link>approach 2</link> is designed for users who wish to include ros into an existing build infrastructure."

+1 That seems reasonable to me.

--

 joq

[Thibault Kruse]

On Thursday, March 10, 2016 at 3:47:21 AM UTC+1, Brian Gerkey wrote:

I can tell you that these days it is the single most common
criticism that I hear when asking people from any kind of organization
what they would change about ROS: don't make me use your build system
/ directory layout / workflow.

There are two ways to interpret that kind of criticism:

A) The current ROS toolchain is great, but ROS should not promote any custom toolchain at all
B) The current ROS toolchain sucks, and it should either be improved, or removed

Without having a first-hand account of those criticisms, it is hard to tell the difference from your report.


Regarding the suggested alternatives (a) and (b), the aspects mentioned in the thread so far:
- effort at OSRF to document an approach
- learning curve for novices to software development
- appeal to academia
- deal-breaker for academia
- appeal to industry
- deal-breaker for industry
- ease of use for packaging and distributing source
- likelihood of software sharing and reuse
- robotics project completion time
- perceived disrespect for orthodox software standards
- Ability to use GUIs and the mouse
- Portability (Windows)

Rating each alternative in these categories and then building a weighted sum of these ratings is something OSRF will have to do anyway.

I'd like to add:

- Heterogenity of package landscape (how many tools do you need to know to run a demo on a PR2 style robot?)
- Migration effort (when OSRF introduces the next new(-ish) backwards incompatible buildsystem)
- Scalability (how well can large builds be optimized)
- Ease of cross-compilation of packages somebody else maintains
- Documentability and Package search (how easy to have a search engine for ros packages)
- Foreign packagability (how easy to package ROS packages in other package managers)

If I had to make the decision, I'd create a table listing those aspects and how well each alternative fares in each discipline, and then sort that table by priority top to bottom.
As a joint work product such a table would be fairly transparent in how the decision was made, much more so than having to track a discussion.


That is, unless the decision is a bike-shed anyway, given OSRF wants to provide the means for both approaches.

> So I wonder: for the novice user, is catkin easier or harder than just CMake?

CMake macros make things easier than pure cmake (duh). Having a workspace tool makes developing many projects in parallel easier (duh). Having lots of possibilities for package crosstalk during the workspace build process makes things much harder when anything goes wrong. Having cmake / setuptools macros/functions with unorthodox semantics also makes things much harder when anything goes wrong.

[Brian Gerkey]

Thanks, Jack, that's a great perspective to have. But then I wonder:
why do you teach your students to use catkin? As far as I know,
rosbuild still works fine as a way to write and build your own ROS
packages on top of other rosbuild packages and/or catkin packages. You
can't build catkin on top of rosbuild (not without some effort), and
you can't push rosbuild packages through the release system, but for
class projects, I wouldn't imagine that those issues matter very much.
I would guess that you could teach rosbuild and ignore catkin as an
internal implementation detail to the ROS package that they're
building upon.

[Geoff]

I also like this approach. Give the two methods equal treatment in the documentation, with an important exception. The ROS tutorials can use the ROS build system. I think that it is reasonable to assume that someone reading the ROS tutorials who does not have previous build system experience would be just as happy using the ROS build system, and someone who does have previous build system experience will be capable enough to refer to the documentation for the alternative method and adapt the tutorial materials appropriately.

 

Geoff

 

[Brian Gerkey]

On Thu, Mar 10, 2016 at 1:51 PM, 'Thibault Kruse' via ROS SIG NG ROS
<ros-sig...@googlegroups.com> wrote:
> On Thursday, March 10, 2016 at 3:47:21 AM UTC+1, Brian Gerkey wrote:
>>
>> I can tell you that these days it is the single most common
>> criticism that I hear when asking people from any kind of organization
>> what they would change about ROS: don't make me use your build system
>> / directory layout / workflow.
>
>
> There are two ways to interpret that kind of criticism:
>
> A) The current ROS toolchain is great, but ROS should not promote any custom
> toolchain at all
> B) The current ROS toolchain sucks, and it should either be improved, or
> removed
>
> Without having a first-hand account of those criticisms, it is hard to tell
> the difference from your report.

That's a good question, and I don't have a definitive answer. My
qualitative assessment is that for most people who are complaining the
reason is A: I shouldn't have to use ROS's toolchain. I already have
my own preferences on tools and workflow, and I don't want to change
how I do my work just because I'm using ROS software in my project.

This is not a technical good vs. bad judgement on those tools, and I
think that it is mostly what Bill described as "aversion to change."
But it's also a completely valid perspective, and one that I
personally identify with very much.

[Thibault Kruse]

So maybe we should realistically be talking about users who mainly provide ROS-agnostic software, but want to create ROS wrappers / bridges / plugins.

For those, it is a burden to create the ROS wrappers / bridges / plugins using special toolsets, so for such users it would be great to build against ROS without the toolset.

This is not merely aversion to change, but an aversion to use multiple different toolsets within the same project for similar tasks. That one I can identify with.

Similarly, we can imagine users who consider ROS just as a communication layer for a handful of processes developed inside their company, without reusing nodes from elsewhere, and most of the software functionality is created in a middleware agnostic way. We can imagine them to think about using ROS as a drop-in replacement for any other kind of messaging layer. Of course they don't want to have to switch to a new buildsystem to try out ROS as a replacement communication layer for their existing processes.

Both kinds of user would typically not even bother to check out other ROS packages from other labs to integrate with, because their job isn't to build a robot using packages from various sources.

So I believe both groups only care about ROS as a communication layer, not as a rich ecosystem of functional open-source packages to reuse. And they only care about how to compile against ROS core, not how to integrate existing functional ROS nodes from the open-source space, or provide packages to the open-source ecosystem in a most reusable way.

I would think that OSRF should be dedicated to promoting open-source and thus give priority to the kind of users who want / need to setup robots reusing various open-source packages, and that kind of user would have much less reservations against a standard set of tools for many packages.

Maybe I miss some kind of user group that has another good justification not to care about the ROS build tools, but I'd like to have good concrete examples for such users and why their aversion to ROS tooling is justified in practice, and not by principle.

[Jack O'Quin]

A reasonable question. Unfortunately, the answer is rather lengthy...

We converted our project packages to catkin back in 2013 as part of moving from Groovy to Hydro. It was a difficult migration, mostly because of the catkin learning curve, and a lack of user-oriented catkin documentation at that time. I ended up writing the catkin howto pages as a direct result of that experience. 

We chose catkin mainly because we wanted to continue using the ROS release system to publish our packages, as we had on Groovy with rosbuild. Although catkin was a difficult change, bloom provided clear and immediate benefits. We also did not want to depend on OSRF continuing rosbuild support for as long as you actually have done.

During the migration we had to use both wet and dry workspaces. While that worked and was necessary during the transition, it was cumbersome enough that we were motivated to migrate everything in order to simplify everyone's build and development work flow. Despite periodic Debian package releases, the system continues to evolve so rapidly that most developers continue building it all from source. (This *is* academic research :-)

At that point we could have continued to teach incoming students rosbuild, but I don't recall any serious discussion of doing it that way. They would have needed to create chained wet and dry workspaces, which is confusing even to experienced ROS developers. 

The purpose of the class is to get young students doing genuine research early in their academic careers. The best and most motivated ones continue working on the system after they finish the class. We wanted them to become comfortable looking at and working with our actual code running on the robots. Some students succeed in producing useful new packages or system modifications, which we want to incorporate into the base. They start out inexperienced, but also quite talented.

So it didn't seem worthwhile to teach them one way to do things while we use another. They'd end up having to learn both build systems, eventually. At least with catkin they have examples of how we already do most of the tasks they'll need.

--

 joq

[Daniel Stonier]

On 12 March 2016 at 22:30, Daniel Stonier <d.st...@gmail.com> wrote:

Thought I'd chime in from a workplace.

Our Catkin Users

Most of our young guys coming in, don't really know CMake. CMake itself, is quite complex. It can also be a nightmare because there is no systematically standardised approaches for things, e.g. find_package. From my experience, and I also suspect that in most teams, you probably only have the odd person who is a CMake (insert any other fairly popular build system here) expert.

Back to the young guys - they pick up catkin with little complaint. Actually, apart from the rosbuild -> catkin transition, I've had exactly zero complaints except for someone trying to do really fancy things to get the python side of things to work with existing but not debianised python packages (this could use some work). Bill, I believe your rant was the last rant about catkin we had in our lab :) This is pretty awesome as it saves me alot of time training people. It actually takes most of them a year or so to even start wondering about build systems and start puzzling about the finer details of cmake.

So there are two cases that catkin has done a very big favour in enabling:

• new users & non-experts in build systems (both typically have no interest or need of becoming experts)
• large projects

Ros Users vs Ros Developers

I would argue that there are already very many ros users (as opposed to ros developers). These people use catkin so they can build their own applications with a minimum of fuss but aren't interested in contributing to the ros ecosystem/community. We even have non-ros teams using catkin to build entirely non-ros software. These are different to the ros users (who just can't/dont wish to catkin) that are being discussed. Subsequently, I think the notion of ros-users and ros-developers is a little blurry.

CMake/Pkg-Config Experts

Anyone who can use CMake/pkg-config directly will be already at a much higher level of knowledge than most roboticists. As I said above, most teams actually don't need everyone to be a cmake expert. It just takes one, and he usually writes scripts/modules/templates for the others (sounds a little like catkin?).

Responses

(a) Tell people to use ROS 2 by creating a ROS 2 package with a
package.xml and calling ament to build it?

This has been a big success in the past and it is the least effort approach to enabling the majority of roboticists up to speed and start doing robotics. I would be wary of changing that. 

Having said that, technical support and a link to another page which lets the CMake/pkg-config/Visual Studio experts use ROS packages independently has to be considered a first class citizen in terms of maintenance and support if you wish to enable pickup of ROS beyond its current boundaries.

(b) Tell people to use ROS 2 by using CMake (or make&pkg-config) in
the normal way, without mentioning package.xml or ament?

This is going to force alot of people to learn much more complicated build systems. To me, it is analogous to telling an engineer he should learn how to use the extremely obtuse posix api for shared memory, filesystems, string handling rather than using something like boost equivalents that wrap the complexity of the posix api. They will consume alot of time doing something they don't need to be doing.

ROS should be about educating people in build systems, it is about enabling them to do robotics ... 

^shouldn't be about 

Note, if you handle a) properly then you are enabling both direct and indirect users of ROS. You are not holding anyone back.

(c) Other?

Is there really any alternative for complex robotics systems on linux/apple/win operating systems? If there is, use that. That's better than going back to raw cmake/pkg-config. I don't know of any that come sufficiently close to catkin/ament though. So that is a massive enabler. Stick to it like superglue.

Daniel

.

[Geoff]

On Sat, Mar 12, 2016, at 22:33, Daniel Stonier wrote:

On 12 March 2016 at 22:30, Daniel Stonier <d.st...@gmail.com> wrote:

Having said that, technical support and a link to another page which lets the CMake/pkg-config/Visual Studio experts use ROS packages independently has to be considered a first class citizen in terms of maintenance and support if you wish to enable pickup of ROS beyond its current boundaries.

 

This, I think, is the truly important bit, and it is at risk of getting lost in trend in this thread to discuss which method of using ROS is "better". Although I don't think the OSRF intends to say "everyone wants to use catkin, so no more pkg-config files for you!", I still want to state my support for giving first-class support to ROS packages, libraries, etc. working with tools like pkg-config and that equivalent tool for Visual Studio (the name of which I forget now, but it is very good). Amongst other things, it's simply being a good citizen to work with the tools that are effectively the standard on their platforms, whichever build system is ultimately promoted in the documentation as the preferred way.

 

Geoff

[Luetkebohle Ingo (CR/AEA2)]

+1

 

Mit freundlichen Grüßen / Best regards

Dr.-Ing. Ingo Luetkebohle

Software Architecture and Analysis (CR/AEA2)
Tel. +49(711)811-12248 | Fax +49(711)811-0 | Ingo.Lue...@de.bosch.com

--

[Nikolaus Demmel]

+1 for this and +1 for promoting catkin/ament as the default choice

[Daniel Stonier]

Thought I'd chime in from a workplace.

Our Catkin Users

Most of our young guys coming in, don't really know CMake. CMake itself, is quite complex. It can also be a nightmare because there is no systematically standardised approaches for things, e.g. find_package. From my experience, and I also suspect that in most teams, you probably only have the odd person who is a CMake (insert any other fairly popular build system here) expert.

Back to the young guys - they pick up catkin with little complaint. Actually, apart from the rosbuild -> catkin transition, I've had exactly zero complaints except for someone trying to do really fancy things to get the python side of things to work with existing but not debianised python packages (this could use some work). Bill, I believe your rant was the last rant about catkin we had in our lab :) This is pretty awesome as it saves me alot of time training people. It actually takes most of them a year or so to even start wondering about build systems and start puzzling about the finer details of cmake.

So there are two cases that catkin has done a very big favour in enabling:

• new users & non-experts in build systems (both typically have no interest or need of becoming experts)
• large projects

Ros Users vs Ros Developers

I would argue that there are already very many ros users (as opposed to ros developers). These people use catkin so they can build their own applications with a minimum of fuss but aren't interested in contributing to the ros ecosystem/community. We even have non-ros teams using catkin to build entirely non-ros software. These are different to the ros users (who just can't/dont wish to catkin) that are being discussed. Subsequently, I think the notion of ros-users and ros-developers is a little blurry.

CMake/Pkg-Config Experts

Anyone who can use CMake/pkg-config directly will be already at a much higher level of knowledge than most roboticists. As I said above, most teams actually don't need everyone to be a cmake expert. It just takes one, and he usually writes scripts/modules/templates for the others (sounds a little like catkin?).

Responses

(a) Tell people to use ROS 2 by creating a ROS 2 package with a
package.xml and calling ament to build it?

This has been a big success in the past and it is the least effort approach to enabling the majority of roboticists up to speed and start doing robotics. I would be wary of changing that. 

Having said that, technical support and a link to another page which lets the CMake/pkg-config/Visual Studio experts use ROS packages independently has to be considered a first class citizen in terms of maintenance and support if you wish to enable pickup of ROS beyond its current boundaries.

(b) Tell people to use ROS 2 by using CMake (or make&pkg-config) in
the normal way, without mentioning package.xml or ament?

This is going to force alot of people to learn much more complicated build systems. To me, it is analogous to telling an engineer he should learn how to use the extremely obtuse posix api for shared memory, filesystems, string handling rather than using something like boost equivalents that wrap the complexity of the posix api. They will consume alot of time doing something they don't need to be doing.

ROS should be about educating people in build systems, it is about enabling them to do robotics ... 

Note, if you handle a) properly then you are enabling both direct and indirect users of ROS. You are not holding anyone back.

(c) Other?

Is there really any alternative for complex robotics systems on linux/apple/win operating systems? If there is, use that. That's better than going back to raw cmake/pkg-config. I don't know of any that come sufficiently close to catkin/ament though. So that is a massive enabler. Stick to it like superglue.

Daniel

.

On 10 March 2016 at 11:47, Brian Gerkey <ger...@osrfoundation.org> wrote:

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

--

Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/

Yujin Inno: http://inno.yujinrobot.com/

[Lennart Na]

In relation to that I want to point out that I already used ROS 2 without ament and with ament in the same workspace.
1: It's great that ament does all dependency management
2: It's kind of nasty if you want to use ament and the classical cmake way, because there are users that want to use your project with both methods ( see https://github.com/ament/ament_cmake/issues/56 )
3: It's hard to combine with another (custom) build system you need to use for some legacy components from another framework. That's also the main point of critics I had in the past that it can be hard sometimes to use ROS as an addition to your own framework / buildsystem. Here the classical cmake way is much easier.
4: Building with ament can be slower than using cmake/make in a workspace that are invoked with a custom script -> this is fairly annoying if you need to do little changes because you're hunting down a bug.

But nevertheless it's possible to combine both ways in a single workspace/ project.

[William Woodall]

@Lennart

In regards to your #4, with both ament and catkin tools you can narrow what is getting built and that can significantly improve the turnaround time on a change. So if, for example, you made a change to a source file (.cpp) in rclcpp then you could do `ament.py build --only rclcpp` and that's not any slower than just doing cmake/make for just one cmake project. If instead you changed a header you might need to do `ament.py build --start-with rclcpp`. Furthermore, if you were wanting to see that change in your package "my_examples" you could narrow the scope even more to `ament.py build --start-with rclcpp --end-with my_examples`.

With catkin you can do similar things, and even more advanced things, with `catkin build`, see: http://catkin-tools.readthedocs.org/en/latest/verbs/catkin_build.html. Our plan is to integrate the two so there is a single tool, or two tools that share the same interface. But the main idea that is present in both tools, that I think could help you in terms of performance, is to narrow down what you build each time using contextual information you have about the state of the code from build to build.

Also catkin tools (which again we hope to merge with ament tools) can build packages in parallel when possible and would considerably improve the build time.

--

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/

[Brian Gerkey]

Thanks for all the great feedback! I must admit to being surprised by
the extent of support for promoting the "ROS way" of doing things. I
had incorrectly assumed that much of this list (an experienced group
of ROS hackers) was reluctantly using rosbuild/catkin/ament only
because there wasn't a good alternative. Lesson learned.

It seems clear to me that for ROS 2 we should fully describe both ways
of doing things, and do our best to track users in one direction or
the other depending on their intended use case (as opposed to
explicitly privileging one or the other).

On Wed, Mar 16, 2016 at 5:12 AM, Lennart Na <darkfi...@gmail.com> wrote:

[David Lu]

If anything, I would prefer going the other way: ROS all the way, with none of this CMake business. 

[Acorn Pooley]

I think for new users it is most helpful to describe one, and only one, way to create a ROS project. Multiple options lead to confusion and wasted time learning unnecessary things. So I recommend making it very clear that the ROS way is the way to go, with the information about using pkg-config and raw cmake (which is also very important for those who need it) being mentioned at more of a footnote, or "for people with special needs" level.

Acorn

[Andrew Hundt]

On Wednesday, March 23, 2016 at 2:45:43 AM UTC-4, Acorn Pooley wrote:

I think for new users it is most helpful to describe one, and only one, way to create a ROS project. Multiple options lead to confusion and wasted time learning unnecessary things. So I recommend making it very clear that the ROS way is the way to go, with the information about using pkg-config and raw cmake (which is also very important for those who need it) being mentioned at more of a footnote, or "for people with special needs" level.

Acorn

I agree with Acorn Pooley that in general it is best to describe and highlight the "one true way" to do something with a footnote/link referring experts to find the resources they need. 

 

On Mar 16, 2016 6:17 PM, "Brian Gerkey" <ger...@osrfoundation.org> wrote:

Thanks for all the great feedback! I must admit to being surprised by
the extent of support for promoting the "ROS way" of doing things. I
had incorrectly assumed that much of this list (an experienced group
of ROS hackers) was reluctantly using rosbuild/catkin/ament only
because there wasn't a good alternative. Lesson learned.

+1 I'm in the "reluctant" category you describe, though my experience is 90% non-ROS robots and 10% ROS robots. I'd also argue that good alternatives may very well exist somewhere out there. :-)