Comments (6)
Not that I'm aware of. We've discussed having a "node IDL" where you could define what the topics and their types ought to be separately from the code. This could be used to verify the system you have assembled actually should communicate with one another. But I don't think we have thought to include qualitative things like publish rates.
I'm not sure what the reaction to a topic being too fast or slow should be, a warning, an error, a diagnostics notice?
from design.
I do not really know about IDLs. Is there an article about the concept somewhere in the wiki or in a website article? Would the "node IDL" address services and actions as well? How could this be used to verify a system in detail?
As in usual sw integration testing including qualitative things like publish rates would only allow to make some rough estimate about overall system dynamics and should not be considered as testing I guess. Assuming the verification overhead would have "neglect able" impact on the dynamic overall system behavior it could be helpful during node integration because verification would be faster, easier and more probable than with rostest tests.
Assertions for precondition checking, invariant (unwanted side effect) checking and postcondition checking are usually enabled just in debug builds and disabled in release builds (due to the impact on performance). Failing checks are considered as actual bug when they are "internal" to a component or an whole application during development. However if a component is "public" exceptions are usually used instead at the API level because failing checks are considered miss-use then which can potentially be handled by higher level application code.
from design.
I do not really know about IDLs
IDL is just a generic term (in this case) which means a language used to describe an interface. In this case the interface of Node, which might include things like parameters, topics, actions, services, etc...
Is there an article about the concept somewhere in the wiki or in a website article?
It's not specific to ROS or our stuff here, but:
https://en.wikipedia.org/wiki/Interface_description_language
How could this be used to verify a system in detail?
If you knew, based on the IDL of two packages A and B, that A published to chatter
and B subscribed to chatter
then you could infer that they talk to each other without running them.
from design.
I don't think we have any plans to pursue this in the short term. But I'm sure it's a topic others might be interested in discussing. It would be worth talking about it in the context of ROS 1 as well since I don't think there is anything ROS 2 specific about this idea, though we might have a chance to make it easier if we can identify what in ROS 1 is lacking to make it easier to do.
Feel free to continue the discussion here, but I'd recommend moving it to https://discourse.ros.org instead. To that end I'll close this for now, but it can be commented on or reopened in the future if needed.
from design.
... In this case the interface of Node, which might include things like parameters, topics, actions, services, etc...
... If you knew, based on the IDL of two packages A and B, that A published to chatter and B subscribed to chatter then you could infer that they talk to each other without running them.
That means that an IDL would allow static code analysis by means of verifying the "static" behaviour of node interfaces.
However "Design By Contract" implementations target at checks during system runtime and addresses "dynamic" behaviour as well.
I don't think we have any plans to pursue this in the short term. But I'm sure it's a topic others might be interested in discussing. It would be worth talking about it in the context of ROS 1 as well since I don't think there is anything ROS 2 specific about this idea, though we might have a chance to make it easier if we can identify what in ROS 1 is lacking to make it easier to do.
I would love to have DbC in ROS1 as well
Feel free to continue the discussion here, but I'd recommend moving it to https://discourse.ros.org instead. To that end I'll close this for now, but it can be commented on or reopened in the future if needed.
I will move the move/copy the issue to https://discourse.ros.org and reference it here.
from design.
Design By Contract (discourse.ros.org)
from design.
Related Issues (20)
- Improvements to rmw for deterministic execution HOT 53
- Multirobot support HOT 9
- Middleware alternatives to DDS HOT 4
- fix login by using new GitHub methods HOT 1
- Changes between ROS 1 and ROS 2 design doc is out of date HOT 1
- Add support for fully qualified names in message defnitions
- Add design document on configuring QoS at startup time HOT 4
- Add support for preemption in actions HOT 39
- Update XML schema definition for launch files HOT 2
- Add [ros2 node kill <node_name>] and [ros2 node kill --all] (similar to [rosnode kill] from ros1) HOT 23
- Article numbering is not clear HOT 3
- Topic name constraints discrepancy HOT 9
- Documentation linter HOT 5
- zero-copy: shared memory using external mapped buffer HOT 3
- is intra-process communication meta-message transfered via DDS? HOT 4
- Logging Design Document
- Update Launch XML Schema HOT 3
- can we add a "date written" to the design docs? HOT 2
- Map char[N] to str in Python
- Why must field names of messages and services be lowercase? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from design.