▌ Technology ModuleBring Your Machine

Your machine.
Our console.

Titan Command Center speaks an open, published protocol — which means anything that can open a WebSocket can join the fleet view. Your research platform, your warehouse robot, your rover project. Yes, even a toy: a phone strapped to an RC car is a legitimate Titan machine, and we mean that architecturally.

Three Steps

Register. Connect.
You're on the map.

01

Register your machine

Open the console at command.titan.ai, hit "Connect your machine," give it a callsign and a type. You get a device ID and a token — that's your machine's identity.

02

Speak the protocol

Open a WebSocket to the console with your token and send telemetry frames — position, battery, heading. The full wire spec is published openly, schemas and all; a minimal client is a few dozen lines in any language.

03

Watch it join the fleet

Your machine appears in the same fleet view as everything else — live pose on the map, status, telemetry, audit trail. Operator commands flow back down the same socket.

Open the console
The Toy Build

A phone on an RC car
is a real robot.

This isn't a gimmick — it's our architecture demonstrated with pocket money. The phone is the brain: camera, GPS, IMU, compute, and the network link, all in one slab. The RC car is a dumb locomotion module, exactly as the platform intends. Strap them together, run a client that reads the phone's sensors and publishes telemetry, and Titan Command Center treats your weekend build with the same seriousness as a patrol fleet: live map position, telemetry, an audit trail.

An afternoon of work, no soldering required to start — telemetry first, motor control when you're ready. The protocol is the same one production machines speak, so everything you learn is real.

The brain

Any reasonably modern phone. Camera + GPS + IMU + LTE/Wi-Fi — a better sensor package than most research robots shipped with a decade ago.

The module

Any RC chassis. It contributes wheels and a battery — zero intelligence required, which is the whole point of the modules doctrine.

The client

A WebSocket, a JSON telemetry frame a few times a second, your token. The connect panel in the console gives you a working snippet; the full spec (OpenAPI + JSON Schemas) is served right off the console at /protocol.

Already Have A Robot?

Your stack probably
already qualifies.

The console binds to a wire contract, not a runtime — so most hobbyist and research stacks join with a small bridge process and zero Titan code on the robot. Rough effort, by stack:

Donkey Car

SMALLEST — reference bridge included

Drop the titan_bridge part into your vehicle loop and add it in myconfig. Its normalized throttle/steering maps to our commands almost 1:1, and GPS builds get real map positions. Remote drive stays off unless you flip the flag.

OpenBot

SMALL — an evening

The closest architectural cousin: phone brain, RC chassis, MCU motor bridge. Publish telemetry from the phone app alongside its own loop; a throttle/steering mix covers the drive side when you want it.

Phone + ARKit builds (RoBart-class)

SMALL — and the best fit

If your phone already does SLAM, you have better pose data than most research robots. Confidence and anchors map directly onto what the console expects — this is the pattern our own prototype fleet uses.

ROS 2

MODEST — a ~100-line bridge node

Subscribe /odom, publish telemetry frames; map inbound commands to /cmd_vel if you opt into teleop. One node, no changes to your existing graph.

Industrial AGVs speaking VDA 5050 enter at the mission layer instead — that's a conversation, not a bridge script.

Ground rules: the public console is a shared demo environment — registrations expire, capacity is capped, uptime isn't promised, and it must never be the control path for anything that could hurt someone. It's for learning, tinkering, and kicking the tires on the real protocol. When your project outgrows it, that's what talking to us is for.