Collision Avoidance and Traffic Jams

[kevin_f2]

Hi all - I'm using collision avoidance (17.2.2) on people in a warehouse situation. I get a lot of traffic jams in the isles unless I select "ignore Inactive Members". How do I get the model to have the avatars back up / move aside (if room) / find alternate routs rather than just waiting for the simulation to end?

If there is no easy way to do that, how do I reduce the space needed by the traveling object (person)?

[SCHamoen]

This is a bump. @phil.bobo, @anthony.johnson

I have created warehouse models in the past with networks and intelligence on it to let pickers with electric pallet trucks pass each other when they where busy picking and the EPT's where parked. So I tried to model it with A* in version 18.1.1 and attached the model, but the operator getting the order is stuck behind the other operator and so the model blocks.

Is there already a way to solve this?

Or is a solution planned for one of the next releases?

Or is it not on the roadmap?

I would guess that the base functionality is already in A* (you are driving around racks etc..)

It would make warehouse models so much easier!!

Model attempt:exampleastar.fsm

[anthony_johnsonT83CM · Accepted solution]

The simplest solution here, as you said, is to check the Ignore Inactive Members box. If your desire is to get the active members to travel around the inactive members, I guess I disagree with your desire. That generally would not be a desired solution. When a truck is idle, other trucks should not move around him. He should get out of the way. So you should have some logic, likely through process flow, to tell a transporter to go somewhere when he's not doing anything, so that he doesn't get in other people's way when he's not doing anything. This is the solution that would be true to real life. As for trucks that are actively loading/unloading, I would think you'd probably have a passing lane in the center of the aisle, and trucks mainly stay in the passing lane, then veer off the center lane to load/unload. You can do this by having a preferred path in the center of the aisle. Trucks will get on that preferred path when they're traveling, and get off it when they're loading/unloading.

If neither of these solutions work for you, then you can also have a process flow that listens to the Transporter's OnAStarBlock event, and then reroute the guy around the blockage as you desire. When we implemented collision avoidance, we decided that any canned "get out of the way" mechanism for simple blockages would likely only work in a small percentage of scenarios, because different scenarios would likely have different means for avoiding blockage. So we just provided the OnAStarBlock and OnAStarContinue events, and just let you roll your own.

There is functionality under the hood where you can create temporary barriers before performing routing. Perhaps we may expose this functionality to FlexScript so that the user can create temporary barriers before dispatching the transporter. However, I don't foresee us implementing much canned functionality any time soon. There are just too many scenarios where canned functionality falls apart.

[SCHamoen]

@anthony.johnson Thanks for the extensive explanation, but I disagree with the fact that driving around an inactive member is a non desirable solution. The situation that you have a lot in warehousing (and where the original poster also pointed to I guess) is where there are multiple pickers in a warehouse (all aisles are 1 way). The picker has a cart or a rack or an EPT and he stops at a rack or storage position to execute his pick. The guy behind him only stops if he has to be at the same rack and has to wait till the position comes free. In all other situations he will drive around the guy and continue his picking.

I mostly agree with your "canned" get out of the way comments, but isn't this mostly based on 2 moving taskexecuters? If a taskexecuter is standing still, what is so different between him and any other fixed resource?

Thanks for pointing out the extra events that can be handled. I'll take a look at those. Temporary barriers might be nice also but then again, what is the difference between those and a taskexecuter standing still? But maybe I overlook something so tell me and I'll stop asking 😉

[anthony_johnsonT83CM]

The problem is that it is quite often more than 2 moving task executers that might be involved. Yes, dealing with just two TE's isn't too difficult. If TE1 is blocking TE2, you could say, well, if TE1 is idle, he should move out of the way of TE2 (but which way?), but if he's loading/unloading then TE2 should reroute around. However, if TE1 is loading/unloading and is already in the location where TE2 needs to go, then TE2 should not reroute, because no matter where he reroutes, he won't be able to get to the location. Sure, that's fine, but what if both TE1 and TE2 are trying to get to Location A, which currently TE0 is on. So when TE1 gets blocked by TE0, according to that logic he says hey TE0 is in the spot where I need to be, so I stay where I am and wait for him to clear. Then TE2 comes along and gets blocked by TE1. TE1 is not currently at the location where TE2 needs to go, so, according to that logic, TE2 needs to route around. But there's no "route around" logic that will get him to his location, because TE0 is already there. In real life, TE2 would see the queue and just get in line, which is what the current logic does automatically. And this chain of waiting could continue infinitely. So, do you wait for a certain amount of time, and then reroute? If you reroute and you still can't get all the way to your destination, is there some "closer" threshold that you say, ok that's good enough, go ahead and reroute even though I can't get all the way there? Or if you're far enough away from your destination do you go ahead and reroute because by the time you get there maybe the location you're trying to get to will have cleared out?

The decision tree of what to do in these situations is just too complicated for us to say that one size will fit all.