Logistic robots: roboport coverage, charging and network design

Robot speed and what it means

The game data stores robot speed in tiles per tick. Multiplying by 60 ticks per second gives the speed in tiles per second, which is easier to reason about:

Robot	Speed (tiles/tick)	Speed (tiles/s)	Max payload	Health
Logistic robot	0.05	3	1	100
Construction robot	0.06	3.5999999999999996	1	100

A logistic robot flies at 3 tiles per second. A construction robot is slightly faster at 3.5999999999999996 tiles per second — 1.20x the logistic robot's speed. This makes sense: construction robots often need to cover a wider area to reach distant ghosts and repair jobs, while logistic robots operate within the denser, smaller logistics zone.

The max_payload_size is 1 for both robot types in the base prototype data. This means one item per trip before any research. Logistic robot cargo size research increases this value per level, but the research bonuses are not in the extracted data — they are defined as technology modifiers rather than prototype properties. In a developed base with cargo size research, a logistic robot can carry multiple items per trip, substantially increasing effective throughput. This page does not fabricate those post-research values.

Energy per move

The logistic robot prototype includes an energy_per_move value of 5. The exact unit interpretation depends on the game's internal energy model; the raw value in the data is 5 and this page presents it as-is rather than converting it to a per-second drain or per-trip cost. Construction robots do not have an energy_per_move field in the extracted data. Both robot types drain energy while flying and must return to a roboport to recharge, which is the primary throughput limiter in a busy logistic network.

Roboport coverage zones

A roboport defines two concentric zones: the logistics network area and the construction area. Both are square regions centered on the roboport, with the dimensions below read from data/2.1/machines.json:

Zone	Radius (tiles)	Side length (tiles)	Area (tiles²)
Logistics radius	25	51	2,601
Construction radius	55	111	12,321

The logistics radius of 25 tiles covers a square of 51 by 51 tiles — 2,601 square tiles total. Logistic robots will only operate within this zone. A chest placed outside the logistics radius of every roboport is not part of any logistic network, even if it is within the construction radius.

The construction radius of 55 tiles covers a much larger square of 12,321 tiles. Construction robots operate within this expanded zone to build ghosts, repair damaged entities, and upgrade or deconstruct marked objects. The construction zone extends well beyond the logistics zone, which is why a single roboport can manage construction across a wide area while its item-delivery network stays compact.

Overlapping roboports

When the logistics zones of two or more roboports overlap, they form a single logistic network. Robots can travel between any two chests in the combined zone. The construction zones also merge, allowing construction robots from any roboport in the network to reach any point within the union of all construction radii.

To extend coverage, place roboports so that their logistics zones touch or overlap. A spacing of 50 tiles between roboports (centre to centre) makes the logistics zones just touch at the edges. A closer spacing provides overlap and redundancy — if one roboport runs low on power or is destroyed, the overlapping neighbours keep the network connected. The construction zones overlap easily at that spacing because they extend much further.

Robot charging behaviour

Each roboport has 7 robot charging slots, also read from the prototype data. When a robot's energy runs low, it flies to the nearest roboport with a free charging slot and recharges before continuing. If all 7 slots are occupied, the robot queues, flying in a holding pattern near the roboport until a slot opens.

Charging is the most common throughput bottleneck in a mature logistic network. A single roboport can only recharge 7 robots at a time. If the network has hundreds of robots making frequent trips, the charging slots saturate and robots spend more time waiting to recharge than flying. The solution is not to add more robots — that makes the queue longer — but to add more roboports, each contributing 7 additional charging slots.

A useful planning heuristic is one roboport per roughly 50 to 100 logistic robots in a busy network, though the exact ratio depends on trip distance, energy per move, and the robot speed research level. Networks with short trips (chest-to-chest within a compact factory) drain less energy per trip and can share charging slots more efficiently. Networks with long trips across a large base need more roboports along the route.

Logistic network vs construction network

The two networks share roboport infrastructure but operate independently. Logistic robots move items between logistic chests according to requests and provider rules. Construction robots respond to ghosts, repair packs, upgrade orders and deconstruction orders. A roboport must contain construction robots for construction tasks and logistic robots for item delivery; the two types do not substitute for each other.

