The lifecycle of an RtActivity consists roughly of two phases:
1. In the first phase, the RoboticsAPI computes the Activity
2. Then the RCC executes said Activity
Figure 1.3: A RtActivity
A SequentialRtActivity is a Sequence of RtActivities that are started in immediate succession in the same real-time context.
This comes in handy if e.g. the robot needs to apply a tool right after moving, or if the robot is required to execute a certain set of movements in a deterministic and continuous way.
The lifecycle of an RtActivity consists roughly of two phases:
1. In the first phase, the RoboticsAPI computes the Activity
2. Then the RCC executes said Activity
Under normal circumstances, no two phases of the same kind can occur at
once within a device, meaning that before an Activity ”‘B”’ can be planned or
executed, it‘s predecessor ”‘A ”‘ needs to be finished with that phase.
A possible flow of sequences may look like this.
As already stated, there are exceptions to this rule, like the command .beginExecute(), which resumes the program flow once an Activity is running. With this, Activities are able to take over other Activities (e.g. blend two or more Activities). A prerequisite for this is of course, that both Activities are already finished with their planning-phase, so both execution-phases can start to mend. This method may however still result (based on the application and what it wants to accomplish) in a possibly unwanted delay between A and B, especially when A was given the command to be taken over by B. (This may happen because the computation-phase of A is shorter than the computation-phase of B, thus, no takeover can be initiated since B is still computing and ”‘missed”’ the takeover.
This possible source of delay can be neutralized by using SequentialRtActivities.
Instead of planning one activity and then executing it, this class pre-plans a
set of activities (along with all occuring parameters) before even one of them
is executed. This ensures that every activity is planned in a deterministic way.
Once calculated, it will always move the same way.
Right below are two simulations based on the same Code, which consists of three separate Activities. While the first two Activities (One: move slightly right.) (Two, move down) should blend in both examples, they will only do so in the second one because they were encapsulated in a SequentialRtActivity.
| Movements without Sequence | Movements with Sequence |
 |  |
To use the class, you need to instantiate it.
| How to create | Summary |
| SequentialRtActivity() | Instantiates a new SequentialRtActivity |
| SequentialRtActivity(String name) | Instantiates a new SequentialRtActivity with a given name. |
| Alternative : Invoke RtActivities.contSequential(activities) | Returns an instantly created and anonymous SequentialRtActivity |
| Methods | Summary |
| addActivity(T activity) | Adds a new RtActivity to the end of the sequence |
| addContActivity(T activity) | Adds a new RtActivity to the end of the sequence (this activity can be taken over by a subsequent activity) |
| getActivities() | Gets the RtActivities contained in this sequence in the order they will be executed |
Also, the SequentialRtActivity ensures that each and every preplanned Activity gets executed, or none at all. If one RtActivity that is a part of the SequentialRtActivity cannot get executed, the whole Sequence will not start. To clarify this, we will use two examples. Both of them will result in a state of failure, but the program aborts at separate points in time:
The first one uses the class SequentialRtActivity, meaning that each activity will be checked whether it can execute or not. If one of them cannot, the whole sequence will be aborted.
The second code will perform the motions 1 and 2, but will abort at motion 3.