Robotic network
The robotic network was introduced with v0.8.0, which also added the Repair packs and Construction robots.
Roboports are the base of the robotic network. They cover an area of 50x50 tiles and if placed near enough together, they are connected and build one big robotic network. Robots can fly inside this network to every point covered by the roboports. Roboports are expensive in both: the crafting and the need for power.
Items
 |
Spawns the Robotic network. Holds and recharges robots and provides the coverage for logistics and construction network. |
 |
Moves items between logistic chests. |
| |
Repairs broken or replaces destroyed entities. Builds and removes entities on command. |
Robots
Robots do in their coverage area, for what they are built to. They need always power to keep flying in the air. When they have nothing to do, they fly in the next roboport and sleep.
Roboports
To create a robotic network, you need to place one Roboport. If you place a second, lines will show you if it is connected with the first. If so, they build a bigger network. The roboports are also used for charging of the bots. See below if you have charging problems.
Avoid "angeled" shaped layouts of roboports!
This is a know issue: robots fly always the shortest way. This means, they can and will fly over areas without roboport-coverage! The distance to the chargers may be too far. This will slow down robots significantly, if you create such a layout.
See also http://www.factorioforums.com/forum/viewtopic.php?f=16&t=1773&p=13797&hilit=Roboports+issue#p15177
Logistic network
The area covered by the robotic network is identical to that of the Logistic network. All Logistic network/Chests inside a robotic network are connected and build the Logistic network. Imagine the logistic chests send their containments to the roboports.
There can be many individual Robotic networks. Bots cannot fly from one network into another.
See Logistic network.
Repair
All broken entities will be repaired with Repair packs by the Construction robots. Destroyed entities will be replaced, if they are available in the same logistic network.
See Repair.
Number of bots in a robotic network
The amount of robots per network is limited:
- the roboports don't have unlimited space.
- flying robots need energy to fly at normal speed and the charging points are limited.
See also this discussion.
So the number of bots in a network depends on these factors:
- number of roboports
- the average distance between the roboports (density)
- the form of the robotic network/placement of the ports
- average distance the logistic bots fly between Logistic network/Chests
- how much damage the Construction robots must repair and how often do they need to place or remove buildings
And in general:
- number of bots flying
- number of bots stored in roboports
As a rule of thumb between 50-100 bots per Roboport is possible.
Things you can do to optimize a robotic network
The transportation-power of the logistic bots is nearly constant! It depends on
- Speed of the bots
- Cargo-stacksize (number of items he can take)
- Number of bots
- Average distance between your chests (all combinations)
- How much they fly empty (the more "random" the transport is, the better, because then there is a bigger chance that an empty robot is near!)
- How long they need to wait for recharge - this effect is "blocking", which means, that up to an unknown maximum the transport-power is constant and suddenly the waiting queue gets too long and this dissolves not (Only if the needed transports is much lower for a minute or so). Funny thing here is, that a slightly lower number of bots is then eventually faster!
To optimize it, you can
- Research speed or cargo-stacksize.
- greatly recommended
- Add more bots to your network
- This has the above disadvantage, that at some point you can't add more bots into your network, because they can't be charged fast enough anymore.
- Add more roboports at strategic points
- This is an expensive enhancement and sometimes this doesn't help. But sometimes this solves some problems.
- Decrease the average distance between the logistic chests
- avoid transport of great amounts raw-material. Use transport-belts for the "main-routes" of the bots. Bring the big material-flows as near to the target, as possible. The transport-power of logistic bots is much bigger than belts, but a constant flow reduces their effectivity very strong, because then they fly half of the time empty.
- Split a big network into two and move the items between these networks with transport belts or trains (and requester/provider-chests).
Example
It's a very good idea to use a robotic network on a train station to unload the chests, which are filled by the inserters from the wagons into storage-chests. The logistic bots have enough time to recharge in the times, when the there are no trains.
But don't use it then, to transport the ore also to the furnaces. For that the belts are much more useful, because the furnaces have a very constant need of raw-material and for constant flow the belts are much more useful.
See this thread thread or this picture
This shows the flow:
Wagon ---Inserter---> Provider chest ---Logistic bot---> Storage- or Requester-chest Requester-Chest ---Inserter---> Belt ---> to the furnaces
No energy left
As of 0.8.5, robots with no energy are destroyed leaving nothing behind. Carried items are also destroyed.
As of 0.10.0, Robots with no energy are no longer destroyed, they will just slow down to a 5th of normal speed.
Choosing the post for charging
Normally a robot takes the nearest roboport to recharge. If the queue on that roboport is too long, he chooses eventually another port.
This is specified with the ratio of
<distance to different roboport> / <queue size of robots waiting>
optimum. Currently, to choose the more distant roboport, the distance must be at most
<Number of robots in the queue and on the way> / 2
So to choose a roboport, that is 10 tiles more distant, it has to have 20 less robots waiting in the queue.
This number should probably be changed as well, maybe it should be one in queue per one tile...