using plain OROCOS components with scheme

[konradb3]

It would be useful to not have dedicated components for CONMAN. Currently every component have to implement Operation interface for CONMAN which make them difficult to reuse in other context.

I think that service interface can be eliminated ( #3 , #4 ). The remaining setOutputLayer can be moved to addBlock operation of the scheme. I would also not limit to only control and estimation layers/sub-graphs but allow arbitrary number.

Do we have any use cases for setting ports to non-exclusive mode ?

[jbohren]

It would be useful to not have dedicated components for CONMAN. Currently every component have to implement Operation interface for CONMAN which make them difficult to reuse in other context. I think that service interface can be eliminated ( #3 , #4 ).

I'll give some motivation / justification on the design decisions in #3 and #4, but here I'll point out that while conman requires these operations, these operations can be named anything, and they can be registered at runtime with the HookService, so even a component which is designed to be used with conman doesn't actually have a build-time or run-time dependency on the conman library.

I would also not limit to only control and estimation layers/sub-graphs but allow arbitrary number.

I think for now, we should stick to just the two layers, simply because they have a clear semantic meaning which relates directly to design. Are there other use cases / graph topologies that don't fit into the two-layer desigmn constraint? My philosophy is that the usefulness of a framework meant to solve a given class of problems is only as useful as the constraints it enforces on the design of solutions to such problems. This means that if we allow an arbitrary number of layers, we lose the usefulness that partitioning into layers gives us in the first place.

Do we have any use cases for setting ports to non-exclusive mode ?

Yeah, if a port corresponds to some sort of sparse / event-like input. You could also have a port which combines all of the messages on it in some reasonable way (adding efforts, composing constraints on a controller, etc).

[konradb3]

Do we have any use cases for setting ports to non-exclusive mode ?

Yeah, if a port corresponds to some sort of sparse / event-like input. You could also have a port which combines all of the messages on it in some reasonable way (adding efforts, composing constraints on a controller, etc).

I think that all data ports must be exclusive and buffered ports non-exclusive. I don't consider non-exclusive ports as useful for RT controllers.

[jbohren]

I think that all data ports must be exclusive and buffered ports non-exclusive.

Right, this is something you mentioned during our conversation the other day. So, as I understand it, RTT::InputPorts can have a default connection policy (OutputPorts do not), but when you're connecting them you can't rely on the user using the default connection:

http://www.orocos.org/wiki/rtt/rtt-20/upgrading-rtt-1x-20/rtt-20-data-flow-ports It is possible to define a default policy for each input port, but it is not recommended to count on a certain default when building serious applications. See the 'RTT::ConnPolicy' API documentation for which policies are available and what the defaults are.

This means that we can't simply define exclusivity based on the connection policy.

I don't consider non-exclusive ports as useful for RT controllers.

I think it's a useful design tool to have, and as long as its modeled in the switching framework, conman can reason about it.

Also, I didn't respond to this before:

The remaining setOutputLayer can be moved to addBlock operation of the scheme.

The problem with this is that it pushes the definition of the meaning of an output port onto the developer who composes multiple blocks, instead of the developer who designs the blocks, themselves. The the whole point of defining this internally is that it defines how the block needs to be executed, no matter what it's connected to.

[konradb3]

http://www.orocos.org/wiki/rtt/rtt-20/upgrading-rtt-1x-20/rtt-20-data-flow-ports It is possible to define a default policy for each input port, but it is not recommended to count on a certain default when building serious applications. See the 'RTT::ConnPolicy' API documentation for which policies are available and what the defaults are.

This means that we can't simply define exclusivity based on the connection policy.

But we can enforce (set) connection policy inside the scheme. I think that we should not allow for buffered connections inside the graph and allow anything on the edges.

The remaining setOutputLayer can be moved to addBlock operation of the scheme.

The problem with this is that it pushes the definition of the meaning of an output port onto the developer who composes multiple blocks, instead of the developer who designs the blocks, themselves. The the whole point of defining this internally is that it defines how the block needs to be executed, no matter what it's connected to.

I am not entirely sure that we need to create two graphs. In my MDE tool the feedback loops was removed before scheduling the graph. Each component defines set of DataPorts required to run. if there was port that was not required it don't transferred into graph for scheduling.

[jbohren]

http://www.orocos.org/wiki/rtt/rtt-20/upgrading-rtt-1x-20/rtt-20-data-flow-ports It is possible to define a default policy for each input port, but it is not recommended to count on a certain default when building serious applications. See the 'RTT::ConnPolicy' API documentation for which policies are available and what the defaults are.

This means that we can't simply define exclusivity based on the connection policy.

But we can enforce (set) connection policy inside the scheme. I think that we should not allow for buffered connections inside the graph and allow anything on the edges.

This is an interesting idea, though I do think that we should allow buffered (non-exclusive) ports. So this would be different than RTT's normal pattern where a component designer sets the default connection policy, and instead the designer of a component specify the required connection policy which corresponds to the port's exclusivity.

The remaining setOutputLayer can be moved to addBlock operation of the scheme.

The problem with this is that it pushes the definition of the meaning of an output port onto the developer who composes multiple blocks, instead of the developer who designs the blocks, themselves. The the whole point of defining this internally is that it defines how the block needs to be executed, no matter what it's connected to.

I am not entirely sure that we need to create two graphs. In my MDE tool the feedback loops was removed before scheduling the graph. Each component defines set of DataPorts required to run. if there was port that was not required it don't transferred into graph for scheduling.

Right, but the assumption here is that you do have DataPorts which are both required to run and introduce cycles.

[konradb3]

The remaining setOutputLayer can be moved to addBlock operation of the scheme.

The problem with this is that it pushes the definition of the meaning of an output port onto the developer who composes multiple blocks, instead of the developer who designs the blocks, themselves. The the whole point of defining this internally is that it defines how the block needs to be executed, no matter what it's connected to.

I am not entirely sure that we need to create two graphs. In my MDE tool the feedback loops was removed before scheduling the graph. Each component defines set of DataPorts required to run. if there was port that was not required it don't transferred into graph for scheduling.

Right, but the assumption here is that you do have DataPorts which are both required to run and introduce cycles.

Yes, but i am talking about annotating the connections as feedback loop not a ports. This is very similar to what you do in simulink or labview, you put the unit delay on the feedback loop.

[jbohren]

In PR #6, the computeControl() and computeEstimation() hooks are gone, and components are assumed to play a single role (control xor estimation), and the updateHook is expected to serve one of those roles.