I am now trying to use A* to simulate KIVA. But when agv loading or unloading queue, it usually do not move to right under the queue in Z direction. Is there any way to fix this? Thank you.
You've added the queues as barriers to the A* grid, so the AGVs can't drive under the queues. When you A-connect an object to the A* navigator, that object becomes a barrier. Just disconnect the queues with a Q-connect, and they will no longer be barriers, allowing the AGVs to drive under them.
thank you so much Anthony. I have another question, the agvs sometimes interference with each during running. Is there any method to avoid this phenomena by using A Star?
I have attached the model as following. I open the trigger Collision Avoidance, but the agvs interference with each other after model running for some minutes.
First, the collision avoidance mechanism works through allocations of grid points. An AGV will allocate a single path to its destination, and will perform collision avoidance only when it tries to allocate a grid point that is already allocated by another AGV. It does NOT do proximity-based collision avoidance. This means that your grid's node spacing must be at least the size of your AGVs, or else the AGVs will run into each other.
Second, we do not pretend that the A* collision avoidance system is sophisticated to any significant degree. When an AGV is blocked by another AGV, it simply waits until the AGV clears its path, and continues on. If there is a circular wait, then one of the AGVs will "get out of the way" one grid space, then continue on. That's it. Kiva, on the other hand, likely has whole teams of engineers who have spent years implementing and honing their collision avoidance logic. We have not, and do not plan to, implement a system to their level of sophistication. If you think you can do that, then feel free to try. You can listen to events on the AGV such as OnAStarBlock, use the A* FlexScript API to analyze the AGV's travel path, allocations, preempt the AGV and send him on a different route, etc.
That said, what I would really suggest is to make some simplifying assumptions that give a Kiva-like result, but avoid any complicated collision logic. On the other hand, if you really need to simulate to the level that Kiva is running their systems, then you should instead be communicating with the Kiva system, using their routing/avoidance algorithms, etc.
13 People are following this question.
