Improving the Developer Experience

For the subset of us interested in finding ways to contribute, I hope folks will (continue to) use the “help wanted” tag on github issues to help us find them. (Or if there’s a better mechanism, please do let us know!)

3 Likes

We noob ROS developers understand that, and would really like a safe place to say “I am having trouble with this” and not get reamed because someone else asked what in no way sounds like the same question and we could not understand how to apply the answer to that question to our question.

Asking a question should not cause anyone to imagine we are complaining about the heroic, guru level work that is being performed to create and maintain ROS - we are hurting and often are wondering if we are the only one with this issue, or if simply finding one of the thousands of packages available and figuring out how to configure the 20-30 options for the package even after being told “that’ll answer your question”.

My background - retired software engineer with life long hobby interest in personal robotics.

My learning issues:

  • not being smart enough to understand how to make my robot report accurate heading: can’t figure out how to configure EKF to fuse wheel encoders and IMU data. My math skills are just not there to understand covariance matrices.
  • not being smart enough to understand to optimize onboard RPi4 SLAM

I don’t think it was anyone’s intention to do that in this thread. ROS Answers is designed to be the place you’re looking for.

Thanks for sharing that! That could be a very helpful resource, but it takes a bit of github skill to get to it and only looks at the core packages, and the most recent issue is from 3 weeks ago. Perhaps some aggregator could be created that looks at the top x% of ROS packages for issues, and then shares them on some external site? I don’t know enough about web dev or the github api to know how straightforward that would be…

Yes, thank you - I am aware of and have participated in both ROS Answers and Robotics StackExchange. They are not always “safe spaces” for noobs.

Sometimes things are just hard (understanding the math inside a state estimator) and sometimes things are hard because no one has figured out how to fund fixing them. Robotics software combines many of these problems.

The hope of open source is that by sharing the cost we can reduce the second class of problem. The challenge though is sharing the cost is not something we are particularly good at. Just look at the number of active contributors to what we consider the “core of ROS” which is spread across 12 GitHub orgs, 104 repos, 356 packages, 494 cmake projects, and 98 python projects.

In many cases, I think we fight against the second class of problem (arbitrarily hard) because we have yet to get to the point where we actually spread the work of building these things across many people. How many people are active committers in those 104 repos should tell you something about how healthy we are at open source. (I don’t know this number, maybe someone has that stat handy, my perception is that it is less than 10)

There is also this perception that there is a vast innate gap in skill between those doing contributions and maintenance and those using the systems so it is fruitless to try to onboard more people to contribute. If that is actually what we believe then we should stop trying to make this open-source thing work. We should focus on improving the journey of new contributors and building a pipeline for making ROS something that is not just kept alive by the valiant efforts of a few.

Anyway, rant over. Like others said, if you find it hard to use, maybe fix it yourself. Contributions welcome or something like that!

7 Likes

I appreciate you calling this one out - it’s a great example of something trivial that makes the learning experience for a new user unnecessarily more difficult, and after that remains a minor annoyance.

That being said, it hasn’t frustrated me enough to even look if there is an issue on GitHub let alone attempting to fix it, so I can’t complain too much!

These sites should be safe spaces to ask questions. And you should not be getting “reamed”. I monitor both sites relatively closely and have not recently observed any attacks personal or otherwise. If you see or experience any of this please flag it on the site using the report button. Or feel free to directly message me about it and I’ll take a look.

Note that there are questions which will get feedback and potentially closed. These efforts are necessary for the maintenance of the site. If you are new to the community you can still ask well formed questions. We do our best to provide good guidelines for how to ask questions. Help Center - Robotics Stack Exchange and Support - ROS Wiki

A few common examples of reasons for closing are: If a question is closed “duplicate” and a pointer to another question is provided that’s not an attack on you, but a pointer for you and anyone else who finds your question in the future a pointer to where there’s already an answer to your question. That way we don’t end up answering the same question many different times, and if someone thinks of it the same way that you do and finds your question they also get the same answer.

And there has been a lot of thought put into the process. Including having standard responses: Copy-pastable comment text for common problems with questions? - Robotics Meta Stack Exchange These standard pieces of feedback point back to the guidelines for asking questions to try to help you revise your question to include the information that the community needs to be able to help you.

A lot of what you’ll find is that the more effort you put into asking a good question the faster and better an answer you’ll get back out. For example ask your question after doing rubber duck debugging and include everything that you previously summarized.

5 Likes

I’ve had reasonable success with rqt_bag (both ROS1 and ROS2). It has yet to crash on me and I can get most browsing etc done. No editing though but I can live with that. I would love to have a better documented rosbag API in python but I got working what I needed to.

For me the biggest learning curve in transitioning from ROS1 → ROS2 was the unpredictable middleware performance and the change in build system from catkin → ament. Much of the middleware gotchas I experienced (and continue to experience) are due to lack of documentation and of examples.

5 Likes

