Checks_CancelReachStatus
const url = 'https://dev-api.qualiastudios.dev/v1/accounts/example/datasets/example/reachStatus:cancel';const options = { method: 'POST', headers: {'X-API-Key': '<X-API-Key>', 'Content-Type': 'application/json'}, body: '{"name":"example"}'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request POST \ --url https://dev-api.qualiastudios.dev/v1/accounts/example/datasets/example/reachStatus:cancel \ --header 'Content-Type: application/json' \ --header 'X-API-Key: <X-API-Key>' \ --data '{ "name": "example" }'Stops the dataset’s current press (REQUESTED or RUNNING), including its
selected legacy group of per-upload runs, as CANCELLED. Independent
presses on member uploads keep running.
Takes not yet sent to the solver are dropped, op runs already on it are
stopped (within a dispatcher tick or two), and takes already solved keep
their results: a later RunCheck on checks/reach answers them from
storage and queues the rest. A run whose takes are all answered ends
SUCCEEDED instead. Answers the status as it reads after the cancel; with
no run under way it changes nothing. Needs what RunCheck needs (a write
on the dataset). NOT_FOUND outside the caller’s workspace.
Authorizations
Section titled “Authorizations ”Parameters
Section titled “ Parameters ”Path Parameters
Section titled “Path Parameters ”The account id.
The dataset id.
Request Body required
Section titled “Request Body required ”Request for Checks.CancelReachStatus.
object
Accounts/{account}/datasets/{dataset}/reachStatus
Example generated
{ "name": "example"}Responses
Section titled “ Responses ”OK
Where a dataset’s reach check stands (Checks.GetReachStatus): one per dataset, always there. Reading it writes nothing and asks for no run.
Served by qds-api.
object
Accounts/{account}/datasets/{dataset}/reachStatus
The settings a RunCheck on checks/reach would use now, resolved: the
dataset’s reach_settings, else the target robot model’s solver and
reach_base, else PYROKI and 0, 0, 0.
object
The IK solver a dataset asks for, PYROKI or DLS. Unset (SOLVER_UNSPECIFIED) follows the target robot’s model, which may be MINK (a run’s resolved settings then say MINK; a request naming it is refused).
Where the takes’ start sits from the relaxed grippers’ midpoint, metres
in the robot’s base frame (x forward, y left, z up): empty or exactly
three numbers, each finite and within 5 m either way. Empty follows the
target robot model’s reach_base, else 0, 0, 0. Stored to 0.1 mm and
applied to both hand paths as one rigid translation from the robot’s home
hand midpoint.
Rotate both paired paths around world up before placing their first-row midpoint at the shared home reference. Radians; finite and within +/- pi. The robot base remains at world (0, 0, 0).
Where the source episode’s hand poses were recorded. Set by qds-api on reads; clients do not set it. TCP runs consume already-resolved TCP channels and never apply calibration again.
Digest of the TCP calibration already applied to the published upload, empty for root poses. Set by qds-api on reads.
The reach key those settings make with the target robot’s current model config. Empty when the dataset has no target robot, the robot cannot be solved against (removed, no model, in another workspace), a merged dataset’s uploads hold their poses at different frames, or fleet could not be asked.
The newest run of any state; unset until the first press.
object
Accounts/{account}/operations/{operation}: the RunCheck that recorded it.
The key its results are stored under (ReachStatus.current_key).
What it was keyed with, resolved: the solver is PYROKI, DLS or MINK and base_m has three numbers.
object
The IK solver a dataset asks for, PYROKI or DLS. Unset (SOLVER_UNSPECIFIED) follows the target robot’s model, which may be MINK (a run’s resolved settings then say MINK; a request naming it is refused).
Where the takes’ start sits from the relaxed grippers’ midpoint, metres
in the robot’s base frame (x forward, y left, z up): empty or exactly
three numbers, each finite and within 5 m either way. Empty follows the
target robot model’s reach_base, else 0, 0, 0. Stored to 0.1 mm and
applied to both hand paths as one rigid translation from the robot’s home
hand midpoint.
Rotate both paired paths around world up before placing their first-row midpoint at the shared home reference. Radians; finite and within +/- pi. The robot base remains at world (0, 0, 0).
Where the source episode’s hand poses were recorded. Set by qds-api on reads; clients do not set it. TCP runs consume already-resolved TCP channels and never apply calibration again.
Digest of the TCP calibration already applied to the published upload, empty for root poses. Set by qds-api on reads.
Accounts/{account}/robots/{robot}: the target robot it ran on.
When Run solver was pressed.
Where it stands.
The takes it covers (handheld and egocentric episodes that carry hand poses): those of the dataset when it was pressed (or the selection), the ones answered from stored results included.
Takes with a result.
Takes that could not be solved.
Why a run that stands REQUESTED or RUNNING has not moved, or why it was given up, in a sentence a person reads (“waiting for the reach service”, “some takes are not ready yet”, “the robot model changed; run again”). Empty while it is moving.
The newest run that ended (SUCCEEDED, FAILED or CANCELLED); unset until one has.
object
Accounts/{account}/operations/{operation}: the RunCheck that recorded it.
The key its results are stored under (ReachStatus.current_key).
What it was keyed with, resolved: the solver is PYROKI, DLS or MINK and base_m has three numbers.
object
The IK solver a dataset asks for, PYROKI or DLS. Unset (SOLVER_UNSPECIFIED) follows the target robot’s model, which may be MINK (a run’s resolved settings then say MINK; a request naming it is refused).
Where the takes’ start sits from the relaxed grippers’ midpoint, metres
in the robot’s base frame (x forward, y left, z up): empty or exactly
three numbers, each finite and within 5 m either way. Empty follows the
target robot model’s reach_base, else 0, 0, 0. Stored to 0.1 mm and
applied to both hand paths as one rigid translation from the robot’s home
hand midpoint.
Rotate both paired paths around world up before placing their first-row midpoint at the shared home reference. Radians; finite and within +/- pi. The robot base remains at world (0, 0, 0).
Where the source episode’s hand poses were recorded. Set by qds-api on reads; clients do not set it. TCP runs consume already-resolved TCP channels and never apply calibration again.
Digest of the TCP calibration already applied to the published upload, empty for root poses. Set by qds-api on reads.
Accounts/{account}/robots/{robot}: the target robot it ran on.
When Run solver was pressed.
Where it stands.
The takes it covers (handheld and egocentric episodes that carry hand poses): those of the dataset when it was pressed (or the selection), the ones answered from stored results included.
Takes with a result.
Takes that could not be solved.
Why a run that stands REQUESTED or RUNNING has not moved, or why it was given up, in a sentence a person reads (“waiting for the reach service”, “some takes are not ready yet”, “the robot model changed; run again”). Empty while it is moving.
Whether last_run was made under another key than current_key: the target robot, model, placement, pose frame or calibration changed since, and a RunCheck would compute something new. Nothing runs by itself.
Accounts/{account}/robots/{robot}; empty if no target robot is assigned.
Example
{ "settings": { "solver": "SOLVER_UNSPECIFIED", "poseSource": "POSES_AT_UNSPECIFIED" }, "lastRun": { "settings": { "solver": "SOLVER_UNSPECIFIED", "poseSource": "POSES_AT_UNSPECIFIED" }, "state": "STATE_UNSPECIFIED" }, "lastFinishedRun": { "settings": { "solver": "SOLVER_UNSPECIFIED", "poseSource": "POSES_AT_UNSPECIFIED" }, "state": "STATE_UNSPECIFIED" }}default
Section titled “default ”Default error response
The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. Each Status message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the API Design Guide.
object
The status code, which should be an enum value of [google.rpc.Code][google.rpc.Code].
A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details][google.rpc.Status.details] field, or localized by the client.
A list of messages that carry the error details. There is a common set of message types for APIs to use.
Contains an arbitrary serialized message along with a @type that describes the type of the serialized message.
object
The type of the serialized message.
Example generated
{ "code": 1, "message": "example", "details": [ { "@type": "example" } ]}