Automatic insertion of robots

[Quax]

So after long hours of gameplay I finally arrived at the robotic age . I set up my first robot factory and started to build up the logistic networks with my roboports. But how can I now insert the newly produced robots into all the roboports? The ony way I figured out so far is to pick them up and insert them into the different roboports manually. However, this is not possible in the long run. I already considered placing requester chests at each roboport and using an inserter. But in that case
a) I cannot control the number of logistic/construction robots to be inserted
b) every time a robot leaves the roboport for his work duty, another would be inserted, wouldn't he?

So if anyone can point me towards an automated way of filling up the roboports with the desired ratio between logistic and construction robots straight from the belt, I'd be glad.

Thanks

[Loewchen]

You can obtain the amount of bots in a network with a circuit connection to a roboport and build your setup around that.

[mmmPI]

b) every time a robot leaves the roboport for his work duty, another would be inserted, wouldn't he?

This is actually a desired behavior of some sort, if you use the circuit network to enable a inserter to add robots to have the desired ratio, you hope that the roboport you choose always has some room.

[SyncViews]

There is no need to add robots to each roboport. they will move around the network by themselves, and dock/park at whichever is nearest when idle. You can use the circuit output of a roboport within the network connected to an inserter with a condition to regulate the total number of construction and logistics added to the network.

There is only a major concern when you have multiple networks? Is this your case? That requires some more complex logic, for example using trains, or requester-inserter-provider setups on small gaps between networks to transfer items from one network to the next.

[Serenity]

I prefer to set the number of desired bots with a constant combinator. Read the bots from a roboport. Then use decider combinators to compare against what you want. And activate an inserter from a chest into a roboport (one each for logistics and construction bots).
When the robots are in demand they will leave the port they are placed into.

Inserting when robots aren't available just causes new ones to be inserted during heavy activity. That does sound nice at first, but about the only time I really struggle with too few construction bots is when paving large areas with concrete. And I'm happy to wait then. But it's personal preference

[hale42]

what I plan on putting together (I have all but the train to robo part done) is, a train that delivers robots then an inserter will add just one from the chest at the train stop then that one robot will fill the rest of the network with bots. a network "head" is used to determine whether or not to add or subtract from the network.

[slippycheeze]

what I plan on putting together (I have all but the train to robo part done) is, a train that delivers robots then an inserter will add just one from the chest at the train stop then that one robot will fill the rest of the network with bots. a network "head" is used to determine whether or not to add or subtract from the network.

Pro tip: don’t forget you can connect an inserter to the logistic network, as well as the circuit network.

[SyncViews]

I prefer to set the number of desired bots with a constant combinator. Read the bots from a roboport. Then use decider combinators to compare against what you want. And activate an inserter from a chest into a roboport (one each for logistics and construction bots).
When the robots are in demand they will leave the port they are placed into.

Inserting when robots aren't available just causes new ones to be inserted during heavy activity. That does sound nice at first, but about the only time I really struggle with too few construction bots is when paving large areas with concrete. And I'm happy to wait then. But it's personal preference

Agree definitely limit on the total number of bots not available. It is easy to do things that will instantly try to use thousands of bots (new requester chests, placing blueprints, destruction planner, etc.).

If you have 1 inserter for construction and 1 for logistics, you can also add a condition directly on a normal inserter to activate on quantity, although then you have 2 inserters to view/change quantities.

[slippycheeze]

Agree definitely limit on the total number of bots not available. It is easy to do things that will instantly try to use thousands of bots (new requester chests, placing blueprints, destruction planner, etc.).

I found that using "one percent of bots should be idle" was ... passable, but did overbuild compared to my expectations. I automatically created new robots as well as injecting them into the network in that case, and ended up with more than 6k bots in the mall, when I expected maybe 2k.

On the other hand, all 99 percent of them were busy all the time, so I guess maybe it was my expectation that was wrong...

[Quax]

Thanks for all the replies .. some further toughts / questions:

This is actually a desired behavior of some sort, if you use the circuit network to enable a inserter to add robots to have the desired ratio, you hope that the roboport you choose always has some room.

So this means I can have more robots available then there are slots in the roboports?

There is no need to add robots to each roboport. they will move around the network by themselves, and dock/park at whichever is nearest when idle.
There is only a major concern when you have multiple networks? Is this your case?

Intresting. I was using my robot on the very oppsite edge of my base as where the robot factory is. However, the roboport at the factory was filled up with robots, but none of them moved out for work. I'm pretty sure there is a logistic network connection. But then, it might have been a local bank holiday for robots ... Or is there a maximum distance the robots will react upon work requests?

Also I haven't been able to observe the robots to return to the nearest roboport when idle. Instead, it looks to me they return to the very roboport they nave initially been inserted at. I think I need to watch them mor closely next time.

And no, I don't have separated networks, so this is not an issue.

[SyncViews]

Intresting. I was using my robot on the very oppsite edge of my base as where the robot factory is. However, the roboport at the factory was filled up with robots, but none of them moved out for work. I'm pretty sure there is a logistic network connection. But then, it might have been a local bank holiday for robots ... Or is there a maximum distance the robots will react upon work requests?

