Optionaldata: PartialMessage<MoveThroughJointPositionsStreamedResponse_BatchAck>OptionalextraAdditional reply data
Static ReadonlyfieldsStatic ReadonlyruntimeStatic ReadonlytypeCreate a deep copy.
Compare with a message of the same type. Note that this function disregards extensions and unknown fields.
Parse from binary data, merging fields.
Repeated fields are appended. Map entries are added, overwriting existing keys.
If a message field is already present, it will be merged with the new data.
Optionaloptions: Partial<BinaryReadOptions>Parse a message from a JSON value.
Optionaloptions: Partial<JsonReadOptions>Parse a message from a JSON string.
Optionaloptions: Partial<JsonReadOptions>Retrieve the MessageType of this message - a singleton that represents the protobuf message declaration and provides metadata for reflection- based operations.
Serialize the message to binary data.
Optionaloptions: Partial<BinaryWriteOptions>Serialize the message to a JSON value, a JavaScript value that can be passed to JSON.stringify().
Optionaloptions: Partial<JsonWriteOptions>ProtectedtoOverride for serialization behavior. This will be invoked when calling JSON.stringify on this message (i.e. JSON.stringify(msg)).
Note that this will not serialize google.protobuf.Any with a packed message because the protobuf JSON format specifies that it needs to be unpacked, and this is only possible with a type registry to look up the message type. As a result, attempting to serialize a message with this type will throw an Error.
This method is protected because you should not need to invoke it directly -- instead use JSON.stringify or toJsonString for stringified JSON. Alternatively, if actual JSON is desired, you should use toJson.
Serialize the message to a JSON string.
Optionaloptions: Partial<JsonWriteStringOptions>StaticequalsStaticfromOptionaloptions: Partial<BinaryReadOptions>StaticfromOptionaloptions: Partial<JsonReadOptions>StaticfromOptionaloptions: Partial<JsonReadOptions>
BatchAck is returned by arm implementations to ack a
TrajectoryBatch. Due to the lack of actionable payload inBatchAck, Arm implementations are not currently obligated to ack every batch, or even any batch. It is currently unspecified whether ack'ing a batch indicates its acceptance, issue to the arm, or completion. These very relaxed requirements may become tighter if and whenBatchAckmessages begin carrying meaningful payloads back to the client. For now, the recommended practice for arm implementors is to ack each batch that has been successfully issued/enqueued to the arm.Generated
from message viam.component.arm.v1.MoveThroughJointPositionsStreamedResponse.BatchAck