Robot Deployment Toolbox

A 3D scan of a building is a collection of points. A robot also needs to know where the floor is, where it may drive, where it must not go, and which places matter. The Robot Deployment Toolbox is used to add that information and to review it.

The scan itself is produced elsewhere. Where a site is captured with one of our handheld scanners, Manifold Scanner Guides covers everything up to the .pcd this tool loads.

The output is the site map, which everything else depends on. It is pushed to the Robot Management Toolbox and reaches the robots from there.

Site preparation is generally performed once for a site, and revisited when the physical environment changes — racking added, a wall moved, a door permanently closed.

A role is required to push a map, not to author one. The three parts of the job are authorized separately:

Action	Role required
Open and edit a map from local files	None — the map stays in your browser
Import a site's map from Fleet	Observer or above at that site
Push a map to Fleet	Site Admin for that site, or Tenant Administrator

Authoring a map therefore needs no role in the fleet management system; authority is checked when the map is pushed. Publishing and activating the pushed revision require those same two roles, and neither is performed in this tool — see Pushing to the fleet.

The toolbox's features are summarized below, and each is covered in its own section.

Feature	What it gives you
Map inspector	Opens a map to examine it and check that routes solve
Map editor	Turns a 3D scan of a site into the map robots navigate by

Map layers

A site map is not one file. What travels between this tool and the fleet is a bundle of layers, and each answers a different question.

Layer	What it is	Where it is used
Navigation graph	The TMG document: nodes, segments, zones and levels	What the robot navigates by, and what the fleet reads a site's waypoints and routes from
Point cloud	The 3D scan the map was authored against	Loaded back into the editor, so a later revision is drawn against the same scan
Occupancy grid	A flat grid of what is free and what is blocked, one per level	Drawn beneath the graph, so its nodes, segments and zones can be read against the building

The two layers together. White is the occupancy grid — the building. Blue is the graph — the nodes, segments and zones the robot reasons about.

The graph is written in TMG — Topometric Navigation Graph, a map specification Weston Robot defines and publishes. It is topometric because it carries both the topology, meaning which places connect to which, and the metric detail, meaning exactly where each of them is. The graph is the map; the rest is the ground it was drawn over — a separation that shows in practice, since a bundle whose occupancy layer is missing still opens as a usable navigation graph, with the absent underlay reported rather than the whole map refused.

The occupancy grid's role today is visualisation: the fleet and the toolbox draw it under the graph so a node or a zone can be related to the floor plan it sits on rather than read as bare coordinates, while a robot navigates from the graph. One further surface is computed rather than stored — the height grid, derived from the point cloud against the level being edited, is what surface snapping uses to settle a node onto the floor, and it exists only while you are working.

Map elements

The navigation graph is where a map's meaning lives, and these are the elements it is built from. TMG exists because the formats already available describe a space without describing what is allowed to happen in it: a point cloud says where the walls are, not that this doorway is a route and that one is off limits.

Element	What it is
Node	A point the robot can be sent to — a waypoint, or a charging station
Segment	A connection between two nodes: the ways the robot may travel
Zone	An area whose boundary applies rules inside it, including no-go
Level	A floor. Nodes and zones each belong to one
Transition	How a robot moves between levels

Most zones on a finished map were never drawn by hand — one is generated around every node and along every segment, marking the envelope the robot may drive within. The ones you do draw are how you say "never go here". A speed limit is set on a segment rather than drawn as a zone.

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.

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.

Data exchange

The two toolboxes exchange maps at two moments and are otherwise independent of each other.

Moment	Direction	What moves	Which tool
Import from fleet	Fleet → this tool	An existing map bundle, pulled down to work on	Editor or inspector
Push to fleet	This tool → Fleet	The finished map, as a new draft revision	Editor only

Only the editor writes back. The inspector can pull a map down to look at it, and never sends one anywhere.

Nothing passes between them in between. A map open in the editor is a copy: it does not follow changes made in the fleet while you work, and the fleet knows nothing of your edits until you push them. Work in progress lives in your own browser rather than on a server, so the two systems share no state at all between an import and a push.

That is deliberate, and it has one practical consequence worth planning around: whoever edits a site's map should import it at the start of the session rather than reusing yesterday's copy, because nothing will tell them if it has moved on. It is also why two people editing the same site's map at the same time is a bad idea — neither would know.

This tool never talks to robots. It pushes to the Robot Management Toolbox, and robots are updated from there; there is no path from here to a machine in the field. A pushed map arrives as a draft revision, and someone in the fleet management system then publishes it and activates it — activation being what puts a map in front of robots, and neither step something this tool can take.

One end of the exchange: a map comes in from the fleet, or from a file on your machine.

Pushing to the fleet covers the four things the push asks for, why the change summary is worth writing properly, the three steps from draft to activated, and what activation costs a robot.

Map inspector

The inspector answers whether a map is sound, without changing it. It opens one from the fleet or from a file, reports what it holds — how many nodes, segments, zones and levels, and every element by name — and tests whether a robot could actually travel between two points you pick. That second job is the one that earns it: a map whose segments do not quite meet looks connected on screen and cannot be navigated, and this is where that surfaces in seconds rather than during a patrol.

The inspector reading a map: what it holds, every element by name, and the graph drawn out.

Map inspector covers the two modes, where a map can be opened from, how to choose which routes to test, and when reaching for it is worth the time.

Map editor

The editor is where a site map is made: it takes a 3D scan of a building and produces the graph a robot navigates by. That means cleaning up the scan, establishing the floor it sits on, and then placing the nodes, segments and zones themselves — work that is staged, so a map can be picked up and revised later rather than rebuilt from the beginning each time the building changes.

The editor at work. The stage bar runs across the top; the map is drawn against the scan and the occupancy map beneath it.

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 lists what helps.