Roboports

Post all other topics which do not belong to any other category.
xplycyt
Burner Inserter
Burner Inserter
Posts: 9
Joined: Wed Apr 18, 2018 2:59 pm
Contact:

Roboports

Post by xplycyt »

Can anyone explain why a roboport holds 350 but can only charge 4 at a time? This seems pretty silly and aesthetically challenging.

Loewchen
Global Moderator
Global Moderator
Posts: 8285
Joined: Wed Jan 07, 2015 5:53 pm
Contact:

Re: Roboports

Post by Loewchen »

Because those two values have as much to do with one another as the amount of toast I can fit in my home vs how much I can heat up at a time.

User avatar
planetmaker
Fast Inserter
Fast Inserter
Posts: 180
Joined: Mon Jan 21, 2019 9:30 am
Contact:

Re: Roboports

Post by planetmaker »

Loewchen wrote: ↑
Wed Jan 15, 2020 3:12 am
Because those two values have as much to do with one another as the amount of toast I can fit in my home vs how much I can heat up at a time.
An now I wish a robot would deliver a steaming-fresh toast hawaii :( I like the comparison! :)

netmand
Filter Inserter
Filter Inserter
Posts: 302
Joined: Wed Feb 22, 2017 1:20 am
Contact:

Re: Roboports

Post by netmand »

It's like owning an electric car (i.e. Tesla) and arriving at the parking lot which has 4 charging spots (that are taken) ... but lots of other empty spaces.

I've wondered why Roboports are the way they are too. There are no non-electric bots to take up those spaces.

The Borg have ports in every slot AFAIK.

Premu
Fast Inserter
Fast Inserter
Posts: 100
Joined: Wed Nov 13, 2019 4:40 pm
Contact:

Re: Roboports

Post by Premu »

netmand wrote: ↑
Wed Jan 15, 2020 3:14 pm
It's like owning an electric car (i.e. Tesla) and arriving at the parking lot which has 4 charging spots (that are taken) ... but lots of other empty spaces.

I've wondered why Roboports are the way they are too. There are no non-electric bots to take up those spaces.

The Borg have ports in every slot AFAIK.
This setup makes sense if you use roboports only occasionally for construction or personal deliveries. With that you can still build a lot fast or get a lot of stuff quickly for a short time while getting away with the minimum amount of roboports to cover the whole area. If their batteries are enough they might do their job and reacharge slowly after having finished. Just don't expect it to work continuesly, for that you need far more roboports close by.

Honktown
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Roboports

Post by Honktown »

You could increase the charge ports and increase the power delivery... be prepared for the 1 gigawatt recharges when a train stops in :D
I have mods! I guess!
Link

User avatar
Impatient
Filter Inserter
Filter Inserter
Posts: 880
Joined: Sun Mar 20, 2016 2:51 am
Contact:

Re: Roboports

Post by Impatient »

It is because the charge time is much lower than the time a bot needs to use that power, I guess.

xplycyt
Burner Inserter
Burner Inserter
Posts: 9
Joined: Wed Apr 18, 2018 2:59 pm
Contact:

Re: Roboports

Post by xplycyt »

It really is just a Factorio joke i guess. Just like when we were told there would be cake...

pieterhulsen
Inserter
Inserter
Posts: 21
Joined: Tue Dec 20, 2016 3:52 pm
Contact:

Re: Roboports

Post by pieterhulsen »

Because it would be very overpowered if they had more, without this limitation belts would be even further from the power of robots

User avatar
GlassDeviant
Fast Inserter
Fast Inserter
Posts: 170
Joined: Wed Feb 11, 2015 1:51 am
Contact:

Re: Roboports

Post by GlassDeviant »

Premu wrote: ↑
Wed Jan 15, 2020 5:08 pm
This setup makes sense if you use roboports only occasionally for construction or personal deliveries. With that you can still build a lot fast or get a lot of stuff quickly for a short time while getting away with the minimum amount of roboports to cover the whole area. If their batteries are enough they might do their job and reacharge slowly after having finished. Just don't expect it to work continuesly, for that you need far more roboports close by.
This is why there are several mods that make changes to roboports or add new types.
- GD

Sorry if my posts are becoming difficult to read, my typing ability is rapidly deteriorating due to a nerve disorder. I try to clean them up before posting but don't always get every last typo.

mrvn
Smart Inserter
Smart Inserter
Posts: 5686
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Roboports

Post by mrvn »

