[Rock-dev] Syskit Feedback

[Chris Mueller]

Am 19.03.2013 17:08, schrieb Sylvain Joyeux:
> On 03/19/2013 05:06 PM, Chris Mueller wrote:
>> Am 19.03.2013 16:43, schrieb Sylvain Joyeux:
>>> On 03/19/2013 04:10 PM, Chris Mueller wrote: def intialize(*arguments)
>>>>    super
>>>>    depends_on(..., :role => 'orientation')
>>>> end
>>> You mean that the scripting block that you have defined works on 
>>> Roby::Task but not on compositions ?
>>
>> Exactly.
>>
>>>> 3) DataService are not shadowing the actual task in this szenario.
>>>>
>>>> # profile ...
>>>> use Base::Motion2DControlledSystemSrv => aria_dev
>>>>
>>>> class ConstantMovement < Syskit::Composition
>>>>    add Base::Motion2DControlledSystemSrv, :as => 'system'
>>>>
>>>>    on :start do |ev|
>>>>        puts "#{system_child}" ==> returns the concrete Task (in my 
>>>> case Aria::Task)
>>>>        system_child.command_in_port => throws an error because the 
>>>> port command_in does not exists in Aria::Task
>>>>    end
>>>> end
>>> This is "intended". There are issues with both options, and I am 
>>> personally not really sure which one is best. Needs more discussions.
>> Is there any option to reference in this case to the model? e.g. 
>> system_child.model ? (for having a uniform port_interface)
> I don't understand what you mean by that ...
Usually data_services also form a uniform port_interface for a set of 
tasks that can be used for this services. Most of the time the port names
differs between the concrete tasks.

e.g Controller A has a port  motion_command of type base/MotionCommand2D and
Controller B has a port movement_command of the same type.

If you have now the concret instance and want to access on the port 
through writer/reader you need always the same names for the port
or you add an ugly case definition depending on the concrete orocos task.




> Sylvain