question

Patrick Zweekhorst avatar image
0 Likes"
Patrick Zweekhorst asked anthony.johnson answered

AGV orientation constraints on path crossings

Hi,

One of our customers has updated its model from 2022 update 2 to 2023 update 1 and the model is no longer working correctly. We have seen another post that seems to be about the same problem, but we are wondering if there is a different solution possible and what the best modeling ways are for modeling such models.
The post that seems to describe the same problem:
How to control the orientation of an AGV on rails in FlexSim 2023 - FlexSim Community

In the case of our customer there is a layout that more or less looks like this:
1689692218552.png

All the path transfers are transfers at path crossings where the AGV needs to stop and rotate 90 degrees. The idea is that an AGV drives forward into a spur path, drop/pick something, drive backward towards the main path and rotate such that it will drive forward again. The customer solved this in FlexSim 2022 Update 2 by adding AGV orientation constraints on the paths. That all worked correctly. However in FlexSim 2023 Update 1 this no longer seems to be an option. The solution given in the linked post mentions adding curves, but if you have a lot of paths, like shown above you don’t really want to do this. Next to the extra work this also changes the outcomes of the model. For the 90 degrees rotation time of the AGV we can define the rotation speed and the time it takes to make this curve.

Ideally we would like something of an option that lets the AGV drive forward after each 90 degrees curve, but not rotate 190 degrees on the spot. I know that Anthony already mentioned a possible option for this but I don’t know if this is something that is on the list to add to the AGV module or that there are other solutions for this. What Anthony mentioned:

“However, in hearing your description about why you need to use orientation constraints, I'm wondering if you really need that feature right now. Instead of a routing-based feature, we could just split the 'turnaround threshold' into two different values. From your description my impression was that generally the AMRs want to travel forward, but they can travel backward in some cases. If we split the turnaround threshold into a 'turn-to-backward' threshold and a 'turn-to-forward' threshold, then you can make the 'turn-to-forward' threshold smaller, say 89 degrees, and the 'turn-to-backward' threshold its normal 91 degrees. Here the AGV would prefer to travel forward, so if it hits a right-angle and it is traveling backward, since the right angle is more than 89 degrees, it will turn around and travel forward from that point. Using this feature, you wouldn't need to use orientation constraints at all.”

To explain the behavior that the customer is looking for in a small example:

1689692235339.png

The AGV drives forward over the red path onto the spur. Loads something, and drives backward over the yellow path. It then stops and rotates 90 such that it can drive forward again over the blue path. What would be the best options to model this?

Thanks,

Patrick

FlexSim 23.1.3
agvorientationpath crossing
1689692218552.png (8.7 KiB)
1689692235339.png (15.8 KiB)
· 4
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Patrick Zweekhorst avatar image Patrick Zweekhorst commented ·
Hi @Jordan Johnson,

Do you know if there are any good solutions for this, or if anyone can take a look at this?

0 Likes 0 ·
Jordan Johnson avatar image Jordan Johnson ♦♦ Patrick Zweekhorst commented ·
I can see in our issue tracker that this issue is slated for review/discussion. When we decide on a course of action, I'll be sure to update you here.
1 Like 1 ·
Jason Lightfoot avatar image Jason Lightfoot ♦♦ Patrick Zweekhorst commented ·
This issue is already being looked at for another question and I believe your question has been added to the case, so we anticipate an update from the development team at some point.
0 Likes 0 ·
Patrick Zweekhorst avatar image Patrick Zweekhorst Jason Lightfoot ♦♦ commented ·
Thanks Jason, We are curious for the update when one is found
0 Likes 0 ·

1 Answer

anthony.johnson avatar image
1 Like"
anthony.johnson answered

Patrick,

I just pushed a commit, which will go into the 23.2 release that fixes this issue, depending on whether you have configured your model correctly. Specifically, if in your model you have configured your AGVs to be able to stop and rotate in place (the stop and rotate threshold is less than 180), then this should fix issues that you might have. However, if your AGVs cannot rotate in place, then you should not place paths in the model that require AGVs to rotate in place. I think the other post may be a model where this is the case, and the 'change' in behavior was actually a bug fix that we made for you.

My more verbose comments from the commit:

The users were incorrect in their expectations of the AGV behavior previously, and they were simply lucky that it worked the way it did. The changes that 'break' backwards compatibility were actually changes that fixed issues in properly simulating AGV orientation, and they were specifically made in relation to models that Patrick was having issues with.

If the user defines the stop-and-rotate threshold as greater than or equal to 180 degrees, then it is assumed that the AGV cannot turn on a dime. As such, based on the starting orientation of the AGV and the two reverse direction thresholds, the orientation of the AGV is essentially pre-determined based on the geometry of the path that it takes, i.e. it is not negotiable, and if this pre-determined orientation results in the AGV getting on a path in an orientation that is not admissible based on the user defining orientation constraints on the path, then the AGV system will print a 'cannot find path to destination' error. The newly appearing error message in 23.0 was essentially the result of bug fixes in the routing algorithm, and brought the behavior in line with how it was designed. If the user wants to get rid of these errors in a model where AGVs cannot turn on a dime, then the user should not put paths into the model that require AGVs to turn on a dime, e.g. grids with right-angle turns.

However, this change fixes issues that arise when the user has defined a stop-and-rotate threshold less than 180, i.e. when the AGVs are able to turn on a dime. First, in the routing algorithm it expands from a transfer using both agv orientations. In other words, since the AGV can turn ona dime, it could technically get to the transfer from any orientation and then proceed forward from the transfer in the given (resolved) orientation.

Second, as part of buildTravelPath(), if the normal direction reversal rules result in the AGV getting on the path in an orientation that breaks a path's orientation constraint, and the AGV can turn on a dime, then it should switch its orientation as part of that transfer.


And finally, from the user manual:

If your AGVs can turn 'on a dime', as many modern Autonomous Mobile Robots (AMRs) can do, then this value should be less than 180. Otherwise you should leave this value at 180 degrees, and define paths that do not require in-place turning.


· 1
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Patrick Zweekhorst avatar image Patrick Zweekhorst commented ·
@anthony.johnson, thank you very much for explaining this. Now that 23.2 is out I will also play with this a little bit. Your help with the other model with the grid AMRs was also very helpful, that model is giving is lots of insights and the AMRs are running pretty realistic. Thanks
0 Likes 0 ·