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

[Asmodehn]

I might be stating the obvious here, but still worth reminding everyone I think...

> How can I prevent from introducing defects into distributed ROS systems which have their root cause in the dynamic interaction of several ROS nodes?

- Don't build a distributed (==multiprocess) system if you don't **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 didn't 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](https://en.wikipedia.org/wiki/Process_isolation), and most recent OSes are [preempting](https://en.wikipedia.org/wiki/Scheduling_(computing)#Summary) ? 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.

- If you have to build a distributed system, congratulations, you are doing distributed system research. This is not robotics and there is a different set of assumptions coming along in that context.
Example : most existing and widely-used distributed software systems rely on the fact that a message, a unit of computation "task", is atomic and [idempotent](https://en.wikipedia.org/wiki/Idempotence). That requirement usually cannot be met in a robotic platform, because of side effects on the real world, the whole point of it. Painful lesson after a year working on https://github.com/asmodehn/celeros - .

For the rest of us having to do both distribution and real world side-effect, I feel the most promising way, is still [integrating side-effects into the theory](https://en.wikipedia.org/wiki/Monad_(functional_programming)#Motivating_examples). But, as far as I know, it is still a software research topic on its own.

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)

For DbC, I'm thinking if you get around implementing a Eiffel-based ROS interface/integration/implementation, you might find some interesting changes needed in ROS itself, even in REPs, in order to make that possible without compromising [Eiffel](https://en.wikipedia.org/wiki/Eiffel_(programming_language)). I'm thinking these changes would likely be worth it for ROS, especially in the long run.
Disclaimer: I'm currently following the same path with Python, improving how ROS integrate with it along the way, and finding basic problems where I didn't expect to...

But ultimately, writing a "solid" software project is a matter of computer science and software engineering expertise, so general software theory, knowledge and tools apply there. It's not a problem specific to robotics, and therefore robotic science and tools (like ROS) are not focusing on it.





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