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.
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.