ROS only simpler

[tfoote]

@actinium226

I hope you’ll forgive the sarcasm but I thought it was the most effective way to get my point across.

Please don’t use sarcasm in forum posts. They are easily misunderstood. The tone that you intend is often lost when translated to text and is especially hard to understand for non-native language readers.

@actinium226

This distinction feels academic. If there were tutorials or use cases where ament_cmake was used by itself, then it might make sense, but from an outside perspective it appears to be designed to work hand-in-glove with colcon as a single unit.

Indeed they are designed to work well together. But that doesn’t mean that they’re not useful separately.

This distinction may seem academic to you but this distinction is quite important. There are many use cases where we leverage this distinction. The first and actually most common one is that things like all the debian packages build and used every day simply use the pure build system and don’t invoke any build tool. I believe that all the other packaging mechanisms for distribution also leverage the build system directly and don’t use a build tool. All of these mechanisms effectively have their own infrastructure that replaces the need for a build tool. When you’re compiling from source having the build tool is much more important to deal with all the different elements on your system and enable you to keep your workspace up to date. We don’t have the documentation of how to use the build system without the build tool in our core tutorials as it greatly increases the complexity of what we need to teach. That doesn’t mean there aren’t active use cases.

As an aside I don’t think it’s useful to go into detail here about what actually ament_cmake is. Please see the linked documentation. But it’s really just a cmake library to make writing CMakeLists.txt more compact. You’re just invoking CMake to build the packages.

The other place where the separation of the build tool and the build system is important is when you’re crossing languages. We support packages using multiple languages with their own build system. The build tool iterates over each of the packages and invokes it’s build system in the right sequence. To that end if we didn’t have the separation between the build system and the build tool then we couldn’t integrate packages across multiple languages.

@actinium226

Is this your idea of a reasonable workflow???

You look to be taking this out of context. This is in reply to a comment that said that the external project to be integrated with had a system that’s unable to be integrated. If you start with that as a premise, this would be the only approach and it would work.

And in practice this is exactly how almost every system is actually built. You got through a sequence of tools and buildsystems to install layer on top of layer onto your system until you have all the features that you want.

@actinium226

Another academic point that’s missing the spirit of the discussion. Saying the build tool is optional to use is like saying that using either Linux or Windows is optional. It’s also not true, the build system doesn’t generate the setup.bash file.

As I pointed out above the build tool is optional and there are active use cases which are working not using it. In addition to the use cases I highlighed above there are also projects that are simply importing and building ROS packages using just the CMake/ament_cmake functionality.

I’m not sure what gave you this impression about the setup scripts, but it’s incorrect. Setup files are generated for each package by the build system, ament_cmake, if you test out a single package by doing your usual cmake; make; make install that there will be setup files generated. However the convenient workspace level setup files that aggregate all the packages in the correct topological order are generated by the build tool because it’s the only thing that knows the topological order. And if you don’t want to use a build tool, then you need to have something else to replace that aggregation logic yourself.

@actinium226

I meant it in the sense that if I wanted to learn how to write some Python code, I can go learn how to write Python code. If I later want to publish that code, I can learn how the packaging system works. With ROS, you can either learn how to package the code first and then how to write it, or learn them simultaneously. This is the main criticism, that the package and build system/tool get in the way of writing code, and that perhaps there’s another approach where you can write the code and package it too without having to mix these two things, like the way they do it in Python. Obviously I’m not literally suggesting that ROS move to the exact Python/pip model, just pointing it out as a potential inspiration for a potential rethink to the package system. While ROS has a system that works and is very popular, I think it could do more to get out of the user’s way and I think this would be beneficial to ROS in the long term.

I think that jumping from learning how to package software at the same time as learning the new API is more complicated that doing one and then the other to “a potential rethink of the packaging system” is a bit of a non-sequitor.

I agree that we could do some of our basic tutorials outside the concept of a package with the goal of teaching separate elements simultaneously. This can allow you to keep the tutorials more focused. As has been pointed out earlier in this thread though there’s a cost to teaching people outside the standard development practices in that you’ll teach them one way to start and then later tell them, “don’t do it the way that we just taught you” because it’s bad practice. That will get people into bad practices.

