Central Platform
Robot fleet management across every site
Hybot's fleet management gives one view of every robot across every location — state, battery, position, daily and lifetime task and distance totals. Operators queue remote commands centrally; robots pick them up on their next heartbeat and acknowledge them. Robots can be added, removed or reloaded without restarting the system.
One fleet, many sites
A single venue can be run from the Core RMS that sits inside it. An estate cannot. The Central Platform exists for the second case: each customer project runs on its own subdomain with a dedicated database for isolation, and the platform sits above all of them.
The fleet page is the single view. Every robot in every project appears with its serial, its current state, battery, character and settings, when it was added, how long it has been in the project, and its lifetime and daily totals for both completed tasks and distance travelled. Those counters are the source of every throughput number this site is willing to quote, because they are measured by the system rather than estimated by us.
How a command reaches a robot
Commands are not fired at robots and hoped for. They are queued on the platform, collected by the robot on its next heartbeat, and then acknowledged back. The available commands are the operational ones: resetting or editing totals, toggling auto-assign, toggling auto-charge, setting a battery range, setting gender, and assigning a published personality.
The queue-and-acknowledge model matters more than it sounds. A robot that is briefly offline still receives the command when it returns, and an operator can tell the difference between "sent" and "applied" — which, when you are looking at a site two countries away, is the whole question.
Adding and removing robots without stopping
Fleets change. A robot goes for repair, a second unit arrives for a trial, a site doubles its coverage for a season. Hybot supports adding, removing and reloading robots dynamically, with no server restart, and a robot whose configuration is wrong is skipped at startup with a warning rather than preventing the rest of the fleet from coming up.
A robot marked inactive is a third state worth knowing about: it continues to broadcast its state so you can see it, but it is skipped for auto-assignment, so it is visible without being dispatchable.
Knowing a site is healthy
Every project heartbeats to the platform. Central diagnostics show, per project, internet quality measured as client-to-project latency, frontend, backend and WebSocket status, and vendor API reachability, charted over the last hour with weak, medium and strong bands and a configurable auto-refresh. Server nodes report as primary and secondary with Up/Down and Active/Standby, and per-project risk analytics rank which sites need attention first.
Releasing changes without coordinating an outage
Update rollout is selective per project. A release can go to one site, be watched, and then go to the rest. Forcing a simultaneous update across an estate converts a small regression into a coordinated outage, which is why the platform does not offer that as the default path.
Where this fits
This page is the hub for everything about coordinating more than one robot. The neighbouring capabilities are how Hybot decides which robot does what, what your guests actually touch and advertising on robot screens.
Deeper reading:
Frequently asked questions
What is tracked for each robot?
- Serial number, current state, battery, character and settings, the date it was added and its time in the project, plus lifetime and daily totals for both completed tasks and distance travelled. Position and state also stream live over a WebSocket connection.
How do remote commands reach a robot?
- They are queued on the platform and collected by the robot on its next heartbeat, then acknowledged back. That means a command survives a robot being briefly offline, and the operator can see whether it was actually applied rather than assuming it was.
What happens if one robot is misconfigured?
- It is skipped at startup with a warning rather than taking the fleet down. In a multi-robot site that is the difference between one unit out of service and a whole morning lost, which is why it is a deliberate behaviour rather than an unhandled error.
Are updates pushed to every site at once?
- No. Update rollout is selective per project, so a release can be taken by one site before the rest. Forcing a simultaneous update across an estate turns a small regression into a coordinated outage.
How do we know a site is healthy without visiting it?
- Each project reports internet quality, frontend, backend and WebSocket status by heartbeat, charted over the last hour with weak, medium and strong bands, alongside primary and secondary server node status and vendor API reachability.
Where this fits
This page is part of The platform behind every Hybot robot. If you are working through the topic in order, these are the neighbouring pages.
How Hybot decides which robot does what
Hybot re-scores the task queue every two seconds and assigns each job by priority, distance and battery, with multi-step workflows and confirmation waypoints.
The guest-facing layer: kiosk, QR and surveys
Kiosk ordering, table QR menus, robot-body surveys and a live order tracker — the parts of Hybot your guests touch, tied to the same task queue staff use.
Advertising on robot screens
Hybot can schedule media to robot screens across a venue or a whole estate, with campaigns managed centrally and measured against the fleet's own counters.
See it running
A demo is the fastest way to judge whether this fits how your venue actually works.