xplycyt wrote: ↑
Wed Jan 15, 2020 2:39 am
Can anyone explain why a roboport holds 350 but can only charge 4 at a time? This seems pretty silly and aesthetically challenging.
That raises the question: How many bots can a roboport charge in the time the bot uses up that power?

Honktown
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Roboports

Post by Honktown »

mrvn wrote: ↑
Thu Jan 16, 2020 11:56 am
That raises the question: How many bots can a roboport charge in the time the bot uses up that power?
Depends on speed, where it returns, etc. For even moderately sped up robots (like 100%) static cost becomes a rounding error, so at 5 kJ/"meter"? tile?:

Charging energy of a roboport is 1000kW (explicitly that). I don't see an explicit charge port count, but it has four charging offsets, which corresponds to four normal ports. It can charge at 5MW, so 4MW max deliverable is under that limit. 4/.005 = 800 meters per second. Base speed of construction bot is "0.06" (tiles per tick). Speed bonus before space science: 240% (from wiki). 800 / (60 * .06 * 2.4 * n) = n robots. 92.59 = n^2. 9.6 robots per second (is that right? it sounds reasonable, I didn't have /n the first time). Someone check my math.
I have mods! I guess!
Link

Koub
Global Moderator
Global Moderator
Posts: 7175
Joined: Fri May 30, 2014 8:54 am
Contact:

Re: Roboports

Post by Koub »

mrvn wrote: ↑
Thu Jan 16, 2020 11:56 am
xplycyt wrote: ↑
Wed Jan 15, 2020 2:39 am
Can anyone explain why a roboport holds 350 but can only charge 4 at a time? This seems pretty silly and aesthetically challenging.
That raises the question: How many bots can a roboport charge in the time the bot uses up that power?
viewtopic.php?p=428014#p428014
Also the whole discussion is interesting.
Koub - Please consider English is not my native language.

User avatar
BlueTemplar
Smart Inserter
Smart Inserter
Posts: 2420
Joined: Fri Jun 08, 2018 2:16 pm
Contact:

Re: Roboports

Post by BlueTemplar »

planetmaker wrote: ↑
Wed Jan 15, 2020 2:09 pm
Loewchen wrote: ↑
Wed Jan 15, 2020 3:12 am
Because those two values have as much to do with one another as the amount of toast I can fit in my home vs how much I can heat up at a time.
An now I wish a robot would deliver a steaming-fresh toast hawaii :( I like the comparison! :)
Well, at least they can already deliver drinks ! :D
BobDiggity (mod-scenario-pack)

User avatar
TruePikachu
Filter Inserter
Filter Inserter
Posts: 978
Joined: Sat Apr 09, 2016 8:39 pm
Contact:

Re: Roboports

Post by TruePikachu »

BlueTemplar wrote: ↑
Thu Jan 16, 2020 1:06 pm
planetmaker wrote: ↑
Wed Jan 15, 2020 2:09 pm
Loewchen wrote: ↑
Wed Jan 15, 2020 3:12 am
Because those two values have as much to do with one another as the amount of toast I can fit in my home vs how much I can heat up at a time.
An now I wish a robot would deliver a steaming-fresh toast hawaii :( I like the comparison! :)
Well, at least they can already deliver drinks ! :D
Nothing like a steaming hot barrel of sulfuric acid!

mrvn
Smart Inserter
Smart Inserter
Posts: 5686
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Roboports

Post by mrvn »

Honktown wrote: ↑
Thu Jan 16, 2020 12:23 pm
mrvn wrote: ↑
Thu Jan 16, 2020 11:56 am
That raises the question: How many bots can a roboport charge in the time the bot uses up that power?
Depends on speed, where it returns, etc. For even moderately sped up robots (like 100%) static cost becomes a rounding error, so at 5 kJ/"meter"? tile?:

Charging energy of a roboport is 1000kW (explicitly that). I don't see an explicit charge port count, but it has four charging offsets, which corresponds to four normal ports. It can charge at 5MW, so 4MW max deliverable is under that limit. 4/.005 = 800 meters per second. Base speed of construction bot is "0.06" (tiles per tick). Speed bonus before space science: 240% (from wiki). 800 / (60 * .06 * 2.4 * n) = n robots. 92.59 = n^2. 9.6 robots per second (is that right? it sounds reasonable, I didn't have /n the first time). Someone check my math.
Your math is wrong. At least the unit "robots per second". The result should be just "robots". I think also dropped in an extra "n" in the last part. Should be 800 m/s / (60 ticks/s * .06 m/tick * 2.4) = 92.59 robots. Notice how the meter, seconds and ticks all cancel out.

