wandelbots_api_client 26.6.0rc3__tar.gz → 26.7.0.dev2__tar.gz

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: wandelbots_api_client
-Version: 26.6.0rc3
+Version: 26.7.0.dev2
 Summary: Wandelbots Python Client: Interact with robots in an easy and intuitive way. 
 Author: Copyright (c) 2025 Wandelbots GmbH
 Author-email: Copyright (c) 2025 Wandelbots GmbH <contact@wandelbots.com>
@@ -31,7 +31,7 @@ Description-Content-Type: text/markdown
 Interact with robots in an easy and intuitive way.
 
 - Compatible API version: 2.6.0 (can be found at the home screen of your instance -> API)
-- Package version: 26.6.0rc3
+- Package version: 26.7.0.dev2
 
 ## Requirements.
 Python >=3.9, Python < 4.0

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/README.md

@@ -2,7 +2,7 @@
 Interact with robots in an easy and intuitive way.
 
 - Compatible API version: 2.6.0 (can be found at the home screen of your instance -> API)
-- Package version: 26.6.0rc3
+- Package version: 26.7.0.dev2
 
 ## Requirements.
 Python >=3.9, Python < 4.0

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "wandelbots_api_client"
-version = "26.6.0rc3"
+version = "26.7.0.dev2"
 description = "Wandelbots Python Client: Interact with robots in an easy and intuitive way. "
 authors = [{ name="Copyright (c) 2025 Wandelbots GmbH", email="contact@wandelbots.com" }]
 license = "Apache-2.0"

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2/__init__.py

@@ -13,7 +13,7 @@ Generated by OpenAPI Generator (https://openapi-generator.tech)
 Do not edit the class manually.
 """  # noqa: E501
 
-__version__ = "26.6.0rc3"
+__version__ = "26.7.0.dev2"
 
 from . import api
 from . import api_client

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2/api/action_chunk_streaming_api.py

@@ -55,7 +55,7 @@ class ActionChunkStreamingApi:
     ) -> None:  # noqa: E501
         """Execute Action Chunks  # noqa: E501
 
-        **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.   # noqa: E501
+        **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.   # noqa: E501
         :param client_request_generator: An AsyncGenerator that yields request of type ExecuteActionChunksRequest and takes an AsyncGenerator of ExecuteActionChunksResponse as an input argument (required)
         :info All responses from the server will be yielded to client_request_generator through the (AsyncGenerator[ExecuteActionChunksResponse, None])
         :type AsyncGenerator[ExecuteActionChunksRequest, None]

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2/api/controller_api.py

@@ -2551,7 +2551,7 @@ class ControllerApi:
     ) -> None:
         """Set Default Mode
 
-        **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.
+        **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.
 
         :param cell: Unique identifier addressing a cell in all API calls.  (required)
         :type cell: str
@@ -2620,7 +2620,7 @@ class ControllerApi:
     ) -> ApiResponse[None]:
         """Set Default Mode
 
-        **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.
+        **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.
 
         :param cell: Unique identifier addressing a cell in all API calls.  (required)
         :type cell: str
@@ -2689,7 +2689,7 @@ class ControllerApi:
     ) -> RESTResponseType:
         """Set Default Mode
 
-        **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.
+        **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.
 
         :param cell: Unique identifier addressing a cell in all API calls.  (required)
         :type cell: str

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2/api/jogging_api.py

@@ -53,7 +53,7 @@ class JoggingApi:
     ) -> None:  # noqa: E501
         """Execute Jogging  # noqa: E501
 
-        **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.   # noqa: E501
+        **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.   # noqa: E501
         :param client_request_generator: An AsyncGenerator that yields request of type ExecuteJoggingRequest and takes an AsyncGenerator of ExecuteJoggingResponse as an input argument (required)
         :info All responses from the server will be yielded to client_request_generator through the (AsyncGenerator[ExecuteJoggingResponse, None])
         :type AsyncGenerator[ExecuteJoggingRequest, None]

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2/api/trajectory_execution_api.py

@@ -55,7 +55,7 @@ class TrajectoryExecutionApi:
     ) -> None:  # noqa: E501
         """Execute Trajectory  # noqa: E501
 
-        **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.   # noqa: E501
+        **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.   # noqa: E501
         :param client_request_generator: An AsyncGenerator that yields request of type ExecuteTrajectoryRequest and takes an AsyncGenerator of ExecuteTrajectoryResponse as an input argument (required)
         :info All responses from the server will be yielded to client_request_generator through the (AsyncGenerator[ExecuteTrajectoryResponse, None])
         :type AsyncGenerator[ExecuteTrajectoryRequest, None]

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2/api_client.py

@@ -85,7 +85,7 @@ class ApiClient:
             self.default_headers[header_name] = header_value
         self.cookie = cookie
         # Set default User-Agent.
-        self.user_agent = "Wandelbots-Nova-API-Python-Client/26.6.0rc3"
+        self.user_agent = "Wandelbots-Nova-API-Python-Client/26.7.0.dev2"
         self.client_side_validation = configuration.client_side_validation
 
     async def __aenter__(self):

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2/configuration.py

@@ -512,7 +512,7 @@ class Configuration:
             "OS: {env}\n"
             "Python Version: {pyversion}\n"
             "Version of the API: 2.6.0\n"
-            "SDK Package Version: 26.6.0rc3".format(env=sys.platform, pyversion=sys.version)
+            "SDK Package Version: 26.7.0.dev2".format(env=sys.platform, pyversion=sys.version)
         )
 
     def get_host_settings(self) -> List[HostSetting]:

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2_pydantic/__init__.py

@@ -13,7 +13,7 @@ Generated by OpenAPI Generator (https://openapi-generator.tech)
 Do not edit the class manually.
 """  # noqa: E501
 
