Syskit use statements are ignored or lost (even in one profile)

[cclausen]

use-statements in the Avalon Profile get lost and you have to redefine EVERY Cmp/Task to use (recursive!) in a new define.

relavant Profilecode that seems to be:

use Base::JointsStatusSrv => thrusters_def
define 'hough_detector', Localization::HoughDetector.
  use(Base::OrientationSrv => PoseAvalon::DagonOrientationEstimator)
use Base::GroundDistanceSrv => altimeter_dev
Hbridge.system(self,'can0','actuatorss','thrusters',6, 3, 2, -1, 4, 5)
define 'world_controller', ::Base::ControlLoop.
  use(thrusters_def,
     'controlled_system' => AuvCont::WorldPositionCmp)
define 'target_move_new', world_controller_def.
  use(Localization::ParticleDetector.
        use(hough_detector_def,
            Base::OrientationSrv  => PoseAvalon::DagonOrientationEstimator),
      'controller' => AuvControl::ConstantCommand,
      Base::GroundDistanceSrv => altimeter_dev,
      Base::ZProviderSrv => depth_reader_dev)

But as this is a "high-level" task, there are most commands depending on others definitions

The ErrorMessage is:

cannot find a concrete implementation for 4 task(s)
Syskit::Component placeholder for Base::OrientationWithZSrv
  3 candidates
    AvalonControl::DephFusionCmp,
    Localization::ParticleDetector,
    Dynamixel::Task
  child ori of Localization::ParticleDetector:0x4d2e7a0{}[]
Syskit::Component placeholder for Base::OrientationWithZSrv
... other 3 Tasks

Neither the ParticleDetector nor the Dynamixel (a motor to spin the laser-mirror) is a OrientationWithZServ. The ParticleDetector CAN be used as one, but there is no code telling Syskit so, in my opinion :-) .

If we use '.use(AvalonControl::DephFusionCmp)' or according definitions we need to define the subcomponents of DepthFusion and so on...

We don't work around this, as it only occures since we added the target_move_new definition using the new controlchain (models/blueprints/auv_cont.rb) as the first action using it.

target_move_def is still working fine in this branch, in another version (branch controlchain of the avalonbundle) even that isn't working, but there are other errors. Therefore we made a "clean" way to get the error.

To reproduce: checkout latest bundles/avalon master-commit (205ed8a84) from https://github.com/auv-avalon/bundle

syskit instanciate -ravalon target_move_new_def!

This currently blocks AVALONs Supervision completly

[doudou]

First, the easy one. Syskit knows better than you do about what provides what. The providers it lists are probably OrientationWithZ providers because they are pose providers. syskit browse would have shown you that.

Where I am lost is why you don't define a configured depth fusion definition and use it directly as your OrientationWithZ provider.

In any case, this does not seem to be a Syskit bug. Since I am the one that suggested that you send this to syskit's issue tracker, I'll go on discussing it here this time. However, next time please as on robotics.stackexchange.com, where Rock user questions are supposed to be asked.

[cclausen]

The easy one: syskit browse doesn't tell me anything about a Dynamixel :-( (with and without -ravalon) The OrientationWithZSrv lists:

Provided By
AvalonControl::DephFusionCmp
Localization::ParticleDetector

define 'target_move_new', world_controller_def.use(localization_detector_def, 'controller' => AuvControl::ConstantCommand, Base:    :GroundDistanceSrv => altimeter_dev, Base::ZProviderSrv => depth_reader_dev)

does not work because of the given error-message (syskit instanciate -ravalon target_move_new_def!)

use ::AvalonControl::SimplePosMove => ::AvalonControl::SimplePosMove.use(position_control_loop_def, localization_detector_def, AvalonControl::DephFusionCmp)
define 'target_move', ::AvalonControl::SimplePosMove

works fine, and it uses the same definition "localization_detector_def" (syskit instanciate -ravalon target_move_def!)

Where I am lost is why you don't define a configured depth fusion definition and use it directly as your OrientationWithZ provider.

We do that:

use AvalonControl::DephFusionCmp => AvalonControl::DephFusionCmp.use(PoseAvalon::DagonOrientationEstimator, altimeter_dev)
use Base::OrientationWithZSrv => AvalonControl::DephFusionCmp

But since we are trying to work around since hours not everything is "the straight forward way" anymore

BTW: I keep getting segfaults with syskit browse/syskit instanciate after seconds/minutes of usage (even without klicking), where can I file these bugs?

[doudou]

Two pieces of advice:

• format your use() statements. If not in your code, then in this issue, reading them is horrible. For an example, see how I reformatted the original text of the issue.
• stop overusing use(def) -- as opposed to use(service => def). The former one looks cool but will bail out if there are ambiguities (your case). The latter is more explicit.
• stop overusing global use() statements. It really looks like you should be creating definitions (especially for the depth fusion composition) and use them where they are needed instead of throwing global use() statements like that.

