Key takeaways
- Distance imposes an unavoidable signal delay — but Movement Prediction anticipates a user's motion before it completes, closing the gap between intent and action.
- In telepresence robotics, wrist-worn sensors capture joint and muscle movement, which the algorithm translates into predicted robot motion ahead of the raw signal's arrival.
- The same prediction core runs across telepresence robots, autonomous vehicles, drones, and satellites — adapted to each domain's specific timing constraints.
- Current production accuracy sits at 75–85%, with telepresence robotics already operating successfully in real deployments.
The physics you cannot engineer around
Remote operation has a hard limit, and it isn't a limit of software. It's the speed of light. Whenever a person controls a machine that isn't in the same room — a robot in a lab a thousand kilometres away, a drone over a disaster site, a vehicle navigating without a driver on board — every signal that travels between the person and the machine takes time. Sensor data has to leave the user, cross the distance, reach the machine, and a response has to make the same journey back. No amount of clever engineering removes that delay; it is built into the structure of the universe.
What can be engineered is what happens to that delay once it's accounted for. A naive remote system waits for the full signal to arrive before acting, which means the machine is always responding to where the user was a moment ago, not where they are now. Over real-world distances, that gap is large enough to turn precise control into something closer to guesswork — fine for sending a single command, but not for mirroring the fluid, continuous motion of a human hand, arm, or body in real time.
"A naive remote system is always responding to where the user was a moment ago, not where they are now."
Predicting motion before it arrives
Movement Prediction takes a different approach. Rather than waiting for a complete signal and reacting after the fact, the algorithm continuously models the trajectory of motion already in progress and projects it forward — acting on where the movement is going, not just where it has already been. By the time the raw signal physically arrives, the system has often already begun the corresponding motion, closing much of the gap that pure signal travel time would otherwise impose.
Consider how this plays out in a telepresence robotics scenario. A researcher needs to run an experiment in a lab on the other side of the world but cannot be physically present. Rather than travelling, they operate a robot built to mirror their own movements precisely. To do this, they wear a set of sensor-equipped wristbands that continuously record the motion of their joints and muscles — the fine, continuous data of how a hand reaches, rotates, and grips. That motion data is processed and converted into a stream of movement instructions, which are transmitted to the robot at the remote location.
How the loop closes
The wristband sensors don't just transmit raw position data — they feed a continuously updating motion model. The Movement Prediction engine analyses the trajectory of recent motion and projects where the joint or limb is headed next, generating predicted movement commands that reach the robot ahead of, or alongside, the raw signal. The robot acts on the prediction; the raw signal continues to refine and correct that prediction as it arrives, keeping the two in sync over time.
Without prediction, this pipeline would still work — but the robot would visibly lag behind the researcher's actual hand movements, with the size of that lag growing directly with distance. With prediction running underneath it, the robot's motion stays tightly coupled to the researcher's, even though the two are separated by a thousand kilometres and the unavoidable transmission time that distance implies.
Why one prediction core works across five domains
The instinct when building for a new domain is to start from scratch — a robotics team builds a robotics-specific solution, a satellite team builds something purpose-built for orbital mechanics, and so on. We took a different path. At its core, motion prediction is the same mathematical problem everywhere it appears: given a history of movement, estimate where that movement is going next, within a timing budget that the application defines. What changes from domain to domain isn't the underlying problem — it's the shape of the constraints around it.
That's what allows a single Movement Prediction engine to sit underneath five very different applications, each tuned to its own operating conditions rather than rebuilt from the ground up:
| Domain | What's being predicted |
|---|---|
| Telepresence robots | Human joint and muscle movement captured via wearable sensors, projected forward into matching robot motion at the remote site. |
| Autonomous vehicles | The trajectory of the vehicle itself and the surrounding traffic, pedestrians, and obstacles, anticipated far enough ahead to act safely at driving speed. |
| Drones | Flight path and control-surface response under wind and payload variation, predicted ahead of command execution to keep flight stable and responsive. |
| Space satellites | Orbital position and the motion of nearby objects, projected forward across the multi-second communication delays inherent to space operations. |
| Enterprise operations | Operational and demand signals across a business, projected forward to anticipate bottlenecks and shifts before they fully materialise. |
A shared foundation, tuned per domain
Every one of these applications relies on the same underlying capability: take a stream of motion or signal data, model where it's heading, and act on that projection within whatever timing window the application demands. A telepresence robot needs that projection within milliseconds, since a human operator will notice and feel even small lag in their own hand movements. A satellite system, by contrast, may be working with communication delays measured in seconds, where prediction has to bridge a much larger gap but with proportionally more time to do so. The architecture is the same; the tuning is domain-specific.
"The mathematical problem is the same everywhere it appears. What changes from domain to domain is the shape of the constraints around it."
Where accuracy matters most
Prediction is, by definition, an estimate — and an honest account of this technology has to be clear about what that means in practice. At 75–85% prediction accuracy in current production use, the algorithm is right often enough to make remote control feel immediate and natural, while the underlying system is designed so that the remaining margin doesn't translate into unsafe or jarring behaviour.
This is managed in two ways. First, the raw signal data continues to arrive and continuously corrects the predicted trajectory, so the system is never relying on a single guess — it is constantly reconciling prediction against ground truth as that truth arrives. Second, every domain implementation includes bounds on how far the system will act on prediction alone before requiring confirmation from the incoming signal, so a low-confidence prediction window doesn't translate into an uncontrolled action at the remote end.
Why this matters
A prediction algorithm that is occasionally wrong but always reconciled against incoming ground truth is far safer in practice than a system that waits for perfect certainty before acting — the latter simply reintroduces the very latency the algorithm exists to remove.
Telepresence robotics: where the technology stands today
Of the five domains the engine supports, telepresence robotics is where Movement Prediction has moved furthest from a research capability into a working, deployed tool. Researchers and operators are already using wristband-driven telepresence robots to act at a remote location — running lab procedures, inspecting equipment, or performing tasks that would otherwise require physical travel — with their own hand and arm movements mirrored by the robot in close to real time, despite the physical distance and the transmission delay that distance carries.
This matters beyond the convenience of not having to travel. It opens up direct physical presence in places that are hazardous, restricted, or simply impractical to reach in person — without giving up the fine motor control that makes hands-on work possible in the first place.
Where this is heading
Movement Prediction was never built to solve one problem. It was built to solve the general problem underneath all of them: distance and delay separate intent from action, and that gap can be closed — not by beating physics, but by getting ahead of it. Telepresence robotics is the domain where that idea is furthest along today, but the same core principle is already running underneath autonomous vehicles navigating traffic, drones holding stable flight, and satellites operating across communication delays that no amount of bandwidth can fully remove.
As prediction accuracy continues to improve and the engine extends further into each of these domains, the goal stays the same: let the person, the vehicle, or the system act at the pace the moment actually demands — regardless of how far away the moment is happening.