Start/Overview
Fleetless bridges a ROS2 robot to the internet with one small process, lets you pick in the console exactly what a client app may see or do, and hands that app a REST + realtime API, a TypeScript SDK and an MCP server.
Fleetless has no end-user UI of its own. The console is a developer tool; the app your users touch is yours to build, and the app starter is one you can clone.
🧭 Where to start
- Getting Started — create the robot, install the bridge, start it, watch it come online. Then Exposing a Robot decides what that robot carries.
- Concepts — how a robot’s ROS graph becomes a slug-addressed API, how apps, app users and roles fit together, and what an AI tool reaches over MCP.
- Reference — the wire, the
fleetless.yamlschema and the TypeScript SDK, field by field. - App Starter — every app-user screen, already built, on the SDK. Clone it and point it at an app.
🧩 The shape of the thing
| Part | What it is |
|---|---|
| Bridge | A ROS2 package on the robot that talks a versioned protocol to the cloud and nothing else — no HTTP server, no shell access, no systemd integration. |
| Cloud | The REST + realtime API, auth, time-series storage, the asset store and the MCP server, in one process your app talks to. |
| Console | Where your team picks what a robot exposes, which apps reach it, what each role in an app may do, and who the app’s own users are. |
| Your app | Anything that speaks HTTPS, optionally through the @fleetless/sdk npm package — web, mobile or server-side, the API does not care. |
A robot’s ROS names never reach a client app: every exposed topic, service or action gets a stable slug, chosen in the console and decoupled from whatever the robot calls it internally, so renaming the ROS node breaks nobody’s app.