diff --git a/TODO.md b/TODO.md index 65ec346..9062c72 100644 --- a/TODO.md +++ b/TODO.md @@ -208,8 +208,161 @@ claims removed were outright fabrications, two of them promising the reader a sa - [x] **Field guidance published (first tranche of [L8]).** Level-surface initialisation and why it matters; loop closure explained for a non-specialist plus route planning; controlled pace, tied to the scanning view's live **Translation** (m/s) and **Rotation** (°/s) readouts and the app's too-fast warning; forward movement through corridors and stairs; gentle tilting for corners and blind spots; sideways through tight doorways; inspect the cloud before exporting. - [x] **External best-practice search exhausted.** `3dmanifold.com/{support,faq,tutorial,tutorials}` all 404; `/download` carries only MindCloud Studio material; `manifoldtechltd.github.io/wiki/` is Odin-only. One addition survived the evidence rule — reflective, transparent and water surfaces return badly, grounded in the manual's own initialisation warning. Rejected as another product's guidance (NavVis VLX, not Pocket2): loop closures every 15–30 m, an on-screen "Quality Map", holding the scanner sideways in corridors (which also contradicts the operator's forward-movement ruling), enriching featureless areas with objects, and 3 h/8 h operator-wellness limits. +## Current customer limitations — branch `docs/current-limitations` + +The current customer-facing limitation layer for the Robot Management Toolbox and the Robot +Deployment Toolbox. It is **not** a mirror of Fleet's engineering backlog: an item earns a place +here only if knowing it helps a customer avoid misunderstanding the product, taking the wrong +action, or wasting meaningful time. Fleet's own TODO and issues remain the engineering record; +cross-repo issue numbers stay out of customer prose and are named here instead, so a maintainer +can trace a decision back rather than filing it twice. + +- [x] **Saved changes can reach a mission the robot already holds, during other work — published + 2026-09-11, broadened the same day.** In `mission-editing.md` › *Sending missions to a robot*, + with a row in the Known limitations table on `robot-management-toolbox/index.md`. Classified a + current customer limitation because it contradicts the expectation the page itself sets two + paragraphs earlier ("Authoring a mission does not put it on a robot"). **It was first written + as a Quick Dispatch limitation, and that was wrong** — the v0.6.0 review established the + republish is a family, and a limitation titled after one control tells an operator they are + safe when they are not. Five operator actions were traced and all five qualify: Quick + Dispatch, **Go Home**, dispatching a saved mission, retrying a failed one-off, and + stopping/cancelling a run. **Four things the investigation established, so nobody + re-derives them:** + - **Residency is not the defect; content freshness is.** The older behaviour — an Active + mission the robot had never been sent becoming resident on a Quick Dispatch — is fixed and + regression-tested in Fleet (`westonrobot-dev/wr_fleet_management` issue #372, and + `backend/test/integration/quickdispatch_payload_narrowing_test.go`). The payload is narrowed + to missions the robot itself reports holding. What is *not* pinned is each held mission's + content: it is composed from the live bank row at push time, so a mission edited and saved + since its last send goes out at the newer version. + - **"Avoid Quick Dispatch" was rejected as the workaround, deliberately.** Naming one control + gives false safety, and telling a customer to hesitate over **Go Home** would trade a content + surprise for a robot somebody is reluctant to recall. The controllable step is the *save*, not + the dispatch, which is what the published wording says. Actions were named only where a + distinct operator press has the observable consequence — not because they share code. Go Home + is listed because it is its own button with the same effect, and Retry because the failed + quick-dispatch banner offers it. + - **Two pushes happen with no press at all.** A one-off run reaching a terminal state, and a + dispatch the robot never admits timing out, both republish the held set at current saved + content. That is why the published wording puts the remedy on the save rather than on a + pre-flight check alone — a check before setting a robot going cannot cover an update that + follows work *ending*. + - **The residency constraint holds for the dispatch family, and NOT everywhere — do not restate + the reassurance that was withdrawn.** Quick Dispatch, Go Home, dispatching a saved mission and + retrying a one-off all narrow the payload to what the robot itself reports holding, so an + unsent mission cannot arrive by those. Two other operator presses do **not** narrow that way on + a robot that is up to date with its map — cancelling a *scheduled* saved mission, and + acknowledging a finished Quick Dispatch — and republish the whole armed set. A sentence + promising that an unsent mission never arrives was published on 2026-09-11 and withdrawn the + same day once the trace reached those two paths. **It must not be reinstated** without the + ruling named below. +- [x] **Residency-identity violation — Fleet ruled 2026-09-11, published the same day.** On a robot + whose set is known and which has adopted the activated map revision, cancelling or + acknowledging a *scheduled* saved mission, and acknowledging a finished Quick Dispatch, each + republish the whole **active** set rather than only what the robot holds. An activated mission + the operator never sent can therefore become resident and then run to its own schedule. Fleet's + verdict: a **known production contract violation** of ADR-056 §5 and a **distinct sibling + defect of #372** — not an accepted semantic, not a supersession of Active ≠ On Robot, and not a + variant of the content-refresh limitation. #372 delivered its own scope and stays closed; a new + Fleet issue linked to it is recommended and **has not yet been created**. Published as its own + `:::warning` in `mission-editing.md` › *Sending missions to a robot*, kept separate from the + content-refresh limitation below because the consequence and the eventual fix differ. + - **The precaution was verified before publishing, not assumed, and is scoped.** It is for a + saved mission that is **active but not on the robot** and should stay off it. Deactivating + excludes such a mission from the affected rebuild — it reads only active missions, and the one + path that adds held-but-deactivated rows back runs only on a robot that has *not* adopted its + map, which is outside the violating condition. It is **not** a way to take back a mission the + robot already holds: deactivating never publishes, so that copy stays until a later push leaves + it out. Deactivating is also free of traps: arming and disarming never + publish to a robot at all, disarm is not gated behind a location-confirmation round, a + deactivated mission can still be dispatched by hand, and reactivating still sends nothing by + itself, so the deliberate **Send to Robot** remains required. + - **Telling operators to avoid a control was rejected again, for the same reason as before.** Stop, + Go Home and the acknowledgement controls are how a robot is recalled and finished work is + cleared. The saved mission is the safe thing to control. + - **Do not describe every acknowledgement as affected, and do not name Quick Dispatch here.** Two + controls were published on 2026-09-11 and withdrawn the same day after tracing the UI rather + than the handler. **Acknowledging a finished Quick Dispatch is not affected on this release:** + ad-hoc work became an execution in migration 083, so it is acknowledged through the execution + route, which narrows unconditionally. The unsafe quick-dispatch branch fires only for a legacy + `quickdispatch-` row minted before 083 and still held by a robot — a transitional + residue, not a normal operation, and not worth customer wording. **Go Home does not belong here + either:** it establishes no residency, and naming it in a residency warning taught operators to + distrust a recall control over a defect it has no part in. It participates only in the + content-refresh limitation. The affected controls are **Stop** and **Acknowledge**, both on a + saved mission that was running to its schedule. + - **The signal exists and is visible before the fact, not after.** A mission the robot holds + whose saved version has moved ahead is badged with both version numbers in the mission list. + It is cleared once the robot acknowledges the newer version, so it has to be read *before* + setting a robot going — which is why the published wording points at it as a pre-flight check + rather than as something to look back on. +- [ ] **Persistent "already confirmed" list after a location-confirmation round — NOT published, + and this is a decision rather than an omission.** Re-opening a mission while a confirmation + round is still open re-shows the locations already confirmed, because that list derives + from stored confirmation state rather than from the visit. It reads as a statement of what + is done, asks for nothing, and has no operational consequence: Fleet un-gates on the count + of *unanswered* items, not on whether the round row has been closed, so the residue never + blocks a robot or a mission. Publishing it would also mean introducing the whole + confirmation-round feature — which these pages do not currently explain — purely to caveat + a footnote of it, and Fleet holds the sweep's semantics frozen pending a v2 state model, so + any wording written now would be pinned to semantics expected to change. Revisit if the v2 + model ships, or if support sees customers reading it as outstanding work. +- [ ] **Mission-wide background audio is not a feature and must not be written up as a + limitation.** An earlier revision implied support; the claim was removed and the branch is + clean (no `background music` / `ambient audio` / `ambient_audio` anywhere in the content + tree). Per-checkpoint **Announce** is the real feature and stays documented in + `mission-editing.md`. The absence of an unimplemented feature is not a customer limitation — + `docs/design/product-page-template.md` › *Prose that earns its place* rules the same way + under **Negative-only**. If it is ever raised again, the answer is already here. +- [x] **Merged `docs/fleet-v0.6.0` into this branch 2026-09-11, and PR #45 now stacks on PR #43 + and then rebased onto `main` once #43 merged.** Done deliberately and early: both branches edit the same five files, + and resolving that at merge time would have meant reconciling prose nobody was looking at. One + content conflict, in *Sending missions to a robot* — #43's rewritten dispatch paragraph was + taken, since it owns that text and points at the Quick Dispatch section it adds; this branch's + two limitation admonitions were kept. Everything else auto-merged. **What the reconciliation + settled, so it is not re-opened:** + - **#43 had already absorbed most of what this branch catalogued.** Its activation paragraph no + longer claims sending is the only thing that puts work on a robot, and it already qualifies the + deactivation case. Two absolute statements did survive and were qualified here: *Saved + locations* ("moving either changes nothing on a robot that was sent the mission earlier") and + the *Common questions* answer about a moved location. + - **`· needs review` — #43's paragraph adopted wholesale**, as planned. This branch's narrower + sentence is gone. + - **The duplicate saved-location material was removed from this branch, not from #43.** #43 owns + the base fact and the **location changed** badge; this branch's caution keeps only what #43 does + not cover — that a move is not checked the way a save is, and that Send is not the only thing + that carries a move across. + - **The double-prompt limitation was withdrawn, because #43 supersedes it.** This branch called + the second prompt when saving a checkpoint as a location an unexplained repeat; #43 documents it + as the **Merge** / **Keep separate** choice, which is intended behaviour. #43 is newer and owns + v0.6.0 product truth, so its account wins. The index row went with it. + - **One clause was added to #43's activation paragraph** pointing at the residency exception + immediately below it, so the rule and its current exception are not read apart. + - **The 23-commit history was squashed for the rebase onto `main`, deliberately.** Every one of + those commits was authored against the pre-#43 text, so replaying them individually would have + meant re-resolving the same reconciliation a dozen times — and several of them carry wording + that was later withdrawn as factually wrong, which a replay would have re-introduced before + fixing it again. The reasoning those commit messages held is in this section instead, which is + why it is written at this length. The pre-rebase history is recoverable from + `backup/pre-main-rebase-481fac1` while that ref exists. + - **`main` had moved well past #43 by then** — the `tutorial/` → `guides/` restructure, the Robot + Platforms pages, new safety and maintenance pages. Of the eight files this branch touches, four + Robot Management Toolbox files were untouched by that restructure and were verified byte-identical + after the replay; `TODO.md` and the two Deployment Toolbox pages were three-way merged. + ## Docs conventions and layout — issue #38 +**Future work, and deliberately gated: run it only after the v0.6.0 documentation and the +current-limitations work have landed on `main`.** The order is not a preference. #38 rewrites prose +across 66 pages, so running it while the facts on those pages are still being corrected means doing +the work twice and losing corrections in the reflow. Factual and current-product accuracy must be +settled first. + +**#38 owns** wording and prose cleanup, removing implementation-shaped explanation, context flow, +discoverability and links, formatting and structure, figure and caption quality, and terminology +harmonisation. **It does not own** whether a statement is true of the current product — that stays +with whichever branch owns the page, and must be complete before #38 begins. + A site-wide sweep of all 66 content pages against `docs/design/product-page-template.md`, `docs/design/ia-proposal.md`, `docs/LESSONS.md` and the two ADRs, with 26 routes measured at 1440×1000 and 375×812 in both themes. **12 defects, 27 inconsistencies, 11 candidates**; diff --git a/solution/img/fleet-map-not-current.png b/solution/img/fleet-map-not-current.png index ca2049b..235d5f8 100644 Binary files a/solution/img/fleet-map-not-current.png and b/solution/img/fleet-map-not-current.png differ diff --git a/solution/img/fleet-new-user.png b/solution/img/fleet-new-user.png new file mode 100644 index 0000000..3f9b903 Binary files /dev/null and b/solution/img/fleet-new-user.png differ diff --git a/solution/img/platform-robots.png b/solution/img/platform-robots.png index 0f33087..d23a69a 100644 Binary files a/solution/img/platform-robots.png and b/solution/img/platform-robots.png differ diff --git a/solution/robot-deployment-toolbox/index.md b/solution/robot-deployment-toolbox/index.md index f5f2895..49ba96d 100644 --- a/solution/robot-deployment-toolbox/index.md +++ b/solution/robot-deployment-toolbox/index.md @@ -73,7 +73,7 @@ Most zones on a finished map were never drawn by hand — one is generated aroun framed caption="Nodes are the points; the lines joining them are segments. Everything shaded is a zone — one around each node, one along each segment. The red rectangle is the only zone on this map that someone drew." /> -**This release supports one level per site**, because robots do not use stairs or lifts on their own. Transition exists in the format for sites that span floors and has no use in a single-level one; a ramp within a level is not a change of level. +**Transition is part of the format rather than part of the workflow.** Nothing acts on a transition today — see [whether a deployment can span floors or elevations](#can-a-deployment-span-different-floors-or-elevations). ## Data exchange @@ -135,6 +135,56 @@ The editor is where a site map is made: it takes a 3D scan of a building and pro [Map editor](/solution/robot-deployment-toolbox/map-editor) covers all five stages with a worked example, what each needs before it will open, how the occupancy map is generated, what surface snapping is for, and what validation checks before you export or push. +## Known limitations + +Where the toolbox, and the workflow it feeds, currently stop. These are present limits rather than a +list tied to one release: when one is lifted, this section changes. + +### Can a deployment span different floors or elevations? + +**Multi-level navigation is not currently supported.** The Deployment Toolbox can represent maps with +multiple levels, but robots currently operate on one level at a time and do not autonomously +transition between levels. The supported model is one deployment level on one physical floor. + +**That floor does not have to be flat.** Inclined roads, slopes, ramps and other gradual changes in +elevation can be part of a deployment wherever the robot can traverse them reliably. + +**Areas at different elevations may still work as one deployment** — including areas you would +normally describe as separate floors — where a continuous, traversable route connects them, such as +a long gradual slope, a suitable ramp, or a broad and gradual stepped transition. That is not +guaranteed multi-floor support. + +**Treat a transition the robot cannot reliably traverse as separating the areas.** A steep flight of +stairs, an abrupt change in elevation, or a similar break divides one deployment from another, and a +robot should not be expected to travel between separate deployment levels on its own. + +**No slope, stair or elevation figure decides this in advance.** Where a deployment depends on such a +transition, test the actual route with the robot that will work it, under the conditions it will work +in, before relying on it. + +What the editor will still let you describe is worth knowing before you plan a building: + +| | | +| --- | --- | +| **The editor authors levels** | Extraction lists every horizontal plane it finds, `+ Manual` defines one directly, and each level carries its own occupancy map | +| **The format carries transitions** | **Transition** describes how a robot moves between levels. It is part of the map specification rather than part of the current deployment workflow | +| **The fleet offers no level to pick** | The Robot Management Toolbox neither reports which level a robot is on nor asks which level a place is on. Everything saved there belongs to the level the robot is operating on | + +### Built for a desktop browser + +**The Robot Deployment Toolbox is designed for desktop or laptop browsers and a mouse-driven +workflow.** Tablet and phone use is not currently supported. + +### Reopening a map requires loading the point cloud again + +**The map is saved as you go; the point cloud is not.** Its levels, nodes, segments and zones are +picked up again when you return to it. The point cloud is held for the length of your session, so a +map reopened later opens without one, and you load it again before going further. + +**Prepare** and **Setup Levels** both read the cloud, so neither runs until it is loaded. Load the +same file you started from, or use **Import from Fleet** for a map that has already been pushed — +that brings the graph, its point cloud and its occupancy map down together. + ## Support Before raising a ticket, note which site and map are involved, and whether the problem is with drawing it, pushing it, publishing it or activating it — those are four different stages, and only the first two happen in this tool. [Before you contact us](/support/before-you-contact-us) lists what helps. diff --git a/solution/robot-deployment-toolbox/map-editor.md b/solution/robot-deployment-toolbox/map-editor.md index 7300476..40e5a69 100644 --- a/solution/robot-deployment-toolbox/map-editor.md +++ b/solution/robot-deployment-toolbox/map-editor.md @@ -24,7 +24,7 @@ The Map Editor turns a 3D scan of a building into a site map. It runs as five nu | **4 · Edit Map** | At least one level is defined | | **5 · Export** | At least one node exists | -Work is saved as you go, and the header shows when it last was. It lives in your browser rather than on a server, so it is yours until you push it. +Work is saved as you go, and the header shows when it last was. It lives in your browser rather than on a server, so it is yours until you push it — [though the point cloud is loaded again each session](/solution/robot-deployment-toolbox#reopening-a-map-requires-loading-the-point-cloud-again). ## 1 · Load Map Data @@ -109,7 +109,7 @@ misaligned, re-scan rather than working around it; the Extraction will happily list several height bands, and a building with more than one storey in the scan will produce more than one candidate plane. That is the tool reading geometry. -**It does not mean a robot can be deployed across those floors.** Multi-floor deployment is not currently supported: a robot does not use stairs or lifts on its own, and this release supports **one level per site**. Level detection and editing is a map-processing capability; the deployment workflow it feeds is single-level. Treat extra detected planes as candidates to choose the floor from, not as floors you can dispatch to. +**It does not mean a robot can be deployed across those floors.** Treat extra detected planes as candidates to choose the floor from, not as floors you can dispatch to — see [whether a deployment can span floors or elevations](/solution/robot-deployment-toolbox#can-a-deployment-span-different-floors-or-elevations). ### The occupancy map @@ -292,7 +292,7 @@ Expected. Pushing creates a draft in the Robot Management Toolbox; someone there A Site Admin or Tenant Administrator can adjust a site's saved locations in the Robot Management Toolbox. Changing the scan, the levels, the graph or the zones is this tool's job. **My site has two floors** -This release supports one level per site, because robots do not use stairs or lifts on their own. Ramps within a level are fine, since a ramp is not a change of level. +The supported model is one deployment level on one physical floor, and that floor need not be flat — slopes and ramps the robot can traverse are ordinary. Two elevations joined by a continuously traversable route may also work as one deployment, while a steep flight of stairs divides them. [Whether a deployment can span floors or elevations](/solution/robot-deployment-toolbox#can-a-deployment-span-different-floors-or-elevations) covers what to check, and says why the route has to be tested rather than judged from a figure. **Why does my map have so many zones?** Most were generated rather than drawn: one around every node and one along every segment. A twenty-four-node site with a single hand-drawn keep-out area still holds fifty-six zones. diff --git a/solution/robot-management-toolbox/index.md b/solution/robot-management-toolbox/index.md index 67d19c7..d4be7c1 100644 --- a/solution/robot-management-toolbox/index.md +++ b/solution/robot-management-toolbox/index.md @@ -77,10 +77,11 @@ role cannot be performed. [Taking control](/solution/robot-management-toolbox/robot-dashboard#taking-control) sets out the control panel and who may use each part of it. -**Above a site.** Managing people — inviting users, granting roles and removing roles — is a -**Tenant Administrator's** responsibility across the tenant. For creating tenants or sites, or -registering or decommissioning a robot, contact [Weston Robot -support](/support/before-you-contact-us). +**Above a site.** Managing people — [creating +users](/solution/robot-management-toolbox/tenant-management#creating-users-and-granting-roles), +granting roles and removing roles — is a **Tenant Administrator's** responsibility across the +tenant, and needs no help from us. For creating tenants or sites, or registering or decommissioning +a robot, contact [Weston Robot support](/support/before-you-contact-us). **Some actions need more than a role.** Holding the right role is necessary and sometimes not sufficient: @@ -237,6 +238,47 @@ Actions are recorded in an **append-only** log: entries are added, never changed [**Deployment and servicing**](/solution/robot-management-toolbox/deployment-and-servicing) — where the system runs (shared cloud, a dedicated cloud instance, or on-premise), what that decides about upgrade scheduling and data residency, and how robots and their software are kept current. +## Known limitations + +What the Robot Management Toolbox does not currently do. These are present limits rather than a list +tied to one release: when one is lifted, this section changes. + +### A control you can see is not always one your role may use + +**Some operational controls stay visible to roles that cannot use them.** An Observer holds no +commands, and can still see controls such as Go Home or mission dispatch on a robot's panel. Pressing +one does not carry it out — authority is checked when the action is sent rather than by hiding the +control, so the action is refused and the robot is not touched. + +Read [Roles](/solution/robot-management-toolbox/tenant-management#roles) as the authority on what +someone may do, rather than reading it off their screen. + +### No level to choose + +**No level is chosen or reported anywhere in this toolbox.** The places you save and the missions you +build belong to the level the robot is operating on — [whether a deployment can span floors or +elevations](/solution/robot-deployment-toolbox#can-a-deployment-span-different-floors-or-elevations) +carries the scope. + +### Built for a desktop browser + +**The Robot Management Toolbox is designed and tested for desktop browsers.** Some views adapt to +smaller screens, but tablet and phone use is not currently supported for normal operation. In +particular, mission editing and robot teleoperation require a desktop or laptop workflow. + +Use a desktop or laptop browser when planning missions, operating robots, or carrying out +administrative work. + +### Limits stated where you meet them + +Three more belong to a single workflow each, and are explained at the point they matter: + +| Limitation | Where it is covered | +| --- | --- | +| **Go Home** can still report work as staged while the robot is already driving home | [Taking control](/solution/robot-management-toolbox/robot-dashboard#taking-control) | +| **Save Mission** does not say why it is unavailable — most often a missing mission name | [Review & Save](/solution/robot-management-toolbox/mission-editing#3--review--save) | +| Moving a saved location on top of another is not checked the way saving one is, so a move can leave two locations at one place | [Saved locations](/solution/robot-management-toolbox/mission-editing#saved-locations) | + ## Support Before raising a ticket, note which site and robot are involved, what the robot was doing just before, and what you saw on screen. [Before you contact us](/support/before-you-contact-us) lists what helps and how to submit a support request. diff --git a/solution/robot-management-toolbox/mission-editing.md b/solution/robot-management-toolbox/mission-editing.md index 1297fa4..f7f562a 100644 --- a/solution/robot-management-toolbox/mission-editing.md +++ b/solution/robot-management-toolbox/mission-editing.md @@ -83,6 +83,8 @@ The route map draws the mission over the site map, numbering the checkpoints in Saving validates first. A checkpoint with no position is named by number and blocks the save until it is set. +**Where Save Mission is unavailable, the reason is above it rather than on it.** The button does not currently say what is missing, and the most common answer is the simplest one — the mission has no name. Read the validation messages at the top of this stage, and check the name in **Details**, before looking for anything harder. + Two things here are worth knowing: - **A "what changed?" note is recorded with the save.** It is optional, and it is what makes the revision history readable later rather than a list of timestamps. @@ -93,9 +95,12 @@ Two things here are worth knowing: A saved location is a named place on a robot's map. A checkpoint made from one **follows it**, so correcting the location later corrects every mission in the Management Toolbox that uses it — which is what keeps a growing library maintainable rather than turning one moved shelf into an afternoon of edits. **A robot that already holds the mission is the exception.** A checkpoint's pose, and the home a -patrol returns to, are resolved at the moment you **Send to Robot** — so moving either changes -nothing on a robot that was sent the mission earlier, and an armed patrol goes on driving to the -pose it was given. Each mission in that state is badged **location changed** in the mission list, +patrol returns to, are resolved at the moment you **Send to Robot** — so moving either does not by +itself change anything on a robot that was sent the mission earlier, and an armed patrol goes on +driving to the pose it was given until that mission reaches it again. Missions hold those places +by reference rather than by copy, so whenever an already-held mission is next sent out its +checkpoints and its home are resolved to where they stand then — **Send to Robot** is how you make +that happen when you want the robot updated now. Each mission in that state is badged **location changed** in the mission list, and one **Send to Robot** clears it. The badge is shown for an offline robot too, because that is exactly when a stale copy keeps running to its own schedule. A mission you have also edited since sending reports that edit instead — one Send answers either cause. @@ -107,7 +112,16 @@ sending reports that edit instead — one Send answers either cause. framed caption="Picking a saved location. The list shows which are already in use, and the robot's home is one of them." /> -Locations are held per robot, are searchable, and can be picked from the list or clicked directly on the map. +Locations are held per robot, are searchable, and can be picked from the list or clicked directly on the map. A checkpoint you placed by hand can also be saved as one, which is what turns a one-off stop into a place the next mission can reuse. + +:::caution Moving a saved location onto an occupied place is not checked + +Correcting a location is the normal way to fix a place that has moved, and in the Management Toolbox it does what it says — every mission that uses it follows it. One limit sits around that. + +**A move is not checked the way a save is.** Saving at an occupied spot is refused, as *One location per place* below describes. Moving an existing location on top of another is not checked the same way, so a move can leave two locations at one spot. Nothing is lost and either still works. + +::: + **One location per place.** Saving a new location at a spot a location already occupies — the same position, facing the same way — is refused, and the refusal names the one already standing there so @@ -157,14 +171,15 @@ Times are the **robot's local time**, not the browser's. Authoring a mission does not put it on a robot. Missions are **sent** to the robot that will run them, and a badge answers the question that follows: does the robot actually have these? -**Nor does activating one.** A mission's activation decides whether it is *eligible* to run — it is -how you enable a schedule, and how you stop it starting again without deleting it. Activation is -not how a mission is put on a robot: **Send to Robot** is the deliberate way to do that, and a -mission can be active and not on the robot, in which case the robot will not run it. Turning a -mission **off** does not take it off the robot by itself either — a robot already holding it can -keep running it until it is sent a list that leaves it out. What confirms any of this is the -robot's own report, so *active* is the Management Toolbox's intent and the badge beside is the -robot's answer: read the badge, not the activation, when you want to know what the robot has. +**Activating a mission and sending it are separate steps.** Activation decides whether a mission is +*eligible* to run — it is how you enable a schedule, and how you stop it starting again without +deleting it. **Send to Robot** is the deliberate operation that puts a saved mission on a robot and +updates a copy the robot already holds to the version you have saved. A mission can therefore be +**Active** without being **On Robot**, and the robot will not run it until it has been sent. Turning +a mission **off** changes whether it is eligible to run; it does not itself remove a copy the robot +already holds. What confirms any of this is the robot's own report, so *active* is the Management +Toolbox's intent and the badge beside it is the robot's answer: read the badge, not the activation, +when you want to know what the robot has. | Badge | Means | | --- | --- | @@ -229,19 +244,22 @@ knowing before you rely on it: ## When an action cannot proceed -The Management Toolbox would rather refuse than guess. Four of these come up in normal use, each turning on a -different missing fact, and each with a different thing to do about it. The first, third and fourth -say so on screen; the second is quieter — what you see is that auto-dispatch has gone paused. +The Management Toolbox refuses an action when it does not have enough information to proceed safely, +or when the result would be invalid or in conflict with something that already exists. Four come up +in normal use, each with a different thing to do about it. + +**[1]**, **[3]** and **[4]** are reported on screen. **[2]** is quieter — what you see is that +auto-dispatch has gone paused. -| Refusal | What it means | What to do | -| --- | --- | --- | -| **The fleet cannot tell what this robot is holding** | The robot has not reported its own mission list recently enough to be trusted. Not knowing is not the same as knowing it is empty, and the Management Toolbox will not treat it as empty | Wait for the robot to report, or bring it back online, then repeat the action. Nothing has been changed on the robot | -| **The removal was withheld, and auto-dispatch is paused** | You asked for work to be taken off a robot whose current list cannot be seen. Sending a corrected list would mean guessing the rest of it, so nothing was sent and new work was paused instead, to stop the robot picking up something you were trying to remove | Wait until the robot reports again, repeat the removal, then **Resume Auto-Dispatch** | -| **A saved location already stands here** | The place you are saving is the same spot, facing the same way, as a location that already exists — and it names the one that is already there | Use the location it names. Two names for one place is what makes a library stop being trustworthy | -| **A place this mission needs cannot be resolved** | The mission refers to a home position or a checkpoint that no longer exists, or that cannot be resolved on the robot's current map. The mission is invalid to send at all, so this is answered before anything about schedules or holds | Open the mission and set the missing place, then send it again | +| Ref | Refusal | What it means | What to do | +| --- | --- | --- | --- | +| **[1]** | **The fleet cannot tell what this robot is holding** | The robot has not reported its own mission list recently enough to be trusted. Not knowing is not the same as knowing it is empty, and the Management Toolbox will not treat it as empty | Wait for the robot to report, or bring it back online, then repeat the action. Nothing has been changed on the robot | +| **[2]** | **The removal was withheld, and auto-dispatch is paused** | You asked for work to be taken off a robot whose current list cannot be seen. Sending a corrected list would mean guessing the rest of it, so nothing was sent and new work was paused instead, to stop the robot picking up something you were trying to remove | Wait until the robot reports again, repeat the removal, then **Resume Auto-Dispatch** | +| **[3]** | **A saved location already stands here** | The place you are saving is the same spot, facing the same way, as a location that already exists — and the refusal names the one already there | Use the location it names instead of saving a second one at the same place | +| **[4]** | **A place this mission needs cannot be resolved** | The mission refers to a home position or a checkpoint that no longer exists, or that cannot be resolved on the robot's current map. The mission is invalid to send at all, so this is answered before anything about schedules or holds | Open the mission and set the missing place, then send it again | -The third and fourth are about the mission itself, so they are answered first: a mission that cannot -be dispatched at all is never reported as merely waiting. +**[3]** and **[4]** are about the mission or its saved places, so they are answered first: a mission +that cannot be dispatched at all is never reported as merely waiting. ## History and logs @@ -271,7 +289,7 @@ A day rule has no cooldown of its own, so a mission that does not end by itself That robot is on an older map than the one the fleet has activated. See [Catching a robot up to the map](/solution/robot-management-toolbox/tenant-management#catching-a-robot-up-to-the-map). **I moved a location and several missions changed** -Expected, if it was a saved location. In the Management Toolbox, checkpoints that reference that saved location are updated together. A robot already holding one of those missions keeps the position it was previously given until you **Send to Robot** again, and each mission in that state is badged **location changed** — see [Saved locations](#saved-locations). +Expected, if it was a saved location. In the Management Toolbox, checkpoints that reference that saved location are updated together. A robot already holding one of those missions keeps the position it was previously given until that mission is sent to it again — **Send to Robot** is the deliberate way to do that — and each mission in that state is badged **location changed** — see [Saved locations](#saved-locations). **Did last night's patrol actually run?** Run history, which records how each run ended. The robot's own report does not keep it. diff --git a/solution/robot-management-toolbox/robot-dashboard.md b/solution/robot-management-toolbox/robot-dashboard.md index 46bb6a6..d7bd3e5 100644 --- a/solution/robot-management-toolbox/robot-dashboard.md +++ b/solution/robot-management-toolbox/robot-dashboard.md @@ -29,7 +29,11 @@ One robot on one screen. The view is laid out so that judging a running mission **Localisation is worth watching.** A robot that is not localised does not know where it is on the map, so map-relative work — dispatching a mission, sending it home — has nothing to work from until it does. The map reports it beside the robot: **Localized** when it is tracking, **Not Localized** when it has no fix, and **Unknown** when the robot has not said recently enough to be trusted. -**Init Pose**, on the map toolbar, is the recovery for a robot that is not tracking. You point at where the robot actually is and set its heading; it localises from there. It stays available while a locations-confirmation round is outstanding, precisely because it is the action that fixes the problem those actions are blocked by. A robot on an out-of-date map revision is a different matter: there Init Pose waits with everything else until the map is put right. +**Not Localized is a status rather than a fault.** It can appear when the robot does not yet have a valid localisation on the current map, and map-relative controls may be unavailable until localisation succeeds. Localisation or navigation warnings caused by a robot not being localised should clear once it localises. + +**Init Pose**, on the map toolbar, is the recovery for a robot that is not tracking. Arm it, then **click to set the location and drag to set the heading** — releasing sends it, and the robot starts localising from the pose you gave. There is no separate confirm step and nothing further to press: watch the reading beside the robot for **Localized**. Init Pose remains available while location confirmation is outstanding. If the robot is on an out-of-date map revision, however, Init Pose remains unavailable until the map is brought up to date. + +Two things make it more likely to take. Put the pose where the robot physically is, as closely as you can judge — near enough in the right place is what it needs rather than an exact figure. And have the robot somewhere with clear, distinctive surroundings rather than a repetitive or bare one, because an aisle of identical bays gives it little to tell one position from another. ## Telemetry @@ -109,6 +113,8 @@ The view is headed with the robot's name, model and serial number. Quote those w | **Commands** | Docking — dock and undock — and posture commands such as stand and sit | | **Missions** | Pick a mission this robot may run, and dispatch it | +**After Go Home, trust the robot rather than the panel.** The robot begins driving home when the command is accepted, but the panel can go on reporting that the work is staged and not moving yet. The press took; the message is behind it. Watch the robot's position rather than pressing Go Home a second time. + **What the E-Stop withdraws is the ability to set the robot going, not the ability to stop it.** While it is active, the controls that would start movement or take on new work are unavailable — driving, Go Home, the stance and docking commands, dispatching a mission, and auto-dispatch. The controls for dealing with what is already running stay available, so a run in progress can still be paused, resumed or stopped, a result acknowledged, and the robot cleared. Releasing the E-Stop is a deliberate second action rather than a side effect of anything else. **Every role at a site may activate the E-Stop, and it needs no control lease.** Safety is not something to @@ -170,6 +176,12 @@ Battery level and the connection to the fleet both change what a running mission Messages are buffered on the robot while the link is down, so telemetry and events from that period arrive once it returns. What is genuinely unavailable in the meantime is the live view and the ability to send a command. +## Unexpected errors + +If the toolbox or robot reports an unexpected error after the normal prerequisites have been +satisfied, power the robot off and on once. This may clear a temporary fault. If the problem remains +after the restart, [contact Weston Robot support](/support/before-you-contact-us). + ## Common questions **Can two people drive the same robot?** diff --git a/solution/robot-management-toolbox/tenant-management.md b/solution/robot-management-toolbox/tenant-management.md index 7239b9c..c09e0a0 100644 --- a/solution/robot-management-toolbox/tenant-management.md +++ b/solution/robot-management-toolbox/tenant-management.md @@ -56,6 +56,45 @@ Each role contains the one below it, so assigning access is one decision per per **One thing worth planning around:** authoring a map and activating it are both administrative authority at that site, so a single administrator can take a map from draft to live. Where a process calls for a second person to approve it first, that approval comes from the process rather than from the system. +## Creating users and granting roles + +A **Tenant Administrator** creates the tenant's own users — there is no need to ask us for an +account. From **Users**, select **New User**: + +| Field | What it is | +| --- | --- | +| **Display Name** | The name shown against the account throughout the toolbox | +| **Email** | The address the person signs in with. It is the login identifier, and must be unique across all tenants | +| **Password** | An initial password you set for them — at least 12 characters, and different from their last three | +| **Require password change on first login** | Leave this on, so the person replaces that password themselves | + +
+ +**Tenant Role** is authority across the whole tenant: + +| Tenant Role | Grants | +| --- | --- | +| **Tenant Administrator** | Site Admin authority at every site, plus managing users and roles | +| **Auditor (read-only)** | Reading operational and audit logs across every site, with no commands | +| **None** | No tenant-wide authority — the account takes what it can do from its Site Roles instead | + +**None does not mean no access.** It means the account holds nothing tenant-wide. Under **Site +Roles** you then pick a site and the role the person holds there — **Observer**, **Operator** or +**Site Admin** — and **Add Site Role** again for each further site. Someone who works in one +building normally has Tenant Role **None** and a single Site Role; the two are combined, so a +tenant-wide role and per-site roles can be held together. + +**Create** finishes the account. + +**Sites are the one exception.** A Tenant Administrator manages the tenant's people, but sites +themselves are provisioned by Weston Robot — a tenant with no sites yet, or one that needs another, +is what to [contact us](/support/before-you-contact-us) about. + ## A site's maps A site does not hold one map; it holds a **map lineage** — a named map that is revised over time. A new **revision** is added to that lineage rather than replacing what was there — so `r4` and `r5` are the same map at two points in its life and the older one is still on record. Revisions arrive either as a push from the Robot Deployment Toolbox or by uploading a map bundle here. @@ -116,10 +155,17 @@ Activating a map does not finish the job. A robot keeps the map it already holds
+ caption="What the fleet activated, beside what the robot reports back. This robot has downloaded the new map without applying it, and its management agent is offline — so the update waits for that agent to return." /> + +Two of those readings are worth knowing the first time you meet them. **downloaded, not applied** +means the robot has fetched the new map and is still running the old one, so it counts as behind +until it switches over. And where a robot's **management agent is offline**, the dialog says so, and +the update waits until it is back — [When a robot reads as +offline](/solution/robot-management-toolbox/robot-dashboard#when-a-robot-reads-as-offline) covers +what that state means. The dialog names the map, the revision the fleet activated and the revision on the robot, so it is clear how far behind it is. The recovery is **Take control & update**, then wait for the robot to confirm; then check the missions and switch them back on. If the switch fails it can be retried from the same place, and the missions unlock when it succeeds.