@wandelbots/nova-api 26.1.0-dev.56 → 26.1.0-dev.57

package/dist/v2/index.cjs

@@ -3101,7 +3101,7 @@ const JoggingApiFactory = function(configuration, basePath, axios$1) {
 */
 var JoggingApi = class extends BaseAPI {
 	/**
-	* <!-- 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. - Sets rate and coordinate system for the jogging response.  #### 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)[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.  ### Responses  - `InitializeJoggingResponse` is sent to signal the success or failure of the `InitializeJoggingRequest`. - Jogging responses are streamed continuously after an `InitializeJoggingRequest` is processed.   Jogging responses contain the robot controller state and the state of the jogging control. - `JoggingErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging.  ### Tips and Tricks  - In the `JoggingResponse`, verify that the robot control is in the desired state, e.g., standstill, with JoggingState. - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops. 
+	* <!-- 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](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](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. 
 	* @summary Execute Jogging
 	* @param {string} cell Unique identifier addressing a cell in all API calls. 
 	* @param {string} controller Unique identifier to address a controller in the cell.

package/dist/v2/index.d.cts

@@ -1314,10 +1314,6 @@ interface InitializeJoggingRequest {
    * Identifier of the tool. Required for robots (all limits, including TCP limits, are respected at all times regardless of the motion). Not required for external axes.
    */
   'tcp'?: string;
-  /**
-   * Unique identifier addressing a coordinate system to which the responses are transformed. If not set, world coordinate system is used.
-   */
-  'response_coordinate_system'?: string;
 }
 declare const InitializeJoggingRequestMessageTypeEnum: {
   readonly InitializeJoggingRequest: "InitializeJoggingRequest";
@@ -1433,6 +1429,7 @@ interface InverseKinematicsRequest {
   'collision_setups'?: {
     [key: string]: CollisionSetup;
   };
+  'reference_joint_position'?: Array<number>;
 }
 interface InverseKinematicsResponse {
   'joints': Array<Array<Array<number>>>;
@@ -5191,7 +5188,7 @@ declare class ControllerInputsOutputsApi extends BaseAPI {
  */
 declare const JoggingApiAxiosParamCreator: (configuration?: Configuration) => {
   /**
-   * <!-- 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. - Sets rate and coordinate system for the jogging response.  #### 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)[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.  ### Responses  - `InitializeJoggingResponse` is sent to signal the success or failure of the `InitializeJoggingRequest`. - Jogging responses are streamed continuously after an `InitializeJoggingRequest` is processed.   Jogging responses contain the robot controller state and the state of the jogging control. - `JoggingErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging.  ### Tips and Tricks  - In the `JoggingResponse`, verify that the robot control is in the desired state, e.g., standstill, with JoggingState. - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
+   * <!-- 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](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](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.
    * @summary Execute Jogging
    * @param {string} cell Unique identifier addressing a cell in all API calls.
    * @param {string} controller Unique identifier to address a controller in the cell.
@@ -5206,7 +5203,7 @@ declare const JoggingApiAxiosParamCreator: (configuration?: Configuration) => {
  */
 declare const JoggingApiFp: (configuration?: Configuration) => {
   /**
-   * <!-- 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. - Sets rate and coordinate system for the jogging response.  #### 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)[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.  ### Responses  - `InitializeJoggingResponse` is sent to signal the success or failure of the `InitializeJoggingRequest`. - Jogging responses are streamed continuously after an `InitializeJoggingRequest` is processed.   Jogging responses contain the robot controller state and the state of the jogging control. - `JoggingErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging.  ### Tips and Tricks  - In the `JoggingResponse`, verify that the robot control is in the desired state, e.g., standstill, with JoggingState. - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
+   * <!-- 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](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](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.
    * @summary Execute Jogging
    * @param {string} cell Unique identifier addressing a cell in all API calls.
    * @param {string} controller Unique identifier to address a controller in the cell.
@@ -5221,7 +5218,7 @@ declare const JoggingApiFp: (configuration?: Configuration) => {
  */
 declare const JoggingApiFactory: (configuration?: Configuration, basePath?: string, axios?: AxiosInstance) => {
   /**
-   * <!-- 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. - Sets rate and coordinate system for the jogging response.  #### 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)[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.  ### Responses  - `InitializeJoggingResponse` is sent to signal the success or failure of the `InitializeJoggingRequest`. - Jogging responses are streamed continuously after an `InitializeJoggingRequest` is processed.   Jogging responses contain the robot controller state and the state of the jogging control. - `JoggingErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging.  ### Tips and Tricks  - In the `JoggingResponse`, verify that the robot control is in the desired state, e.g., standstill, with JoggingState. - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
+   * <!-- 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](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](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.
    * @summary Execute Jogging
    * @param {string} cell Unique identifier addressing a cell in all API calls.
    * @param {string} controller Unique identifier to address a controller in the cell.
@@ -5236,7 +5233,7 @@ declare const JoggingApiFactory: (configuration?: Configuration, basePath?: stri
  */
 declare class JoggingApi extends BaseAPI {
   /**
-   * <!-- 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. - Sets rate and coordinate system for the jogging response.  #### 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)[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.  ### Responses  - `InitializeJoggingResponse` is sent to signal the success or failure of the `InitializeJoggingRequest`. - Jogging responses are streamed continuously after an `InitializeJoggingRequest` is processed.   Jogging responses contain the robot controller state and the state of the jogging control. - `JoggingErrorResponse` with error details is sent in case of an unexpected error, e.g., controller disconnects during jogging.  ### Tips and Tricks  - In the `JoggingResponse`, verify that the robot control is in the desired state, e.g., standstill, with JoggingState. - Ensure that the websocket connection remains open until the jogging motion is stopped to avoid unexpected stops.
+   * <!-- 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](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](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.
    * @summary Execute Jogging
    * @param {string} cell Unique identifier addressing a cell in all API calls.
    * @param {string} controller Unique identifier to address a controller in the cell.