While it's used in industry sometimes, ROS is really one of those by-and-for-academia tools. There's a reason it's near-universally reviled, and why "migrate off of ROS" is a standing goal at a lot of robotics companies.
There's also a reason why it's a standing goal, rather than a completed goal.
It does little or nothing really well, but it does everything kind of okay.
There's a lot of "alternatives", most of which do something much better, sometimes much much much better, than ROS, but none of which can replace it all completely. PyRobot, Viam, OROCOS, Webots, all of these do some things much better than ROS, but none of them can drop in and easily replace everything without a lot of developer time, often adding new features to the platform.
Sure. A ROS system, being a collection of independent nodes coupled with a publish/subscribe messaging system, allows you to mix and match nodes for whatever. So as a researcher, it is great. It gives you a "good enough" robot for the 98% that is necessary infrastructure for the 2% where you want to experiment/innovate. In an commercial setting, yeah, you run into scaling issues all over the place. Also, the code quality of different stock nodes is highly variable.
So ROS can get you past your A-round -- but count on addressing scalability and stability issues as go. Which is why "write out ROS" is on everybody's to-do list.
In any case, learning ROS is well worth it. As a hiring manager, I know I can easily teach you our system if you know ROS already.
One of my pet peeves with the algorithm/science ecosystem surrounding ros is that almost all of these algorithms are not usable without ROS. Deep down inside some planning algorithm, you find ros data structures, ros publishers etc. This is poorly designed code. It's like letting raw SQL queries infect an entire ecosystem of libraries. IMO, this pattern is holding robotics back.
Two examples come to mind of packages that do NOT do this:
1. plotjuggler [1], which is a tool for plotting time serious data. It can connect to ROS, but also supports many other communication paradigms, like mqtt, zeroMQ, websockets, custom data and some more I forget.
2. nvblox, which at its core doesn't depend on ROS but instead provides a ros2 compatibility layer.
Yeah, it makes it a real pain, because you have to rip a whole bunch out, and often there's a much smaller and cleaner library underneath, once it doesn't need to deal with the extra crap ROS inflicts on it.
I suffer it so much every single time I have to interact with it that sometimes I really really want to do something else, but I can't. Unfortunately is not my call, is part of my job. I have already made my opinion about ROS in a previous thread, but another user synthesized it very clearly: it's a trainwreck. Now we can be more precise: it's an academia trainwreck tool.
Trust me, having your own crufty cobbled-together robotics code base that gets more and more insipid over time is way worse. 10/10 would start anything new with ROS.
That's really interesting. I've thought about trying to replace ROS with GRPC before too. I could never find a report of anybody actually doing that in the robotics space. Can you share more? How did it go? What pitfalls did you run into?
GRPC is very performant. A few points, ensure you have a script to compile the GRPC protobuf, ideally in docker so that you don’t pollute your local environment. That other pitfall, is don’t save raw protobuf binaries, you will face backwards compatibility issues as you change the definition of the protobuf, just write everything into MCAP’s. GRPC essentially replaces ROS messages with protobuf definitions and is not a publish, subscriber model, but you can build publisher/ subscribers out of it. It is managed by Google, used in android, web dev etc so it is very performant and reliable.
If you have the people to build something like this, could well be. If you're a smaller shop without any real experts, the structure enforced by ROS will prevent a lot of chaos and debugging.
Foxglove founder here. Foxglove is framework agnostic - we have first class ROS support but you can just as easily bring in custom data via Websocket or MCAP files.
Tangentially relevant: the TryHackMe Advent of Cyber side quest this year[0] featured a pair of ROS nodes that we had to attack.
I had never encountered ROS before but, having scoured the documentation to figure out how to write a malicious node[1] and exfil data via `rostopic`, it sure felt great not to have to use ROS professionally, and to know I was probably never going to encounter it again.
I don't know the rules of the TryHackMe Advent of Cyber, but I find it a bit strange that it had one of the quests targeting a version of ROS that has been deprecated for the past 5 years and will be completely EOL'd this May.
ROS 2 moved away from the codebase that the quest targeted many years ago.
CTFs are generally puzzles/games, not pentests themselves, so they will deliberately use out of date or misconfigured versions of software so that they are vulnerable in a known way.
> It does little or nothing really well, but it does everything kind of okay.
Yes. ROS is basically mediocre interprocess middleware with a standard interface used by much academic software. So you can hack stuff together without too much trouble. It won't be efficient or reliable, but it's useful.
* it's a loosely coupled messaging framework (so you can have 5 daemons that talk to each other to accomplish control at multiple levels)
* it's got robotics libraries with difficult robotics algorithms (PID tuning, forward and reverse kinematics, a way to run control loops very fast, ...)
* it's got sensor libraries (algorithms) and drivers
ROSCon Macao, 2019. As a time hack (our food robotics R&D facility, the "Noodleplex", was right across the border) I dragged all the academics down to the best bar (little resistance offered) instead of attending. While an interesting set, I was gobsmacked how little industrial nous attendees had and came to form the opinion that ROS use goes hand in hand with a "ROS can do CV ... everything is a nail" mentality. CV is a niche tool. Deployed, commercially relevant engineering generally uses something else unless the explicit system goal is visual input, because something else is always faster, cheaper, more reliable and has a supply chain stability half life greater than six months.
There's also a reason why it's a standing goal, rather than a completed goal.
It does little or nothing really well, but it does everything kind of okay.
There's a lot of "alternatives", most of which do something much better, sometimes much much much better, than ROS, but none of which can replace it all completely. PyRobot, Viam, OROCOS, Webots, all of these do some things much better than ROS, but none of them can drop in and easily replace everything without a lot of developer time, often adding new features to the platform.