It does tend to use the nearest idle robot as well, so if you have enough robots then ones far enough away might not get used letting the roboport fill up, which is generally then not a problem unless you get a situation like every slot is filled with one type of robots so that it can't insert the other (very rare, and inserting into two different roboports even more reliable).

In some cases if you create a very large number of requests, the game seems to have a limited "processing rate", and robots won't be dispatched immediately that in theory could be. This seems to be most noticeable if you have a lot of things that can not be fullfilled because the network lacks the resources (for example thousands of blueprinted concrete, but no concrete. belts can be another common example).

Maybe there was a gap, you can see the network in the roboports info and there is an overlay to show the connection lines. Remember the connection distance is smaller than the construction radius.

Also I haven't been able to observe the robots to return to the nearest roboport when idle. Instead, it looks to me they return to the very roboport they nave initially been inserted at. I think I need to watch them mor closely next time.

Was the closer roboport full, or already had a queue of robots wishing to recharge? If a near one is too busy, they can try further away.

[ratchetfreak]

Agree definitely limit on the total number of bots not available. It is easy to do things that will instantly try to use thousands of bots (new requester chests, placing blueprints, destruction planner, etc.).

I found that using "one percent of bots should be idle" was ... passable, but did overbuild compared to my expectations. I automatically created new robots as well as injecting them into the network in that case, and ended up with more than 6k bots in the mall, when I expected maybe 2k.

On the other hand, all 99 percent of them were busy all the time, so I guess maybe it was my expectation that was wrong...

But often the actual issue is charging and not number of bots. Adding more bots just makes it worse. Up until the workload drops to something the roboports can handle which is when the queue of charging bots slowly starts dwindling to sustainable levels.

[FuryoftheStars]

Also I haven't been able to observe the robots to return to the nearest roboport when idle. Instead, it looks to me they return to the very roboport they nave initially been inserted at. I think I need to watch them mor closely next time.

Was the closer roboport full, or already had a queue of robots wishing to recharge? If a near one is too busy, they can try further away.

One behavior that I’ve seen that I don’t understand, more so when deconstructing, is that the robots will not go to the nearest storage to drop off their goods. They’ll instead travel long distances to go back to storage chests that are closer to the first robo port I constructed.

[orzelek]

Also I haven't been able to observe the robots to return to the nearest roboport when idle. Instead, it looks to me they return to the very roboport they nave initially been inserted at. I think I need to watch them mor closely next time.

Was the closer roboport full, or already had a queue of robots wishing to recharge? If a near one is too busy, they can try further away.

One behavior that I’ve seen that I don’t understand, more so when deconstructing, is that the robots will not go to the nearest storage to drop off their goods. They’ll instead travel long distances to go back to storage chests that are closer to the first robo port I constructed.

Robots also have additional rule that might be causing what you are seeing - they will try to put item to storage chest that already has this item.

[FuryoftheStars]

Also I haven't been able to observe the robots to return to the nearest roboport when idle. Instead, it looks to me they return to the very roboport they nave initially been inserted at. I think I need to watch them mor closely next time.

Was the closer roboport full, or already had a queue of robots wishing to recharge? If a near one is too busy, they can try further away.

One behavior that I’ve seen that I don’t understand, more so when deconstructing, is that the robots will not go to the nearest storage to drop off their goods. They’ll instead travel long distances to go back to storage chests that are closer to the first robo port I constructed.

Robots also have additional rule that might be causing what you are seeing - they will try to put item to storage chest that already has this item.

