2
$\begingroup$

I am searching for a way that allows me to wait for some conditions on ports before applying a new state.

My concrete Problem: I want to make sure that my AUV aligns to the right pipeline. Therefore before starting the pipeline-tracking, I want to check for the current system heading.

My current state-machine looks like this:

find_pipe_back = state target_move_def(:finish_when_reached => false , :heading => 1 ...)

pipe_detector = state pipeline_detector_def

pipe_detector.depends_on find_pipe_back, :role => "detector"

start(pipe_detector) forward pipe_detector.align_auv_event, success_event

roughly I am looking for a way to condition the last-forward.

$\endgroup$
1
$\begingroup$

Such "conditioning" was existing in the pre-syskit days, and it got removed as it made the state machines considerably more complex. Usually, what starts as a simple condition becomes quickly something a lot more involved.

The best way is therefore to create a dedicated composition that would do the monitoring:

class PipelineFinder < Syskit::Composition
  argument :expected_heading
  add PipelineDetector::Task, :as => 'detector'
  def heading_within_tolerance?(current, tolerance)
    # Test for tolerance
  end
  task_script do
    # Don't know the name of the relevant port, so I am making it up
    reader = detector.pipeline_state_port.reader
    wait detector.align_auv_event
    if (data = reader.read_new) && heading_within_tolerance?(data.yaw, tolerance)
      emit :success
    else
      emit :false_positive
    end
  end
end

Note that you could also attach the task script on the detector task in a separate action:

describe('runs the pipeline detector but filters against an expected direction').
   required_arg('expected_heading')
def detect_pipeline_with_validation(arguments = Hash.new)
   detector = pipeline_detector_def
   expected_heading = arguments[:expected_heading]
   detector.task_script do
     # same script than up there, except that expected_heading
     # is in this case a local variable
   end
   detector
end
| improve this answer | |
$\endgroup$
  • $\begingroup$ Regarding the compositions you mention, i have then to poll inside of the composition and emit a own-defined event for this?. I would prefer the action_script way you proposed, is there a drawback from design point of view?. I see the actions scripts more robust because they are checked during modeling only during runtime!?? $\endgroup$ – Matthias Goldhoorn Jun 4 '14 at 8:25
  • $\begingroup$ I now tried this solution, the problem is that poll is not defined for action_scripts. :-( $\endgroup$ – Matthias Goldhoorn Jun 10 '14 at 14:25
  • $\begingroup$ Then you need to use a monitoring composition and integrate it into your state machine. One thing that bothers me: what is the semantic of the test ? Would it not be something that would make sense to put in the detector composition (having an optional expected_direction argument and a found_expected_pipeline event ?) $\endgroup$ – sylvain.joyeux Jun 10 '14 at 14:40
  • $\begingroup$ Could do something like this (adding to the detector-cmp or create monitor cmp), but i had the impression that my use case is really mission-specific (more a workaround for the current-scenario). There are (again) multiple ways of doing it. Not sure what's in general the best. But i want to keep the compositions as simple as possible. Only a composition, not a "solving"-thing in general $\endgroup$ – Matthias Goldhoorn Jun 10 '14 at 14:53
0
$\begingroup$

I don't know if i understand right, but couldn't you make another condition in your state machine for a transition? So for example if you find a pipe or whatever and afterwards you get the permission from the user to follow this pipe ... these two conditions could form the transition to switch to the next state.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.