You assert that the “package and build system/tool get in the way of writing code”. This is not connected to your previous line of though, it’s jumping from learning these two things together is potentially confusing, to stating that packaging gets in the way of developing code. I strongly disagree with this. Packaging is a very important tool for good software engineering. Purely writing lines of code is great, but what makes the ROS ecosystem vibrant is how much and how easily people can share code. And the first priority for making software shareable is to provide enough metadata for other users to be able to reuse the code. This is exactly the metadata that you need to give to the package. Likewise the package infrastructure makes you think about your dependency structure and what sort of modularity you can support. And we have a lot of tools for testing, linting, and distributing packages.

In your development you’re welcome to do anything you want in your CMakeLists.txt and you’re welcome to not create and setup a package.xml if you just want to leverage the functionality that ROS provides. But as soon as you want to share your code with others. You’ll want to export the appropriate .cmake files to support downstream users. And declaring your dependencies appropriately in your package.xml will make it much easier for users to verify that they have all the necessary dependencies satisfied.

You mention that ROS has a working system that’s popular, but then imply that the packaging is getting in the way of the system. However small modular packages are generally preferred due to their siginifcantly easier maintenance. This was highlighted in the recent guidelines for architecting ROS Guidelines on how to architect ROS-based systems

There’s always space for improvement in any system. Many times people learning a system can get frustrated and upset and believe that there must be a better way to do something. And as I just stated there usually is. But in these projects there’s a lot of history and built up functionality and experiences that have shaped the system over many times years of development. Proposing a general “rethink” of the system is not particularly helpful. If there are particular pain points that can be improved we can focus on improving those. If we run into blockers then maybe we need to consider structural changes. It would really help to focus on what you want to happen instead of general complaints that the current system doesn’t work for you.

@smac

The discussion above on Ament / Colcon does not change the fundamentals that they are the default and widely accepted toolset for ROS2. >90% of developers will be working with them. I believe that your and @actinium226 issues are very genuine and should be properly addressed with advanced documentation and examples without them however that is atypical for the majority of users. Having some note in the very early tutorials with links what you both describe would give folks like yourselves the opportunity to go down the road-less-traveled makes alot of sense. However, education conventions usually stipulates a concept needs to be brought up at least 3 times before its solidified in a students’ mind. The importance of additional exposure for new ROS users (and new linux/programmers) to the toolset cannot be overstated.

Indeed there’s always multiple ways to use any tool and we want to make sure to focus on the one that we recommend most people use. There will always be power users who divert from the beaten path, but it’s counter productive to try to teach new users all of the power options before they understand how to put together a whole system. This approach is much more rewarding and helps with getting people engaged quickly which is what they need to have a good experience and come back to learn more.

@Eric_Schumann

I started following the tutorial at: https://index.ros.org/doc/ros2/Tutorials/Rosidl-Tutorial/ , and the rails came undone. This tutorial fails to build with cryptic errors. One of our partners put me in touch with their ROS/ROS2 expert, and he is helping me work through the build environment issues. We will solve these issues, but this is pain I can do without. My first MQTT project worked in 30 minutes from start to hello world (with my own custom payload). I have so far invested 2 days of my time and at least a few hours of others time, and still do not have a working basic example of a custom payload with ROS2, in fact, we have so-far been unable to get the above tutorial to run on my development machine.

I’m sorry that you spent all that time working on this tutorial. As is called out at the top of that tutorial you’ve gotten ahead of our documentation, the tutorial starts with,

INCOMPLETE: this is a draft of an upcoming tutorial for creating and using custom ROS interfaces.
Disclaimer: The code provided is to support the explanation, it is likely outdated and should not be expected to compile as is"

This explains why you’ve likely been having an issue getting it to compile on your system. Since that tutorial is incomplete it’s likely more productive to find an example package as close to what you want to do to follow. In this case I’d recommend looking at a small representative package such as example_intefaces and examples

If others run into these sort of disclaimers in the future please take a moment to search and if nothing found ask on https://answers.ros.org to see if there might be another example you could follow or if there’s more up to date resources or an example you could follow. We have a large helpful community that can answer well crafted questions quite quickly. There are dozens of packages that declare their own messages that we could point you to as examples in the mean time until we have time to fill in that tutorial.