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.
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.
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.
> 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.
I tried to use ROS2 twice in my professional career. Both times ended up with massively bloated build pipeline code, significantly longer build times, and massively bloated Docker images.
Don't use ROS2. The benefits just aren't worth it. It's great for school but it's terrible for production.
I have worked in two failed and failing startups that invested heavily in ROS. I could fill several volumes with "ROS Gotchas". Everything in the ROS stack is either a useless curio or an on-fire clown car.
Using ROS is a great way to turn your project and business into a cautionary tale.
Ros2's colcon will build the packages in your workspace individually, in topological order of the dependency DAG. This is a completely insane way to structure a c++ build because it destroys the innate parallelism of the compilation process.
The build system for ros1, catkin, didn't have this problem because it turned all your packages into a single cmake build. Just one of the many ways that ros2 was a regression from ros1.
For a while new grads had a severe lack of hands on ROS experience. Though many companies don't use ROS, it is so entrenched in the industry that most solutions look similar enough for transferrable skills. (Src: was hiring mgr in robotics)
Highly recommend if you want to get into robotics you have ROS experience and demos / stories at hand.
Been 10 years in and around the robotics industry and I'd recommend exactly the opposite. I've assisted companies refuse to work with anything touching ROS. Most successful things I've seen in production that are with ROS use a large non-ROS core with a thin ROS layer on top for compatibility. Companies that do use ROS have needed several times the resources of those that don't, to achieve the same thing.
Usually people get stuck with ROS in commercial environments either because they inherited it from an academic project (company is a spinoff), or they used ROS for a demo and afterwards never planned with long enough roadmaps to make the cost benefit analysis obvious enough.
Ok, I've been 10 years in it as well, if that's important.
There's simply no reason to skip ROS as a student. My advice was not for businesses, whatsoever. And every single ROS replacement I've seen is ROS-like enough that the language ROS defined for all of us is effectively lingua franca.
But the antibodies that are triggered by even mentioning ROS should tell anyone how much it is not a fun thing to learn or work with. But it is a common touchpoint. It's really hard to understand _nearly any_ design decision in robotics software without first understanding why it isn't ROS.
I'm really intrigued by robotics as future career. How would you rate it for the next 10-15 years? I'm seriously thinking of investing in a masters degree focused on robotics (CMU). I'm close to 50 and already have a cs PhD. Just intrigued by it and feel it might have a longer career (when it takes off).
Wow, you’re still interested in learning at close to 50. That’s commendable. I did my masters at CMU robotics, and I would recommend doing it. Most students will be under 30, but CMU is a very practical school with an actual focus on building and programming robots, so if you’re proactive you can wet your feet plenty during your masters programme. Don’t expect to learn much from courses though, most of the learning happens in your off time in robotics projects or when doing robotics research with professors, and in that CMU is really good
Robotics is a very hard topic. If on top of that you add ROS which almost everyone is using you will end up very disappointed and without much enthusiasm to do robotics at all. My major criticism to ROS is that because robotics is already hard, ROS does not make it a single bit enjoyable or easy, all the opposite as a matter of fact.
You have a CS PhD? I highly doubt you can learn something there. If it is about knowledge, find out what books are used in the masters. With a PhD you must be able to learn yourself
Robotics is already taking off. It’s just not evenly distributed. I think several companies are being highly optimistic in their projections of millions of humanoid robots in five years. But, I think it’s the common mistake of overestimating the short term and underestimating the long term.
Now is an excellent time to work in robotics. Every major car company will be transitioning their car offerings to semi-robotic systems. Every major Army, navy, or air force will be adopting automated systems in an increasing degree. Decent wages for bluecollar work means decent prices for automated systems. The buildout of American manufacturing means automation is key. Finally, space exploration booms mean robots (not necessarily fully autonomous, but largely automated systems) are in increasing demand for aerospace too. Is spaceX building robots? Yes they are!
I would recommend the masters for the coursework and practical background. A degree from CMU will get you through the pedigree filter at most jobs. I've hired plenty of CMU masters students and have always been happy with them.
Robotics itself does have many of the job archetypes you'd expect from a hardware/software heavy industry.
Regardless of the path, specialization is key. You might be (woefully incompletely) categorized as:
- systems folks (middleware, CUDA, distributed systems, hard C, C++, ROS-like, etc). Even things like CI/CD knowledge as applied to robotics can get you a long way.
- Vision (CNN/DL, but do not stop there. You should also have basic knowledge of tracking, homographies, and the old school CV stuff to make it work well in a system (as opposed to just scoring high on training data))
- Controls (PID and the bigger cousins - this is not my area)
- Tracking (EKF and the bigger cousins - in particular MH-EKF and please don't skimp on batch filters we have enough CPU to do that nowadays)
- Mapping & Prediction (often this is done so poorly that a person who has lots of practice building 2d/3d and semantic maps is a godsend, especially incorporating uncertainty - critically predicting future maps (+5-30s) is an amazing thing to have)
- Planning (99% of planning nowadays is trajectory planning which is kind of "just" figuring out from a map and destination what the signal is over time that goes to the control subsystem. But there's also route planning- where should we go an in what order, activity planning (what are good destinations and in what order), or even multi-agent planning (how do I get a bunch of agents to not just collide when trying to do individual activities))
- Proprioception (Sometimes just called Estimation) you'll want to be an expert in IMUs, Gyros, the EKF filter, using vision signals, magnetic signals, GPS, etc
- Exterioception (more general than Tracking) options are LIDAR, Radar, Bog-Standard Dispartiy, or any other sensor you can think of.
- Simulation - rapidly becoming extremely important or foundational to a good robotics program, especially one built on learning. This often has a lot of overlap with games programming so this can attract a certain type.
Roughly speaking, if you decide you like one of Sim, Controls, Planning (what kind?), Proprioception, Exterioception/mapping, Tracking, or Systems, you should tailor your coursework and projects to match.
Oh and I should mention - once you pick one of these, they are often very different when you are working on wheeled vehicles vs legged ones vs aircraft vs spacecraft vs plain-old-arms/ manipulators. But the skills are transferable so learn strong fundamentals.
Anti-recommendations:
- LLMs. I have heard they are going to be helpful, but are just hype so far. Skip for robotics AFAICT
- UI/UX. Everyone says they are going to invent the easiest-to-use automated system, just as soon as it "works". Spoiler alert, just like Akins laws of spacecraft design, if your system involves building a robot to build some other product, you are defacto a robotics company and will spend all your time making the robot work.
There are very few "Generalist" robotics positions -- you'll be competing with PhDs who are specialists but picked up enough experience doing their PhD to have generalist level skills. You want to be on a specific team doing a specific thing deeply. It's also the most fun to be on a specialized team!
Remember, there are two hard problems in robotics: Perception and Funding. So Simulation, Proprioception, Exterioception, Mapping, Prediction, esp Vision (nowadays) are hugely important to the success of a program. As a planning guy, the rest is "easy".
Highly recommend to avoid any companies that would touch ros with a 10ft pole. It's an unmitigated pile of endless shit, and any projects that don't recognize this are also.
What would you recommend instead for the ones that would be interested to start learning robotics stuff? (Not trying to be snarky but actually curious)
Ok I will just say it. ROS sucks and is a nightmare to use. When it does work it doesn't work well. I am not sure why we continue to use this outdated programming method. I have several robot. All of them could use ROS but I choose not to torture myself with what a mess that would be. Now a days coding or programming does not have to be unenjoyable. If you want to not use the dreaded ROS method to kill your brain then use ChatGPT 1.o this will change the way you code forever and you will actually enjoy it and look forward to coding with it. It takes the nightmare away that ROS created. No one wants to use ROS let's be honest. So finally there is a better way. ChatGPT 1.o makes ROS to look like an outdated mess.
I love ROS. There are setup files for stuff inside ROS (pathfinding etc) that I haven't enjoyed, and I've definitely struggled with things like keeping it all standardised with like dockerfiles, but the ROS itself? the concurrency is amazing. I constantly wish I had it on non-robotics projects...
as others have mentioned, it has scaling issues. But for getting things done on a base level, its super powerful. The fault-tolerance it allows has benefited our robots a lot - it's often possible even with severely degraded systems to manually guide one around.
I do agree with what others have said about how the best usages are often to not go too deep into the ecosystem and instead use its messaging and concurrency protocol in limited ways, and have a lot of your internal logic siloed, to avoid hardcore dependency. After all, the idea of this kind of system is to allow new nodes to listen to sensor data (coming in) and/or planning goals (going out) to be able to make their decisions. Not passing some kind of intermediate calculation to some other subsystem
Worked with ROS in research, industrial, and warehouse spaces for 12 years now, with fleets of hundreds to thousands of robots, tens to hundreds of thousands total worldwide. If there's one thing I could convince people of, it's to never use ROS to communicate between hosts.
If you want to use ROS for IPC on the same host, fine. That can all be debated but okay. But if you want to communicate to different robots, especially over WiFi, ROS is missing most of what you need, and it's things that roboticists do not need to reinvent as the Web has been grappling with these issues for a lot longer by millions of more developers.
- You will have to worry about versioning, either on your terms of when you're inevitably forced to
- Even if you don't plan on operating multiple versions in harmony (years later you'll regret believing you could get away with this), you have to deal with the edge effects of when you upgrade them remotely/on-site.
- ROS API definitions ("ROS Messages") are defincient. Yes, you really need to support `null` but you also need a whole lot more expessiveness in general. You'll invent your own string-but-actually-json message at some point.
- You end up manually dealing with well-trodden problems like compression, authentication, authorization.
- Failed comms, reconnecting, retrying, etc. will be a huge pain.
I think the simplest question to ask yourself/team is: "Could this be an HTTPS API? Could this be a Websocket? Do we even have the correct skills on the team to answer this question or did we only hire ROS people?"
Those of you who use ROS in production, do y'all use ROS 1 or 2? Do you maintain your own fork? I'm curious how people do this, with the upcoming Noetic deprecation.
Where I was, 1 was standard, 2 experimental and nothing worked really. Slowly a half assed, bug ridden internal implementation of ROS 2 was started… a sh*tshow to be honest. The discontinuity between R1 and R2 was for me just unacceptable, unprofessional and just awful.
If I could decide (and in the area where I am, we did) I would ditch the whole thing. After all, if you squint, ROS is a collection of things:
- a launcher (which is a very bad scripting language embedded in horrible XML). Can be very easy be substituted by some python or shell scripts.
- a description language of messages, that can be read by C, Python and Lisp; can be substituted by raw sockets or google protocol buffers or whatever.
- a parameter/configuration distribution system, which can be implemented based on libconfig (https://github.com/hyperrealm/libconfig)
All that options are pretty much standard, stable and well supported, with bindings for any mainstream language.
I would run away from ROS2 to avoid another disaster when ROS3 comes.
> After all, if you squint, ROS is a collection of things:
ROS came about because before ROS existed, robotics researchers cobbled together ad-hoc ROS-like systems using the tools you point out. ROS itself started as a project called "Switchyard", which was built to operate one of Stanford's robotics projects. Research labs around the country each had their own take on this kind of system, which made sharing research very difficult. What ROS did was standardize the platforms between all labs, enabling us to share our algorithms, which at the time mostly revolved around localization, mapping, and path planning.
hi, I've dabbled in robotics from a hobbyist perspective, and I've gotten as far as installing ROS and following some tutorial and online courses a few times.
I agree with what you said about launcher/ipc/config - my plan if I ever use Ros is to keep it in a box and use my own communication layer to connect with things in various environments (rather than trying to solve incompatible conda environments).
however one thing you've missed, which may well be the biggest offer from Ros and the reason why I haven't sworn off it entirely is the library of robotics functionality such as SLAM and various planning algorithms.
in your opinion, are these at least well implemented? would they be easy to rip out and run separately?
I run a robotics dev tools company and we work closely with companies of all sizes across the robotics industry, so have a unique perspective on this.
I would say about half of the industry (read: for-profit robotics startups from early stages through to 10,000s of robots in production) uses ROS, and of those probably 2/3 are on ROS 2 at this point, and the rest are in some stage of migration. ROS 2 solved a lot of problems that didn't need solving, but like it or not ROS 1 is abandonware at this point so almost no one is planning to stick with ROS 1 longer than they have to.
Most companies aren't maintaining their own fork of ROS (other than to submit patches upstream), but a small number of companies on ROS 1 forked it and diverged so significantly that there is no point trying to rebase on ROS 2 - of these GM Cruise was the most notable, although the future of their stack is unknown now that GM canceled the robotaxi project.
The other half of the industry uses some sort of in-house stack built from parts (compare batteries-included frameworks like rails/django to building a backend using libraries like expressjs and sequelize). There is usually some form of pub/sub messaging architecture, because pub/sub is a natural fit for robotics and makes it easier to log and replay/resimulate. Some common things I see are zeromq, vanilla DDS (no ROS), zenoh, or write their own pub/sub (sometimes using shared memory). The messages themselves are often protobuf, flatbuffer, cbor, json, or sometimes just raw c structs.
Building your own stack isn't hard, but its much easier if you have used ROS before and know which concepts you want to reuse, rather than reinventing everything from first principles.
If people are just starting out in robotics, or just starting a robotics company, I still recommend ROS despite its warts, it is worth learning because it has had such a big influence on the current ecosystem. There is no "right answer" though, many companies have been successful with each approach.
You treat it like the metaphorical toxic waste it is: avoid it at all costs. You don't need ROS to get a dependency manager, a build system, a middleware, and/or a process manager.
The ROS project has terrible governance, and the community suffers heavily from groupthink.
I just got banned from their forum for questioning what the ROS Foundation has done in the past two years--specifically on the build system. Yes, their middleware is unforgiving of alternative ways other than their wrong and outdated development practices, but their community is more religiously attached to their precious tools for development.
No, you were not banned, your permission to post publicly was restricted because for the past three years you've been insulting, spreading lies and refusing to cooperate with other members of the community who actually want to change things and improve ROS. You're the one who is taking this personally because you claim Open Robotics is going after you. You've broken the code of conduct numerous times. The fact that you're incapable of any introspection and realizing that other people in that same thread are criticizing ROS in a civilized way and who are also proposing alternatives to ROS' build system, while you're just adding noise and whining about being personally targeted, makes Ryan's decision to restrict your permission to post publicly even more reasonable.
Groupthink is what happens when people don't share their dissenting views, so the group as a whole makes poor decisions. This is why it is a bad idea to silence dissent. This defines the ROS community, as you have exemplified.
So it is good that you come and read the comments here. Welcome!
ROS is painful to work with and doesn’t scale well. It’s a shame Microsoft abandoned Robotics Developer Studio over a decade ago.
Robotics Developer Studio started off in a promising direction. It had the CCR (Coordination and Concurrency Runtime) and the DSS (Decentralized System Services) which together made it possible to coordinate real time robotics in a RESTful environment across distributed hardware. It had also had full access to .NET. There’s never been anything quite like it since. Unfortunately MS pulled the plug before it had a chance to mature into an easy-to-use well documented platform.
Readit News
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.
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.
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.
[1] https://github.com/facontidavide/PlotJuggler
[2] https://github.com/nvidia-isaac/nvblox?tab=readme-ov-file#c-...
[3] https://github.com/NVIDIA-ISAAC-ROS/isaac_ros_nvblox
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.
[0] https://tryhackme.com/r/room/adventofcyber24sidequest
[1] https://0x85.org/sidequest2024-2.html
ROS 2 moved away from the codebase that the quest targeted many years ago.
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.
Think of it as the PHP level of robotics.
* 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
* it's got a simulator
* it's a linux distro specialized for robotics
You can keep going for a while with this.
As far as I'm aware very few real time operating systems support CUDA, and none that are free. You could look at Concurrent's RedHawk Linux.
Don't use ROS2. The benefits just aren't worth it. It's great for school but it's terrible for production.
Using ROS is a great way to turn your project and business into a cautionary tale.
The build system for ros1, catkin, didn't have this problem because it turned all your packages into a single cmake build. Just one of the many ways that ros2 was a regression from ros1.
Highly recommend if you want to get into robotics you have ROS experience and demos / stories at hand.
Usually people get stuck with ROS in commercial environments either because they inherited it from an academic project (company is a spinoff), or they used ROS for a demo and afterwards never planned with long enough roadmaps to make the cost benefit analysis obvious enough.
There's simply no reason to skip ROS as a student. My advice was not for businesses, whatsoever. And every single ROS replacement I've seen is ROS-like enough that the language ROS defined for all of us is effectively lingua franca.
But the antibodies that are triggered by even mentioning ROS should tell anyone how much it is not a fun thing to learn or work with. But it is a common touchpoint. It's really hard to understand _nearly any_ design decision in robotics software without first understanding why it isn't ROS.
I would recommend the masters for the coursework and practical background. A degree from CMU will get you through the pedigree filter at most jobs. I've hired plenty of CMU masters students and have always been happy with them.
Robotics itself does have many of the job archetypes you'd expect from a hardware/software heavy industry.
Regardless of the path, specialization is key. You might be (woefully incompletely) categorized as:
- systems folks (middleware, CUDA, distributed systems, hard C, C++, ROS-like, etc). Even things like CI/CD knowledge as applied to robotics can get you a long way.
- Vision (CNN/DL, but do not stop there. You should also have basic knowledge of tracking, homographies, and the old school CV stuff to make it work well in a system (as opposed to just scoring high on training data))
- Controls (PID and the bigger cousins - this is not my area)
- Tracking (EKF and the bigger cousins - in particular MH-EKF and please don't skimp on batch filters we have enough CPU to do that nowadays)
- Mapping & Prediction (often this is done so poorly that a person who has lots of practice building 2d/3d and semantic maps is a godsend, especially incorporating uncertainty - critically predicting future maps (+5-30s) is an amazing thing to have)
- Planning (99% of planning nowadays is trajectory planning which is kind of "just" figuring out from a map and destination what the signal is over time that goes to the control subsystem. But there's also route planning- where should we go an in what order, activity planning (what are good destinations and in what order), or even multi-agent planning (how do I get a bunch of agents to not just collide when trying to do individual activities))
- Proprioception (Sometimes just called Estimation) you'll want to be an expert in IMUs, Gyros, the EKF filter, using vision signals, magnetic signals, GPS, etc
- Exterioception (more general than Tracking) options are LIDAR, Radar, Bog-Standard Dispartiy, or any other sensor you can think of.
- Simulation - rapidly becoming extremely important or foundational to a good robotics program, especially one built on learning. This often has a lot of overlap with games programming so this can attract a certain type.
Roughly speaking, if you decide you like one of Sim, Controls, Planning (what kind?), Proprioception, Exterioception/mapping, Tracking, or Systems, you should tailor your coursework and projects to match.
Oh and I should mention - once you pick one of these, they are often very different when you are working on wheeled vehicles vs legged ones vs aircraft vs spacecraft vs plain-old-arms/ manipulators. But the skills are transferable so learn strong fundamentals.
Anti-recommendations:
- LLMs. I have heard they are going to be helpful, but are just hype so far. Skip for robotics AFAICT
- UI/UX. Everyone says they are going to invent the easiest-to-use automated system, just as soon as it "works". Spoiler alert, just like Akins laws of spacecraft design, if your system involves building a robot to build some other product, you are defacto a robotics company and will spend all your time making the robot work.
There are very few "Generalist" robotics positions -- you'll be competing with PhDs who are specialists but picked up enough experience doing their PhD to have generalist level skills. You want to be on a specific team doing a specific thing deeply. It's also the most fun to be on a specialized team!
Remember, there are two hard problems in robotics: Perception and Funding. So Simulation, Proprioception, Exterioception, Mapping, Prediction, esp Vision (nowadays) are hugely important to the success of a program. As a planning guy, the rest is "easy".
I love ROS. There are setup files for stuff inside ROS (pathfinding etc) that I haven't enjoyed, and I've definitely struggled with things like keeping it all standardised with like dockerfiles, but the ROS itself? the concurrency is amazing. I constantly wish I had it on non-robotics projects...
as others have mentioned, it has scaling issues. But for getting things done on a base level, its super powerful. The fault-tolerance it allows has benefited our robots a lot - it's often possible even with severely degraded systems to manually guide one around.
I do agree with what others have said about how the best usages are often to not go too deep into the ecosystem and instead use its messaging and concurrency protocol in limited ways, and have a lot of your internal logic siloed, to avoid hardcore dependency. After all, the idea of this kind of system is to allow new nodes to listen to sensor data (coming in) and/or planning goals (going out) to be able to make their decisions. Not passing some kind of intermediate calculation to some other subsystem
If you want to use ROS for IPC on the same host, fine. That can all be debated but okay. But if you want to communicate to different robots, especially over WiFi, ROS is missing most of what you need, and it's things that roboticists do not need to reinvent as the Web has been grappling with these issues for a lot longer by millions of more developers.
- You will have to worry about versioning, either on your terms of when you're inevitably forced to
- Even if you don't plan on operating multiple versions in harmony (years later you'll regret believing you could get away with this), you have to deal with the edge effects of when you upgrade them remotely/on-site.
- ROS API definitions ("ROS Messages") are defincient. Yes, you really need to support `null` but you also need a whole lot more expessiveness in general. You'll invent your own string-but-actually-json message at some point.
- You end up manually dealing with well-trodden problems like compression, authentication, authorization.
- Failed comms, reconnecting, retrying, etc. will be a huge pain.
I think the simplest question to ask yourself/team is: "Could this be an HTTPS API? Could this be a Websocket? Do we even have the correct skills on the team to answer this question or did we only hire ROS people?"
If I could decide (and in the area where I am, we did) I would ditch the whole thing. After all, if you squint, ROS is a collection of things:
- a launcher (which is a very bad scripting language embedded in horrible XML). Can be very easy be substituted by some python or shell scripts. - a description language of messages, that can be read by C, Python and Lisp; can be substituted by raw sockets or google protocol buffers or whatever. - a parameter/configuration distribution system, which can be implemented based on libconfig (https://github.com/hyperrealm/libconfig)
All that options are pretty much standard, stable and well supported, with bindings for any mainstream language.
I would run away from ROS2 to avoid another disaster when ROS3 comes.
ROS came about because before ROS existed, robotics researchers cobbled together ad-hoc ROS-like systems using the tools you point out. ROS itself started as a project called "Switchyard", which was built to operate one of Stanford's robotics projects. Research labs around the country each had their own take on this kind of system, which made sharing research very difficult. What ROS did was standardize the platforms between all labs, enabling us to share our algorithms, which at the time mostly revolved around localization, mapping, and path planning.
I agree with what you said about launcher/ipc/config - my plan if I ever use Ros is to keep it in a box and use my own communication layer to connect with things in various environments (rather than trying to solve incompatible conda environments).
however one thing you've missed, which may well be the biggest offer from Ros and the reason why I haven't sworn off it entirely is the library of robotics functionality such as SLAM and various planning algorithms.
in your opinion, are these at least well implemented? would they be easy to rip out and run separately?
I would say about half of the industry (read: for-profit robotics startups from early stages through to 10,000s of robots in production) uses ROS, and of those probably 2/3 are on ROS 2 at this point, and the rest are in some stage of migration. ROS 2 solved a lot of problems that didn't need solving, but like it or not ROS 1 is abandonware at this point so almost no one is planning to stick with ROS 1 longer than they have to.
Most companies aren't maintaining their own fork of ROS (other than to submit patches upstream), but a small number of companies on ROS 1 forked it and diverged so significantly that there is no point trying to rebase on ROS 2 - of these GM Cruise was the most notable, although the future of their stack is unknown now that GM canceled the robotaxi project.
The other half of the industry uses some sort of in-house stack built from parts (compare batteries-included frameworks like rails/django to building a backend using libraries like expressjs and sequelize). There is usually some form of pub/sub messaging architecture, because pub/sub is a natural fit for robotics and makes it easier to log and replay/resimulate. Some common things I see are zeromq, vanilla DDS (no ROS), zenoh, or write their own pub/sub (sometimes using shared memory). The messages themselves are often protobuf, flatbuffer, cbor, json, or sometimes just raw c structs.
Building your own stack isn't hard, but its much easier if you have used ROS before and know which concepts you want to reuse, rather than reinventing everything from first principles.
Some newer robotics frameworks are also starting to spring up which is great to see, for example https://github.com/copper-project/copper-rs and https://github.com/dora-rs/dora
There are also frameworks more specifically targeted towards robot learning, for example https://github.com/huggingface/lerobot
If people are just starting out in robotics, or just starting a robotics company, I still recommend ROS despite its warts, it is worth learning because it has had such a big influence on the current ecosystem. There is no "right answer" though, many companies have been successful with each approach.
"You either die trying to scale ROS to production, or you live long enough to repeatedly reinvent it?" - Johnny 5
A previous job used ros2. IMO, it's worse in most ways compared to ros1. The launch system of ros2 alone is enough reason not to use it.
I just got banned from their forum for questioning what the ROS Foundation has done in the past two years--specifically on the build system. Yes, their middleware is unforgiving of alternative ways other than their wrong and outdated development practices, but their community is more religiously attached to their precious tools for development.
This is the post I wrote: https://discourse.ros.org/t/build-systems-package-management...
So it is good that you come and read the comments here. Welcome!
Robotics Developer Studio started off in a promising direction. It had the CCR (Coordination and Concurrency Runtime) and the DSS (Decentralized System Services) which together made it possible to coordinate real time robotics in a RESTful environment across distributed hardware. It had also had full access to .NET. There’s never been anything quite like it since. Unfortunately MS pulled the plug before it had a chance to mature into an easy-to-use well documented platform.