[ros-users] [Discourse.ros.org] [Next Generation ROS] Design By Contract

fkromer ros.discourse at gmail.com
Sat Sep 9 11:27:32 UTC 2017

[quote="asmodehn, post:20, topic:2405"]
Dont build a distributed (==multiprocess) system if you dont have to. Programming language elements (functions, classes, libraries, packages) are made for composing correctly in all sorts of ways, and there is usually theoretical background, tooling, conventions, processes, to help you satisfy the cognitive biases you didnt know you had. No distributed software system that allows you to control the distribution graph, has anything equivalent to that currently. ROS is no exception (actually erlang might be the only exception).
Example : A whole part of Operating System design is to prevent processes interactions, and most recent OSes are preempting ? This is opposed to the features suitable for a distributed system, which by definition needs process cooperation, and where controlling when each process can be interrupted, or not, is really useful. In one process, in one language, all these problems vanish.

ROS is a multi process system on the robot/(multi-)processor level itself. I guess you mean multi device system instead of multiprocess system. Right, distributed systems are beyond robotics. However robotics and distributed systems have already merged into distributed robotics ([Kiva robots in an Amazon warehouse in 2011](https://www.youtube.com/watch?v=6KRjuuEVEZs)). Isn't it the time to ease the development of such systems (and single robots) by providing better framework capabilities?

As Amazon already did non real time distributed robotics in 2011 I think considerations w.r.t. preemption and inter-process interaction beyond the robot level is more critical in real-time (soft/firm/hard) applications.

[quote="asmodehn, post:20, topic:2405"]
Regarding ROS, the best bet is likely to integrate/interface/implement ROS with the existing programming language that provide the feature that you need, instead of trying to integrate that awesome language feature into ROS (because it implies re-implementation and proactive maintenance from ROS community for something that is not purely robotics related)

I would argue that if a framework implementation lacks conceptual features this cannot be compensated with the choice of suitable programming languages which address lower levels of abstractions only. But you are right, it is better to improve a framework w.r.t. to it's given capabilities instead of trying to integrate language features (at least in the short term).

[Visit Topic](https://discourse.ros.org/t/design-by-contract/2405/21) or reply to this email to respond.

More information about the ros-users mailing list