RoboChallenge’s remote-robot interface separates receiving observations from committing actions. A model runs on the user’s machine, requests timestamped camera and robot observations, and sends duration-bearing commands to a queue. The robot executes those commands in first-in, first-out order. Once submitted, an action cannot be withdrawn through the queue interface described in the report.
This creates a useful distinction for a VLA developer: a new observation can inform the next command, while earlier commands are still waiting to run. The camera and robot interfaces operate asynchronously, so receiving a fresher image does not itself replace the motion already submitted.
Section 2.1 of the RoboChallenge technical report describes this control arrangement. Understanding its queue semantics helps explain both the flexibility of user-side inference and the delay between seeing a change and acting on it.
The user’s process owns the inference loop
The report compares several ways to evaluate a model remotely: transferring model weights, submitting a container with the inference system, or exposing a model API for the evaluator to call. RoboChallenge instead exposes the robot to a process controlled by the user.
Inference, observation-format conversion and action post-processing remain on the user’s side. The user calls the service’s APIs rather than hosting a publicly reachable inference endpoint. That direction of communication also accommodates users whose computers sit behind network address translation.
This division puts the timing logic next to the model. A client can request observations while an earlier sequence of commands is executing, then prepare a later sequence using those observations. The service handles the robot-side queue; the client decides which observations to use, how to transform model outputs, and when to submit more movement.
The interface therefore supports more than a rigid cycle of stopping, capturing an image, running inference and moving once. The report explicitly motivates asynchronous access with temporal alignment and action-chunking methods. The particular alignment algorithm still belongs to the user’s inference process.
Capture time and command position describe different things
A capture request returns timestamped RGB, depth and proprioceptive observations. The timestamp identifies when the observation was captured. The time at which a client receives the response comes later, after acquisition and communication.
For motion, the client posts actions together with their durations. The robot consumes the queue in order, and the API exposes the current queue length. These are different kinds of information: an observation timestamp locates sensor data in time, while queue occupancy describes work already submitted to the robot.
Suppose a model receives an image showing that an object has shifted. It can use that image to choose its next action. If earlier actions remain in the queue, however, those actions execute first. Appending a new command does not turn it into a correction of commands already queued.
That behavior follows from two properties stated together in the report: FIFO execution and irrevocable submissions. An asynchronous capture creates another opportunity to observe the scene; the command queue determines when the resulting decision can enter the motion sequence.
A hypothetical queue shows the committed-motion interval
Consider an illustrative timeline, not a measured RoboChallenge run. At time zero, three commands are queued, A is just about to start, and no earlier command is still executing. Assume their stated durations are their execution intervals and omit communication and transition overhead for this calculation.
| Queued command | Hypothetical duration | Execution interval from time zero |
|---|---|---|
| A | 0.10 seconds | 0.00–0.10 seconds |
| B | 0.20 seconds | 0.10–0.30 seconds |
| C | 0.15 seconds | 0.30–0.45 seconds |
If a new observation leads the client to append D behind C before the queue drains, D begins at 0.45 seconds in this simplified timeline. The first 0.45 seconds of movement were already committed by A, B and C. Receiving another image during that interval does not remove them.
The remaining commitment shrinks as execution proceeds. At 0.25 seconds in the same example, B has 0.05 seconds left and C still has 0.15 seconds, leaving 0.20 seconds before D. This calculation uses the assumed position within B as well as the durations; the number of queued entries alone cannot supply it.
For that reason, queue length and pending motion duration serve different purposes. Three short commands and three long commands have the same count but different time horizons. The report gives action duration as part of the submission and queue length as returned information; its interface description does not specify a field for the remaining duration of the action currently executing. A client-side estimate must account for what execution timing it actually knows.
Buffering trades continuity against response timing
The queue has a direct engineering consequence. More pending movement can keep the robot supplied with commands while inference or communication takes time. It also places more committed motion ahead of a decision based on a newer observation. A smaller pending interval brings a new decision closer to execution, while giving the client less time to supply subsequent actions before existing work ends.
These are consequences of the described interface, rather than a recommended buffer setting. The useful interval depends on how long inference takes, how variable communication is, and how quickly the task state changes. The queue count becomes more informative when interpreted with the submitted durations and known execution progress.
A separate quantity is the age of the observation underlying a command when that command starts. With timestamps expressed on a comparable time basis, this is the command’s start time minus the observation’s capture time. It can include observation transfer, inference, action submission and waiting behind earlier commands. A fast model can still act on an old observation if substantial motion is already queued.
The robot VLA evaluation guide places observation age and latency within a broader evaluation record. RoboChallenge’s specific contribution here is an interface that exposes timestamped sensing and duration-bearing asynchronous commands, making the client’s temporal decisions part of the deployed system.
Job scheduling sits outside the motion queue
The report also describes scheduling APIs that tell users when evaluation is expected to run, which model needs to be loaded, and how an evaluation job is progressing. Those messages help allocate inference resources before and during a job.
They operate at a different level from the FIFO action queue. Knowing when to load a model prepares the user-side process for evaluation. Knowing what movement is already committed determines when that process’s next decision can affect the robot.
This article reads the documented interface; no account, API request or robot run was used. The practical design question is where each new observation enters the command timeline. In RoboChallenge’s reported arrangement, the client can keep observing while the robot moves, but new decisions take their place after the commands it has already submitted.