But 92.59 seems a bit high. I don't think a single roboport can sustain 92.59 construction bots placing stuff all around it.

There should also be 2 answers to the question:

1) number of robots that can be charged without running out of power (unstable, any disruption will move into the second case)
2) number of robots that can be charged when they have run out of power and are waiting at the worst possible spot

The difference here being the time it takes the bots to move up to the charging pad. That time between the waiting positions and the charging pad is lost to charging and needs to be factored in too. So number 1 is the best case scenario and unstable. Number 2 is the worst case scenario but could recover to case 1 with some idle time.

Honktown
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Roboports

Post by Honktown »

mrvn wrote: ↑
Mon Jan 20, 2020 10:55 am
Honktown wrote: ↑
Thu Jan 16, 2020 12:23 pm
mrvn wrote: ↑
Thu Jan 16, 2020 11:56 am
That raises the question: How many bots can a roboport charge in the time the bot uses up that power?
Depends on speed, where it returns, etc. For even moderately sped up robots (like 100%) static cost becomes a rounding error, so at 5 kJ/"meter"? tile?:

Charging energy of a roboport is 1000kW (explicitly that). I don't see an explicit charge port count, but it has four charging offsets, which corresponds to four normal ports. It can charge at 5MW, so 4MW max deliverable is under that limit. 4/.005 = 800 meters per second. Base speed of construction bot is "0.06" (tiles per tick). Speed bonus before space science: 240% (from wiki). 800 / (60 * .06 * 2.4 * n) = n robots. 92.59 = n^2. 9.6 robots per second (is that right? it sounds reasonable, I didn't have /n the first time). Someone check my math.
Your math is wrong. At least the unit "robots per second". The result should be just "robots". I think also dropped in an extra "n" in the last part. Should be 800 m/s / (60 ticks/s * .06 m/tick * 2.4) = 92.59 robots. Notice how the meter, seconds and ticks all cancel out.

But 92.59 seems a bit high. I don't think a single roboport can sustain 92.59 construction bots placing stuff all around it.

There should also be 2 answers to the question:

1) number of robots that can be charged without running out of power (unstable, any disruption will move into the second case)
2) number of robots that can be charged when they have run out of power and are waiting at the worst possible spot

The difference here being the time it takes the bots to move up to the charging pad. That time between the waiting positions and the charging pad is lost to charging and needs to be factored in too. So number 1 is the best case scenario and unstable. Number 2 is the worst case scenario but could recover to case 1 with some idle time.
Robots vs robots/sec just depends on whether or not we're counting time. I'd prefer a unit of robots/s because that's what we're looking for: max robots supportable* per second.

I originally got 90-whatever, but I felt it was far too high. I think there should be an "n-robots" term on both sides, since the robots chargeable per unit time is a dependent on the count of robots chargeable - a higher density means more energy consumed, curving down the amount we can support.

1v2 is a point, but if we're considering ALL factors, there's a minimum number of robots chargeable: moving things exactly at their round trip fast distance supported (most drain per trip/least time spent dilly-dallying) and the maximum: robots are going to a destination they can't reach, and are therefore taking the longest possible time to return to a roboport. I'd rather look for something at least approximately reasonable under general conditions - no slow travel, speed is high enough so that static cost is less than 5-10% total energy used, etc.

Edit: guess depends on how one looks at the problem. I'm thinking of "unit-of-work" kind of thinking. "n-per-roboport" is equally valid.
I have mods! I guess!
Link

mrvn
Smart Inserter
Smart Inserter
Posts: 5686
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Roboports

Post by mrvn »

Honktown wrote: ↑
Mon Jan 20, 2020 11:27 am
mrvn wrote: ↑
Mon Jan 20, 2020 10:55 am
Honktown wrote: ↑
Thu Jan 16, 2020 12:23 pm
mrvn wrote: ↑
Thu Jan 16, 2020 11:56 am
That raises the question: How many bots can a roboport charge in the time the bot uses up that power?
Depends on speed, where it returns, etc. For even moderately sped up robots (like 100%) static cost becomes a rounding error, so at 5 kJ/"meter"? tile?:

