Why ROS is still choosen against ROS 2?

Next Generation ROS
,
21

I would say maturity is just fine for the stage we’re at. We’re coming up on Indigo was the first really-truly-definitely stable ROS 1 version. We just hit ROS 2’s I-turtle this year. I think much of the Zenoh work to clean-up internal ROS 2 layers to support non-DDS solutions & having a non-DDS solution will account for a good chunk of the gripes about ROS 2 - and that is very much so ongoing and with heavy involvement with Intrinsic’s team and is responding to community concerns.

I won’t say things are perfect, but its quite an exaggeration to talk like ROS 2 isn’t ready for production and its performance is so inadequate. All of Nav2 can run on a Raspberry Pi which is heavily uses all of ROS 2’s APIs. both with and without process composition with tons of room to spare.

Moreover, I can point to multiple tractor companies, delivery robots, quadrupeds, large scale autonomous drones, and warehouse robotics companies til the sun goes down that publicly boast their use of ROS 2 by extension of Nav2: Robots Using — Nav2 1.0.0 documentation

There are things to do still yet, but it is proven many times over and has serious involvement and investment from the likes of iRobot, Bosch, Amazon, Sony, TRI, and other serious players that aren’t just dabbling. So, I disagree with your general viewpoint on this subject. I tend to trend pessimistic about things, but I’m not at all pessimistic about ROS 2 in its current state or where the trajectory is taking us.

16 Likes
22

From a research perspective it is sometimes irrelevant how systems run. What matters are limited resources. In a paper, ROS is often mentioned as a side note, and has little contribution to research itself. This sometimes means that you have to allocate your limited resources carefully. So that is the legacy aspect.

If, however, you are in the luxurious position to explore ROS 2, you’ll find that there exists functionality that you wouldn’t want to miss, I am talking Python launch, asynchronous flows, first class actions, standard library, compatibility with deep learning libraries (not sure this is still a problem in ROS 1), plug and play over multiple machines, distributed parameters, communication to non-ROS systems.

This flexibility comes at a cost. ROS 1 hides a lot from the user, whereas ROS 2 gives you greater access and therefore also a greater burden. For individual use, especially in research, I am not in need of a system that runs flawlessly for months without deadlocks. I care about collecting data from a single experiment.

So maybe the gap is not research - industry, rather system scale? Maybe ROS 2 is aimed at large scale systems, when in reality small scale systems outnumber.

2 Likes
23

ROS 2 is stated to be designed for production. Therefore, we must evaluate its design and achievements under their self-proclaimed objective. The Foundation and the TSC are formed by several trillion-dollar and billion-dollar companies and I don’t understand why they expect us to comment like evaluating a fifth-year science project. Of course, I will ask for today’s highest standards for software and tools from the Foundation.

And this is the raison d’etre of having a Foundation in the first place. Every community member must ask them why they don’t find resources if there is a lack of manpower for project tasks. As a concrete solution, maybe the Foundation should increase FTE requirements from members. This is a much better and more sustainable solution than asking for volunteer/student help for critical infrastructure tasks.

24

I do understand your rationale for holding them against their proclamations. However, ROS 2 is FOSS and is largely driven by the community. It is the job of the community members (IMO) to demand new features, and the cool part is, if you know how to implement that feature, you can simply implement it and if all goes well, you have now contributed back to the project. If not, you’ve made a good effort, so maybe someone will take over from there and refine it to meet the needs of the general public.

A lot of stuff that the Foundation does that goes unseen would be organizing the conferences, going and meeting people, and asking them for their contributions to the ROS 2 project. This is largely how we have the sponsors, and hence, the project is in its current state as of today. You’ve got to take all that into account as well.

Is it perfect? No, not yet. Does it have the potential to be perfect? Of course, eventually. The endeavor is to bridge the distance between these two questions.

I’d leave you with a line stolen from JFK : “Ask not what the community can do for you, ask what you can do for the community.” You are doing your job as the critique, as you should. But, it might be of interest to take a step back sometimes and admire how much we have done from time to time, as well.

Have a nice day :grinning:

Cheers,
Sampreet

3 Likes
25

These commercial companies in the TSC are not here simply for the sake of science and research and open-source spirits —not saying it is a bad thing. Thus, I always give my production grade comments (thus unforgiving — production environments are unforgiving) based on this observation, as this is an academic-industrial project targeting production. Please do not ask for less as a researcher…

Working with a well-designed production environment is a great asset for researchers. It reduces the time-to-market and increases the speed of advancements by getting real-world feedback quicker. Yet, as stated in this thread many times, this is beyond the capacity of individual researchers and volunteers — I ignore the comments asking individuals to implement it if they do not like it. This is where companies must come in to help while taking their profits. Relying on volunteer efforts or ad-hoc contributions is no solution for production software. The Foundation must bear the responsibility to execute and manage it. This includes admitting failures as well to make it better.

Note that, apparently, the researchers’ concerns are not considered adequately in the design of ROS 2, and they see a regression between ROS 1 and ROS 2. This reveals that the TSC does not have enough academia-affiliated members to drive scientific advancement and idealism. I hope community representatives are taking notes…

1 Like
26

I agree with that, however: these contributions are highly focussed on technical functionality. Which is only natural, as the goal of the contributors is mainly to get their job done.

I think it is important to discriminate between ‘technical quality’ and ‘usability quality’.

The ‘technical quality’ is in fact already very high.
I have been astonished again and again by the available functionality in ROS 2 and Gazebo while developing my own application:
I run a ROS 2 setup for a multi-robot system with distributed control, online motion profile generation for synchronized motion, and operational modes configurable through parameters and launch files.
I have been able to fully debug my software, and I am currently implementing a perception system, without having the actual hardware available yet.
And the graphics are truly great as well, as I generated baked textures and light maps for all my models.

But: 1) I haven’t been running it 24/7 yet (so I can’t comment on stability for industrial use, holding my breath for that!), and 2) I has cost me blood, sweat and tears to get there.

Still now I often experience that adding a new feature requires extensive digging through code to look how something works or why it does not work as expected. And this indeed often still is very frustrating, even though in the meantime I got proficient at it, and learned best practices by doing.

This is the area of documentation / best practices / use cases / etc., i.e. ‘usability quality’. There’s a long way to go wrt this.

I don’t really see how the current organic way of waiting for community contributions can lead to significant progress in this area, at least not anytime soon. It is not in anyone’s get-my-job-done path.

I don’t think either that progress in this area is a task for the core contributing team. A core developer and a technical writer are typically different profiles.

I do think that this is a cause of a lot of frustration in the community, and I do think it hinders more wide-spread adoption of ROS 2 and Gazebo.

3 Likes