0
$\begingroup$

I had just tested my first monitor, which results in the following error regarding the suggestion in How to define conditions for state-machines in roby?

unfortunately i ran into a runtime error, i don't know whether this is a bug or if i misuse the monitor...

16:28:27.564 (Roby) = failed emission of the weak_signal event of Pipeline::Detector:0x71f5cf0
16:28:27.564 (Roby) = Backtrace
16:28:27.564 (Roby) |
16:28:27.564 (Roby) | /home/auv/dev/tools/roby/lib/roby/task.rb:663:in `emitting_event'
16:28:27.564 (Roby) | /home/auv/dev/tools/roby/lib/roby/task_event_generator.rb:46:in `emitting'
16:28:27.564 (Roby) | /home/auv/dev/tools/roby/lib/roby/event_generator.rb:628:in `emit_without_propagation'
16:28:27.564 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:1017:in `block (2 levels) in event_propagation_step'
16:28:27.564 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:648:in `propagation_context'
16:28:27.564 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:1015:in `block in event_propagation_step'
16:28:27.564 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:559:in `block in gather_propagation'
16:28:27.565 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:648:in `propagation_context'
16:28:27.565 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:559:in `gather_propagation'
16:28:27.565 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:1014:in `event_propagation_step'
16:28:27.565 (Roby) |/home/auv/dev/tools/roby/lib/roby/execution_engine.rb:783:in `block in event_propagation_phase'
16:28:27.565 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:761:in `gather_errors'
16:28:27.565 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:779:in `event_propagation_phase'
16:28:27.565 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:1426:in `process_events'
16:28:27.565 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:1940:in `block (2 levels) in event_loop'
16:28:27.565 (Roby) | /home/auv/dev/tools/roby/lib/roby/support.rb:176:in `synchronize'
16:28:27.565 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:1939:in `block in event_loop'
16:28:27.565 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:1917:in `loop'
16:28:27.565 (Roby) /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:1917:in `event_loop'
16:28:27.565 (Roby) | /home/auv/dev/tools/roby/lib/roby/execution_engine.rb:1797:in `block (3  levels) in run'
16:28:27.565 (Roby) =

Don't know whether this is a bug, or if i had miss-used the monitor... here is the action_state_machine i'm using:

183     describe("Find_pipe_with_localization").
184         optional_arg("check_pipe_angle",false)
185     action_state_machine "find_pipe_with_localization" do
186         find_pipe_back = state target_move_def(... some long stuff here ... )
187         pipe_detector = state pipeline_detector_def
188         pipe_detector.depends_on find_pipe_back, :role => "detector"
189         start(pipe_detector)
190
191         pipe_detector.monitor(
192             'angle_checker', #the Name
193             pipe_detector.find_port('pipeline'), #the port for the reader
194             :check_pipe_angle => check_pipe_angle). #arguments
195             trigger_on do |pipeline|
196                 angle_in_range = true
197                 if check_pipe_angle
198                     angle_in_range = pipeline.angle < 0.1 && pipeline.angle > -0.1
199                 end
200                 state_valid = pipeline.inspection_state ==  :ALIGN_AUV || pipeline.inspection_state == :FOLLOW_PIPE
201                 state_valid && angle_in_range #last condition
202             end. emit pipe_detector.success_event
# for non-monitor use, this works if the above is commented out
203 #        forward pipe_detector.align_auv_event, success_event
204 #        forward pipe_detector.follow_pipe_event, success_event
205
206         forward pipe_detector.success_event, success_event
207         forward pipe_detector,find_pipe_back.success_event,failed_event #timeout here on moving
208     end
$\endgroup$
5
  • $\begingroup$ are you sure that the first line is not cut prematurely ? If I look at Roby's code, the error comment is much longer (and more informative) $\endgroup$ Jun 17, 2014 at 12:46
  • $\begingroup$ the only line above is: 11:10:24.775 (Roby) Internal Error: #emit_without_propagation emitted a LocalizedError exception. This is unsupported and will become a fatal error in the future. You should usually replace raise with engine.add_error $\endgroup$ Jun 20, 2014 at 9:15
  • $\begingroup$ OK, got it. There's a bug in the display of the exception. The code does set a pretty specific message but it does not get displayed by EmissionFailed#pretty_print. Looking at the code line, it appears that the event gets emitted but the task is not started $\endgroup$ Jun 23, 2014 at 11:43
  • $\begingroup$ Okay, even so, how it can be happen that the (an) event is emmited in the above code? The code simply emmited the success_event of the pipeline detector which should run..?! $\endgroup$ Jun 23, 2014 at 11:45
  • $\begingroup$ The state machine is not emitting the event that is causing your problem. Something else is. $\endgroup$ Jun 23, 2014 at 14:49

1 Answer 1

1
$\begingroup$

Apart from the error message that is very unspecific (look at my comment to the question), the event that is causing the fault (weak_signal) is not part of the state machine. I guess that there is something else going on here that has no relationship with the monitor at all.

$\endgroup$
2
  • $\begingroup$ What i wondering about, ist that a) in the simulation this monitor works perfectly, and b) if i not using the monitor, and the forward directly the setup works well too..., suggestions? $\endgroup$ Jun 23, 2014 at 11:57
  • $\begingroup$ Have you looked at the event log ? To me, it looks like some event gets forwarded to a task that is not yet started. I start to think that it is something that Roby should ignore and filter out instead of creating an error, would be a lot more usable than the current situation and not change semantics so much. $\endgroup$ Jun 23, 2014 at 13:00

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.