This separation matters for network design. A large construction project (building a new outpost, for example) can tie up every construction robot in the network, but logistic robots continue delivering items unaffected. Conversely, a busy logistic network with robots constantly charging does not prevent construction robots from operating, as long as charging slots are available. The 7 charging slots are shared between both robot types, however, so a surge in construction activity can delay logistic robot recharging and temporarily reduce item throughput.

Logistic chest types

All five logistic chest variants have the same inventory capacity of 48 slots and 350 health, but they serve entirely different roles in the network:

Chest	Slots	Role
Passive provider chest	48	Provides items to robots when requested; robots take from it but never deliver to it
Active provider chest	48	Actively pushes items into storage or requester chests; use for overflow or trash
Storage chest	48	General storage; robots deposit items here when no requester needs them
Buffer chest	48	Stores items locally for quick resupply; can also provide to the network
Requester chest	48	Requests specific items in specified quantities; robots deliver to it

Passive provider chest

The passive provider is the most common chest in a logistic network. Assemblers and furnaces insert their output into a passive provider chest, and robots pick up those items when a requester or buffer chest needs them. Robots never deliver items to a passive provider, so it acts as a pure source. This is the chest to place at the output of production lines.

Active provider chest

The active provider actively pushes its contents into the network. Robots will move items out of an active provider even if no requester has asked for them, depositing them into storage chests. This makes it useful for trash disposal — for example, removing unwanted items from a player's trash slots — but inappropriate for production output, because it can cause items to be moved into storage and then immediately requested back, generating wasted robot trips.

Storage chest

Storage chests are the network's warehouse. Robots deposit items here when an active provider overflows or when items have no specific requester. Storage chests can be filtered to accept only one item type, which helps keep the network organised. They are also where robots pick up items for construction if no passive provider has the needed item.

Buffer chest

The buffer chest is a hybrid: it can request items from the network like a requester, and it can provide items to other requesters like a passive provider. This makes it useful for local caching — placing a buffer chest near a high-consumption area so robots make short, fast trips from the buffer rather than long trips from a distant provider. Buffer chests can also supply items directly to players.

Requester chest

The requester chest pulls specific items in set quantities from the network. You configure it with a list of items and amounts, and robots deliver from passive providers, buffer chests, or storage chests until the request is fulfilled. Requester chests are the standard way to supply assemblers with ingredients in a robot-fed factory. Each inserter pulling from the requester chest into the assembler keeps the machine running as long as the network has the requested items.

When robots beat belts

A logistic robot carries 1 item per trip (before cargo size research) at 3 tiles per second. A yellow belt carries 15 items per second continuously. On a pure throughput basis, a single robot is vastly slower than a belt. The comparison changes in three situations:

1. Many-to-many routing. Belts excel at moving items in a straight line from one source to one destination. When items need to go from many producers to many consumers in a web of relationships — malls supplying players, mixed-product outposts, modular factory blocks — routing belts between every pair becomes a spaghetti of underground segments and splitters. Robots make the routing implicit: any chest can send to any chest, and the pathfinding is handled by the flight logic.
2. Low-volume, high-variety delivery. A mall that produces dozens of different items at one or two assemblers each does not need belt throughput; it needs flexibility. A requester chest at each assembler pulls the right ingredients from passive providers across the network without dedicated belt lanes for each item.
3. Construction and remote tasks. Belts cannot build ghosts, repair walls, or deconstruct obsolete miners. Construction robots do all of these across the 55-tile radius without any fixed infrastructure beyond the roboport.

Robots are a poor choice for high-volume, point-to-point transport — moving thousands of ore per minute from a mine to a smelter. For that, belts or trains remain the right tool. The robot's strength is flexibility and coverage, not bulk throughput. Even with maximum cargo size research, a robot swarm delivering ore would require thousands of robots and roboports, consuming far more power and UPS than a few blue belts.

Designing a robot-fed factory block

A typical robot-fed block places assemblers in a grid with passive provider chests at each output and requester chests at each input. Roboports are spaced so their logistics zones cover the entire block, with extra roboports added for charging capacity as robot count grows. The block does not need belts at all for internal routing, which frees up floor space for more machines.

