[RSDK-14156] Introduce MoveThroughJointPositionsStreamed to Arm API

[Andrew C. Morrow (acmorrow)]

No description provided.

[Deleted user (ghost)]

Hey Andrew C. Morrow (@acmorrow) — this PR has been approved and CI has been green for 3+ business days. Ready to merge?

Auto-comment from overwatch. Will not re-nudge for 7 days.

[Dan Gottlieb (dgottlieb)]

Per offline conversations with Esha Maharishi (@EshaMaharishi) and Andrew C. Morrow (@acmorrow):

We believe there's a legitimate future where responses aren't just acknowledging that the arm has completed another batch of points, but also feeds back some other information (such as statistics regarding how well the producer is providing input/starving the arm).

I don't want to commit to what that latter schema looks like, but I want to help future proof application code using this API that's pulling off these responses. Such that, for example, if they're intending to count off acknowledgments, we unambiguously express that a response is an acknowledgment, versus some other future message we invent (e.g: some queue state response).

More concretely, riffing off the above example for requests -> init/batch messages (apologies if this doesn't compile out of the box):

message MoveThroughJointPositionsStreamedResponse {
  oneof message {
    Ack ack = 1;
  }
}

message Ack {
  int batchNumber = 1; // request number? 
  google.protobuf.Struct extra = 99;
}

Where (if I did this right) I expect a client wanting to count acknowledgment responses coming through can write:

for response := range responses {
  if response.GetAck() != nil {
    counter++
  }
}

[Andrew C. Morrow (acmorrow)]

Per offline conversations with Esha Maharishi (Esha Maharishi (@EshaMaharishi)) and Andrew C. Morrow (Andrew C. Morrow (@acmorrow)):

We believe there's a legitimate future where responses aren't just acknowledging that the arm has completed another batch of points,

Just a quick clarification, but there currently is no obligation for arms to ack every batch. Most implementations ack the batch not once it is completed, but immediately after issuing it to the hardware.

but also feeds back some other information (such as statistics regarding how well the producer is providing input/starving the arm).

As I mentioned yesterday, doing exactly this was proposed in the internal scope draft, but we cut it to de-risk the project. I agree with you that it is likely to return.

I don't want to commit to what that latter schema looks like, but I want to help future proof application code using this API that's pulling off these responses. Such that, for example, if they're intending to count off acknowledgments, we unambiguously express that a response is an acknowledgment, versus some other future message we invent (e.g: some queue state response).

Yes, that makes sense to me.

More concretely, riffing off the above example for requests -> init/batch messages (apologies if this doesn't compile out of the box):

message MoveThroughJointPositionsStreamedResponse {
  oneof message {
    Ack ack = 1;
  }
}

message Ack {
  int batchNumber = 1; // request number? 
  google.protobuf.Struct extra = 99;
}

Where (if I did this right) I expect a client wanting to count acknowledgment responses coming through can write:

for response := range responses {
  if response.GetAck() != nil {
    counter++
  }
}

That looks about right to me. I may tweak a few of the names, but I should be able to have a revision implementing this idea up today. It'll ripple through the RDK, C++ SDK, and Python SDK PRs, but for now I think that's as far as it goes. Note that for SDKs like C++ which implement their own vocabulary types rather than using raw protos, adding support for new messages in the oneof will require API changes to support it. I think that's OK though.

[Dan Gottlieb (dgottlieb)]

Re: the clarification, happy to remove batchNumber in this proposal and just leave this is an empty message.

Generally speaking -- take whatever liberties you like w.r.t naming.

[Andrew C. Morrow (acmorrow)]

Dan Gottlieb (@dgottlieb) - Updated, PTAL.