I wanted to try it our for myself, but I would need an up-to-date model pack. Run rock-pack-models avalon in your rock installation and put the generated avalon.tar.bz2 file somewhere I can download it. I've got one from Matthias a few days ago but it is already invalid.

[cclausen]

You can get an nearly up do date model pack on https://dl.dropboxusercontent.com/u/16997918/avalon.tar.bz2 it refers to 205ed8a84ff75e72b25e68b6f4b54e1da05ac7ad "Syskit use statements are ignored or lost"

I'll try to apply the advices in future

[doudou]

Went to your the commit / pack you sent by email (we'll have to avoid this in the future, took me 10 min to find it back).

The problems I have there are quite straightforward, the definition

define 'world_controller', ::Base::ControlLoop.use(
    'controller' => thrusters_def, 
    'controlled_system' => AuvCont::WorldPositionCmp
)

is completely bogus (both are controlled systems, none are controllers)

[doudou]

Ah ... or I don't have the latest rock.dfki bundle. Can you tarball you whole bundles/ folder and give me access to it ?

[goldhoorn]

Unfortnatly i cannot give you accedd to the spacegit, since it's dfki internal only. but i packed the bundles folder:

http://auv.informatik.uni-bremen.de/framework/logs/20140702-bundle.tgz

[doudou]

That is all I was asking for.

[doudou]

So ... my comment up there was actually right. thrusters_def is a ControlledSystemSrv, not a ControllerSrv

@cclausen: what error do you get ?

[goldhoorn]

So i added a few-additional defines to get the profile (with the old chain) running again.

But i had a few things i could reproduce:

1. Syskit tells the dynamixel is a OrienationWitZ, from my POV there is NO reason wot it to be. I assume it is related to the transformer. But even then it is a bug, a tranformation is not be taken into account to fullfill a classical Dataservice..

2. I had one time that syskit tells me there is no Data service OrientationWithZ available (for the Localization). I nevertheless i tried to enforce it by set it:

   OrientationWithZ => 'depth_fusion' this worked after a new instanciate. I postponed the bug and processed with the work, now i cannot re-trigger this bug anymore :-(

3. global use-statements are totally broken. I tried to force:

   137 #use Base::OrientationWithZSrv => depth_fusion_def

without any success. I need to specify it each time for each define which uses OrientationWithZ. So on the current HEAD we switched from all global use statements to define really everything on our system. By doing so the profile gets really large. It is usable, but i think we should either completely forbid global-use's, OR make them really work. If you @doudou don't want to support this. We had to chose option one.

what me afraids more is with all this defines and recursive defines, and so on. One big part of syskit is lost. We had really to define ALL and everything to make sure that the right system-setup is done. This makes the syskit use one the one hand more intuitive, -> simply defining all Data-Serverices every time, but on the other had more complex and less-easy reusable.

[doudou]

As always, when you complain about something not working, give steps necessary to reproduce it. I don't know whether you are complaining about is a bug or not, because I just can't reproduce it at all.

As for the dynamixel being interpreted as a OrientationWithZ, this is not syskit a syskit bug. The transformation producers are tagged as PoseSrv, and PoseSrv provides OrientationWithZ. If you want to remove this, you'll have a hard time since all PoseSrv are potential transformation producers.

[goldhoorn]

As mentioned, you can reprodce the "use" bug (3) by commenting in line 137, and comment out line 142:

Base::OrientationWithZSrv => depth_fusion_def,

for (2) i will have a look, (1) i cannot reproduce by my own too :-( Everything else @cclausen has to check...

[doudou]

Given how much time I spend helping you there, I think that it would be basic courtesy to be explicit about the ways to reproduce, what you expect and what you get. Especially in an issue thread where between you and @cclausen there are three versions of the bundle, two different states of the underlying system (two system packs) and that you and him may or may not work on the same definition(s). You guys did not even understand what the other was doing properly, so why should I know ?

From now on, the only answer you will get from me is "be more specific" if I don't get:

• the commit in the avalon bundle which I am supposed to use
• a model pack if it changed since the last time
• the command line that I am supposed to run
• what you get
• what you are expecting to get.

[doudou]

Correcting myself, while all PoseSrv are TransformationSrv, all TransormationSrv should not be PoseSrv (which is what is currently defined). Feel free to create PR on the rock bundle to make the change.

[goldhoorn]

I don't know where we are SO unspecific as you mention. Of course @cclausen and me working on different branches -> we do different thinks. The main part we are doing is debugging syskit and triing to get it running in our setups, or with out requirements. And we are struggling from bug to bug.

If we don't mention something special we are talking about the master branch. I working on a different branch, but i never told you because the branch i'm working on is roughly working and i use it only for debugging of the orogen_loader stuff. (or simply running it).

We send you the required model-pack every time you requested it, but the model-pack (so the system setup) is the absolute same. Maybe one version is slightly newer than the other one. But this in only causes by the normal development workflow of large projects.

Christian told you the command he run in the first message of this thread. I not wrote a new one, yes i forgot this because i thought it's not needed because the error occurs on instanciatation during the model check. In my last message i told you the steps to reproduce. (expect the running command, try any definition like target_move_def).

Everything else in my message says "sorry i discovered there a problem which i cannot reproduce", or was a statement how i see (what i think) regarding the "use" problem. You also often answers only to the last part of a message without take into account the (sometimes) multiple points of a comment.

You can find the current model here: https://www.dropbox.com/s/yat7fs75e3ejzvd/2014-07-08-model-pack-avalon.tgz the avalon bundle is on master: 6a5ec0a5e736aacf088cbe80795f68bfde2735f1

[doudou]

Instead of arguing whether it is my job to find out what to do or not, you would save both our time by just giving me a summary of the information I need. You have still not told me what error you get and what you are expecting. Not an interpretation of what the error is, what the error is.

For god's sake, I am asking for four things, and it took three messages to not give them all (and waste a lot of screen space to argue that you did). Stop wasting both our time and just give the information. It would have saved two days and a lot of (virtual) ink.

[goldhoorn]

• the commit in the avalon bundle which I am supposed to use
  • working: https://github.com/auv-avalon/bundle/commit/6a5ec0a5e736aacf088cbe80795f68bfde2735f1
  • non-working (new created): https://github.com/auv-avalon/bundle/commit/9471de814b819e13c5cb59756aeafa19c2aa77dc
• a model pack if it changed since the last time
  • https://www.dropbox.com/s/yat7fs75e3ejzvd/2014-07-08-model-pack-avalon.tgz
• the command line that I am supposed to run
  • syskit instanciate -r avalon target_move_def!
• what you get

cannot find a concrete implementation for 3 task(s)
Syskit::Component placeholder for Base::GroundDistanceSrv
  2 candidates
    SonarTritech::Micron,
    SonarTritech::Echosounder
  child echo of AvalonControl::DepthFusionCmp:0x502c740{}[]
Syskit::Component placeholder for Base::GroundDistanceSrv
  2 candidates
    SonarTritech::Micron,
    SonarTritech::Echosounder
  child echo of AvalonControl::DepthFusionCmp:0x731cdb8{}[]
Syskit::Component placeholder for Base::GroundDistanceSrv
  2 candidates
    SonarTritech::Micron,
    SonarTritech::Echosounder
  child echo of AvalonControl::DepthFusionCmp:0x7bb4ae8{}[]
(Syskit::TaskAllocationFailed) (show: filtered backtrace, full backtrace)
from /home/goldhoorn/bootstraps/avalon/tools/syskit/lib/syskit/network_generation/engine.rb:491:in validate_generated_network
/home/goldhoorn/bootstraps/avalon/tools/syskit/lib/syskit/network_generation/engine.rb:491:in validate_generated_network
/home/goldhoorn/bootstraps/avalon/tools/syskit/lib/syskit/network_generation/engine.rb:464:in compute_system_network
/home/goldhoorn/bootstraps/avalon/tools/syskit/lib/syskit/network_generation/engine.rb:1068:in resolve
/home/goldhoorn/bootstraps/avalon/tools/syskit/lib/syskit/gui/instanciate.rb:129:in block in compute
/home/goldhoorn/bootstraps/avalon/tools/syskit/lib/syskit/gui/instanciate.rb:106:in each
/home/goldhoorn/bootstraps/avalon/tools/syskit/lib/syskit/gui/instanciate.rb:106:in compute
/home/goldhoorn/bootstraps/avalon/tools/syskit/lib/syskit/gui/instanciate.rb:74:in compute
/home/goldhoorn/bootstraps/avalon/tools/syskit/lib/syskit/scripts/instanciate.rb:107:in <top (required)>
/home/goldhoorn/install/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in require
/home/goldhoorn/install/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in require
/home/goldhoorn/bootstraps/avalon/tools/syskit/bin/syskit:19:in <main>

• what you are expecting to get.
  • Should work the same way, because i globally define which GroundDistanceSrv Provider should be used

[doudou]

Both work for me on orogen_loaders. Try cherry-picking 157a45d9c12e6389b6c421dd2a8d80a4d79c3365, it might be the source of your problem (this is a wild guess, I really cannot test).

[goldhoorn]

This seems indeed to solve the issue. I can instanciate with no problems here...

@cclausen did you have any other defines/setups that match this topic/bug? @doudou: back port this to master?

[doudou]

Done. I am closing this, tell me if you still have related problems.