Real-Time Robotics Framework

User Tools

Site Tools

You are here: EEROS Wiki » EEROS Architecture » Sequencer » Sequence
eeros_architecture:sequencer:sequence

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
eeros_architecture:sequencer:sequence [2017/08/16 09:53] – [Simple Example] grafeeros_architecture:sequencer:sequence [2020/05/22 11:08] (current) – [Simple Example] ursgraf
Line 5: Line 5:
 A main feature of a sequence is whether it blocks the flow of control during running through its steps or whether the steps run in parallel to the main flow of control. A main feature of a sequence is whether it blocks the flow of control during running through its steps or whether the steps run in parallel to the main flow of control.
 [{{ :eeros_architecture:sequencer:sequenceblocking.png?500 | //Sequence B is blocking, sequence C is nonblocking// }}] [{{ :eeros_architecture:sequencer:sequenceblocking.png?500 | //Sequence B is blocking, sequence C is nonblocking// }}]
-Sequence A runs. That is, all its steps run consecutively. After step 1 is done the sequence B is called. As B is blocking its two steps run while A is being blocked. Only after B finishes does the control return back to A where step 2 and step 3 are then executed. After this sequence C is called. As C is nonblocking its two steps run in parallel to the remaining steps of sequence A. A must wait for C to finish by calling //join//. \\ +Sequence A runs. That is, all its steps run consecutively. After step 1 is done the sequence B is called. As B is blocking its two steps run while A is being blocked. Only after B finishes does the control return back to A where step 2 and step 3 are then executed. After this sequence C is called. As C is nonblocking its two steps run in parallel to the remaining steps of sequence A. A must wait for C to finish by calling //wait()//. \\ 
-A nonblocking sequence will run in its own thread of execution while a nonblocking sequence always runs in the same thread as the calling sequence.+A nonblocking sequence will run in its own thread of execution while a blocking sequence always runs in the same thread as the calling sequence.
  
-IMPORTANT The main sequence must always be defined as nonblocking. Otherwise, the main program would not return after calling //start()//. +IMPORTANT The main sequence must always be defined as nonblocking. Otherwise, the flow of control would not return to the main program after calling //start()// of the main sequence. 
  
 ===== Sequence and Step ===== ===== Sequence and Step =====
-Every step is itself basically a sequence. However, a step is always blocking. All the other features such as preconditions and exit conditions as well as monitors are identical, see below. A user has to define her own sequences or steps with: +Every step is itself basically a sequence. However, a step is always blocking. All the other features such as preconditions and exit conditions as well as monitors are identical, see below. A user has to define her own sequences or steps as described in [[.:define_sequence|]]. 
-  - Extend class //Sequence// or //Step//, respectively. +
-  - Implement the function //action()//. This comprises the work which should be done. In case of a sequence this might be a sequence of steps. In case of a step it might be setting a new set position.  +
-  - Implement the ()-operator with parameters. This ensures that calling a sequence or step with parameters (e.g. step1(10, 3)) is possible. +
  
  
Line 22: Line 20:
  
   - Every sequence starts by checking the preconditions for this sequence to be met. If the test fails the sequence will immediately stop.     - Every sequence starts by checking the preconditions for this sequence to be met. If the test fails the sequence will immediately stop.  
-  - The main work of the sequence is done in the function //action()//. Such a function can include any amount of work. However, this function should not block (do not use sleep, do not wait for some condition, do not wait for user input). This point is highly important, because a blocking //action//-function does not allow for checking exit conditions and monitors, see next point.+  - The main work of the sequence is done in the function //action()//. Such a function can include any amount of work. However, this function should not block (do not use sleep, do not wait for some condition, do not wait for user input). This point is highly important, because a blocking //action//-function does not allow for checking exit conditions and monitors, see [[eeros_architecture:sequencer:define_sequence#define_exit_conditions|Define Exit Conditions]].
   - The sequence than repetively checks for its exit condition to become true. As long as this is not the case, the sequence or step stays in this loop.    - The sequence than repetively checks for its exit condition to become true. As long as this is not the case, the sequence or step stays in this loop. 
   - In parallel to checking the exit condition the monitors of each sequence are also checked. For monitors see [[.:monitors]]. As soon as a monitor fires the sequence or step will terminate.   - In parallel to checking the exit condition the monitors of each sequence are also checked. For monitors see [[.:monitors]]. As soon as a monitor fires the sequence or step will terminate.
Line 31: Line 29:
 class Move : public Step { class Move : public Step {
 public: public:
-  Move(std::string name, Sequencer& seq, BaseSequence* caller, Robot& r) : Sequence<>(name, seq, this) { }+  Move(std::string name, Sequence* caller, Robot& r) : Step(name, this) { }
   int operator() (double x, double y) {xPos = x; yPos = y; return start();}   int operator() (double x, double y) {xPos = x; yPos = y; return start();}
   int action() {   int action() {
     robot.setValue(xPos, yPos);     robot.setValue(xPos, yPos);
 +    return 0;
   }   }
   bool checkExitCondition() {   bool checkExitCondition() {
Line 44: Line 43:
 class MoveSequence : public Sequence { class MoveSequence : public Sequence {
 public: public:
-  MoveSequence(std::string name, Sequencer& seq, BaseSequence* caller) : Sequence<>(name, seq, this), moveXY("step", seq, this) {setNonBlocking();}+  MoveSequence(std::string name, Sequencer& seq) : Sequence(name, seq), moveXY("step", this) { }
   int action() {   int action() {
     robot.moveXY(10, 10)     robot.moveXY(10, 10)
     robot.moveXY(15, 25);     robot.moveXY(15, 25);
     robot.moveXY(22, 35);     robot.moveXY(22, 35);
 +    return 0;
   }   }
 private: private:
Line 55: Line 55:
 </code> </code>
  
-The sequence moves a hypothetical robot in x,y direction.+The sequence //MoveSequence// comprises three steps //moveXY//. Each of them moves a hypothetical robot a predefined robot in x,y direction. 
 + 
 +===== Waiting for Sequences to Finish ===== 
 +Usually at some stage in your program you have to wait for a given sequence to finish until the program should continue. There are two methods to accomplish this, ''wait()'' and ''waitAndTerminate()''. \\ 
 +The former waits for a given sequence to finish running. It returns as soon as all the steps defined in the sequence have completed running. However, it does not terminate the associated thread. This allows to restart the same sequence with ''start()'' later on in the program. \\   
 +On the other hand, ''waitAndTerminate()'' does also wait for all the steps defined in the sequence to have completed. Further, it will terminate the associated thread and return only after successful elimination of the thread object. After this, the sequence cannot be restarted. \\ \\ 
 +IMPORTANT Never use ''wait()'' or ''waitAndTerminate()'' from within the safety system or the control system. The two methods should solely be used by other sequences or by the main program.
  
eeros_architecture/sequencer/sequence.1502870022.txt.gz · Last modified: 2017/08/16 09:53 by graf