Robots on the Moon or Mars are driven with seconds to minutes of round-trip delay. Researchers test interfaces that help operators cope, but each study builds its own setup, and papers rarely describe it completely enough to rebuild. UNITE turns the whole setup (delay, input, feedback, vehicle, assistance, task, logging) into a configuration you can share, rerun, and change one factor at a time.
Delay slows operators, raises error rates, and pushes them into a move-and-wait strategy. Techniques such as predictive displays and shared control help, but they are evaluated on study-specific apparatus. Comparing two techniques, or rerunning one, means reconstructing that apparatus from prose.
Existing tools cover parts: Gazebo and CARLA simulate robots and vehicles, TELECARLA adds networked teleoperation, PsychoPy and UXF run trials. None represents the full delayed-teleoperation loop as one configuration.
Charts how delayed human-in-the-loop mobile teleoperation experiments are built and reported, and where the reports leave gaps.
A modular Unity environment where communication, input, feedback, vehicle, assistance, task and logging are separately configurable components.
A prior lunar-delay user study rebuilt in UNITE without extending its architecture, exposing three apparatus details the original paper left open.
A miniature of UNITE's teleoperation loop. Your input is sampled at 10 Hz, queued on the uplink, applied by a vehicle model, observed, and queued on the downlink before you see it. The solid rover is what the operator sees. Change the delay split, switch assistance modules on and off, and watch the configuration on the right update.
Illustrative simulation written for this poster, not UNITE's code. The course, vehicle model, disturbance and route-keeping rule are simplified stand-ins; the configuration format is a sketch of the idea, not UNITE's file format. Try: turn on the predicted path, then enable terrain disturbance and see prediction and truth drift apart.
A study that reports only "2.56 s round trip" leaves the split open. For the operator the response always arrives 2.56 s after a key press, but the split decides how stale the displayed image is and how fresh the state is that remote-side assistance acts on. Maag et al. ran 200/0, 0/200 and 100/100 ms splits as separate conditions.
Fixed 2.56 s round trip, as in the reconstructed study. Diagram only; it ignores processing and frame time.
ACM DL, IEEE Xplore, Scopus and Web of Science, up to and including 2025. A study was included when a human operated a ground or surface vehicle, delay was an experimental condition, and there was a real user study (procedure, participants, participant-level results, or operator count). Fifteen method demonstrations with a human in the loop but no user study were removed during charting.
From four databases; 6 more found by manual search.
After automatic (ASySD) and manual deduplication.
Charted with a codebook built from a 10-study pilot, following stages of the teleoperation loop.
Each backed by variation the charting found across studies.
Unreported details were coded as "not reported" and never inferred from hardware descriptions. Participant counts, training and subjective measures were charted but left to experiment-management tools: UNITE covers the apparatus, not the study protocol.
A staged orchestrator runs the loop with separate uplink and downlink paths. Thirteen modules, grouped below, each declare what they consume and publish. Implementations are interchangeable when their contracts match.
Each module states what it does not do. Communication treats payloads as opaque; command mapping expresses intent but never moves the vehicle.
Before uplink transmission, after uplink reception on the robot, and after downlink reception at the operator. The same shared-control function can be placed on either side as separate conditions.
Remote state is captured before remote-side assistance (available locally, undelayed) and again after the vehicle update (optionally sent down the delayed link).
Cardinaels et al. (CHI '26) had 24 participants drive a simulated lunar rover under a fixed 2.56 s round trip, comparing three feedforward visualizations (Network, Path, Envelope) with a delayed-video baseline. It was not in the review corpus. All four conditions became scenes that differ only in the downlink operator-side assistance module; no architectural extension was needed. Three details still had to be decided:
Only the round trip was reported. The reconstruction assigns all 2.56 s to the uplink and 0 s to the downlink.
Six disturbance sources were described, with Perlin noise for some, but values were "iteratively calibrated". Values in UNITE are explicit choices meant to give comparable variation, not the original calibration.
The paper credits cliffs and boundaries. The original source shows a slope-based boundary detector with a threshold and reverse-on-contact, now ported as a remote-side assistance module. A reader of the paper alone could not recover this.
The original authors overlap with this paper, so source code was available as a reference. That is what made gaps 2 and 3 resolvable at all.
Mitigated with a fixed codebook, a pilot pass, and a separate "unclear" code that was resolved against field definitions.
Initial evidence only, done by an overlapping author team. Other vehicles, techniques, communication conditions and tasks remain to be tested.
Values stored on components (e.g. lighting) are recoverable from a scene; properties that emerge from geometry (e.g. corridor width) are not labelled as factors and still need reporting.
Participants, training, counterbalancing and questionnaires are out of scope and left to tools such as UXF or PsychoPy.
A review of 83 delayed-teleoperation studies yields seven parts every setup has. UNITE makes each part a configurable module, so a study can be rerun, compared under matched conditions, or changed in one factor. Rebuilding a carefully reported study still surfaced three unstated apparatus choices, which UNITE turns into explicit configuration fields.