Barrier specific condition on barriers in A* navigator

Question

question

Patrick Zweekhorst asked Jun 22, '20 anthony.johnson edited Jun 25, '20

Barrier specific condition on barriers in A* navigator

Hi,

We are wondering if it is possible to know on which barrier a rule is triggered when using conditional barriers in A*. Attached is an example model that shows a situation we want to model. When there is an item in queue3 or queue4 the entrance next to that queue should not be available for the operator. In that case the operator should walk around the barriers to one of the other queues.

We wanted to solve this with some conditions on barriers. The problem we have there is that if we assign a rule to a barrier, we don’t know on which barrier that rule is. When you look at the code of the rule the only object that is available is the traveler (as param(1)).

As we understand it this would mean that we need a rule for the barrier located next to queue3 and an extra rule for the barrier (which is not in the model) located next to queue4. This is fine in this example model, but in the actual model there are many more of these locations. It does feel really strange if we need to add a separate rule for each single barrier.

The code in the rule fires once for each barrier that has that rule, so we assume it is known somewhere for which barrier this code is executed. Is this information also available in FlexSim? If we would know the barrier on which the current rule code is executed we would be fine (like Object barrier = param( 2) or something).

If that information is not there, how should we solve such a problem in general?

Thank you for any tips on this.

Barrier_1.fsm

Software Version:

FlexSim 20.1.3

flexsim 20.1.3 a star navigation barriers condition rule

1592812649888.png (46.2 KiB)

1592812668682.png (13.4 KiB)

barrier-1.fsm (46.5 KiB)

· 2

Joerg Vogel commented · Jun 22, 2020 at 08:20 AM

Have you tried to evaluate param(2), param(3) and so on. Sometimes there are not-documented parameters available. We call this in German “ein Schuss ins Blaue“.

0 ·

Patrick Zweekhorst Joerg Vogel commented · Jun 22, 2020 at 08:29 AM

Hi @Jörg Vogel

Yes we tried that already and it all returned NULL . Thanks for the tip anyway

0 ·

Answer 1 · 2020-06-25T16:02:42Z

anthony.johnson answered Jun 25, '20 anthony.johnson edited Jun 25, '20

Unfortunately the best option for you is to create one barrier condition per entrance rule. The reason it must be done this way is so that caching paths can work properly in all scenarios. While, in your model, the barrier condition is evaluated for each barrier, if you were to check the "Cache Paths" box, it would change the code path such that barrier conditions are no longer evaluated per barrier. Instead, when path caching is enabled, each barrier condition is evaluated before routing, and a lookup is made into a stored cache map whose key includes the state of all barrier conditions. This is so that the routing solutions from the same source to the same destination can store different paths depending on which barrier conditions are true. This is why the only parameter available to the barrier condition code is the traveler itself.

Answer 2 · 2020-06-22T17:08:35Z

tannerp answered Jun 22, '20 Patrick Zweekhorst commented Jun 23, '20

@Patrick Zweekhorst,

Unfortunately, because there aren't other parameters passed into the header for that code, all we have to work with is the traveler object. You might be able to access the traveler's task sequence and identify the queue he is traveling to that way, but I couldn't figure out a way to get that to work.

I tried creating a solution with Network Nodes, but it proved to be even more tedious (in my opinion) than adding conditions for each barrier. You could try streamlining this method with Process Flow that listens to groups of NNs, but it still might be a pain.

I think the method you have developed is the best one for this behavior, although I recognize that it's going to take a large amount of custom code to work. For what it's worth, here's my attempt with NNs: barrier-1_1.fsm

I used Custom Code with the "contextdragconnection" and "optimizenetwork" functions.

· 3

Patrick Zweekhorst commented · Jun 23, 2020 at 12:57 PM

Hi @tanner.p,

Thank you for trying to find a solution (I am just not able to download your attachment, it gives an error). As you describe using network nodes could also be a solution, but will require quite some work. So we do want to keep using A*. Using the network nodes can become quite complicated (as you already noticed I guess)

Would it be an option to extend the code headers of the rules on the barrier? The rule is called for each barrier that is using the rule, so I assume this information is there (probably somewhere in c++). Getting the actual barrier as second parameter would increase to possibilities quite a lot for the rules. Maybe this is something for the dev list?

@Matthew Gillespie, I noted that you also answered another question regarding conditions on barriers, do you maybe have another idea for this problem or should we go ahead with separate rules for each barrier as Tanner and I described above?

Thanks for all the help

0 ·

tannerp Patrick Zweekhorst commented · Jun 23, 2020 at 02:37 PM

@Patrick Zweekhorst,

For what it's worth, I'm attaching my model that makes use of Network Nodes again if you'd like to see it. Hopefully it works. Sorry about the errors - our Answers hub hasn't been playing nice with attachments lately.

barrier-1_1.fsm

0 ·

barrier-1-1.fsm (52.1 KiB)

Patrick Zweekhorst tannerp commented · Jun 23, 2020 at 02:53 PM

I was able to download it now. You did make a nice example, but as you say using many rules might still be more easy

1 ·

question