AGV module, racks, and offset travel

I am working on a warehouse model where I would like to use racks and AGV's for storing and picking parts. Visually, I would like the AGV to go to the proper bay of the rack and place the object in the proper level. I thought I could do this with offset travel, but it seems like AGV's are not designed to work with offset travel? Whenever I connect a transporter to an AGV network and tell it to use offset travel. It will revert back to not using offset travel when I reset the model. This isn't happening if I disconnect the transporter from the AGV network though. Can anyone confirm that the AGV module is not compatible with offset travel and suggest any ideas on alternative ways to get my visuals to work the way I want? I have 2 ideas I am toying around with now.

1. Pickup/dropoff control points for each bay in the rack. This seems like it might be hard to manage because I have several hundred rack locations in the model I am making.

2. Create the offset travel myself by having destination control points at each end of the rack such that whenever an AGV arrives it receives a new task sequence to travel to the exact rack location it should go to. I'm leaning toward this approach.

Hello Ryan,

as you may have noticed the parameter travel offset for load and unload task is set always in the properties of the taskexecuter to "do not travel offset for load and unload tasks" when you reset your model. The tasks pick- or place offset are working only when the taskexecuter uses the offset travel. Perhaps someone from the development can tell us, if the agv module is intended to to be used on every object of the taskexecuter class or if it is a specialized version for a railway system.

Jörg

Jörg, yes what you described is what I am seeing. If I set the transporter to "travel offsets for load/unload tasks" while it is connected to an AGV network it will change back to "do not travel offsets for load/unload tasks" when I reset the model.

However, there is another option on the picklist that I overlooked before called "use navigator for offset travel". If I use this option in the transporter it does not get changed on model reset, but I get an error saying there is no path to the destination when the transporter attempts to do the offset travel. So the question still remains is offset travel compatible with AGV's?

I attached a sample model where I set the transporter to "use navigator for offset travel" so you can see the error.

Ryan,
You can't do offset travel using the AGV module. That's something I'd like to put in eventually, but right now it's not available.
Regards,
Anthony Johnson

Thanks for confirming that, Anthony.

I did some more reading/testing and found that offset travel does work with the Network Nodes that are in the base library. I thought I had read somewhere (can't remember where) that the AGV module was developed to replace Network Nodes similar to how the Conveyor module is meant to replace the conveyor objects in the base library. Am I wrong in thinking that? Just wondering if I should consider using Network Nodes in this model rather than the AGV module.

Ryan,
The AGV module is meant to replace the network node system in some cases. However, with cases such as offset travel, the AGV system is "not there yet", and in some cases I think the AGV system could be overkill. For example, if you want to simulate human-driven fork trucks moving around a warehouse, the high-precision simulation of the AGV's could be "too precise" to properly represent human decisions. Given these reasons, we have left the network node system in as the default. At some point that may change, but for now that's the way it is. We will likely put offset travel into the AGV network, but even when we do, AGV's will still be forced to stay "on the path". Offset travel will just be a way to dynamically determine a distance along the path to go to. This means that even when we put this in, the network path system may still be a better option in some scenarios, specifically because the network path system allows offset travel to go anywhere, truly off the network. That type of functionality might better represent human-like decisions in some scenarios.

If we continue forward with two network-based travel options, then we'll definitely need to have some document or documents that help people figure out these questions, and highlights the differences between the two options, so we can make the decision of which system to use easier.

Honestly, I'm open to suggestions on what others think of this strategy.
Regards,
Anthony Johnson