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

[fkromer]

[quote="iluetkeb, post:31, topic:2405"]
Can you give one or more examples of the kind of interface bugs you mean?
[/quote]

One example: You integrate 2 nodes ("a" and "b") which have not been tested before (or if so not well enough). The first node "a" is publishing a topic and the second one "b" subscribes to it and publishes an own topic as well. You know that the subscribing nodes ("b") topic message values may never be outside a valid value range. During integration something goes wrong and you locate the root cause in wrong topic message values published of node "b". You do not know why exactly the topic message values are invalid. It could relate to invalid topic message values which "b" received from "a", or in a wrong implementation of "b" itself which does not prevent from publishing invalid values. Having a DbC mechanism violations of such exceptions would be notified about during node integration even before integration issues could be discovered at all. (It would be possible that integration issues occur just in rare cases and the issue could keep undetected during integration and pop
  up in the field the first time.)

[quote="iluetkeb, post:31, topic:2405"]
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.
[/quote]

As far as I know the only way to detect unconnected nodes which should be connected is to use `rqt_graph`. (Mismatched topic types are even harder to detect and require to look for missing `Connections:` when using `rosnode list <node>`.) Does anyone know how to check issues like that in an automated fashion?

Aren't rostests with [paramtest](http://wiki.ros.org/rostest/Nodes#paramtest) test nodes the candidate to prevent from range issues in parameters?

[quote="iluetkeb, post:31, topic:2405"]
I wouldnt call these interface issues as such, or at least we dont need new specs on that, it would be sufficient to actually check the current ones.
[/quote]

Right. (It was never about interface issues in terms of the ROS implementation just in terms of its usage.)

[quote="iluetkeb, post:31, topic:2405"]
Have you seen my talk at ROSCon? Its 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]

Not yet. I was looking for exactly something like LTTng. Will there be open sourced tools in addition to LTTng?

[quote="iluetkeb, post:31, topic:2405"]
Arent 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]

If the same node is used in different applications and/or environments the requirements that's true abd could be classified via use cases (here: warehouse, car) and the checks parametrized according to that. (Application specific: A warehouse robot should never drive faster than 1m/s. Environment specific: Every of your self-driving cars should not drive faster than 50km/h in the city and faster than 200km/h on the autobahn.)

[quote="iluetkeb, post:31, topic:2405"]
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 weve 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 dont 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 thats again a system-level aspect.
[/quote]

I do not know about the automotive sector at all but the industrial automation sector (hard real-time safety critical, up to IEC61508 SIL3) only. However I know for sure that people use trace tools on the RTOS level like [Trace for FreeRTOS/SafeRTOS](https://www.highintegritysystems.com/tools/safertos-trace/) and on the C function level like [microtrace](http://www.lauterbach.com/frames.html?microtrace.html) for function runtime and response time analysis. However it's possible that this is just done for cases when the system's overall response time cannot be determined using measurements on the system level (e.g. error case handling which could be hard to force on the system level for some cases).





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