+1 for this.
Im a newcomer to ROS.
I see the issue of various things being “undermaintained”. So, I have difficulty understanding how the decision was made some years ago, to come up with a whole new set of APIs in ROS2… but then not port widely used critical packages, as part of the ROS2 release. Such as ROS-industrial.

And worse yet, the decision to make a"ROS1" bridge. It may seem like a good short-term idea, but in the long term, its terrible. It negatively incentivises people to port packages.
A far better solution, in my opinion, would have been to put that effort into some kind of compability layer, or porting tools, that made it easier to bring the old code into direct ROS2 usability.
It’s like the early days of the linux desktop wars with ms-windows emulation.
Sure, it made a lot of people short-term happy… but it put off linux desktop progress for maybe a decade.

The best thing for ROS’s future is a unified and well documented standard framework that can then be easily ported to any robot platform with a minimum of effort.
If it takes over a year for a large vendor such as Yaskawa, with their paid resources, to come out with ROS2 functionality for their robot… then seems like there’s something major missing.

2 Likes

I have difficulty understanding how the decision was made some years ago, to come up with a whole new set of APIs in ROS2… but then not port widely used critical packages

I think you’re conflating a few things here. There wasn’t a decision to just not port things, there was a decision to update the APIs (for reasons discussed elsewhere). Porting packages is then the responsibility of the package maintainers (as it is between ROS1 versions): a lot of the ROS-industrial packages are still on Melodic. This returns us to the problem of ‘who is willing to sit down and do the maintenance work’.

As an aside: I don’t really see why the problem is “loads of customized things on top of ROS”-- is the implication here that building on top of ROS is bad practice? That seems odd.

the decision to make a"ROS1" bridge … negatively incentivises people to port packages

Yeah, that’s an interesting point actually. But, here we are.

The best thing for ROS’s future is a unified and well documented standard framework that can then be easily ported to any robot platform with a minimum of effort

Are you describing ros_control and the ROS2 equivalent, ros2_control? Or something else? Keep in mind that there are many, many different needs, so there cannot be a one-size-fits-all solution.

If it takes over a year for a large vendor such as Yaskawa, with their paid resources, to come out with ROS2 functionality for their robot… then seems like there’s something major missing.

Has Yaskawa been actively contributing to development of a ROS2 port? Their package is still on Kinetic and git history appears to be community-driven.

Largely off-topic, so click-to-expand if you still want to read it

I won’t go into any details here, but:

this is off-topic here and doesn’t say anything about the state of ROS 2.

Pace of development of MotoROS2 neither was nor is affected by the subject(s) being discussed in this thread.

Large (industrial) OEMs have very different motivators from open-source communities and measure development cycles typically in years. And just to put it in perspective: the initial development of MotoROS1 (ie: the motoman_driver) took about 2.5 years, and included just the base functionality.

The reference is to MotoROS2, for which development does not take place in the repository you refer to.

Just to clarify: branching policy for those repositories dictates to only branch when absolutely necessary. As the readme states, those packages are perfectly usable on newer ROS 1 versions.

1 Like

The thread got a bit derailed. I think the point was to find weak points in the ROS ecosystem, things that are really painful but we got used to it because we see no hope of it getting fixed, like RViz.

I think one of the top annoyances in ROS2 is QoS. It really is important and necessary, but having to spend minutes in RViz trying to figure out the QoS settings of a topic because otherwise it won’t show data is so annoying. Similarly writing subscribers. I know ros2 topic info -v prints the QoS settings, but when working with a lot of different QoS topics (and especially general subscribers) it is very tedious. ROS2 would benefit greatly from an auto-QoS subscriber, both inside and outside RViz. (I saw in some thread that the info is there in the DDS implementation but not propagated to the ROS layer as of right now.)

3 Likes

Hi!

From my perspective, I kind of agree to the point of ROS got too large to handle. Humble is ~1000 packages with very varying level of code quality, and since I tried to cross compile most of it, I think I can have an opinion on that.
One thing that really makes me wonder if ROS is the way to go for implementing an industrial grade robot are the quality issues. Although it is not a big issue, I came across a regression that is described here and I offered a PR here but for the past 3 months or so nobody even seems to have the time to say that this is bullshit and needs to be closed. The recently (finally!!!) addressed realtime issues might serve as another example.
That said, I had PR towards Microsoft that got merged 2 years in, so I still have not lost faith :slight_smile:

My point is: given the limited resources, would it make sense to focus on a ROS2 - Core, instead of adding all those packages that soak up so much resources… ?!

1 Like

That is why ROS 2 introduced the explicit quality level of packages. I hope that the higher the quality level, the better the support. Of course this still has some limits. But basically, if you’re using QL4- packages, you’re just on your own (with a high probability). But it also happens that some interesting package is provided by an individual who is not yet proficient enough to write good code, but is happy to merge any improvements.

5 Likes

I will be happy and grateful to help you with the best of my knowledge and abilities. Driven by desire to work with you out of curiosity and to contribute to the work you are doing. Thank you for your time and consideration.

But basically, if you’re using QL4- packages, you’re just on your own (with a high probability)

