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

[Ingo Lütkebohle]

[quote="fkromer, post:30, topic:2405, full:true"]
Initially my intention to start this thread was to discuss if and how formal specification and formal verification of ROS 2 node/nodelet interfaces by means of DbC could be applied to/implemented in ROS 2. I am interested in DbC because it has the big advantage that it could speed up the integration of ROS 2 nodes/nodelets within a system because it prevents from struggling with bugs which relation to the interface based interaction between nodes/nodelets. 
[/quote]

Can you give one or more examples of the kind of interface bugs you mean?

In my experience, the most frequent issue -- at least initially -- with connecting nodes is that something is not connected, because of a wrong name. The next most frequent seems to be spelling and/or range issues in parameters.

I wouldn't call these interface issues as such, or at least we don't need *new* specs on that, it would be sufficient to actually check the current ones.

[quote="fkromer, post:30, topic:2405, full:true"]
(I do not know about any tracing tools for ROS which are usual tools for real-time related verification.) 
[/quote]

Have you seen my talk at ROSCon? It's not specifically about that, but I mention how we used LTTng to trace messages and callback invocations. This is in the soon-to-be-released tracetools package.

[quote="fkromer, post:30, topic:2405, full:true"]
However w.r.t. rates and response times I would consider different "classes":
1) the "incoming" rates one node/nodelet expect from other nodes to receive, the nodes/nodelets "outgoing" rates which are expected from other nodes, the response time of one node
2) the rates and response time of a component
2) the rates and response time of a system

If 1) the node/nodelets do not satisfy "rough" rate or response time requirements there is a pretty good chance that 2) the component or 3) the system will not behave like you would like it to behave as well.
[/quote]

Aren't those specs strongly related to your requirements or, in other words, to the outward behavior your system is expected to have? For example, when I drive a 1m/s in a warehouse, I might have different requirements regarding pose update rate then when I drive 50km/h through city traffic.

[quote="fkromer, post:30, topic:2405, full:true"]
[quote="iluetkeb, post:29, topic:2405"]
"I am also strongly of the opinion that rates should be a property of a system, not a component."
[/quote] 
People having a background in safety critical, real-time embedded system development could disagree here.
[/quote]

Hmm, most of what I know about embedded systems comes from the automotive people here at Bosch, and they are very concerned with safety. I might have got it wrong, of course, but given how often we've internally talked about this, I would be surprised.

What is true is that rates are often *specified* on a task level, with callbacks being assigned to a task according to their rate needs, but that is an implementational aspect, which most people actually don't like, but accept as the way things are, unfortunately, implemented.

Anyway, in most cases, they are not interested in rates at all, only in *response time*, and that's again a system-level aspect.





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