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?
My suggestion: start with ROS, but make absolutely sure to separate ROS from your “business intelligence“. The one think I hate from ROS, is that it makes it difficult. But keep them separated. Also the launch IPC and config parts, don’t do them dependent from each other. If possible do not rely on launcher. So later you can switch away if needed. And you will need. ROS is great for prototyping, changing things, development. But is just not for deploying in production. The whole possibility of inspecting the messages between nodes, means you have to pay a price.
> in your opinion, are these at least well implemented? would they be easy to rip out and run separately?
Not a simple answer:
- from the architecture pov i think many questionable decisions were made: you need to master many languages: XML, launch, message files, yaml, python or C, Cmakefiles for catkin… why?! Why not making launcher files, messages all just yaml or json? Just too complex for nothing.
- The code, you can look yourself, is write only. No way you can change anything without needing 1 year understanding…
- BUT: it does work, and works well. I’ve not found a kill bug or something. So, I guess is ok.
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.
