It's a fine balance between Not Invented Here syndrome vs. trying to hammer the square peg of off-the-shelf OSS into the round hole of the actual problem you're trying to solve.
For example they suggest ROS as a robust industry-ready software, which absolutely hasn't been my experience: you hire a bunch of domain experts to solve the various [hardware, controls, perception, imaging, systems] problems, but once you use ROS as your middleware you end up needing a bunch of ROS experts instead. This is due to the horrible build system, odd choice of defaults, instability under constrained resources, and how it inserts itself into everything. You end up needing more fine-grained control than ROS gives you to make an actually robust system, but by the time you discover this you'll be so invested into ROS that switching away will involve a full rewrite.
The same goes for further downstream: OpenCV images are basically a void* with a bunch of helper functions. (4.x tried to help with this but got sideswiped by DNN before anything concrete could happen.)
I guess it's the same rant the FreeBSD people have about the Linux ecosystem and its reliability. However I'd hope we raise our standards when it comes to mobile robotics that have the potential to accidentally seriously hurt people. And who knows, maybe one day OpenCV and ROS will pleasantly surprise me the way Linux has with its progress.
> they suggest ROS as a robust industry-ready software, which absolutely hasn't been my experience
Also BY FAR not my experience.
Personally I see ROS as a cool thing for prototyping and research, but I see it certainly not as a serious solution for industry.
> This is due to the horrible build system, odd choice of defaults, instability under constrained resources, and how it inserts itself into everything.
This is an excellent short description of the main pain topics. I would add, that the need to work with 5 different languages (YAML, XML, MSG, CMAKE and C and/or Python) from scratch, makes it difficult for SME that are not software people to be productive in short time.
>This is due to the horrible build system, odd choice of defaults, instability under constrained resources, and how it inserts itself into everything. You end up needing more fine-grained control than ROS gives you to make an actually robust system, but by the time you discover this you'll be so invested into ROS that switching away will involve a full rewrite.
So true. The worst is that at many companies they will write a ROS clone in the end that does what they need, instead of getting rid of this awful programming paradigm altogether.
Tbf ROS is a pretty old project. ROS1 dates back to 2009 iirc. A lot of technologies didnt exist back then. Even ROS 2 is now relatively old. The way I see it is that we have since learned a lot about software engineering. I dont think using cmake with catkin and relying on debian packages makes much sense now a days. But back in 2009 I can see why we would have to do it. Heck using catkin to share c++ code by copying the code into a local workspace was so much easier than having to figure out which set of systemwide packages and which cmake incantations would work correctly. Today, however we know how to do packagemanagement much better via tools like cargo. However some core ideas like pub/sub,micro services, message definitions, message recording and playback will be part of your stack.
With regards to startups in general though. Having worked at a few Ive noticed that at the earliest stages the goal is for a few individuals to build quickly. Often this means certain framework choices that may not be suitable to scaling. As one scales one has to then evolve the architecture to ensure developer velocoty. This may mean rewriting everything. Im not surprised that people are rewriting ROS internally. At the end of the day there are a few good ideas in there, but at some point one has to acknowledge that implementations were lacking.
Personally if one were to write a middleware framework in 2024 Id go with rust, mcap, zenoh, rerun and possibly use ecs instead of topics.
Even when ROS started, we already knew a lot of better ways to build software.
The problem is the primary ROS contributor was/is a hybrid robotics engineer + software developer, which meant their colleagues were more likely of "closed, vendor firmware toolchains are normal" et al. norms, which meant their community hadn't internalized a lot of those solutions.
And this isn't to bash different types of devs -- god knows even leading edge software practices have all kinds of gaps -- but is to say that few people can be 100% in multiple hard things, all at once.
At the end what ROS provides for that cost, is a IPC, Logging, configuration and a startup tree (through launch system). Waaaay too expensive.
- We have moved to standard sockets IPC, or protocol buffers.
- For logging just trivial printing.
- For configuration to libconfig
- For launch system to simple shell scripts.
The beauty with using protobuf, libconfig or whatever is that they're libraries. If you find a better RPC/messaging library for your needs it's easy to replace one library, if you find a better config management you replace one library, if you want better logging you replace one library.
I despise the framework approach, it ossifies bad decisions and then it becomes a monumental task to move away from the framework, because now you need to replace everything.
For example they suggest ROS as a robust industry-ready software, which absolutely hasn't been my experience: you hire a bunch of domain experts to solve the various [hardware, controls, perception, imaging, systems] problems, but once you use ROS as your middleware you end up needing a bunch of ROS experts instead. This is due to the horrible build system, odd choice of defaults, instability under constrained resources, and how it inserts itself into everything. You end up needing more fine-grained control than ROS gives you to make an actually robust system, but by the time you discover this you'll be so invested into ROS that switching away will involve a full rewrite.
The same goes for further downstream: OpenCV images are basically a void* with a bunch of helper functions. (4.x tried to help with this but got sideswiped by DNN before anything concrete could happen.)
I guess it's the same rant the FreeBSD people have about the Linux ecosystem and its reliability. However I'd hope we raise our standards when it comes to mobile robotics that have the potential to accidentally seriously hurt people. And who knows, maybe one day OpenCV and ROS will pleasantly surprise me the way Linux has with its progress.