Dear all,
I am happy that my post about synch event handling stimulated a "healthy" discussion in the forum.
As Ianticipated, maybe we should take astep backward and decide which should be the main design criteria of RTT 2.0.
I suggest to keep a "voting" style in our posts, even if it is not ademocratic decision... Peter will just take our opinion into account and decide by itself :D
PLEASE,be concise and, when you reply to someone else e-mail, please quote ONLY the part of the text that is significant, otherwise it is very difficult to keep track of the ideas in the debate.
Ok, lets go straight to the cake.
I would define "flexibility" as the possibility, offered by RTT to the programmer, of create different interface of communication and policies to be used to determine the behaviour of the system.
On the other hand, "safety", in a component based architecture, is related to "decoupling troubles". In the ideal case, a malfunctioning component (called further TaskX) should not jeopardize the behaviour of other components which would have worked properly otherwise. If any component of the system depend strictly from TaskX, there should be amechanism to make this component aware that TaskX is not functioning properly.
The question is: what RTT should be?
A) MORE FLEXIBLE: it is up to the system designer to keep the whole system safe. We never compromize flexibility for safety and the most important feature in the design is real-time performace.
"with great power comes great responsabilities"
B) SAFE for DEFAULT and optionally more FLEXIBLE: the API will be written in such a way that implicity the safest mechanism of communication is the one "promoted". Optinally, there are some settings for "experienced users only" which are more flexible and less safe.
"While I am learning, don't bother me with details"
C) SAFETY FIRST: RTT should be design keeping in mind safety as the first requirement, even if the performance in terms of flexibility and/or real-time might be decreased.
"The life of a person might depend from a robot programmed with Orocos".
Please give your opinion. I really hope we come out from this discussion with a large majority... it would make future discussion much easier!
Please state your preference and the PROS and CONS of your and others option (if you feel you have something to say, of course).
Thank you in advance for your time.
Davide
flexibility vs safety in RTT 2.0
On Apr 27, 2009, at 18:58 , Davide Faconti wrote:
> I start first :)
>
> There is only 1 option that I dislike (the one used so far, by the
> way). The A)
>
> Let me state some of the CONS:
>
> 1) it is against reusability of components. If you can trust a
> component written by someone else, because it can corrupt the
> behaviour of the entire system, you will have to learn by hearth what
> other have done inside their code... read it as "not reusability" and
> "waste of time".
>
> 2) it doesn't make sense to emphatize on real-time and not on
> robustness. Fast response is usually tightly related to prevent
> catastrophic events.
>
> 3) you can not use RTT to create a "safe layer" for your robot (think
> about self-collision, human collision avoidance, impedance controll)
> and then do experiment trusting this layer. A bug in your code would
> affect components with theoretically higher priority than your.
I disagree with all the above. 1) If you trust components written by
someone else without investigation, you should not be writing safety
critical software. 2) Smacks of the reliability vs safety debate,
which has long since been finished. 3) You can use RTT in a safety-
critical robot system.
Safety is a system-wide issue. In robotics it involves the mechanical,
the electrical, *and* software. Opining against Orocos as a method of
safety control is only seeing a small piece of the problem
More in other emails ...
Stephen