I think that this is a great vision, but unfortunately some very foundational packages, such as launch do not seem to have a quality declaration?

As a pretty heavy python user, I have noticed that the quality of the Python packages is lagging, and could be improved. Unfortunately my attempts to contribute to improve the quality of the launch package have gone unanswered so far. Even though I pinged most people who seem to regularly contribute to launch, no one has replied on my draft PR to give me any advice.

So I will echo the sentiment of some of the above posters: it seems like maintainers of core packages do not actually have enough time to guide community contributions and this means that unfortunately the core of ROS2 is not at the quality level that it could be.

2 Likes

At the risk of going offtopic:

I am experienced in developing industrial ROS-powered robots following a modern software engineering process (and I think ROS is great).

Returning back to academia, I observe many students struggling getting started with ROS (reminding me of myself when I got started). These struggles include:

  • trying to install their first ROS packages,
  • connecting computers in a network,
  • starting nodes/launch files,
  • compiling their first community contributed package.
    Frequently, a ROS solution is ditched in favor of a do-it-yourself implementation. If they can create their own package, the code quality is low (sorry) and even if the package works as intended, it is by no means portable/maintainable once students move on.

To lower the entry burden, I am currently experimenting with ROSbloX. ROSbloX are ROS building blocks, i.e. physical devices which run one single containerized ROS package, e.g. a LiDAR driver or a SLAM algorithm. The idea is that ROSbloX can be used to compose robots with complex functionalities even by less experienced developers.

More information: https://rosblox.github.io/
Thank you for your inputs.

1 Like

I do love the push to develop a maintainable, industrial strength ros, so I’m very appreciative. This is just a little grain of salt.
I’ve the past six months needed to work with a ROS2 codebase developed by a vendor, so I’ve personally been making the shift from ROS1 to ROS2. These are the biggest things that stand out to me:

TL;DR: mostly docs, and a lot of dropped little things in the most commonly touched parts of ros
  • Documentation is non-existant. Like, scarily so. Like, I’m referencing design docs from 5-7 years ago, or ros1 docs hoping for things not to change ago, or finally the woefully incomplete main ROS2 docs site.

    • Off the cuff, of the desired needs and capabilities from ros that handle 90% of my problems, it’s usually only the same 30% or so of everything that ros can do (now that other 10%…). The main docs site is full of everything, the full 100% of what ros can do, yet is insufficient to meet this common 90%, and very distracting.

    • Alternatively, the source code for ros2 is very readable; I usually just have a few github links to the source code open (rclcpp, rclpy, or tooling, depending). So this has been a pleasant experience for fixing my problems.

    • On that note, I wouldn’t teach a robotics class with ros2. The ros1 docs were so mature (*cough* in comparison) that it would be much easier for students who struggle with googling or reading source code to work with them, and the well practiced good styles we’ve developed over the years. (when even chatgpt and google-copilot can’t help you write good code)

    • Style: code styles that promote node / launch file interface composition readability. Kinda rare in ros1, but we did have the wiki pages with the packages’ nodes’ sub/pub/topics/params listed; intra/inter-file docs were less-so. Both non-existent ros2.

  • Tooling that feels like a regression.

    • Lack of support for xml launch files. The python ones are incredibly verbose for the 90% of real need, and are not as easy to quickly read+parse. Launch file errors are terrifying and useless. Eval/Var don’t work easily, needing lots of string escapes. Using Arg/Let for simplifying repeated strings, with variable substitution for commands/nodes doesn’t work easily / correctly, I don’t bother trying anymore.

    • We finally have types for python, decent workflow integration (mypy/pylance-vscode), and beartype is the most glorious python pkg ever created that disregards everything else that follows in this subpoint, but typing support for messages (aka all our datastructures) and rclpy (aka which the rest of our code is entangled with) have second class implementation. (Thanks to the few volunteers who keep pushing! :confetti: )

    • With respect to python, finally on python3 for a long time, yet all ros pkgs / installations exclusively (or else painfully?) only go in the system pkgs. It’s very difficult to leverage pyenv well with ros2, and pick your favorite incarnation of virtualenvs are still excluded to non-ros projects.

    • Gazebo / Ignition isn’t a regression per-se, but year over year I don’t think it’s gotten better, enough that we end up writing some simulator-esque thing for some subset of our product that doesn’t necessarily need a full physics simulator…

  • I felt comfortable using Indigo for years (back when we were too scared to jump versions), and kinetic was the best distro to work out of (in terms of ported packages and ros1 maturity). Now with Noetic we have the updated ubuntu and python 3, great. I’d still use any of them for production or teaching. But I find that every release of ros2 seems to have a personally-critically-missing feature or such, that I keep backporting (company almost will transition to ubuntu 22…). I find that the only and best way to have everything that I would want is to build / develop out of rolling. But even if I did, I find more important features lingering in long issue or PR tickets, so I’m always waiting for more.

    • Cheers to the clearpath etc guys who started the Nix package installation / building thing mentioned last roscon! I look forward to having the bleeding edge at my fingertips, as soon as I figure out nix.
8 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.