Free space navigation | AnyLogic Help

Manual movement

When moving in free space mode, transporters detect their surroundings and avoid obstacles using the most efficient route to reach the destination point.

Walls, nodes with restricted access, and transporters with the same navigation type are always recognized as obstacles. If needed, you can also specify most of the space markup shapes specific to Material Handling Library (such as conveyors, cranes, lifts, and so on), pallet racks, and storages as obstacles by selecting the Is obstacle option in their properties.

When calculating the space where the free space navigation is available, the engine includes all elements that can affect the transporter’s route within this space. Then, the engine expands the resulting free space within the certain boundaries. However, this space is restricted, and placing destination points outside the calculated boundaries may result in a runtime error. Avoid placing destination points too far from markup elements to avoid this.

You can also include transporters with path-guided navigation in the list of obstacles by selecting Recognize all transporters option in the properties of the TransporterFleet block.

Transporters can either avoid network nodes with restricted access or ignore the restrictions.

Movement in free space navigation mode

Pedestrians are ignored by transporters moving in free space mode, which means the transporters will run over these shapes during model execution.

Transporters with free space navigation mode can move between levels using level gates and lifts.

Unlike the transporters with the path-guided navigation type, you cannot specify any particular route for transporters moving in the free space mode apart from the target they must reach. You can use the recalculateRoute() function to specify a new destination for the transporter during the model run.

If you want to obtain information about the transporter’s movement from its current location to the destination, you can use the transporter’s getRouteData() function. It will return a list of movement tasks of PLAIN type. Each movement task of this type will describe the movement of the transporter inside a cell of the navigation mesh.

The navigation type, home locations, and additional rules of movement for a fleet of transporters are defined in the properties of the TransporterFleet block.

Manual movement

You can manually move transporters using the move() function. First, select the desired transporter programmatically, then call the function.

See the following example calls:

Iterator<Transporter> it = transporterFleet.iterator(); // Iterate through the transporter fleet 
it.next().move(node); // Move the transporter to the node
it.next().move(node, TransporterState.DELIVERING) // Move the transporter to the node and set it to the specified state

There are several notations of this function for transporters, which you can find in the corresponding section of the Transporter API. When manually commanding the transporter to move, you can either specify its state explicitly, or omit the state parameter; in the latter case, the transporter will be moved to the MOVING_IDLE state. Do not try to manually move the transporter in the IDLE state (that is, don’t pass it as a parameter): this will throw an exception.

If the transporter is already under the control of an agent as a result of the agent passing through Material Handling Library blocks (SeizeTransporter, MoveByTransporter, or ReleaseTransporter), or if the transporter is performing a load or unload operation, it cannot be moved manually. However, you can call move() after the SeizeTransporter block even if the transporter is not yet released: for example, if the agent using the transporter is currently performing some other task, such as staying inside the Delay block (meaning the transporter is in the PROCESSING state). This also applies to the cases when the transporter was moved with the MoveByTransporter block which had the Release transporter parameter disabled (that is, the block only seized the transporter).

The commands issued by the blocks that affect the transporter always take precedence over the manual movement, that is, if the agent moving through the flowchart triggers the control of the transporter, the manual movement will stop and the transporter will resume handling the agent.

    If you command the seized transport to move by using move() with a status other than DELIVERING, this transporter will drop the agent that seized it. Reassigning DELIVERING by another move() call or a block will cause the previously dropped agent to “teleport” back to the transporter.

If the transporter is moving after the move() function call and receives a new move() function call, the new command will completely interrupt the previous one, regardless of the transporter’s state caused by the first call.

How can we improve this article?