When I was just starting out with ROS and trying to get the robot to navigate, there are two things I wish I knew:
- ROS is not perfect
- You might be the right person to fix it
To some in this community, the idea that ROS is not perfect is glaringly obvious (as many Discourse threads will attest). With a community of this size though, and so many people using the code, the core repos get an air of legitimacy for beginners. When I first started with ROS, I spent a lot of time reading the nav stack source code, and I came to a false conclusion: If a package isn’t doing what I want, it’s because I don’t understand it. The authors must have had a good reason for making it this way.
I had this grand notion that Willow Garage (the company behind the origins of ROS) handed down this perfect code from on high. Robot navigation was completed and perfected at a Menlo Park utopia, and I was at fault for not understanding what they were trying to do.
The “secret” is that ROS, for all of its strengths, is a big pile of “good enough” code.* The nav code I was looking at was good enough for a particular robot to do a particular task, but the fact that it couldn’t handle what I was trying to do was an oversight from the original developers, not my own understanding. It took me a long time to understand this.
ROS is made by people. And there are always compromises. There could be a dozen reasons why the code isn’t what you want it to be.
- Written by a software engineer with limited access to a real robot
- Written by a robotics scientist who prioritized mathematical correctness over software maintainability
- The code was written by someone at a company that had a particular use case
- Designed before the advent of some piece of technology.
- It was written by an expert robotics software engineer for your use case, but with extremely limited time to get it merged.
(And yes, many of those people work at big fancy companies, but those companies also have complex/conflicting priorities that result in compromises of their own)
Even if the code wasn’t perfect, I still had this belief that the people who wrote it were “real roboticists.” I mean, I started grad school thinking I was going to do computational genetics, who was I to try to improve this code? There can also be dozens of reasons why you believe you’re not the right person to fix it. Maybe you didn’t go to Stanford or Carnegie Mellon. Maybe you’re not in the Bay Area or another robotics hub. Maybe you haven’t even been in the field that long. And maybe when you do get your chance to work at one of the big companies, it doesn’t work out the way you expect it to.
The phenomenon of Imposter Syndrome is not exclusive to the open source robotics landscape, but I feel it is worth bringing up at this time in our community because it’s still easy to feel like there are two tiers to the ROS Community: the insiders and the outsiders. The insiders are giving ROS talks, getting elected to committees, and have fancy titles at impressive companies. Everyone else is on the outside, just trying to get their code to work and hoping for the best. But if you put in the time and work, there is no real division. It’s all just folks.**
I cannot speak for everyone. I can say this: I’m grateful to have been elected a representative of this community. I’m grateful to be the maintainer on a number of packages. However, I have stood where many of you are now: a confused grad student just trying to get a demo to work for a paper, the new member of a small software team at a startup, or the person just trying to get their one friggin PR merged. How to progress from there can take many paths, but I offer the following advice.
- Start off humble. (Not to be confused with ROS 2 Humble). Give the code authors the benefit of the doubt, and try to understand why things are written the way they are before rushing in to change things.
- Identify your unique voice. It can be helpful that you’re not like every bro in Silicon Valley. Your perspective can help expand the functionality beyond what the original authors ever dreamed.***
- Do not fear going your own way. If package X is not working for you, feel free to swap it out with something else. Develop your own stack for solving the problem. Then you can come back to package X with a concrete alternative approach and possibly work on integrating.
- Acknowledge the shoulders you’re standing on. When you come out with a new feature/package, the tendency is to go full Apple Keynote and hype it up by overstating its features and diminishing what came before. However, if you acknowledge the strengths of the prior work and admit the shortcomings of the new, that makes it that much easier for the next person to come along and build on your work. It’s not binary.
- Be kind.
We, all of us, can change this community. We, all of us, can make it better. We, all of us, have something to contribute.
*This is arguably true of all software, except maybe Roller Coaster Tycoon.
**That’s not to say there aren’t real divisions between different groups. However, I’m going to save my thoughts on the balance between maintainers and contributors and maintainer burnout for another day.
***It is also worth noting that identifying the uniqueness of your situation can also help to find ways to be humble. You’ll get a lot further when you say “this package won’t compile” when you acknowledge that most people compile on Ubuntu and note that you’re trying to compile it on a Windows 98 web browser.
****For a long time, I believed that I couldn’t get great things done until I got to one of those utopian perfect environments. It took years of therapy and at least one great musical theatre song to make me realize that the answer to “When/Where is it best to solve this problem” is now and here.