Charging energy of a roboport is 1000kW (explicitly that). I don't see an explicit charge port count, but it has four charging offsets, which corresponds to four normal ports. It can charge at 5MW, so 4MW max deliverable is under that limit. 4/.005 = 800 meters per second. Base speed of construction bot is "0.06" (tiles per tick). Speed bonus before space science: 240% (from wiki). 800 / (60 * .06 * 2.4 * n) = n robots. 92.59 = n^2. 9.6 robots per second (is that right? it sounds reasonable, I didn't have /n the first time). Someone check my math.
Your math is wrong. At least the unit "robots per second". The result should be just "robots". I think also dropped in an extra "n" in the last part. Should be 800 m/s / (60 ticks/s * .06 m/tick * 2.4) = 92.59 robots. Notice how the meter, seconds and ticks all cancel out.

But 92.59 seems a bit high. I don't think a single roboport can sustain 92.59 construction bots placing stuff all around it.

There should also be 2 answers to the question:

1) number of robots that can be charged without running out of power (unstable, any disruption will move into the second case)
2) number of robots that can be charged when they have run out of power and are waiting at the worst possible spot

The difference here being the time it takes the bots to move up to the charging pad. That time between the waiting positions and the charging pad is lost to charging and needs to be factored in too. So number 1 is the best case scenario and unstable. Number 2 is the worst case scenario but could recover to case 1 with some idle time.
Robots vs robots/sec just depends on whether or not we're counting time. I'd prefer a unit of robots/s because that's what we're looking for: max robots supportable* per second.

I originally got 90-whatever, but I felt it was far too high. I think there should be an "n-robots" term on both sides, since the robots chargeable per unit time is a dependent on the count of robots chargeable - a higher density means more energy consumed, curving down the amount we can support.

1v2 is a point, but if we're considering ALL factors, there's a minimum number of robots chargeable: moving things exactly at their round trip fast distance supported (most drain per trip/least time spent dilly-dallying) and the maximum: robots are going to a destination they can't reach, and are therefore taking the longest possible time to return to a roboport. I'd rather look for something at least approximately reasonable under general conditions - no slow travel, speed is high enough so that static cost is less than 5-10% total energy used, etc.

Edit: guess depends on how one looks at the problem. I'm thinking of "unit-of-work" kind of thinking. "n-per-roboport" is equally valid.
robots/s makes little sense. That's just the charging speed / time to charge. For that to be useful you then also need to know how often a bot needs to charge.

The question for me was: How many robots can you stage at a roboport without a queue building up?

Note: 1v2 isn't about bots running out of energy out in the wild. That happens too but then your roboports aren't planted dense enough. I ment the case that a robot has arrived at the roboport in the outer ring where bot wait to charge and runs out of energy right that tick. Even in that case I want no queue forming around the roboport (assuming bots arrive at a constant rate).

Honktown
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Roboports

Post by Honktown »

mrvn wrote: ↑
Mon Jan 20, 2020 12:55 pm
...
We may both have calculated wrong.

With 4 logistic robots being delivered 4 MW total, for no queue to form, the remaining robots can consume power at most at a rate of 4MW. With 5kJ/m as the consumption of logistic bots, and speed as S, the remaining bots supportable n, the equation would be is 4 MW = .005 MJ/(meter-robots) * ( S m/s) * n robots for logistic bots. For 240% speed and a base rate of 3 tiles (meters) per second, that's 4 = .005 * (2.4 * 3) * n., 4 = .036n, ~111 = n, for a total of 111+4 = 115 bots. For 240% bonus speed and a base rate of 3 tiles (meters) per second, that's 4 = .005 * (3.4 * 3) * n., 4 = .051n, ~78 = n, for a total of 78+4 = 82 bots. The general equation would be n = [800/(3 * (1 + percent speed bonus))] + 4. Does that sound right? Needs testing. At infinite speed, that goes to 4 bots supportable, which makes sense.
I have mods! I guess!
Link

Nemo4809
Long Handed Inserter
Long Handed Inserter
Posts: 94
Joined: Thu Jan 16, 2020 10:49 am
Contact:

Re: Roboports

Post by Nemo4809 »

Maybe the charging port count and charging in general is to limit the range of the bots.

You can have 350 construction bots and have it dismantle a 350 piece structure nigh instantly - although they all have to charge before returning into the roboport.

Transporting 350 items over long distances via logistic bots though would be very slow as they have to keep recharging along the way with only 4 ports per roboport.

Post Reply

Return to β€œGeneral discussion”