The boundary between robot-fed blocks and belt-fed blocks is usually a row of buffer or requester chests fed by belts from a main bus or train station. The belt delivers bulk materials (ore, plates, coal) to the block's input chests, and robots distribute those materials internally. Output passive providers feed back into a belt or train loading station. This hybrid approach uses belts for what belts are good at (bulk transport) and robots for what robots are good at (flexible distribution).

Robot speed research and worker robot speed bonuses

The base speeds of 3 tiles per second (logistic) and 3.5999999999999996 tiles per second (construction) are the unmodified prototype values. Worker robot speed research increases both speeds by a percentage per level, and worker robot cargo size research increases the number of items a logistic robot carries per trip. Neither research modifier is present in the extracted prototype data — they are technology effects applied at runtime — so this page cannot state the post-research speeds or payload sizes. The effect is substantial at high research levels: a fully upgraded logistic robot is several times faster and carries multiple items per trip, which changes the throughput calculus considerably.

What this means for planning is that a robot network designed around the base values will outperform expectations as research completes, not underperform them. A roboport placement that provides adequate coverage early will still provide that coverage later; the robots will simply make trips faster and carry more per trip. The constraint that does not improve with research is charging: more and faster robots making more trips consume more energy, and the 7 charging slots per roboport become the bottleneck sooner as robot counts grow.

Power requirements and roboport placement

The roboport has 500 health and must be powered to operate. When unpowered, it does not charge robots, does not connect to the logistic network, and does not dispatch construction robots. In a large base, roboports should be placed with redundant power feeds so that a single damaged power pole does not disconnect a segment of the network.

Roboports connect to each other automatically when their logistics zones overlap, forming a single contiguous network. The visual connection is shown as a dotted line between adjacent roboports. If two roboports are placed too far apart and their logistics zones do not touch, they form separate networks that do not share robots or items. This can be intentional (isolated outpost networks) or accidental (a gap in coverage). The construction zone can overlap even when the logistics zones do not, which means construction robots may operate across the gap but logistic robots cannot cross it.

For a factory-wide network, place roboports in a grid pattern at intervals of 50 tiles or less. This ensures the logistics zones connect while the construction zones overlap generously, leaving no construction blind spots. In a compact factory block, roboports can be placed closer together to increase charging capacity, since each additional roboport adds 7 charging slots even if its coverage is redundant.

Common robot network mistakes

• Too few roboports for the robot count. The charging queue grows, robots spend more time waiting than flying, and item delivery slows to a crawl. Add roboports, not robots.
• Active provider chests on production output. Items get hauled to storage and then hauled back to requesters, generating wasted trips. Use passive providers for production output.
• Gaps in roboport coverage. A single missing roboport can split the logistic network in two, with robots unable to cross the gap even though the construction network appears connected.
• Using robots for bulk transport. Delivering thousands of ore per minute by robot requires enormous robot counts and power. Belts or trains are the correct tool for high-volume point-to-point transport.
• Unfiltered storage chests. When every storage chest accepts every item, robots scatter items across the network and retrieval becomes slow. Filter storage chests by item type to keep the network organised.

Applies when…

• Robot speeds are read from data/2.1/machines.json as tiles per tick and multiplied by 60 for tiles per second.
• max_payload_size = 1 is the base prototype value. Logistic robot cargo size research increases this value, but research levels and bonuses are NOT FOUND in data/2.1/.
• energy_per_move = 5 is presented as the raw value from the prototype data. Its exact unit interpretation in the game's energy model is not converted here.
• Roboport construction radius is 55 tiles and logistics radius is 25 tiles, both from machines.json.
• Each roboport has 7 charging slots from robot_slots_count in the prototype data.
• All logistic chest variants have 48 inventory slots, read from machines.json.
• All figures are for game version 2.1.12. Mods that change robot speed, roboport radius, or chest capacity will change these values.

Questions or corrections? Contact [email protected].

Related

• Inserters and belts — throughput comparison for the transport robots replace
• Main bus design — the belt architecture that often feeds robot networks
• Belt balancer designs — splitter counts for belt-side infrastructure
• Smelting ratios — a use case where belts outperform robots for bulk transport