Only ROS 2 is implemented on top of DDS. Nobody uses it in practice, and the entire thing is super beta. ROS 1 is a danger to public safety, and the very thoug

Only ROS 2 is implemented on top of DDS. Nobody uses it in practice, and the entire thing is super beta. 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.