[Rock-dev] Dynamic Ports in Task Model

[Sylvain Joyeux]

> But the more self-descriptive it is, the better.

A general point, not related to the merits of your proposal: this is a
trap. No, it's not, if making it more descriptive makes it too
restrictive. Most model-based frameworks failed miserably because
something that's too restrictive leads to having to work around the
model to achieve your goals. Anything "dynamic" usually fits this.
Most robotic MDE developed in the last 10 years ended up not
supporting anything dynamic for this very reason.

> a) a more streamlined way of how to handle dynamic ports in the code
> b) a better generic knowledge on the structure of your task
> c) a cleaner interface for your model validation to hop onto
> d) a generic and natural way for task introspection

I don't see any of these points achieved by having to set a property
that lists the dynamic ports.

(a) and (b): it does not give more knowledge. The property has to be filled
  * if it is filled by the task's user code, it replicates the current
RTT introspection mechanism
  * if it is filled by *gasp* the system integration layer, it has to
know things about the task's implementation ... with the caveat I
already described.
(c) a cleaner interface for your model validation to hop onto
  * please keep the discussion at a system level. oroGen is not the
only description of the components/system, and should *definitely* not
be. To me, it sounds like a generic "more models are better" argument,
which - as I pointed out at the beginning of this email - is not a
good point to make.
(d) there is already task introspection. Why do you want to create
another task introspection mechanism that doubles it ?

Sylvain

On Wed, Oct 19, 2016 at 9:42 AM, Jakob Schwendner
<jakob.schwendner at dfki.de> wrote:
> Since I started this, I should probably also reply :)
> I would like to avoid any discussion on the general merit of dynamic ports.
> I think it was understood by most what I intended with the proposed change. Just going a bit further with what Sylvain already hinted he would like orogen to generate: the helper function for generating the dynamic ports, and a general contract on the lifecycle (e.g. when can the ports be generated.)
> That orogen itself is not capturing the entire model is fine with me. But the more self-descriptive it is, the better.
>
> Just a few things:
> - I don't see that generating new ports in the RUNNING state is necessary anywhere. Restricting it for the transition to CONFIGURED is not harmful but only helpful.
> - How it works now with e.g. the joint_dispatcher is that you create a configuration, if this configuration is not consistent or invalid, you don't transition to CONFIGURED.
> - The change I proposed would do the same thing: The configuration for the joint_dispatcher (and imho any other module) would just be expressed in a slightly different manner.
> - Yes, only at run-time would you know if it worked, unless you have another model and validation tool sitting on top.
>
> What you gain though, is
> a) a more streamlined way of how to handle dynamic ports in the code
> b) a better generic knowledge on the structure of your task
> c) a cleaner interface for your model validation to hop onto
> d) a generic and natural way for task introspection
>
> One task that was mentioned that would be more complex is the one mentioned by Martin, the robot_frames.
> Instead of parsing a URDF in task, you would put this into the configuration procedure for your task. I think both syskit and orogen.cpp know how to do this, at least with the transformers, and could probably do the same with robot_frames.
>
> Cheers,
>
> Jakob
>
>