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

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Dirk Thomas via ros-users


[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.
[/quote]

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)
[/quote]

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.


If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <http://lists.ros.org/mailman//options/ros-users>
Reply | Threaded
Open this post in threaded view
|

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

Dirk Thomas via ros-users
In reply to this post by Dirk Thomas via ros-users


Instead of waiting for more capabilities in ROS2 it is probably more valuable to add more capabilities to the current ROS1 framework. Without DbC on the ROS node level one can verify the ROS node interface with rostest. Currently the set of reusable test nodes is limited. What about adding more generic test nodes like [fake topic publishers](https://github.com/fkromer/ros_comm/tree/faketopicpublisher) (draft state) to `ros_comm`? (The example tests can be run with `catkin_make run_tests_rostest_rostest_test_faketopicpublisher.test` and `catkin_make run_tests_rostest_rostest_test_faketopicpublisher0.test` in the catkin workspace.)





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


If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <http://lists.ros.org/mailman//options/ros-users>
Reply | Threaded
Open this post in threaded view
|

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

Dirk Thomas via ros-users
In reply to this post by Dirk Thomas via ros-users


[quote="fkromer, post:21, topic:2405"]
ROS is a multi process system on the robot/(multi-)processor level itself. I guess you mean multi device system instead of multiprocess system
[/quote]

Actually I do mean multiprocess. But I do not mean "We cannot make it work/do what we want" or even "We cannot make it do what we want all the time". I mean "We cannot be sure that it will never do [things](https://www.engadget.com/2017/07/17/dc-security-robot-throws-itself-into-pool/) that weren't intended".
And I know for a fact that there are more robots out in the world, doing unexpected dangerous thing, because they weren't programmed with total safety in mind, than most people know about. All it takes is an unchecked integer to wrap around, and disaster strikes in the real world. Make it distributed, and the disaster likeliness increases exponentially.

So sure we can build robots, and distributed systems, but, when it come to a robot that can poke the eye of a child because it looks like it's a button to press, it's different than a harmless backend database cluster in the basement, so you better be sure of what you're programming... and for distributed systems (multiprocess) the theory is quite new, so most language/frameworks won't help you there.

[quote="fkromer, post:21, topic:2405"]
Isnt it the time to ease the development of such systems (and single robots) by providing better framework capabilities?
[/quote]

Definitely yes, but instead of adding potentially heavy features, without being sure they will be used and maintained, I would first focus on doing like https://jepsen.io/, that is, provide tools that show people working in robotics, what and where the problems are in the system they build. Actually probably doing the same as what works for security hackers : tell people their system is broken/unsafe, nobody cares. Make anyone (including their customer) able to [break it](https://usbkill.com/), and then they react... and some might listen.

[quote="fkromer, post:22, topic:2405"]
Instead of waiting for more capabilities in ROS2 it is probably more valuable to add more capabilities to the current ROS1 framework.
[/quote]

I personally fully agree with this statement, but I _think_ most people are focusing on ROS2 these days, which means even less maintenance resource for ROS1, so we need to be careful that what we add is really worth it.

[quote="fkromer, post:22, topic:2405"]
Currently the set of reusable test nodes is limited. What about adding more generic test nodes
[/quote]

I would also agree there. You can always send a PR to add the tests node you miss to rostest, and discuss it with the maintainers :-)
And you can also write a package for the specific nodes you need. I started doing that for my own needs in https://github.com/pyros-dev/pyros-test.
But these days I am thinking we need something more like a ROS [Simian Army](https://github.com/Netflix/SimianArmy) :

- some package that randomly kill and restart nodes, probably based on launch files...
- some package that randomly sends messages around, like a ros-[hypothesis](http://hypothesis.readthedocs.io/) that would generate any valid message based on a ROS definition, to test your nodes against. I have already implemented most of this one, as part of other projects, but I still need to make it a package on its own, whenever I get the time and motivation...
- probably a few more...





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


If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <http://lists.ros.org/mailman//options/ros-users>
12