For engineers building remote operation
Seyd is a software product for fast, secure teleoperation over the public internet. It solves the parts every teleop stack ends up rebuilding: latency, loss, NAT, security, links that narrow without warning. Built once, tuned for driving by camera. Video, sensors and commands go straight from the machine to the operator's browser, with no server in between. Drop it into your robot and your UI. Keep everything else.
The hard parts
A WebRTC demo takes a week. Everything after it is the same six problems, and every team that ships teleoperation rebuilds them. Seyd is those six, built once, tuned on real cellular links, and open source on your hardware.
No server re-compresses your video and no jitter buffer grows to look smooth. Frames are paced on the camera's clock inside a presentation budget you set, 50 to 150 ms by profile. 17–31 ms median robot to browser over cellular, span stated.
LatencyEvery frame carries Reed-Solomon repair material, so most losses are rebuilt without a round trip: 99.3% of frames complete at 5% loss. What repair misses costs one skipped frame, not a second of delay that never comes back.
LossRobots sit behind 4G routers, satellite dishes and factory firewalls. Each announces its routes; our prober tests every one from outside before a session; the browser races the reachable ones and keeps the fastest. The fleet list shows who is online and whether direct will work. The relay only as a shown, metered last resort.
ReachabilityEvery byte rides QUIC under TLS 1.3, directly between machine and operator. A robot proves itself with a key it generated and never shares; driving is a short-lived pass signed by our key; who may drive which robot is a grant, and who had control when is in the audit log. Your video never touches our servers on a direct session.
Identity and permissionsSeyd measures the link in a closed loop and asks the camera for less when it narrows, more when it recovers. Where the camera offers several streams it switches instead of re-encoding. Resolution first, frame rate last, keyframes on demand. When the robot's network changes, its routes are re-gathered and announced again, so the operator reconnects to where it is now.
AdaptationA frame is admitted before its first byte leaves and sent whole; keyframes are never dropped. On a bad second the operator sees now, minus one frame. If the picture cannot be trusted, the screen says so and a clean frame is requested at once, and the HUD shows every number behind it.
MeasuredYour cameras, your autonomy stack, your safety logic and your operator UI. Seyd states its needs, a bitrate ceiling, a keyframe, a latency budget, and your systems decide how to meet them. Where a network still needs a hand, Seyd names the setting: a 4G router with UPnP off wants one UDP port forwarded, Starlink is a documented configuration, and iPhone needs an app because Apple's browsers cannot open the direct path.
How it works
A small program on the robot, one element in the operator's web page, and a signalling cloud that brokers a direct, encrypted connection between them. Video, sensors and commands never pass through our servers.
We forward your camera's own encoded bytes. Never decoded, re-compressed or stored. Quality is whatever your camera produces; privacy is structural, not a policy.
One click takes the wheel; colleagues watch the same feed read-only. The robot itself enforces a single driver, and the console shows who has it.
If a network blocks direct connections, Seyd names what it found and the setting to change. If you allow it, our relay carries the session as a last resort, and every screen says so.
Latency
Video-call technology re-compresses your video on a server and holds frames in a buffer that grows so playback looks smooth. Both exist for someone else's problem. Seyd does neither.
What remains is your camera's encoder, the browser's decoder, the speed of light, and a presentation budget you set. Frames are paced on the camera's clock inside that budget, so the picture is steady and never drifts further behind.
A jitter buffer trades time for smoothness. Fine for a film. For a human steering two tonnes, it means acting on a world that has moved on. Seyd's budget is fixed, 50 to 150 ms by profile, and never grows to hide a bad second.
Decoding and pacing run in a worker. Your web app cannot stutter the video by being busy.
Loss
You cannot stop a network from losing packets. You can decide what happens when it does.
At 5% packet loss, 99.3% of frames still arrive complete. Without repair material, 71.9% do, and every damaged frame smears the ones after it.
Reachability
Robots sit behind 4G routers, satellite dishes and factory firewalls, networks built to keep connections out. Seyd works the problem before anyone tries to connect.
The console shows each robot's reachability up front: direct connection likely, or this site needs a change, with the change named.
Office or depot Wi-Fi: works out of the box. 4G/5G routers: enable UPnP or NAT-PMP and Seyd opens the pinhole itself, or forward one UDP port once. Starlink: a documented configuration.
The direct race always runs first. Only when it fails, and the robot permits it, does the session go through our relay. The HUD, the status line and the guidance box all say so, and why. Metered, priced separately, never hidden.
Integration
Seyd does not replace your cameras, your autonomy stack or your safety logic. It states its needs; your systems decide how to meet them. A first integration is an afternoon. The developer docs walk through every form factor, with the API references generated from the code.
# /etc/seyd/seydd.toml — the daemon needs no code [[channel]] kind = "video" name = "main" input = "rtsp://192.168.1.20:554/Streaming/Channels/101" codec = "avc1.42001f" # or rtp://0.0.0.0:5000 [[channel]] kind = "sensor" name = "telemetry" input = "udp://127.0.0.1:5002" [[channel]] kind = "command" name = "drive" output = "udp://127.0.0.1:5004"
The daemon runs on the robot's own Linux computer, reads the stream the camera already produces and hands commands to your control software as UDP datagrams. It tells your systems when the camera should adjust and when an operator connects or leaves.
<script type="module">import '@seyd/web';</script> <seyd-video robot-id="lift-truck-07"></seyd-video> <seyd-hud></seyd-hud>
A live, drivable feed inside your own web app: your branding, your workflow. Connection health, a "someone else is driving" indicator and the relayed-session notice come with it. Any framework; the elements are plain custom elements.
seyd_agent_create(&cfg, &callbacks, &agent); seyd_push_frame(agent, video, au, len, keyframe, capture_ts_us);
One Rust core with a C ABI. The daemon, Python, C++ and ROS 2 are thin wrappers with no protocol logic, so nothing drifts.
With a coding agent
The Seyd skill is a folder you drop into Claude Code, or any agent that reads the Agent Skills format. It carries every form factor, the publisher contract, enrolment and access, the network and the verification ladder. The agent reads your code, asks about what it cannot see, writes the plan and then builds it. Install it from the docs, then type something like these.
| Piece | Who uses it | State |
|---|---|---|
| seydd daemon | Anyone who wants it running: a config file, no code. RTSP, RTP and UDP inputs | shipping |
| @seyd/web on @seyd/core | The web app an operator drives from: custom elements, or the session API for your own UI | shipping |
| libseyd C ABI | The foundation every wrapper attaches to | shipping |
| Python SDK | Research robots, prototypes, our own demo | shipping |
| C++ wrapper, ROS 2 node | Industrial controllers; the standard robotics framework | planned |
| Headless pilot | Hands an existing operator application the same streams on localhost, unchanged | planned |
| Mobile SDKs | Driving from a phone or tablet, and the route to iPhone and iPad | on demand |
Use cases
The hardest version of this problem: a vehicle that is autonomous most of the time, on networks nobody controls, where a human must be able to take over convincingly.
A prototype leaves its comfort zone on a test route. A safety operator takes the wheel from the control room, then hands back. The takeover path is bought before the autonomy is trusted.
A dispatcher watches a whole fleet from one dashboard and drops into the driver's seat of any vehicle on demand, while colleagues follow the same feed read-only.
Subsea and industrial ROVs piloted over a vessel's satellite uplink; steerable cameras on sites and towers. Our public demo is exactly this.
Your C2 stack already works on the vehicle's own network. Seyd carries its real-time topics across the internet unchanged, video on its own fast lane, and hands them to your software as if it were local.
Measured
The demo above runs on the same stack as a customer robot. These figures are from field runs on it, and each says what it covers.
| Path | Round trip | Robot → browser p50 / p95 | Loss |
|---|---|---|---|
| Wired LAN | ~1 ms | <1 / 3 ms | 0% |
| Operator on a 4G hotspot, robot on an office LAN | 21–44 ms | 17 / 50 ms | 0–0.4% |
| Operator on a 4G hotspot, robot behind a 4G routertwo cellular hops, port mapped by UPnP | 51 ms | 31 / 59 ms | 0% |
| Injected 5% packet loss | — | 99.3% frames complete | 5% |
"Robot → browser" runs from the first byte leaving the robot's agent to the whole frame reassembled in the browser, measured on one clock. It excludes the camera's encoder and the presentation budget you set. Every number we quote says which span it covers.
Pick seyd-demo at the top. Drag the picture or use the arrow keys to look around, scroll to zoom, press S for live statistics. If someone else is driving, you watch until the seat is free.
Cloud and identity
Our cloud introduces robot and browser, decides who may connect to what, hands out short-lived passes, and records who had control when. Then it steps aside.
A robot proves itself with a key it generated and never shares. A driving session is a five-minute pass signed by our key. Only a human sign-in touches an identity provider, so a fleet keeps running while that provider is out.
No identity provider can say "Anna may drive robot 42 but only watch robot 7", so organisations, roles, grants and the audit log are ours, in Postgres. After any incident the first question is who had control at 14:32. We record it as a matter of course.
Plain containers on Postgres. The whole cloud runs from one docker compose up on a laptop or inside your own building, with no hyperscaler dependency in application code. The public service runs in Belgium, its database in Frankfurt. Console access is by invitation.
Everything that runs on your hardware is open source: the engine, the daemon, every wrapper, the browser components. No held-back "smart part"; the value is the field-tuned system, not a withheld algorithm. Your engineers and auditors read every line inside your vehicle, and the protocol is public.
Your video never crosses our servers on a direct session, so our cost does not grow with your usage. Per robot we see a 100-byte heartbeat every five seconds. The one thing with real marginal cost, the relay, is metered and priced separately, never a silent fallback.
Pricing
Open-source SDKs and our hosted service, free for your first robots. Evaluate on your hardware, on your network.
Fleet console, accounts and access control, reachability before you connect, audit history, priority support.
The service as a self-hosted product for on-premise and classified environments, with single sign-on, audit trails and integration support.
For sites that permit nothing in. Priced separately because it is the one thing with real marginal cost. Shown on every screen, taken only after the direct race fails.
Roadmap