Using States to handle runtime events

As stated in section 1.4.4, RtActivities are executed atomically in a real-time context by the RCC. This execution can be controlled by the Robotics API only in a limited way. However, it provides means to specify reactive behavior in RtActivities before their execution. This specification consists of two parts: On the one hand, specifying the events that should trigger a reaction (e.g., some sensor measuring certain values) and on the other hand, defining the reaction to those events.

Events are modeled in the Robotics API by the concept State. A State describes some part of the robot system’s state during its runtime which may be true (the corresponding Robotics API State is then called ’active’) or false. States are supplied by various sources, e.g. sensors (related to their measurements), devices (expressing their internal state) and also RtActivities (related to their execution state). The following examples illustrate this:

• LWR lwrLeft = RoboticsRegistry.get("LwrLeft", LWR.class); 
  DoubleSensor forceXSensor = lwrLeft.getForceXSensor(); 
  // A State that is becoming active when a certain measured value is exceeded 
  State greater = forceXSensor.isGreater(5);
• DigitalInput in0  = RoboticsRegistry.get("in0", DigitalInput.class); 
  // State that reflects the state of the digital input 
  State setState = in0.getSetState();
• LWR lwrLeft = RoboticsRegistry.get("LwrLeft", LWR.class); 
  PlannedRtActivity ptpHome = lwrLeft.use(PtpInterface.class).ptpHome(); 
  // State that becomes active at 50\% of the motion's execution time 
  State progress = ptpHome.getMotionTimeProgress(0.5);

The change in the activeness of a State is an event that can trigger a reaction. This reaction can influence the execution of a single RtActivity, or can influence the coordination of multiple RtActivities. The rest of this section explains how single RtActivities can be enhanced by reactive behavior. The orchestration of multiple RtActivities according to certain patterns is discussed in section 1.5.

On the level of single RtActivities, the current version of the Robotics API allows to define States that lead to cancelling the RtActivity. Cancelling indicates that the RtActivity should stop execution as fast as possible. The method

declares the given States to be triggers that lead to cancelling the RtActivity. Any of the States specified will lead to cancelling the RtActivity as soon as it becomes active. The same applies to any States supplied to subsequent calls to this method.

In section 1.4.4, the method RtActivity.cancelExecute() was introduced as a way to cancel an RtActivity from the Java workflow. In contrast to this, States which are defined as cancelling conditions are monitored in the same real-time context as the RtActivity during execution. Thus, fast and deterministic triggering of cancel is guaranteed.

The following extension of the abovementioned example code cancels a motion as soon as a field bus input has been set:

As mentioned before, each RtActivity is required to handle cancelling as best as possible. Path motions in the Robotics API are implemented such as to brake the robot as fast as possible upon cancel.