[cjwoodall]

I will admit I have almost always made the choice to not use ros2. I am trying to use it now for some work, and I can see where/when it would be useful...

But I almost always feel like there is just so much STUFF involved in ros, that really is just better resolved by having really robust controllers, well defined protocols, and everything else.

I wait to pass judgement until I have more information though

[mikepurvis]

I've been a ROS 1 (and now 2) user since 2010. I like the game engine analogy given elsewhere in the thread, in that ROS gives you some important things "for free" if you cooperate with its ecosystem conventions. Data bagging, visualization, teleop, and sim are the some obvious ones that I think a lot of teams don't think about if they're just focused on getting cartographer or whatever going, and not considering the larger development and debugging questions.

For some, packaging/deployment would also fall under the umbrella of a solved-by-ROS problem, however I don't think the Open Robotics supplied debs are suitable for most product deployments, for a variety of reasons that I've discussed in two separate ROSCon talks.

[dimatura]

I usually feel the same when starting something new. The "STUFF" is annoying and often feels like overkill when a project is new and minimal. Installing/building ROS, the package boilerplate, etc. And often I can get away with more minimal alternatives like just a single (possibly multithreaded) process, or multiple processes with a simple IPC. But then again I often end up wanting a lot of the extra stuff you get with ROS like the bags, the viewers, the cli tools, etc. LLMs help on both fronts though - they're decent at making DIY versions of ROS-like functionality, but they're also pretty good at handling the ROS boilerplate. (Which is one area where I'd see peppyOS being a severe disadvantage).

[jeff-hykin]

As someone who has used ros2, I feel fine passing judgment; it is terrible. If its easier to write your own stack, do it. Your own stack will be easier to add to and maintain long term. The conceptual design (nodes) is great, its just the execution that is awful.

[rcxdude]

This is my experience as well. The average quality in ROS is rock-bottom and so while it contains all of the things you might want from a robotics framework, you pay dearly for it. I would also say that whole the concept of distributed network modes is a convenient one for robotics development, stringing your control loops through such a structure is a recipe for disaster and should be avoided in your system design as much as possible (and one of the problems with ROS as a framework is that it heavily encourages this)

[Ekami]

Our goal is to make all of this super easy with the installation of a single script. We're also working on a SaaS in parallel which will allow you to fire up the whole stack in your browser, 0 setup required (you pick the robot you want and it runs in a sim in your browser). Then, when you're satisfied with the result you just run a bash script on your Jetson board and everything will work the same on your real robot.