@wandelbots/nova-api 26.6.0-rc.3 → 26.7.0-dev.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/v2/index.cjs CHANGED
@@ -701,7 +701,7 @@ const ActionChunkStreamingApiFactory = function(configuration, basePath, axios$2
701
701
  */
702
702
  var ActionChunkStreamingApi = class extends BaseAPI {
703
703
  /**
704
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
704
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
705
705
  * @summary Execute Action Chunks
706
706
  * @param {string} cell Unique identifier addressing a cell in all API calls.
707
707
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -3256,7 +3256,7 @@ var ControllerApi = class extends BaseAPI {
3256
3256
  return ControllerApiFp(this.configuration).listRobotControllers(cell, options).then((request) => request(this.axios, this.basePath));
3257
3257
  }
3258
3258
  /**
3259
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > Set control mode as the default with `PUT /api/v2/cells/{cell}/controllers/{controller}/mode?mode=MODE_CONTROL`. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
3259
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
3260
3260
  * @summary Set Default Mode
3261
3261
  * @param {string} cell Unique identifier addressing a cell in all API calls.
3262
3262
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -3650,7 +3650,7 @@ const JoggingApiFactory = function(configuration, basePath, axios$66) {
3650
3650
  */
3651
3651
  var JoggingApi = class extends BaseAPI {
3652
3652
  /**
3653
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
3653
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
3654
3654
  * @summary Execute Jogging
3655
3655
  * @param {string} cell Unique identifier addressing a cell in all API calls.
3656
3656
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7824,7 +7824,7 @@ const TrajectoryExecutionApiFactory = function(configuration, basePath, axios$16
7824
7824
  */
7825
7825
  var TrajectoryExecutionApi = class extends BaseAPI {
7826
7826
  /**
7827
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
7827
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
7828
7828
  * @summary Execute Trajectory
7829
7829
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7830
7830
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -5596,7 +5596,7 @@ type ZodValidationErrorErrorDetailsInnerPathInner = number | string;
5596
5596
  */
5597
5597
  declare const ActionChunkStreamingApiAxiosParamCreator: (configuration?: Configuration) => {
5598
5598
  /**
5599
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5599
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5600
5600
  * @summary Execute Action Chunks
5601
5601
  * @param {string} cell Unique identifier addressing a cell in all API calls.
5602
5602
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -5611,7 +5611,7 @@ declare const ActionChunkStreamingApiAxiosParamCreator: (configuration?: Configu
5611
5611
  */
5612
5612
  declare const ActionChunkStreamingApiFp: (configuration?: Configuration) => {
5613
5613
  /**
5614
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5614
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5615
5615
  * @summary Execute Action Chunks
5616
5616
  * @param {string} cell Unique identifier addressing a cell in all API calls.
5617
5617
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -5626,7 +5626,7 @@ declare const ActionChunkStreamingApiFp: (configuration?: Configuration) => {
5626
5626
  */
5627
5627
  declare const ActionChunkStreamingApiFactory: (configuration?: Configuration, basePath?: string, axios?: AxiosInstance) => {
5628
5628
  /**
5629
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5629
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5630
5630
  * @summary Execute Action Chunks
5631
5631
  * @param {string} cell Unique identifier addressing a cell in all API calls.
5632
5632
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -5641,7 +5641,7 @@ declare const ActionChunkStreamingApiFactory: (configuration?: Configuration, ba
5641
5641
  */
5642
5642
  declare class ActionChunkStreamingApi extends BaseAPI {
5643
5643
  /**
5644
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5644
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5645
5645
  * @summary Execute Action Chunks
5646
5646
  * @param {string} cell Unique identifier addressing a cell in all API calls.
5647
5647
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7158,7 +7158,7 @@ declare const ControllerApiAxiosParamCreator: (configuration?: Configuration) =>
7158
7158
  */
7159
7159
  listRobotControllers: (cell: string, options?: RawAxiosRequestConfig) => Promise<RequestArgs>;
7160
7160
  /**
7161
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > Set control mode as the default with `PUT /api/v2/cells/{cell}/controllers/{controller}/mode?mode=MODE_CONTROL`. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7161
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7162
7162
  * @summary Set Default Mode
7163
7163
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7164
7164
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7299,7 +7299,7 @@ declare const ControllerApiFp: (configuration?: Configuration) => {
7299
7299
  */
7300
7300
  listRobotControllers(cell: string, options?: RawAxiosRequestConfig): Promise<(axios?: AxiosInstance, basePath?: string) => AxiosPromise<Array<string>>>;
7301
7301
  /**
7302
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > Set control mode as the default with `PUT /api/v2/cells/{cell}/controllers/{controller}/mode?mode=MODE_CONTROL`. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7302
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7303
7303
  * @summary Set Default Mode
7304
7304
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7305
7305
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7440,7 +7440,7 @@ declare const ControllerApiFactory: (configuration?: Configuration, basePath?: s
7440
7440
  */
7441
7441
  listRobotControllers(cell: string, options?: RawAxiosRequestConfig): AxiosPromise<Array<string>>;
7442
7442
  /**
7443
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > Set control mode as the default with `PUT /api/v2/cells/{cell}/controllers/{controller}/mode?mode=MODE_CONTROL`. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7443
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7444
7444
  * @summary Set Default Mode
7445
7445
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7446
7446
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7581,7 +7581,7 @@ declare class ControllerApi extends BaseAPI {
7581
7581
  */
7582
7582
  listRobotControllers(cell: string, options?: RawAxiosRequestConfig): Promise<_$axios.AxiosResponse<string[], any, {}>>;
7583
7583
  /**
7584
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > Set control mode as the default with `PUT /api/v2/cells/{cell}/controllers/{controller}/mode?mode=MODE_CONTROL`. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7584
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7585
7585
  * @summary Set Default Mode
7586
7586
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7587
7587
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7860,7 +7860,7 @@ declare class ControllerInputsOutputsApi extends BaseAPI {
7860
7860
  */
7861
7861
  declare const JoggingApiAxiosParamCreator: (configuration?: Configuration) => {
7862
7862
  /**
7863
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7863
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7864
7864
  * @summary Execute Jogging
7865
7865
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7866
7866
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7875,7 +7875,7 @@ declare const JoggingApiAxiosParamCreator: (configuration?: Configuration) => {
7875
7875
  */
7876
7876
  declare const JoggingApiFp: (configuration?: Configuration) => {
7877
7877
  /**
7878
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7878
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7879
7879
  * @summary Execute Jogging
7880
7880
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7881
7881
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7890,7 +7890,7 @@ declare const JoggingApiFp: (configuration?: Configuration) => {
7890
7890
  */
7891
7891
  declare const JoggingApiFactory: (configuration?: Configuration, basePath?: string, axios?: AxiosInstance) => {
7892
7892
  /**
7893
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7893
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7894
7894
  * @summary Execute Jogging
7895
7895
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7896
7896
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7905,7 +7905,7 @@ declare const JoggingApiFactory: (configuration?: Configuration, basePath?: stri
7905
7905
  */
7906
7906
  declare class JoggingApi extends BaseAPI {
7907
7907
  /**
7908
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7908
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7909
7909
  * @summary Execute Jogging
7910
7910
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7911
7911
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -11030,7 +11030,7 @@ declare class TrajectoryCachingApi extends BaseAPI {
11030
11030
  */
11031
11031
  declare const TrajectoryExecutionApiAxiosParamCreator: (configuration?: Configuration) => {
11032
11032
  /**
11033
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11033
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11034
11034
  * @summary Execute Trajectory
11035
11035
  * @param {string} cell Unique identifier addressing a cell in all API calls.
11036
11036
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -11045,7 +11045,7 @@ declare const TrajectoryExecutionApiAxiosParamCreator: (configuration?: Configur
11045
11045
  */
11046
11046
  declare const TrajectoryExecutionApiFp: (configuration?: Configuration) => {
11047
11047
  /**
11048
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11048
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11049
11049
  * @summary Execute Trajectory
11050
11050
  * @param {string} cell Unique identifier addressing a cell in all API calls.
11051
11051
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -11060,7 +11060,7 @@ declare const TrajectoryExecutionApiFp: (configuration?: Configuration) => {
11060
11060
  */
11061
11061
  declare const TrajectoryExecutionApiFactory: (configuration?: Configuration, basePath?: string, axios?: AxiosInstance) => {
11062
11062
  /**
11063
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11063
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11064
11064
  * @summary Execute Trajectory
11065
11065
  * @param {string} cell Unique identifier addressing a cell in all API calls.
11066
11066
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -11075,7 +11075,7 @@ declare const TrajectoryExecutionApiFactory: (configuration?: Configuration, bas
11075
11075
  */
11076
11076
  declare class TrajectoryExecutionApi extends BaseAPI {
11077
11077
  /**
11078
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11078
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11079
11079
  * @summary Execute Trajectory
11080
11080
  * @param {string} cell Unique identifier addressing a cell in all API calls.
11081
11081
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -5596,7 +5596,7 @@ type ZodValidationErrorErrorDetailsInnerPathInner = number | string;
5596
5596
  */
5597
5597
  declare const ActionChunkStreamingApiAxiosParamCreator: (configuration?: Configuration) => {
5598
5598
  /**
5599
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5599
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5600
5600
  * @summary Execute Action Chunks
5601
5601
  * @param {string} cell Unique identifier addressing a cell in all API calls.
5602
5602
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -5611,7 +5611,7 @@ declare const ActionChunkStreamingApiAxiosParamCreator: (configuration?: Configu
5611
5611
  */
5612
5612
  declare const ActionChunkStreamingApiFp: (configuration?: Configuration) => {
5613
5613
  /**
5614
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5614
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5615
5615
  * @summary Execute Action Chunks
5616
5616
  * @param {string} cell Unique identifier addressing a cell in all API calls.
5617
5617
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -5626,7 +5626,7 @@ declare const ActionChunkStreamingApiFp: (configuration?: Configuration) => {
5626
5626
  */
5627
5627
  declare const ActionChunkStreamingApiFactory: (configuration?: Configuration, basePath?: string, axios?: AxiosInstance) => {
5628
5628
  /**
5629
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5629
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5630
5630
  * @summary Execute Action Chunks
5631
5631
  * @param {string} cell Unique identifier addressing a cell in all API calls.
5632
5632
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -5641,7 +5641,7 @@ declare const ActionChunkStreamingApiFactory: (configuration?: Configuration, ba
5641
5641
  */
5642
5642
  declare class ActionChunkStreamingApi extends BaseAPI {
5643
5643
  /**
5644
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5644
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
5645
5645
  * @summary Execute Action Chunks
5646
5646
  * @param {string} cell Unique identifier addressing a cell in all API calls.
5647
5647
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7158,7 +7158,7 @@ declare const ControllerApiAxiosParamCreator: (configuration?: Configuration) =>
7158
7158
  */
7159
7159
  listRobotControllers: (cell: string, options?: RawAxiosRequestConfig) => Promise<RequestArgs>;
7160
7160
  /**
7161
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > Set control mode as the default with `PUT /api/v2/cells/{cell}/controllers/{controller}/mode?mode=MODE_CONTROL`. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7161
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7162
7162
  * @summary Set Default Mode
7163
7163
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7164
7164
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7299,7 +7299,7 @@ declare const ControllerApiFp: (configuration?: Configuration) => {
7299
7299
  */
7300
7300
  listRobotControllers(cell: string, options?: RawAxiosRequestConfig): Promise<(axios?: AxiosInstance, basePath?: string) => AxiosPromise<Array<string>>>;
7301
7301
  /**
7302
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > Set control mode as the default with `PUT /api/v2/cells/{cell}/controllers/{controller}/mode?mode=MODE_CONTROL`. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7302
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7303
7303
  * @summary Set Default Mode
7304
7304
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7305
7305
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7440,7 +7440,7 @@ declare const ControllerApiFactory: (configuration?: Configuration, basePath?: s
7440
7440
  */
7441
7441
  listRobotControllers(cell: string, options?: RawAxiosRequestConfig): AxiosPromise<Array<string>>;
7442
7442
  /**
7443
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > Set control mode as the default with `PUT /api/v2/cells/{cell}/controllers/{controller}/mode?mode=MODE_CONTROL`. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7443
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7444
7444
  * @summary Set Default Mode
7445
7445
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7446
7446
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7581,7 +7581,7 @@ declare class ControllerApi extends BaseAPI {
7581
7581
  */
7582
7582
  listRobotControllers(cell: string, options?: RawAxiosRequestConfig): Promise<_$axios.AxiosResponse<string[], any, {}>>;
7583
7583
  /**
7584
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > Set control mode as the default with `PUT /api/v2/cells/{cell}/controllers/{controller}/mode?mode=MODE_CONTROL`. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7584
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
7585
7585
  * @summary Set Default Mode
7586
7586
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7587
7587
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7860,7 +7860,7 @@ declare class ControllerInputsOutputsApi extends BaseAPI {
7860
7860
  */
7861
7861
  declare const JoggingApiAxiosParamCreator: (configuration?: Configuration) => {
7862
7862
  /**
7863
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7863
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7864
7864
  * @summary Execute Jogging
7865
7865
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7866
7866
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7875,7 +7875,7 @@ declare const JoggingApiAxiosParamCreator: (configuration?: Configuration) => {
7875
7875
  */
7876
7876
  declare const JoggingApiFp: (configuration?: Configuration) => {
7877
7877
  /**
7878
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7878
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7879
7879
  * @summary Execute Jogging
7880
7880
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7881
7881
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7890,7 +7890,7 @@ declare const JoggingApiFp: (configuration?: Configuration) => {
7890
7890
  */
7891
7891
  declare const JoggingApiFactory: (configuration?: Configuration, basePath?: string, axios?: AxiosInstance) => {
7892
7892
  /**
7893
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7893
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7894
7894
  * @summary Execute Jogging
7895
7895
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7896
7896
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7905,7 +7905,7 @@ declare const JoggingApiFactory: (configuration?: Configuration, basePath?: stri
7905
7905
  */
7906
7906
  declare class JoggingApi extends BaseAPI {
7907
7907
  /**
7908
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7908
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
7909
7909
  * @summary Execute Jogging
7910
7910
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7911
7911
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -11030,7 +11030,7 @@ declare class TrajectoryCachingApi extends BaseAPI {
11030
11030
  */
11031
11031
  declare const TrajectoryExecutionApiAxiosParamCreator: (configuration?: Configuration) => {
11032
11032
  /**
11033
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11033
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11034
11034
  * @summary Execute Trajectory
11035
11035
  * @param {string} cell Unique identifier addressing a cell in all API calls.
11036
11036
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -11045,7 +11045,7 @@ declare const TrajectoryExecutionApiAxiosParamCreator: (configuration?: Configur
11045
11045
  */
11046
11046
  declare const TrajectoryExecutionApiFp: (configuration?: Configuration) => {
11047
11047
  /**
11048
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11048
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11049
11049
  * @summary Execute Trajectory
11050
11050
  * @param {string} cell Unique identifier addressing a cell in all API calls.
11051
11051
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -11060,7 +11060,7 @@ declare const TrajectoryExecutionApiFp: (configuration?: Configuration) => {
11060
11060
  */
11061
11061
  declare const TrajectoryExecutionApiFactory: (configuration?: Configuration, basePath?: string, axios?: AxiosInstance) => {
11062
11062
  /**
11063
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11063
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11064
11064
  * @summary Execute Trajectory
11065
11065
  * @param {string} cell Unique identifier addressing a cell in all API calls.
11066
11066
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -11075,7 +11075,7 @@ declare const TrajectoryExecutionApiFactory: (configuration?: Configuration, bas
11075
11075
  */
11076
11076
  declare class TrajectoryExecutionApi extends BaseAPI {
11077
11077
  /**
11078
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11078
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
11079
11079
  * @summary Execute Trajectory
11080
11080
  * @param {string} cell Unique identifier addressing a cell in all API calls.
11081
11081
  * @param {string} controller Unique identifier to address a controller in the cell.
package/dist/v2/index.js CHANGED
@@ -677,7 +677,7 @@ const ActionChunkStreamingApiFactory = function(configuration, basePath, axios)
677
677
  */
678
678
  var ActionChunkStreamingApi = class extends BaseAPI {
679
679
  /**
680
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
680
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: danger --> > **Experimental** > > This endpoint is experimental and its behavior may change in future releases. > Websocket endpoint Provides action chunk control for a motion group. An action chunk is a queue of timed waypoints that the robot moves through by best effort. This can be used for realtime action chunk streaming, e.g., from a Vision-Language-Action (VLA) model. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeActionChunksRequest` to configure the action chunk. - Sets the robot controller mode to control mode. - Claims the motion group. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `ActionChunk`s to stream waypoints. - The first message starts an internal clock. - Each waypoint carries a timestamp relative to that clock for when it should be reached. - Existing waypoints in the queue that are older than the first new timestamp are removed. - The current session timestamp is reported in `execute.details.jogger_session_timestamp_ms` of the [streamRobotControllerState](#/operations/streamRobotControllerState) endpoint. #### 3. Stop the motion - Send `PauseActionChunksRequest` to stop the motion. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeActionChunksResponse` after `InitializeActionChunksRequest` - `ActionChunkResponse` after `ActionChunkRequest` - `PauseActionChunksResponse` after `PauseActionChunksRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during moving. ### Tips and Tricks - Ensure that the websocket connection remains open until the action chunk motion is stopped to avoid unexpected stops. ### Robot States - The robot controller state is reported in the [streamRobotControllerState](#/operations/streamRobotControllerState) as JOGGING. - The meaning of the states is: - `RUNNING`: The robot is moving through the waypoints. The clock (`execute.details.jogger_session_timestamp_ms`) is running. - `PAUSED_BY_USER`: The robot is braking or in standstill due to a user request. The clock IS paused. - `PAUSED_NEAR_JOINT_LIMIT`: The robot is braking due to a joint limit. The clock is NOT paused. - `PAUSED_NEAR_COLLISION`: The robot is braking due to a collision. The clock is NOT paused. - `PAUSED_NEAR_SINGULARITY`: The robot is braking due to a singularity. The clock is NOT paused. - `PAUSED_NEAR_WORKSPACE_BOUNDARY`: The robot is braking due to a workspace boundary. The clock is NOT paused.
681
681
  * @summary Execute Action Chunks
682
682
  * @param {string} cell Unique identifier addressing a cell in all API calls.
683
683
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -3232,7 +3232,7 @@ var ControllerApi = class extends BaseAPI {
3232
3232
  return ControllerApiFp(this.configuration).listRobotControllers(cell, options).then((request) => request(this.axios, this.basePath));
3233
3233
  }
3234
3234
  /**
3235
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > Set control mode as the default with `PUT /api/v2/cells/{cell}/controllers/{controller}/mode?mode=MODE_CONTROL`. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
3235
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ Switch between monitor and control usage as default for a robot controller. Monitoring mode is used to read information from the robot controller and control mode is used to command the robot system. As long as the robot controller is connected via network, monitoring mode is always possible. To switch to control mode the robot controller must be in `automatic` or `manual` operating mode and safety state `normal` or `reduced`. If the robot controller is in `manual` operating mode, you have to manually confirm the control usage activation on the robot control panel. This manual confirmation can\'t be replaced with this API. Without manual confirmation the robot controller will stay in monitor mode. The robot system will try to activate the required operation mode for the requested usage unless no active call requires a different mode. > **NOTE** > > `setDefaultMode` enables the robot controller to stay in control mode to keep the motors activated. > This allows for faster execution of sequential movements as no mode switches are required. > **NOTE** > > Some robot controllers prevent the external activation of automatic operating mode. In this case, changing the operating mode manually at the robot controller is mandatory. > **NOTE** > > The current operation mode and safety state can be requested via [getCurrentRobotControllerState](#/operations/getCurrentRobotControllerState). If a mode change is not possible, the response lists reasons for the failed change.
3236
3236
  * @summary Set Default Mode
3237
3237
  * @param {string} cell Unique identifier addressing a cell in all API calls.
3238
3238
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -3626,7 +3626,7 @@ const JoggingApiFactory = function(configuration, basePath, axios) {
3626
3626
  */
3627
3627
  var JoggingApi = class extends BaseAPI {
3628
3628
  /**
3629
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
3629
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a dynamically adaptable jogging motion for a motion group. Jogging describes controlling a motion group by sending real-time commands to move either its joints or the TCP. The commands contain target velocities that may change at any time during execution, so the resulting motion cannot be computed upfront. ### Preconditions The motion group is not moved by any other endpoint. ### Requests #### 1. Send `InitializeJoggingRequest` to configure the jogging. - Sets the robot controller mode to control mode. - Claims the motion group for jogging. For robotic arms, TCP is required to ensure that limits, including TCP limits, are respected. #### 2. Send `JointVelocityRequest` or `TcpVelocityRequest` to start the jogging motion. - Commands can only be processed in the cycle rate of the controller - Sending commands faster will not increase the responsiveness of the jogging motion, it will lead to dropped commands - It is recommended to couple sending commands with the [state stream](#/operations/streamMotionGroupState), which can be subscribed to via nats as well. #### 3. Change or stop the jogging motion - Change the jogging direction and/or velocity during the jogging motion with `JointVelocityRequest` or `TcpVelocityRequest`. - To stop the jogging motion, send zero velocities via either request or `PauseJoggingRequest`. ### Responses - Each request is acknowledged with a corresponding response: - `InitializeJoggingResponse` after `InitializeJoggingRequest` - `JointVelocityResponse` after `JointVelocityRequest` - `TcpVelocityResponse` after `TcpVelocityRequest` - `PauseJoggingResponse` after `PauseJoggingRequest` The responses confirm that the requests were received. They do not signal that the operation was successful; check the [motion group state](#/operations/streamMotionGroupState) for that. - `MovementErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging. ### Tips and Tricks - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
3630
3630
  * @summary Execute Jogging
3631
3631
  * @param {string} cell Unique identifier addressing a cell in all API calls.
3632
3632
  * @param {string} controller Unique identifier to address a controller in the cell.
@@ -7800,7 +7800,7 @@ const TrajectoryExecutionApiFactory = function(configuration, basePath, axios) {
7800
7800
  */
7801
7801
  var TrajectoryExecutionApi = class extends BaseAPI {
7802
7802
  /**
7803
- * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. > **NOTE** > > By default, the robot controller returns to monitor mode after each movement, which causes a pause before the next movement starts. > To keep the motors activated and avoid this pause between sequential movements, set control mode as the controller\'s default with [setDefaultMode](#/operations/setDefaultMode). #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
7803
+ * **Required permissions:** `can_operate_controllers` - Operate and monitor robot controllers ___ <!-- theme: success --> > Websocket endpoint Provides execution control over a previously [planned trajectory](#/operations/planTrajectory). Enables the caller to attach input/output actions to the trajectory. ### Movement behavior | Virtual controller | Physical controller | |------------------|-------------------| | Desired joint configurations are commanded to each motion group and **applied immediately** | Move to desired **actual joint configuration**, **if possible** | ### Concept of location - The location or path parameter specifies the exact position along a trajectory. - The location is a scalar value that ranges from 0 to `n`, where `n` denotes the number of motion commands, or trajectory segments, e.g., line, p2p, etc. See [planTrajectory](#/operations/planTrajectory). - Each integer value of the location corresponds to one motion command, e.g., 3.0 to 3.999 could be a line. ### Preconditions - The motion group\'s control mode is not claimed by any other endpoint. - The motion group\'s joint position are at start location specified with `InitializeMovementRequest`. - Use [executeToTrajectory](#/operations/executeToTrajectory) to move the robot to the start location. ### Requests #### 1. Send `InitializeMovementRequest` to lock the trajectory to this connection The following actions are executed: - Sets robot controller mode to control mode, - Sets start location of the execution Keep in mind that only a single trajectory can be locked to a websocket connection at a time. Pausing the current movement enables you to send another `InitializeMovementRequest` to execute another trajectory on the same connection. #### 2. Send `StartMovementRequest` to start the movement Sets direction of movement, default is forward. #### **Optional** - To pause, send `PauseMovementRequest` before the movement has reached its end location. - Change the movement\'s velocity with `PlaybackSpeedRequest` after initializing the movement with `InitializeMovementRequest`. ### Responses To monitor the state of the movement, listen to the [state stream](#/operations/streamMotionGroupState). The state is published via nats as well. Field `execute` in the `MotionGroupState` indicates whether a movement is ongoing and carries execution details. Each request has a corresponding acknowledgment response. They signal success or failure of the request. Especially for `PauseMovementResponse`, it does not signal the end of the movement. Additionally, `MovementError` messages can be sent in case of unexpected errors during the execution, e.g., controller disconnects during movement. ### Tips and Tricks - A movement can be paused and resumed by sending `PauseMovementRequest` and `StartMovementRequest`. - Send `PlaybackSpeedRequest` before `StartMovementRequest` to reduce the velocity of the movement before it starts. - Send `PlaybackSpeedRequest` repeatedly to implement a slider. The velocity of the motion group can be adjusted with each controller step. Therefore, if your app needs a slider-like UI to alter the velocity of a currently running movement, you can send `PlaybackSpeedRequest` with different speed values repeatedly during the movement. - A closed trajectory (end and start joint position are equal) can be repeated by sending `StartMovementRequest` after the movement has finished.
7804
7804
  * @summary Execute Trajectory
7805
7805
  * @param {string} cell Unique identifier addressing a cell in all API calls.
7806
7806
  * @param {string} controller Unique identifier to address a controller in the cell.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@wandelbots/nova-api",
3
- "version": "26.6.0-rc.3",
3
+ "version": "26.7.0-dev.3",
4
4
  "description": "API Client to interact with Wandelbots Public API.",
5
5
  "type": "module",
6
6
  "files": [