4 ms·

> When deciding which roboport to charge at, the robots crucially did not consider the current robots on the way to that roboport, only those already in the que

> When deciding which roboport to charge at, the robots crucially did not consider the current robots on the way to that roboport, only those already in the queue, and did not factor in how many free charging spots the roboport has open. By adding these two extra parameters into the equations, the distribution of the robots improves quite nicely. A great example of how omitting one factor can really change the qualitative behavior of your heuristic. I didn't know that the robot pathing to charging stations took into account queue length, since I was so used to seeing the infamous circles-of-depleted-robots queuing around roboports. Turns out they already had some smarts, but because the smarts omitted the (perhaps only in hindsight) metric of robots-heading-to-charge from the queue estimate, the practical effect it was trying to avoid (brigading around a single charging port) wasn't actually avoided. On another side note, it's been a while since I've done the math, but it turns out that each roboport can only support about 50-100 robots. If you've got more logistics robots on a route than that, you need more roboports to keep the item flow up. If you don't have enough roboports, you're doomed to see throughput collapse as they're stuck in charging queues, although now I'm interested to start running tests to see how throughput is affected in such a degraded mode.

dragontamer 3y ago
> On another side note, it's been a while since I've done the math, but it turns out that each roboport can only support about 50-100 robots. If you've got more logistics robots on a route than that, you need more roboports to keep the item flow up. If you don't have enough roboports, you're doomed to see throughput collapse as they're stuck in charging queues, although now I'm interested to start running tests to see how throughput is affected in such a degraded mode. That's... a poor way of thinking about roboports IMO. Roboports are specified with a charging speed: 4x ports of 1MW each. Robots have (3 kW static) + (5 kJ/m) power-usage. We can largely ignore the 3kW as a rounding error especially as infinite-research causes the distance based metric to dominate. A Kilowatt is simply a kilojoule-per-second. Rewriting the units: that means a Roboport's 4000kW of charging is: 4000kJ/s (or perhaps 4x1000kJ/s for the 4x ports), divide this out with 5kJ-per-meter for: (4x1000 kJ/s) / (5kJ/m) == 4x 200 m/s. Or 200-meters-per-second across 4 robots. EDIT: I seem to have doubled up on the 4x multiple times in my first draft. Lets hope my revised math is correct now. ------------ That is to say, each Roboport provides 200-meters-per-second to 4x robots of charge. Again: assuming the 3kW static is ignored. But you can consider "infinite research" to be the asymptote where you get closer-and-closer to this 800-meters-per-second aggregate limit of Roboport charging speeds. ----------------- You can assume that at "maximum speeds", the dominant factor is charging speed. That is: all Robots have so much work to do that they're all "just" waiting to be charged by the roboports. Each Roboport provides additional charge of 200 meters-per-second aggregate movement to your worst-case robot network. "Best case" is when your Roboports are _NOT_ the bottleneck (ie: Robots charge, then see that they have no tasks left to do and then start to sleep). In this case, additional roboports do nothing and instead its speed that dominates. But we can see that in "busy" networks with thousands of items to move (ex: 8x train of 8000 green circuits per train == 64,000 circuits to move per delivery), its roboport-charge that dominates. You pretty much want to max out the density of Roboports and maximize the amount of charge you deliver to your robot network ---------- So its not that "Roboports support X number of Robots". Its that "Roboports support X-amount of robot travel distance per second". The number of robots doesn't matter. The only thing that matters is how much the robots are moving.

dragontamer 3y ago

> On another side note, it's been a while since I've done the math, but it turns out that each roboport can only support about 50-100 robots. If you've got more logistics robots on a route than that, you need more roboports to keep the item flow up. If you don't have enough roboports, you're doomed to see throughput collapse as they're stuck in charging queues, although now I'm interested to start running tests to see how throughput is affected in such a degraded mode. That's... a poor way of thinking about roboports IMO. Roboports are specified with a charging speed: 4x ports of 1MW each. Robots have (3 kW static) + (5 kJ/m) power-usage. We can largely ignore the 3kW as a rounding error especially as infinite-research causes the distance based metric to dominate. A Kilowatt is simply a kilojoule-per-second. Rewriting the units: that means a Roboport's 4000kW of charging is: 4000kJ/s (or perhaps 4x1000kJ/s for the 4x ports), divide this out with 5kJ-per-meter for: (4x1000 kJ/s) / (5kJ/m) == 4x 200 m/s. Or 200-meters-per-second across 4 robots. EDIT: I seem to have doubled up on the 4x multiple times in my first draft. Lets hope my revised math is correct now. ------------ That is to say, each Roboport provides 200-meters-per-second to 4x robots of charge. Again: assuming the 3kW static is ignored. But you can consider "infinite research" to be the asymptote where you get closer-and-closer to this 800-meters-per-second aggregate limit of Roboport charging speeds. ----------------- You can assume that at "maximum speeds", the dominant factor is charging speed. That is: all Robots have so much work to do that they're all "just" waiting to be charged by the roboports. Each Roboport provides additional charge of 200 meters-per-second aggregate movement to your worst-case robot network. "Best case" is when your Roboports are _NOT_ the bottleneck (ie: Robots charge, then see that they have no tasks left to do and then start to sleep). In this case, additional roboports do nothing and instead its speed that dominates. But we can see that in "busy" networks with thousands of items to move (ex: 8x train of 8000 green circuits per train == 64,000 circuits to move per delivery), its roboport-charge that dominates. You pretty much want to max out the density of Roboports and maximize the amount of charge you deliver to your robot network ---------- So its not that "Roboports support X number of Robots". Its that "Roboports support X-amount of robot travel distance per second". The number of robots doesn't matter. The only thing that matters is how much the robots are moving.