Core RMS
How Hybot decides which robot does what
Hybot re-evaluates the task queue every two seconds and assigns each job to the best available robot by weighing task priority, distance to the pickup point and remaining battery together. Tasks run as multi-step workflows with human-confirmation waypoints, and guest requests enter the same queue as staff-created ones.
The assignment loop
Every two seconds, the Core RMS looks at the whole queue again and decides which robot should take each waiting job. Three inputs are weighed together:
| Input | What it represents | Why it is in the decision |
|---|---|---|
| Task priority | How urgent the job is relative to others | A bill that has been waiting should not lose to a newer, closer job forever |
| Distance to pickup | Travel the robot must do before it starts | The cheapest unit of work is the one that needs least travel |
| Remaining battery | Whether the robot can finish | A robot that will hit its threshold mid-run has not saved anyone time |
They are weighed together rather than applied as a sequence of tie-breakers. That distinction is the point: a marginally closer robot does not automatically beat a much better charged one, which is what a naive nearest-robot rule would do and why nearest-robot fleets end the shift with one exhausted unit and one that barely moved.
Why re-score rather than assign once
Because every input changes while the job waits. A robot finishes early. One drops below its battery threshold and takes itself to charge. A higher-priority task arrives. Assigning at creation time freezes a decision made with information that is stale within seconds.
Re-scoring is also what makes adding a robot immediately useful. There is no rebalancing step and no dispatcher to retrain; the next cycle simply has one more candidate.
Four task types, and one direct dispatch
The shipped task types are DELIVER_ORDER, GET_ORDER, DELIVER_BILL and
COLLECT_DISHES. They come from hospitality, which is where the platform was
built, and they map cleanly onto any carry-and-collect problem — a bench is a
table with a different name.
Separately, a robot can be sent straight to any configured point of interest through the API without creating a queued task. That is the primitive most integrations reach for first.
Multi-step workflows and waiting for a person
Not every job ends when the robot arrives. A task can contain a confirmation waypoint: the robot reaches the point and waits until somebody confirms the step before it continues or returns. That is how a handover is modelled honestly, rather than pretending the robot knows the tray was taken.
There is a neat consequence of this in restaurants. If a guest answers the survey on the robot's own body display, submitting the survey auto-confirms the robot's waiting step after a couple of seconds, so the robot releases itself without anybody tapping DONE.
Battery as a first-class input
Each robot carries its own persisted settings: auto-charge on or off, battery thresholds, and whether it participates in auto-assignment at all. Below its threshold a robot takes itself to charge and stops being scored for work. Battery is not an alarm bolted on afterwards; it is one of the three terms in the assignment decision.
Where this fits
This page sits under the Hybot platform alongside robot fleet management, the guest-facing layer and robot-screen advertising.
Deeper reading:
Frequently asked questions
What are the four task types?
- Deliver an order, get an order, deliver a bill and collect dishes. They are the shipped set, and they come from hospitality where the platform was built. A robot can also be dispatched directly to any named point of interest without a queued task.
Why re-score the queue instead of assigning once?
- Because the inputs change. A robot finishes early, another drops below its battery threshold, a higher-priority job arrives. Assigning once at creation locks in a decision made with stale information, so the queue is re-evaluated every two seconds instead.
How are priority, distance and battery balanced?
- They are weighed together rather than applied in sequence, so a slightly closer robot does not automatically win over a much better charged one. The result is a single assignment per job per cycle rather than a first-come queue.
What is a confirmation waypoint?
- A step in a multi-step task where the robot waits until a person confirms before continuing. It is how a handover is modelled: the robot arrives, waits at the table or bench, and releases itself only once somebody acknowledges the step.
Do guest requests jump the queue?
- No. A request raised by a guest becomes an ordinary runtime task marked as originating from the customer, and it is scored on the same terms as anything staff created. It is visible as a separate source without being a separate queue.
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.
Robot fleet management across every site
Hybot fleet management shows every robot across every location in one view, queues remote commands, monitors heartbeats and rolls out updates per project.
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.