Command HQ

Command HQ is the fleet management side of CTRL+R, built for organizations running more than a handful of machines. A single robot needs an operator. A fleet needs to know who is allowed to touch what, what every device is doing right now, what happened last week, and how the whole thing behaves when something goes wrong. That is what this is.

It is designed for mixed fleets. Robots from different manufacturers sit alongside cameras, edge devices and sensors in the same views, with the same permissions and the same history, so growing the fleet does not mean adding another dashboard.

Two controls sit at the top of every tab: a site picker and a team picker, so a large organization can narrow everything down to one building or one group. Your current role is shown next to them, so it is always clear what you are permitted to do.

Overview

The landing tab, and the one to check first thing in the morning. It shows headline counts for the organization: how many members against your seat limit, how many devices, how many are online right now, and how many invitations are still outstanding.

Below that, the member list shows who is in the organization and their role, and Fleet health lists every device with its type, session count and current status. One screen answers "is anything down, and is anyone around to deal with it".

Members

People are invited by email address and given a role. There are four:

Roles are a shorthand for a finer-grained set of permissions, and you can see exactly which ones a member holds. They cover viewing and managing members, viewing and managing devices, operating devices, viewing sessions and logs, viewing and managing settings, viewing, managing and executing commands, and managing notification rules. Operating a robot is deliberately separate from managing one, so you can let someone drive without letting them reconfigure anything.

Access can also be narrowed per person to specific devices, so a contractor or a site-based team only sees the machines they are responsible for.

Eagle Eye

Eagle Eye is live visibility across everything connected at once: robots, drones, camera streams, sensors and anything else enrolled. Rather than checking machines one at a time, you watch the whole site.

Idle online robots stream together in view-only mode, with no control attached. If a robot is already in a live session, its tile shows who is driving it instead of the feed, so opening Eagle Eye can never interrupt or take over somebody's session.

Tiles can be arranged automatically or locked to a fixed grid, and the list can be filtered to online devices only. There is also a map view, which places devices geographically rather than in a grid, with anything lacking a known position grouped to one side.

Devices

Everything enrolled in the organization lives here, and it is deliberately broader than robots. Four types can be added:

They all share the same permissions, the same fleet views and the same history, so a camera in a corridor and a humanoid on the floor are managed the same way.

The fleet is shown in three views:

• Diagram draws the relationship between operators and machines, so you can see who is assigned to what, which links are live, and which devices nobody owns.
• Bubble clusters devices around the person who owns them, which makes uneven distribution obvious at a glance.
• List is the detail view: model, type, status, who it is assigned to, who is using it right now, and accumulated session hours.

Devices can be filtered by state, including in use, online, offline, error and unassigned. From any row you can start a teleop session or open that device's configuration, and new devices are added from here.

Sites

Sites are for organizations operating in more than one place. Each site has its own address and timezone, its own set of devices, and its own map.

Uploading a floor plan turns a site into something operators can navigate. Click anywhere on the map to create a named waypoint, and robots at that site can be sent there. Maps accept PNG, JPG, YAML or PGM, and PGM is what most robots produce from their standard mapping routine. See Locations for how this works end to end.

Because devices and people are scoped to a site, a large organization can hand a building to a local team without exposing the rest of the fleet.

Sessions and Logs

Every teleop session is recorded and timestamped: which device, which operator, when it started, how long it ran, and how it ended. Sessions are marked active, completed, failed or terminated, so a bad session is visible rather than buried. The whole table exports to CSV.

Alongside it, the Logs view records events across the fleet at three severities: information, warnings and errors. Connection losses, low battery, failed calibrations, firmware updates and successful actions all land here with tags and timestamps, filterable by month and searchable.

The value is pattern-spotting. One robot failing calibration is an incident. The same robot failing calibration every Tuesday is a maintenance problem, and that only becomes visible when the events sit in one searchable place instead of inside separate sessions.

Customizations

Where the platform gets shaped around your fleet rather than the manufacturer's defaults. Four groups:

• ROS Commands are organization-level actions published to a topic on your robots, defined once and reused across the fleet. See Custom Commands.
• Controller holds controller configurations. Alongside a standard gamepad you can add your own layouts and map commands to specific buttons, which is how a bespoke or specialist controller gets supported.
• Locations manages the waypoints placed on your site maps. See Locations.
• Keyboard defines key bindings, so a keyboard can act as a full controller with movement, camera and command keys, plus modifiers for things like a speed boost or fine control.

Configurations can target specific robots, so an arm and a ground robot can each have controls that suit them while operators stay in one interface. All of it sits behind the command permissions described above.

Deny List

Organization-level access control for the cases where permissions are not enough. Rules block by IP address, user, device or region.

Each rule records a reason, who created it and when, and can either be permanent or carry an expiry date, which suits a temporary suspension while something is investigated. Rules can be deactivated without deleting them, so the history of a decision is not lost.

Typical uses: blocking a region you are not licensed to operate in, cutting off an IP address making repeated unauthorized attempts, or suspending an operator after a safety violation.

Notifications

Notifications turn fleet events into something a person actually sees. The tab has two halves: a feed of what has happened, and the rules that decide what is worth raising.

A rule is made up of four things:

• The event that triggers it, such as a robot disconnecting, a robot error, a command being executed, or a new member joining.
• A severity, so genuine problems are distinguishable from routine information.
• Who to tell, either by role or by naming individual members.
• How to tell them.

Rules can be switched off without being deleted, and the feed tracks what has been read, so a shift handover starts from what is still outstanding.