Those aren’t good comparisons with ROS, in my opinion. For all of their internal complexity, both the linux kernel and git are single, monolithic repositories, and hence using a standard tool such as make makes sense.
ROS is a large set of interconnected repositories, and most of those repositories aren’t managed by a single entity (Open Robotics or anyone else). The closest analog I can think of offhand is Linux distributions, and there, you have tons of custom tooling (essentially everything around building .debs or .rpms can be considered equivalent).
You have some good points about making it easier to use more standard tools, and I’d be all for documentation to help that. But a lot of what catkin, ament, and colcon do is allow the simpler management of that large graph of loosely connected packages.
To be fair, there are actually infinite ways to build the software (or any software). In the end, a build system is just something that knows how to invoke the compiler command line for the source files in the correct order, and place the output files in known places. What catkin, ament, and colcon do is make it easier to follow the conventions and place everything where other packages expect. However, if you want to leave the beaten path and not use the recommended ways, then some friction is going to be involved. Again, I think some more documentation on what is going on at the lower levels would help here.
Yes, it would. In fact, after my initial encounter with catkin, I went looking for something like that and I found your repository: GitHub - gerkey/ros1_external_use. I wish none of “Hello, ROS!” examples used catkin, which could be introduced later, when really needed.
In my opinion that would even worsen the user experience.
First a user reads a tutorial how to write a package which teaches them to use plain CMake. Second the user moves on to the next tutorial where they want to create a library in one package and use it from another - but that tutorials says “forget what you just learned - and use catkin API instead of pure CMake”.
Perhaps. It highly depends on the distribution of needs of first time ROS programmers. There is a group, which doesn’t need to create packages, at least initially. It would help if “Hello ROS” tutorials mentioned that pure CMake can be used in these cases. Users who know that they will have to create multiple packages on day one, could skip over pure CMake section. It doesn’t really have to be a full section on CMake. Just a short footnote would help a lot, so a newbie like me would not assume that it is catkin or bust.
I don’t see why ROS needs to cater exclusively to people who have never used CMake before. Surely there’s a way to accommodate both users who are new to CMake and those who have used it before?
I understand what you’re trying to say, but it’s missing the point. Anything that can be done in one Turing-complete language can be done in another. The thrust of this thread is how can we reduce the friction required to “Bring Your Own Tool”, while also preserving the things that have made ROS successful to date.
Having read what has been posted so far I’m getting the feeling that the main threshold to start changing things is not technical, but the time and effort required.
If the current use-cases for which specialised tools were built can be supported by a different approach, I don’t believe anyone would object to this.
The question now becomes: who will do the work?
It’d be good to realise that what is there currently works for a large number of users, and the suggestions and enhancements in this thread require quite some effort to implement. Especially if they would have to be done in a way which doesn’t break the current workflows I believe.
This leads to the situation where many of the candidates that could do this work won’t feel motivated to do it, as they’re not being limited by the tools they use in the same way as the OP and other contributors in this thread feel they are (or know how to work around those limitations better). They’d then rather spend their time on other things such as the many items on the ROS 2 roadmap which have not seen any work yet.
As I wrote in my my initial comment, I’m not saying nobody should “complain” as they got all of this for free, but I’m worried this discussion will not lead to any actions if the originators do not own the problem and at least initiate something.
And then we end up with another “example” of how the ROS community is unwilling to use anything but their “custom tools”, which is actually not true at all.
I think it will really interest in industrials company if this will permit to any company to quickly enter in the ROS world, and their developers using “Standard programing tools” .
“The question now becomes: who will do the work?”
In this case, I would suggest to mutualize efforts and may be involve OSADL (osadl.org)
This is exactly what I was trying to explain: without someone owning the problem, suggestions such as these will not lead to any actions.
You’re asking a community of people which is already insanely busy just getting their work done to change something that works quite well for a large number of their use-cases. And you’re asking this because you feel this could lead to more users and it could support particular workflows better even though the developers you’re asking this of are not exposed to the same problems you appear to have identified (or are able to better cope with the limitations).
All this means is more work for developers that already have too much work.
And again, just to emphasise: I’m not saying nothing should change and everything is perfect as it is. I’m just trying to clarify why it may appear there isn’t much interest in what has been posted here by OP, you (@sancelot) and others.
May be like many people I would be voluntary to work on this project. I think it is a big challenge. But altough it is opensource I think the effort in this case will need sponsoring and supported by industrials company. As many people, I suppose, I am opened mind seeking a job if you find a company to pay my work !
@gavanderhoorn I just want to say, you’re absolutely right that I’m complaining about something that is free.
I guess I just wanted to raise awareness of the issue. I felt so frustrated working with these tools, it felt like I constantly had to fight the tool to achieve what I wanted. And I figured if I brought up my experience maybe some people would think “hm, yea, maybe there is a better way to do this”
I do think we’ve raised some good points here, and oftentimes it’s gotten back to the documentation. I think I would have been less frustrated if documentation had clearly explained, in some technical detail, how a particular tool worked. I’d love to contribute to the documentation, but I don’t know where to start. The catkin documentation has 4 separate pages each claiming to be some form of documentation for catkin. And if I contribute a change saying “this is how the tool works” and then the author of the tool changes how it works, do I have to go back and update the documentation? That sounds like a lot of work, and it sounds like something the tool developer should be responsible for. I can only look at the source code and behavior and make deductions about how it works, but since I’m not the developer I can’t really tell if what I’m seeing is intentional or emergent behavior.
I think it would be really great if OSRF stepped up and worked towards consolidating the documentation so that it’s (mostly) in one place, like Eigen or CMake or Python, and also encouraged its developers to provide technical explanations of tools in addition to high level explanations. From there, the community would be in a much better position to contribute to the docs and improve them further.
And again, I realize I’m complaining about something that’s free and asking others to do the work. I really just wanted to throw in my 2 cents to this issue because it felt better than stewing in silent frustration
Before linking them into the main tutorials list, I’d love to get feedback. Does something like this scratch the itch that we’re discussing? Where would you like to encounter it among the existing tutorial content?
If there’s enough interest, we could work together to create a fuller set of tutorials that offer an alternative on-ramp to ROS, where you don’t use catkin, or roscd, or even create ROS packages (i.e., no package.xml, no explicit dependency management). There are of course limitations on how far you can go with this approach, but it could be useful for those who are strictly users of ROS libraries and don’t want to adopt any of the ROS development tools.
Since those tutorials use the exact same code as the existing tutorials (I assume?) I think they should rather reference them instead of showing the same content. While they might reuse the content of the existing tutorials internally as a user I would be confused if there is a tiny difference between the source I am missing. Atm it is pretty much impossible to determine what is different and what is the same (which also makes it hard to give other feedback).
The second tutorial should have a bold message at the top that such a package is by design not releasable with bloom and can’t be built in a workspace together with other ROS packages. (For the first and third tutorial that would at least be possible after a package.xml has been added.)
@gerkey Hey these are great! I’ll see if I have some time tonight to add sections describing how to place the files and create a custom setup.bash to enable using rosrun/rosmsg.
I hear what @dirk-thomas is saying about how similar they are to existing tutorials, but I think it makes sense to have them self-contained. I do think it would make sense to add a blurb at the top as to why one might want to use plain cmake instead of catkin so that users can get relevant context.
Even better would be to add cmake as a third option to the {catkin | rosbuild} build system selector on those tutorial pages. Then we can maintain the shared content and its use in one place. I figure that we could consider that idea if we ever have enough new content to justify making changes to the original tutorials. For now I just want a way to represent the new ideas in a self-contained manner. I decided that that was easiest to do by liberally including (not copying) the contents of the original tutorials.
Yep. And that’s just a subset of the caveats that should be placed in front of this entire way of using ROS. If you take this path, you’re saying, “I don’t want to organize my code into ROS packages, I don’t plan to release my code via the ROS build farm, and I’m not trying to make my code easy for others to use in their ROS workspace. I just want to call into the ROS libraries from my code.”
Though foreign-sounding to those of us who are long-steeped in ROS development, I suspect that this perspective may in fact be appropriate for many users. For example, students doing one-off class projects may have no need to create a ROS package when they can instead write a bare Python script. Or a commercial team may already have its own code organization and release practices and be willing to depend on and use ROS, but not to mimic the way that ROS is developed.
It’s unfortunate this is what you took away from my post, as that was not what I was trying to say.
I actually tried to emphasise the opposite: your feedback is very valuable, as it’s coming from someone with a fresh perspective.
However, the chances of the situation being improved will increase significantly if, instead of “just” posting comments on a forum (note the quotes there), you (not you personally, but in general) actually own the problem and act.
It was more a bit of expectation management than anything else I believe.
There is another scenario: researcher, who wants to use ROS/Ignition simulation for algorithmic experimentation on embodied agents. This can be conveniently accomplished by building an executable with traditional C++ toolchain and interfacing with ROS infrastructure. The simplest tutorial how to accomplish that could be based on controlling the turtle in turtlesim.
Oh no, not at all, I just meant to say that you have a valid point here.
I agree with you. Unfortunately, my resources are limited, and so the most I had bandwidth to do is stir the pot. I figured it more productive to express an opinion rather than continue to be frustrated, and I think it’s been helpful! Clearly there’s good discussion on this thread and @gerkey has added to the docs so it looks like the situation is improving!
