ROS 1 is a danger to public safety, and the very thought of it running things like self driving cars, robots that interact with humans, or exo-sceletons is making me sweat.
It is half assed, complex, and most importantly buggy.
To name one example, instead of relying on some general binary serialisation protocol that everybody uses, ROS implements a custom messsage serialisation format with a custom message schema language, that generates code which involves a lot of raw buffer to struct casting.
To verify compatibility between different talking ROS nodes they exchange a MD5 checksum of a normalized text version of the message schema both nodes have.
The issue is that during the normalisation step they accidentally "forget" the arity of variables (scalar, array including it's length, list).
This can cause two nodes to have slightly different message definitions, which ROS will happily cast into a C struct, just smashing whatever data is out of alignment into other fields that happen to be there.
They consider this a no-fix, since a change of the renormalisation step would mean that packages would have to be recompiled in order to be compatible. And they find that forcing their users to recompile their code is too much of a burden for them.
Also in practice TCP is used for everything, with no QoS whatsoever.
ROS 2 dependency on DDS is a whole other can of worms. While DDS seems to work somewhat well in practice, the fact that it's spec is a monstrous nightmare (hey at least they didn't use corba) and that vendors only show compatibility on a yearly "hey the demo kinda runs" event, doesn't make me conviced that this is not introducing more problems than it solves.
Also even if DDS is a fine system, why entrust the same people that wrote ROS 1 with finding sane defaults for it's QoS, and why choose their horrid message serialisation format, and awkward catkin tooling?
Just use DDS, the DDS message serialisation format, and whatever build system you feel like.
So heed my words, stay away from ROS don't touch it with a ten foot pole unless you absolutely have to.
Source: I wrote a clojure port of ROS that doesn't hook into their codegen chain and reimplements their entire system from the centralized master node to the code generation.
I think your DDS comments apply nicely to OpenDDS, and I sincerely hope that the spotlight of ROS2.0 will improve OpenDDS significantly.
ROS is a good platform to study and learn. It is not something you'll find in a car in a garage. But it is worth it, because there are similar-enough platforms used for actual, real-world applications that would impress even the most curmudgeonly programmer. Such as ...
In my experience, one of my worst experiences with ROS was maintaining environments and python versions as well as the build system.
ROSCORE: a single point of failure. This immediately has a bunch of negative implications on prototyping small nodes and scaling to large systems.
No concept of vehicles, sensors, resources to interact with, and so on. You have to look up what topic to subscribe to, deal with their ad-hoc message types, etc just to connect to a process managing a part of a vehicle / robot.
No semi-persistent data storage is built in, meaning you need separate databases, intra-process shared memory, etc.
Zero multi-agent awareness. You'd have to solve a bunch of problems like adding / disconnecting robots from whomever is running roscore (we don't have one!).
Abysmal command and data routing, and no sub-structures that make it easy to verify commands, ensure the right nodes are in charge, display statuses, discover what nodes are running on a system and how to command them, and so on.
And convenience stuff, like ROS has no command editor for easily scripting a vehicle's actions, without need for programming (though you can program all you want).
And no legacy. We have access to some tried-and-true code-bases here to incorporate.
When you say it's a thin wrapper around DDS, are you using ROS 2 already?
(Personally, while working on my master's thesis I tried ROS for some weeks before switching to V-REP Edu + NumPy + OpenCV. Not saying everybody should do that, but it worked for me)
Caveat: ROS is for research into robotics systems and algorithms. You can pick up your fav language, write something up, and use a thin IPC library (pub / sub) to tie it into the ecosystem.
Otherwise, it quickly becomes impossible to share portable modules and code libraries (all written in different languages, mind you). The alternative: Sticking to their language and compiling in their library or dealing with their dependency chain ... is much worse.
All I'm saying is, there are cases when you do need IPC, but you can do it without ROS... Surely it brings major benefits wrt. code reuse, but it can also be quite intimidating for a newcomer. I guess the best way of mastering it would be working on an existing project and having some experienced user walk you through it.
So there's a learning curve, sure. But when you want to jump on a new system, or prototype a small algorithm on a large system, ROS will save you a lot of trouble. Also it's everywhere. Any academic or industry roboticist will know and probably use ROS, at least for prototyping.
I don't have any opinion on it, just wanted to state that it isn't new, which may be good, stability FTW!!!