Path-guided navigation

The transporters with path-guided type of navigation conduct their movement along paths and nodes connected to create a network. The source and destination points can be located in different networks / levels: transporters can move between these networks / levels through network ports or lifts.

Unlike moving resources defined with ResourcePool block, transporters in this mode avoid collisions and give way at crossroads. In case of collision, they have to wait for a period of time before resuming their movement. These options can be customized in TransporterControl block.

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

By default, path-guided transporters recognize only transporters of the same type as obstacles. You can make them recognize transporters with free space navigation as well, by selecting the Recognize all transporters option in the properties of the TransporterFleet block.

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

Currently, the movement algorithm of the path-guided transporters has the following specifics regarding collisions:

• Intersection overlaps and collisions: Transporters will stop when they encounter another transporter at intersections, regardless of path, and slow down based on the Min distance to obstacle parameter.

  

  If the intersection is configured with a point node resized to minimum or with a diameter less than the specified value, collisions may occur.

  

• Collisions on adjacent paths: Transporters will stop to resolve collisions if their paths are close together in the network.

  

• Resolving collisions: Collisions can be resolved at both paths and nodes. Before collision resolution, transporters with conflicting routes stop for a timeout, during which the collision is resolved.

By default transporters select the shortest possible route to the destination, but custom routing can be defined in TransporterControl block.

You can specify the conditions that must be met so that the transporter can enter nodes and paths in the network. You can select nodes and paths which the transporter will avoid while still moving along the shortest possible route. These settings will be applied to all transporter fleets with path-guided type navigation.

To specify individual routing rules for a single transporter fleet, you have to select the Custom routing option in the properties of the corresponding TransporterFleet block. These settings will have priority over the settings specified in TransporterControl block.

If an obstacle appears when the transporter is already on its way, you can call the recalculateRoute() function and it will recalculate the transporter's route to avoid collision. Recalculation will still allow for the custom routing algorithm if you have specified one before.

You can obtain the information about the transporter's route from its current location to the destination by calling the transporter's getRouteData() function.

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 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.

When moved manually, path-guided transporters:

• Trigger the On enter path, On exit path, On enter node, and On exit node actions of the TransporterFleet block that hosts them. The On seize and On release actions are ignored.
• Follow the rules specified by the TransporterControl block.

How can we improve this article?

Send