I figured this may be part of it, but I've seen them fill up these chests and then start using completely empty ones next to the ones they just filled and continue from there, never using the ones that are closer to where they're actually deconstructing (I'll have to run some more tests to confirm). I suppose this behavior is fine when the deconstruction site is only a few chunks away, but when it's 25+, this becomes a huge waste in travel time.

Has anyone collected all the rules the bots follow somewhere, here on the forums or on the wiki?

[mmmPI]

This is actually a desired behavior of some sort, if you use the circuit network to enable a inserter to add robots to have the desired ratio, you hope that the roboport you choose always has some room.

So this means I can have more robots available then there are slots in the roboports?

2 options here,

1 all the roboports are completely filled in all their slot with robots, and you have some left over robots that can't find any room so they are forced to stay in the air. This can happen if you have for example 1 robotport, and you insert robots in it, while the others are working, when they try to get back, they have no room. ( not very desirable)

2 what i meant, was to select 1 roboport to be the "insertion" roboport, and the robot should leave it to go to do some work and then don't come back to this particular insertion roboport, but to any other closer to where there are robots jobs nearby. then you have 1 spot that can be used to insert all the robots. ( providing it has room ).

If the robots were to always come back to their insertion point that wouldn't be possible and you'd have to insert in all the different robotport.

[slippycheeze]

Agree definitely limit on the total number of bots not available. It is easy to do things that will instantly try to use thousands of bots (new requester chests, placing blueprints, destruction planner, etc.).

I found that using "one percent of bots should be idle" was ... passable, but did overbuild compared to my expectations. I automatically created new robots as well as injecting them into the network in that case, and ended up with more than 6k bots in the mall, when I expected maybe 2k.

On the other hand, all 99 percent of them were busy all the time, so I guess maybe it was my expectation that was wrong...

But often the actual issue is charging and not number of bots. Adding more bots just makes it worse. Up until the workload drops to something the roboports can handle which is when the queue of charging bots slowly starts dwindling to sustainable levels.

That is absolutely true, and I didn’t even think to mention all that complexity. I did keep track of charging delays in my mall and supply them with additional power - especially on busy routes, since charge port use is not a uniform thing. I ended up grabbing the Robocharger mod to provide additional slots without using roboports to make that a little more effective. It is, to me, a suitably balanced way to do this: reasonable power consumption overhead, and unlike many mods it has no storage, and does not extend the logistics or construction networks.

Without that, yeah, it would have spiralled out of control, so isn’t a strategy I’d use again despite knowing how to manage that problem: if I have to keep track of it as a human, I am eventually going to mess it up. Unfortunately, I couldn’t find any way to read the “queue depth for charging” from the network, so now I honestly don’t know what I’ll do for auto-scaling. Probably nothing. Outposts already used a “total count target” manually set…

One behavior that I’ve seen that I don’t understand, more so when deconstructing, is that the robots will not go to the nearest storage to drop off their goods. They’ll instead travel long distances to go back to storage chests that are closer to the first robo port I constructed.

Robots also have additional rule that might be causing what you are seeing - they will try to put item to storage chest that already has this item.

This is almost certainly what is happening. The priority order for robots is roughly:

1. chest where things already are
2. chest with the logistic filter set to the thing
3. the first chest built that isn't full

Internally the logistic network treats all storage as equal, and doesn't consider distance very much when it comes to moving things around. This is why you generally want to centralize storage, and avoid sprawling logistic networks.

[Quax]

I watched my robots clocely last evening:

- when idle, they will return to one of the nearest roboports, but not exactly the nearest (which of course still has free place for them).
- they definitely are returning deconstructed material to the chest already holding the same item. Which makes placing a chest at each roboport rather useless, as they won't be used anytime soon.
- a strange beaviour occurs on charging: 20 or more robots are waiting to be charged at one single roboport, instead of using one of the other roboports in the surrounding area. I guess they don't "recalculate" the way to the recharging roboport once they decided they need to recharge. Will use the robocharger mod to get around that bottleneck.


Thanks for your suport here

[SyncViews]

- they definitely are returning deconstructed material to the chest already holding the same item. Which makes placing a chest at each roboport rather useless, as they won't be used anytime soon.

For large construction jobs (deleting forests, old bases, etc. or building concrete, solar farms, etc.) on very large scales I almost always end up making it a separate network. Then either transfer stuff by train, or using logistics bots (where they can make proper use of the capacity upgrades instead of construciton bots carrying 1 tree, 1 tile, etc. across the entire base).

Buffer chests can kinda work for the construction side, and requester chests for the deconstruction side (assuming whatever you are deconstructing does not exist in provider/storage, e.g. if you are burning all your wood/trees).

I guess they don't "recalculate" the way to the recharging roboport once they decided they need to recharge. Will use the robocharger mod to get around that bottleneck.

No, once bots have a job assigned they stick to it. Normally bottlenecks can be worked around.

• When looking for a roboport to charge at, they only look a certain distance further than the closest. Not sure on the exact mechanics, but having roboports closer together in busy areas will distribute them (and if they tried to go to one further they would run out of power anyway, they decide to charge at a set "low power" point, no intelligent routing, which is why sometimes they fly past a roboport and then turn back).
• ]Never build a concave network. Bots will try and cut the corner, and run out of power. Fill in the corners with roboports to make it convex, or split into multiple networks.
  
  Further, when a robot runs out of power on the way to a roboport and goes very slow as well as delaying its own job significantly, it effectively slows down the charging at that roboport, and then other robots run out of power and move slow from the "holding range" to the charge point.
• The robot speed upgrades help greatly, as they move from the holding/queue to the charge point faster.
• Smaller networks are generally better. If using them for logistics rather than belts, ideally a network should only be a few roboports big, to keep them flying the shortest distances possible and prevent sudden "bursts" from overwhelming the charging capability in the area.

[Quax]

• Smaller networks are generally better. If using them for logistics rather than belts, ideally a network should only be a few roboports big, to keep them flying the shortest distances possible and prevent sudden "bursts" from overwhelming the charging capability in the area.

Interesting Point. Currently I have distributed my roboports so that the whole area is covered by the logistic Network. So in fact I actually do have a 50x50 grid of roboports on my base. This because I neede them to distribute my building elements from the main bus factory to the border areas of my base as I'm slowly expanding my base by shifting the borders further and further way from the center.

I guess I'm gonna post a pic of my current base here for some pro tips on the logistic network