-__version__ = "26.6.0rc3"
+__version__ = "26.7.0.dev2"
 
 from . import api
 from . import api_client

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2_pydantic/api/action_chunk_streaming_api.py

@@ -55,7 +55,7 @@ class ActionChunkStreamingApi:
     ) -> None:  # noqa: E501
         """Execute Action Chunks  # noqa: E501
 
-        **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.   # noqa: E501
+        **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.   # noqa: E501
         :param client_request_generator: An AsyncGenerator that yields request of type ExecuteActionChunksRequest and takes an AsyncGenerator of ExecuteActionChunksResponse as an input argument (required)
         :info All responses from the server will be yielded to client_request_generator through the (AsyncGenerator[ExecuteActionChunksResponse, None])
         :type AsyncGenerator[ExecuteActionChunksRequest, None]

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2_pydantic/api/controller_api.py

@@ -2551,7 +2551,7 @@ class ControllerApi:
     ) -> None:
         """Set Default Mode
 
-        **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.
+        **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.
 
         :param cell: Unique identifier addressing a cell in all API calls.  (required)
         :type cell: str
@@ -2620,7 +2620,7 @@ class ControllerApi:
     ) -> ApiResponse[None]:
         """Set Default Mode
 
-        **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.
+        **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.
 
         :param cell: Unique identifier addressing a cell in all API calls.  (required)
         :type cell: str
@@ -2689,7 +2689,7 @@ class ControllerApi:
     ) -> RESTResponseType:
         """Set Default Mode
 
-        **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.
+        **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.
 
         :param cell: Unique identifier addressing a cell in all API calls.  (required)
         :type cell: str

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2_pydantic/api/jogging_api.py

@@ -53,7 +53,7 @@ class JoggingApi:
     ) -> None:  # noqa: E501
         """Execute Jogging  # noqa: E501
 
-        **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.   # noqa: E501
+        **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.   # noqa: E501
         :param client_request_generator: An AsyncGenerator that yields request of type ExecuteJoggingRequest and takes an AsyncGenerator of ExecuteJoggingResponse as an input argument (required)
         :info All responses from the server will be yielded to client_request_generator through the (AsyncGenerator[ExecuteJoggingResponse, None])
         :type AsyncGenerator[ExecuteJoggingRequest, None]

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2_pydantic/api/trajectory_execution_api.py

@@ -55,7 +55,7 @@ class TrajectoryExecutionApi:
     ) -> None:  # noqa: E501
         """Execute Trajectory  # noqa: E501
 
-        **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.   # noqa: E501
+        **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.   # noqa: E501
         :param client_request_generator: An AsyncGenerator that yields request of type ExecuteTrajectoryRequest and takes an AsyncGenerator of ExecuteTrajectoryResponse as an input argument (required)
         :info All responses from the server will be yielded to client_request_generator through the (AsyncGenerator[ExecuteTrajectoryResponse, None])
         :type AsyncGenerator[ExecuteTrajectoryRequest, None]

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2_pydantic/api_client.py

@@ -85,7 +85,7 @@ class ApiClient:
             self.default_headers[header_name] = header_value
         self.cookie = cookie
         # Set default User-Agent.
-        self.user_agent = "Wandelbots-Nova-API-Python-Client/26.6.0rc3"
+        self.user_agent = "Wandelbots-Nova-API-Python-Client/26.7.0.dev2"
         self.client_side_validation = configuration.client_side_validation
 
     async def __aenter__(self):

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2_pydantic/configuration.py

@@ -512,7 +512,7 @@ class Configuration:
             "OS: {env}\n"
             "Python Version: {pyversion}\n"
             "Version of the API: 2.6.0\n"
-            "SDK Package Version: 26.6.0rc3".format(env=sys.platform, pyversion=sys.version)
+            "SDK Package Version: 26.7.0.dev2".format(env=sys.platform, pyversion=sys.version)
         )
 
     def get_host_settings(self) -> List[HostSetting]:

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2_pydantic/models/__init__.py

@@ -1,6 +1,6 @@
 # generated by datamodel-codegen:
-#   filename:  tmp0aztgv0p
-#   timestamp: 2026-08-12T09:18:21+00:00
+#   filename:  tmp6_fw6fhf
+#   timestamp: 2026-08-12T08:18:25+00:00
 
 from __future__ import annotations
 

{wandelbots_api_client-26.6.0rc3 → wandelbots_api_client-26.7.0.dev2}/wandelbots_api_client/v2_pydantic/models/models.py

@@ -1,6 +1,6 @@
 # generated by datamodel-codegen:
 #   filename:  models.yaml
-#   timestamp: 2026-08-12T09:18:21+00:00
+#   timestamp: 2026-08-12T08:18:25+00:00
 
 from __future__ import annotations
 from pydantic import AnyUrl, AwareDatetime, BaseModel, ConfigDict, EmailStr, Field, RootModel