[Rock-dev] Preventing multiple instances of compositions

[Matthias Goldhoorn]

Hmh i wondering regarding this,

i thought we fixed this issue, the problem is here:

Simulation::MarsActuator{1}:0x69a7f58
and
Simulation::MarsActuator{1}:0x73ca0a8

This should be resolved by syskit and reused insted. There seems a 
problem in the nerwork_generation merge-phase.
Try to look into this, why, during the transaction is applied the the 
component could not be reused.
Increase the debug level for this, this should give you the right hin.

It does not seems to be a design problem for syskit.

Otherwise try to create a simple unit-testcase which i can work on...

Matthias

On 17.03.2014 10:48, Christian Rauch wrote:
>
>
> Am 17.03.2014 07:59, schrieb Matthias Goldhoorn:
>> Are you using master?
>> If you are using next the next commit after the merge phase should fix
>> this problem.
> Yes, we are on next. With syskit commit 423fb288 (net_gen: properly 
> synchronize finishing [...]) the error is still present. The error 
> also occurs when switching completely with syskit and roby to master.
>
> Regards,
> Christian
>
>
>> We had this a while ago.
>>
>> Best,
>> Matthias
>>
>> On 14.03.2014 18:25, Christian Rauch wrote:
>>> Hello,
>>>
>>> we have a simulation composition (AriaSim) using some simulated 
>>> devices.
>>>
>>> If we start this and an additional composition connected to simulated
>>> devices we get sometimes (not reproducible) this error message:
>>>
>>> {{{
>>> Syskit[FATAL]:
>>> /home/christian/rock_virgo_next/tools/syskit/lib/syskit/network_generation/engine.rb:526:in 
>>>
>>> `block (2 levels) in validate_generated_network': device locomotion is
>>> assigned to both Simulation::MarsActuator{1}:0x69a7f58{driver_dev =>
>>> device(Dev::Simulation::Mars::Actuator, :as => locomotion), conf =>
>>> [locomotion], locomotion_actuators_mappings => [1, 2, 3, 4]}[] and
>>> Simulation::MarsActuator{1}:0x73ca0a8{driver_dev =>
>>> device(Dev::Simulation::Mars::Actuator, :as => locomotion), conf =>
>>> [locomotion], locomotion_actuators_mappings => [1, 2, 3, 4]}[], but
>>> the tasks have mismatching inputs (Syskit::SpecError)
>>> }}}
>>>
>>> Where locomotion is a simulated devices defined by:
>>> {{{
>>> define_simulated_device("locomotion", Dev::Simulation::Mars::Actuator)
>>> do |dev|
>>> ::Simulation::MarsActuator.dispatch('locomotion_actuators',
>>> (1..4).to_a ).
>>>          use_deployments(/mars_locomotion/).
>>>          with_arguments(dev.arguments).
>>>          with_conf('locomotion')
>>> end
>>> locomotion_dev.period 0.01
>>> }}}
>>>
>>> and used in:
>>> {{{
>>>    define 'aria', Virgo::AriaSim.use(
>>>      'actuators' => locomotion_def,
>>>      [...]
>>>    )
>>> }}}
>>>
>>> In the network graph (see attached *.dot file) one can see that the
>>> simulation composition (Virgo::AriaSim) is started twice, and
>>> therefore also the Simulation::MarsActuator::Cmp.
>>> I guess that is not correct.
>>>
>>> It might be, that this problem does not occur when a second
>>> composition is started accessing a simulated device, but then it
>>> happens later when a third, ... composition is started.
>>>
>>> => Any ideas why this happens and only happens randomly?
>>>
>>>
>>> Our guess was to prevent the creation of multiple AriaSim instances by
>>> setting it as a driver by:
>>> {{{
>>> class AriaSim < Syskit::Composition
>>>      [...]
>>>      driver_for Dev::Platforms::MobileRoboticsSim, :as=>'ariasimdev'
>>> end
>>> }}}
>>>
>>> Which results in the error:
>>> {{{
>>> Syskit[FATAL]: cannot find a device to tie to 1 task(s)
>>> Syskit[FATAL]: for Virgo::AriaSim:0x64e5380{}[]
>>> Syskit[FATAL]:   no candidates for Virgo::AriaSim:ariasimdev
>>> Syskit[FATAL]: Engine#resolve failed
>>> }}}
>>>
>>> => So the second question is if a composition could be set as a driver
>>> and if so, how?
>>>
>>> Regards,
>>> Christian
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Rock-dev mailing list
>>> Rock-dev at dfki.de
>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>
>>
>


-- 
  Dipl.-Inf. Matthias Goldhoorn
  Space and Underwater Robotic

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 1
  28359 Bremen, Germany
  
  Zentrale: +49 421 178 45-6611
  
  Besuchsadresse der Nebengeschäftstelle:
  Robert-Hooke-Straße 5
  28359 Bremen, Germany
  
  Tel.:    +49 421 178 45-4193
  Empfang: +49 421 178 45-6600
  Fax:     +49 421 178 45-4150
  E-Mail:  matthias.goldhoorn at informatik.uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik