Roboport/Logistic Network/Robot Enhancements/Robot Routing/Charging

This are only lists of links to other suggestions!
Search, if your idea has been already suggested.
Post Reply
User avatar
Global Moderator
Global Moderator
Posts: 10638
Joined: Tue Apr 16, 2013 10:35 pm

Roboport/Logistic Network/Robot Enhancements/Robot Routing/Charging

Post by ssilk » Sun Nov 29, 2015 12:40 am

Related Logistic Suggestions

I moved the whole logistic network/chest extensions to viewtopic.php?f=80&t=43460 Logistic Network and Logistic Chest Extensions

These suggestions are a little bit "mixed up", cause there is not really a clear line between roboports, roboport-area, logistic-network (and -area) and the robots in that both areas. I'm sorry for that, but it is a game-mechanic, which is very entangled (and it is good so).

First some explanations:
- There is a logistic network, a logistic area, a construction network and a construction area. Logistic bots can work only in a logistic area, construction bots can work only in the construction area.
- All connected roboports built a (logistic or consruction)-network.

Provide and catch back robots into and from a logistic network:
- With v0.12 you can place an inserter to fill in bots into a roboport. Use the robot-combinator-mod (see below), to find out, how many are really needed.
- With v0.12 you also grab bots out of a roboport with an inserter.
- With v0.12 you are not able to order some number of bots to roboports to take the robots out of the network.
- With v0.13 we will be able to connect the circuit network to the logistic network and get robot-count and other info from there. See FFF #123.

(Suggestion: Enable the player to order robots to a roboport, like a requester chest. That enables you to take them slowly out of the network. Same seems to be simple for repair packs. In the end it is nearly the same game mechanics as in Siedler II, where you order knights, swords etc. into towers.)

