I wanted working with a robot to feel less like setting up an experiment from scratch every morning. Connecting cameras, finding devices, starting environments, and switching between teleoperation and inference were taking attention away from the work I actually wanted to do.
The goal was a persistent workstation: a robot I could connect to remotely, collect demonstrations with, and use to test policies through the same familiar workflow. I developed this approach while working on remote data capture and autonomy for Dust Technologies.
Keep the setup with the robot
The physical connections stay beside the hardware. A small computer handles the arm, cameras, and recording, while the operator connects from a laptop or headset. More demanding policy computation can happen elsewhere.
This makes the operator’s location less important and the setup easier to return to. A session can begin with seeing the scene and taking control, rather than reconstructing a collection of device connections.
It also creates room for different ways of demonstrating a task. A leader arm and a VR controller offer different experiences, but both can feed the same robot workstation.
Make autonomy part of the same workflow
I wanted a learned policy to use the same path to the robot as a human operator. That makes the transition from collecting a skill to testing it much smaller.
A person can demonstrate, let a policy try, and take over when it needs help. Those interventions are useful evidence: they show where the policy’s experience falls short and provide examples of how to recover.
The practical challenge is maintaining a clear sense of control. The operator needs to know who is moving the arm, whether the commands are current, and how to intervene. Those properties matter as much as getting a camera feed onto a remote screen.
Record what actually happened
A useful recording captures the scene, what the robot was asked to do, and what it actually did. Those signals can disagree, especially when motion lags, contact changes the task, or feedback stops updating.
Keeping them distinct makes a failed attempt much more informative. I can ask whether the policy chose an unhelpful action, the hardware struggled to follow it, or the recording missed part of the interaction.
The workstation became a foundation for that learning loop: demonstrate, inspect, test, intervene, and improve. Its value is in making those steps easy enough to repeat. Better infrastructure gives me more opportunities to notice what the next experiment should be.
Original remote teleoperation and inference post · Related: Robot data quality