General suggestions about roboports (mixup)
viewtopic.php?f=6&t=1633 Logistic bot control tower [Very old, still interesting]
viewtopic.php?f=6&t=3202 Some ideas to change Bots mechanic
(and answer: viewtopic.php?f=6&t=3202&hilit=roboport+charge#p23536 - see also down to Robocharge-mod)
viewtopic.php?f=6&t=3551 Custom UI notifications from logistic network conditions
viewtopic.php?f=6&t=4605 logistic questions
viewtopic.php?f=6&t=5348 Bigger, smaller roboports and interstation
viewtopic.php?f=68&t=5748 reassign pending construction robots with cargo
viewtopic.php?f=6&t=6981 Ordering docked bots
viewtopic.php?f=6&t=7993 Splitting up roboport functions
viewtopic.php?f=6&t=8214 "Logistic network"-independent robot recharging
viewtopic.php?f=6&t=13457 Multiple Roboport/Blueprint suggestions
viewtopic.php?f=6&t=14568 Modules for the Roboport
viewtopic.php?f=6&t=25365 Two robo suggestions! [change logistic area size]
viewtopic.php?f=6&t=28985 Allow roboports to snap to logistics net when holding shift
viewtopic.php?f=6&t=34171 filter for roboport content
viewtopic.php?f=6&t=35401 Roboport ideas
viewtopic.php?f=6&t=35516 Multi-purpose (smart) logistic chest
viewtopic.php?f=6&t=37484 Builder Bots

Handling of the Number of Bots in a Network
viewtopic.php?f=6&t=4723 Power and the robots
viewtopic.php?f=6&t=4996 Smarter Robot charging
viewtopic.php?f=6&t=3850 Roboports may request bots
viewtopic.php?f=6&t=5749 Logistic bot network usage statistics [See robotic combinator mod below]
viewtopic.php?f=6&t=8925 Distribution of robots
viewtopic.php?f=6&t=10152 Controlling robot distribution
viewtopic.php?f=6&t=14083 Robot Dropoff
viewtopic.php?f=6&t=18996 Add support for adding and removing robots from network
viewtopic.php?f=6&t=28176 Control Number of Bots in Roboport/RP Content To Circuts
viewtopic.php?f=6&t=41099 Roboport Robot filter
viewtopic.php?f=66&t=45318 Filter in roboports
viewtopic.php?f=6&t=47144 Add auto lauch and request robots ability to roboport

Handling of Robot-Routing / Pathing / Charging

This sub-topic is about problems, when the robot-area is not in a circle shape, but hase more the shape of an "U", well described with this pics.
The general opinion of this forum is currently, that there is not much, that could be improved here by more intelligent routing, cause that means, that the robots need to take a lot more CPU cycles, to calculate that path. Current behavior looks non-optimal, but is not that bad, as it looks (only for the case of U-shaped base, but that should just be avoided or you live with the problems they create. :)
36vs1x.png (12.39 KiB) Viewed 6021 times
4aiuom.png (20.67 KiB) Viewed 6021 times
technjshv.png (6.65 KiB) Viewed 6021 times
viewtopic.php?f=6&t=3283 Logistic bot pathing improvement
viewtopic.php?f=6&t=12859 Bot Exclusion Zones
viewtopic.php?f=6&t=18082 Let all bots use the personal roboport to charge.
viewtopic.php?f=6&t=23021 Node based pathing for bots
viewtopic.php?f=6&t=21781 Stack size bonus for construction robots
viewtopic.php?f=6&t=26702 Logistics bots should cancel job when request is canceled
viewtopic.php?f=6&t=28325 Roboport option to output construction needs
viewtopic.php?f=6&t=28614 Bot pathing for big bases
viewtopic.php?f=6&t=37761 Roboport waypoint setting
viewtopic.php?f=6&t=38036 Make all bots stay inside their network
viewtopic.php?f=6&t=41361 Construction chests
viewtopic.php?f=6&t=41428 Optimize Drone Movement [explains, why this is not such a good idea]
viewtopic.php?f=6&t=42214 Droids Pathfinding
viewtopic.php?f=6&t=48183 Worker Robots Pathfinding Update (!Important)

An interesting statement from a dev:
viewtopic.php?f=11&t=15234&p=103165&hil ... rt#p103529


The Right Pane / Logistic Info

This will be changed in V 0.15. See FFF #180.

viewtopic.php?f=80&t=17779 Detach Logistic Item Listing From Right Pane [Link Collection Thread]
( viewtopic.php?f=6&t=2583 Logistic network, Storage Infoscreen
viewtopic.php?f=6&t=1222 Logistic overview on the right side
viewtopic.php?f=6&t=4706 Logistics Statistics Screen
viewtopic.php?f=6&t=9957 Logistic System Informational Window
viewtopic.php?f=6&t=13393 Interface For Logistics Storage )


viewtopic.php?f=6&t=3768 Prioritize Ghost buildings and blueprint construction
viewtopic.php?f=6&t=3868 Player logistic slot improvements
viewtopic.php?f=6&t=22711 Use of a key combination to force personal or base robots to build / deconstruct.

viewtopic.php?f=16&t=15109 Build time 0.5s for Logistics/Construction Robots

Defaults for Requesting Items
viewtopic.php?f=67&t=9069 Requester chests should default to zero or one
viewtopic.php?f=6&t=26731 Initial amount of items delivered by logistic system

viewtopic.php?f=120&t=14650 Robocharge - Robot Charging Station
viewtopic.php?f=92&t=14388 Advanced Logistics System 0.2.10

Related Logistic Suggestions

I moved the whole logistic network/chest extensions to viewtopic.php?f=80&t=43460 Logistic Network and Logistic Chest Extensions

Other related collections

viewtopic.php?f=6&t=2563 Trains as linkers between seperated logistic networks
viewtopic.php?f=80&t=15326 Stack Filters for Chest, Vehicles and others
viewtopic.php?f=80&t=19987 More Game Information (Statistics, Monitoring, Graphs)
viewtopic.php?f=80&t=18093 Roboport/Logistic Network/Robot Enhancements/Robot Routing/Charging
Last edited by ssilk on Thu Aug 10, 2017 1:47 pm, edited 47 times in total.
Reason: Added last line in Blueprinting.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

Burner Inserter
Burner Inserter
Posts: 5
Joined: Tue Oct 04, 2016 4:14 pm

Re: Roboport/Logistic Network/Robot enhancements

Post by wolfmanrawrs » Tue Oct 04, 2016 5:33 pm

There is an idea for this I didn't see. Giving construction robots a build order / priority:
1 - Deconstruction
2 - Power routing(Poles, Substations, etc)
3 - Roboports
4 - Power generation(Solar panels, accumulators, steam engines and set up parts)
5 - Defenses(Walls, Gates, Turrets)
6 - Other Structures (Assemblers, tanks, etc)
7 - Modules
8 - All other(Flooring, Landfill, etc)

Posts: 28
Joined: Fri Nov 28, 2014 4:20 pm

Re: Roboport/Logistic Network/Robot enhancements

Post by nyspace1 » Sun Feb 19, 2017 9:09 am

an idea that I came up with on this topic, please reply

I would love to be able to reserve logistic robots for a requester chest or an active provider chest. What I mean is, I want to be able to specify an amount of logistic robots to only the task of filling or taking objects from the specific chest. Robots would be reserved for the chest when they bring or take an item from it up to the specific amount, if reachable. When the robot count is lowered, the robots would become unreserved until the new lower amount is reached. If the amount is raised, more robots would become reserved until the new higher amount is achieved, if reachable.

User avatar
Global Moderator
Global Moderator
Posts: 10638
Joined: Tue Apr 16, 2013 10:35 pm

Re: Roboport/Logistic Network/Robot enhancements

Post by ssilk » Sun Feb 19, 2017 4:02 pm

Yes, see for example: viewtopic.php?f=6&t=41099 Roboport Robot filter, which is the latest example for such a suggestion.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

Burner Inserter
Burner Inserter
Posts: 9
Joined: Sat May 25, 2019 2:19 am

Re: Roboport/Logistic Network/Robot Enhancements/Robot Routing/Charging

Post by Bonaducci » Sun Jun 02, 2019 10:50 pm

I don't want to create whole separate thread yet I did not see exactly proposition I think of.

Whole idea is not to make robots too smart (like trains require proper signals to work) and yet provide good functionality (if signals are good, routes and behavior of trains is great). We should also take computing power into consideration as robots are counted in thousands.

The biggest problem I found is that robots don't even consider their battery lifetime and they try to fly way further than they can. In real life any algorithm should consider recharges. My proposition is simple and would fix most of problems. Of course it does not fix flying over enemy territory but would improve that as well.

Currently robots just fly out to destination and go to nearest station if battery is drained. Change I propose is to plan charges ahead. I'd list all steps needed for that but there is actually one new step. Depending on current implementation it could even improve performance of huge logistic networks.
Logical side:
1. Destination is in reach?
true - fly there
no - fly to reachable roboport that is closest to destination
2. When you reach this roboport go to 1. Either go straight to destination or get next reachable roboport that is in range.

Algorithm side:
I don't know how it is implemented right now, so it's hard to tell. Surely you have some collection of roboports as you need to know which one is closest to robot for charging or docking. Maybe you mapped roboports to tiles so at each position you know roboports in range. I don't know.
One way of implementing that would be keeping list of roboports in range of each roboport. That would not scale good with good networks but would have best performance. This way even with huge networks you have just a bunch of roboports in radius of constant flight of fully charged robots. Those are roboports you can reach without recharging. Now if distance to destination is higher than robot range, you have this bunch of roboports that are in range. Just check which one is closest to destination and fly there. Don't even plan how you will fly afterwards. Check that when you are charging. This way not matter how long flight it would be, you have the same number of processing to do.

Possible problem of this solution would be getting stuck at one roboport when your network requires flying back and around. Just like some penisula which has closest roboport to other side or sea but is still too far away. In this case your starting roboport would be the closest one. You can simply go back to old mechanism when this happens. Fly straight to destination and at some point you will either reach it or stop for charging somewhere going back to new mechanism.

Other solution would require planning whole route ahead but it has some problems. Route may change (new roboports or some removed during flight). It would also add some processing for each long flight. I think limiting to closest roboport would be optimal idea.

Now comparing it with the case from images above. Let's assume basic robot with 3m/s. It holds 1,5MJ, uses 3kJ/s (hence 1kJ/m) and 5kJ/m travelled. Sum it up and you have 6kJ/m on full speed and 250m range on full charge. Maximum distance between stations diagonally would be around 70m so it should be able to through 2 stations at least before charging at 3rd.

Let's visualize it on the same example as above images.

Simple case.
1. Take closest to Z roboport within flight range.
2. Z is in range.

The same with smaller flight range.
1. Take closest to Z roboport within flight range.
2. Take closest to Z roboport within flight range.
3. Z is in range.

Now the problem I mentioned.

Original implementation:
1. Go straingt to Z.
2. No energy, slowly go to closest roboport to charge.
3. Go straingt to Z.
4. No energy, slowly go to closest roboport to charge.
5. Go straingt to Z.
6. No energy, slowly go to closest roboport to charge.
7. Go straingt to Z.

Proposed solution with simplest fallback mechanics (if Z is not in destination and yet we are in closest roboport, fly there anyways).
1. Take closest to Z roboport within flight range.
2. Take closest to Z roboport within flight range.
3. Take closest to Z roboport within flight range.
4. Fallback, fly straight to Z.
5. No energy, slowly go to closest roboport to charge.
6. Z is in range.

Extended fallback that extends search radius to find closest roboport that would also be closer to Z than current one.
1. Take closest to Z roboport within flight range.
2. Take closest to Z roboport within flight range.
3. Take closest to Z roboport within flight range.
4. Fallback, take closest roboport that is also closer to Z than current one.
5. Z is in range.

As I mentioned, it would also be possible to plan whole path ahead but it would be much more complicated. Then it would take route around the water instead. I think my proposal is sufficient, it greatly reduces robot stupidity and is still fairly simple.

Also I mentioned that it will not fix problem with flying over enemy territory but it actually might improve that behavior. This way robots will try to stay within fast flight range from roboports, so they would not try to fly directly through unknown territory. Instead they would jump along the route.

Why this solution seems most reasonable to me?
- Despite more calculations for robot routing, it is limited only to first "jump" robot makes. Currently each time battery dies algorithm has to find closest roboport to robot coordinates. This solution removes that need and instead each time requires finding closest roboport to Z that is in range. To make it less CPU hungry rach roboport could keep some list of ports in range limiting how much checks will be done. Such list will also be pretty easy to handle. If you create new roboport, list all ports in range. One time action. Of course each roboport in range will have this one in range as well, so add them to their list. While removing (disabling) roboport you already have a list of those in range, so just follow it and "unsubscribe". The point is that it should have similar performance to current one regarding robots behavior and would only add some performance loss for creating and removing roboports. Also memory usage should not be that bad unless you have hundreds of thousands of roboports.
- Compared to solution showed by @ssilk it does not stop at each roboport on the route. Just when it's needed.
- It surely depends on implementation but it should be fairly simple to implement, so less risk of introducing new bugs. If currently each robot holds one target, then it would have to hold final destination as well as current target, so it could update route after charging. Despite that only collection of roboports in range and logic behind it would be necessary.

Moreover for charge balancing you can use variation of current mechanism.
Currently it considers distance from robot to closest roboports and queue for charging with some ratio of queue size vs additional distance to charge.
In my proposal you can use almost the same mechanism. If choosen roboport for charging has queue over X, then consider next one that is a bit further from destination. This way in case 100 robots fly on the same route from one container to another, they would split into several groups charging at different ports, even taking different routes. After first charge they will not be one single pack but several smaller ones which will be easier to charge. It's necessary to see such thing in action to tell if it works as expected.

Burner Inserter
Burner Inserter
Posts: 11
Joined: Thu Sep 26, 2019 8:42 pm

Re: Roboport/Logistic Network/Robot Enhancements/Robot Routing/Charging

Post by RadioDoc » Sun Oct 13, 2019 2:07 pm

So I was thinking about the routing issue, and it dawned on me that a simpler way to approach it might be to use something similar to what's already in place for the train pathfinding.

If you have each logistic network defined as a Zone, then you path Zone center to Zone center until you hit the target Zone, then go to destination chest.

When you place a logistic chest, it should gain an identifier something like [A.1] - it's chest 1 in Zone A. In the case of overlapping networks, the zone designation goes to whichever Roboport is closer.

So let's look at an actual network here:
So right now, I have a logistics bot flying direct from D.3 to F.1. Sure it's quick until we get into the situation of the bot being out of juice and needing to detour for a recharge. Now, yes, this is all in nice and close together, but the principle here should be the same. The bot should be looking at the path along the connection lines already established - D.3 > D > C > E > F > F.1 - instead of flying direct from D.3 > F.1.

If we want to take it a step further, set a toggle in each Roboport to define bot behavior in that zone - direct or point-to-point. If I set direct, then I should be seeing the behavior I'm seeing now. If I set point-to-point, any zone transition causes the bot to travel to the zone center before going to the next waypoint. For adjacent zones with different properties, the bot adheres to the new zone's rules. For example, let's say A, B & F are set direct, C & E are set point-to-point. A bot traveling from A to F will cross into zone C, so it will go from A to the center of C, then to E, then to the destination in F.

This is just my two cents, but I think that will greatly help us reign in the insanity we see with the bot networks and also give us some ability to streamline operations. But really, we just want to get away from this:
I know what two points led the bot to be out there, but come on...

Post Reply

Return to “Frequently Suggested / Link Collections”

Who is online

Users browsing this forum: No registered users