While forklift dispatching logic appears to be a rigid set of rules, it is actually the accumulation of field experience. Behind every configuration parameter lies a real-world issue encountered in an actual project; likewise, every functional iteration is driven by a specific on-site case. Tracking the workflow as the main thread, this article deconstructs the design logic behind key features—exploring their origins, the problems they solve, and their current implementations.

Travel Height Adjustment

When a forklift departs from a staging point, the forks must be adjusted to an appropriate travel height. The travel height cannot be zero, nor can it be too high, due to the following constraints:

1. When unloaded, a fork height of zero will block the laser sensor on the forklift's rear-view side, disabling its own obstacle avoidance. Simultaneously, lasers from other forklifts cannot detect it, which compromises two-way perception.

2. When loaded, a fork height of zero means the cargo is dragging along the ground, preventing normal travel.

3. When the travel height is too high, the loaded center of gravity $CoGCoG$ becomes elevated, reducing stability. Furthermore, sites with low ceilings present a collision risk during high-level travel.

Forks can be adjusted in two directions during travel:

1. Lowering: After picking, the forks are at an elevated position and must be lowered to a safe height during travel.

2. Raising: In some scenarios, pallet/fork recognition requires the forks to be raised to a specific height, otherwise sensors cannot scan them. For example, when a forklift departs from a staging point with its forks lowered, it needs to raise them to the recognition height while moving.

The three common field scenarios and their corresponding handling methods are:

1. Unrestricted Scenarios: Simply configure the unloaded/loaded travel heights for the robot group, and the system will automatically adjust them at the appropriate waypoints.

2. Adjustment Restricted to Pre-positions: Transport order steps must be created to raise or lower the forks at the pre-position. Height control is managed by the business layer, while the dispatching layer does not intervene.

3. High Takt Time Requirements (Pre-raising/Pre-lowering Required): Enable "Travel-Time Lifting" and configure the pre-lifting distance before picking/dropping (see the next section for details).

Because unloaded and loaded states have different constraints on travel height, they require independent configurations. Early versions featured only a single travel height parameter, which failed to meet requirements in projects that needed to differentiate between the two states. Version 6.4.2 separated this into Unloaded Travel Height and Loaded Travel Height, both defaulting to 0.1m.

Travel-Time Lifting: From Single Configuration to Scenario-Specific Control

Prior to the introduction of travel-time lifting, a forklift had to stop and wait at the pre-position for the forks to lift or lower to the target height before executing a pick or drop. Stopping and waiting at the pre-position caused a fixed efficiency loss, which was particularly prominent in projects with demanding takt times. Field feedback revealed that during manual operations, operators would start lifting the forks while en route, ensuring they were mostly in position by the time the forklift reached the pre-position. This feedback drove the development of the travel-time lifting feature.

Travel-time lifting includes two sub-scenarios:

1. Lifting/Lowering to Travel Height on the Move: After completing a pick or drop, the forklift adjusts its forks to the travel height concurrently while moving, eliminating the need to stop at the pre-position to wait for the adjustment.

2. Pre-lifting/Pre-lowering to Action Height Before Pick/Drop: This requires the corresponding travel-time lifting switch to be enabled and the pre-lifting distance to be configured to $>0\text{m}>\; 0\backslash text\{m\}$. The forklift begins adjusting its forks on the move once it is within this configured distance from the pre-position. The goal is to ensure the forks are already in place upon arrival at the pre-position, eliminating wait times. Note: Even if the height is adjusted in advance, the forklift must still stop at the pre-position to execute maneuvers like rotation and recognition.

When these two sub-scenarios overlap—meaning a specific path segment requires both "lowering to travel height on the move" and "pre-lifting to pick/drop height"—the latter takes priority.

Early versions had only one "Travel-Time Lifting" configuration item shared by both unloaded and loaded states. However, actual projects revealed that the two states have different requirements:

1. When unloaded, the forks are light and the CoG is low, making the risks of travel-time lifting manageable and acceptable.

2. When loaded $especiallywithheavyloadsathighlevelsespecially\; with\; heavy\; loads\; at\; high\; levels$, lifting while moving raises the CoG, increasing stability risks. Consequently, some customers requested that this feature be disabled in the loaded state.

As a result, we later split the configuration into Travel-Time Lifting $UnloadedUnloaded$ and Travel-Time Lifting $LoadedLoaded$ to support independent toggles.

The theoretical formula for calculating the pre-lifting distance is:

$\text{Distance}=\frac{\text{Target Height}-\text{Current Height}}{\text{Fork Lifting Speed}}\times \text{Forklift Travel Speed}\backslash text\{Distance\}\; =\; \backslash frac\{\backslash text\{Target\; Height\}\; -\; \backslash text\{Current\; Height\}\}\{\backslash text\{Fork\; Lifting\; Speed\}\}\; \backslash times\; \backslash text\{Forklift\; Travel\; Speed\}$

The higher the target rack level and the faster the forklift travels, the greater the required pre-lifting distance. Currently, this parameter is manually configured based on on-site measurements.

Take a picking task as an example (unloaded travel height = 0.1m, picking start_height = 2.2m, pre-lifting distance = 12m):

• Travel-Time Lifting Disabled: After leaving the staging point, the forklift stops at a certain point after exiting the initial path segment, adjusts its fork height to 0.1m on the spot, travels to the pre-position at this height, lifts the forks to 2.2m while stationary at the pre-position, and then enters the storage location to pick the load.

• Travel-Time Lifting $UnloadedUnloaded$ Enabled with a 12m Pre-lifting Distance: The forklift adjusts its forks to 0.1m concurrently while moving. It begins raising its forks to 2.2m on the move at a distance of 12m from the storage location. By the time it reaches the pre-position, the forks are essentially in place. After a final verification, it enters the storage location to pick the load.

Pre-positions: From Strict Constraints to Automatic Identification

Racks have beams. When a high-lift forklift picks or drops loads on the second tier or above, the forks will hit the beams if they are raised or lowered directly inside the storage slot. The existence of a pre-position is a physical constraint, not an optional design. The forklift must complete its fork height adjustment at a safe position before entering the rack, and then insert the forks horizontally into the slot.

Early versions imposed strict constraints on pre-positions:

1. Each storage location could have one and only one pre-position.

2. The pre-position had to be an LM $landmarklandmark$ point.

In complex projects, these constraints frequently caused issues. Some storage locations can be entered from two directions, requiring two pre-positions. In high-density storage aisles, AP $accesspointsaccess\; points$ are directly connected to one another without LM points in between, making it impossible to build maps according to standard specifications. These limitations resulted in heavy mapping workloads, and many site layouts simply could not be accommodated.

Consequently, we removed the restrictions on the quantity and types of pre-positions, allowing the dispatching system to automatically identify and plan them. The M4 system does not require pre-positions to be configured separately in the map, nor does it mandate that they be LM points; a single storage location can now have multiple pre-positions. For high-density storage aisles, multiple slots within the same aisle share a single pre-position. The forklift completes its fork adjustment at the aisle entrance and then enters the target slots sequentially.

Picking: Pallet Recognition vs. Non-Recognition Workflows

Once the forklift arrives at the pre-position, the picking workflow branches into two categories based on whether pallet recognition is required.

Non-Recognition Picking

The forks rise to the start_height and insert directly into the pallet, then lift to the end_height to complete the pick. For example, with a picking height of 2.2m and a clearance height of 2.3m:

1. The forklift arrives at the pre-position, and the forks rise to a start_height of 2.2m.

2. The forklift moves into the storage slot, and the forks insert into the pallet.

3. The forks lift to an end_height of 2.3m, lifting the pallet off the rack to complete the pick.
   
   

Recognition Picking

The purpose of recognition is to capture the actual position of the cargo, correcting horizontal and angular deviations caused by manual placement, and in rare cases, vertical deviations. Depending on the rec_height configuration, there are three scenarios:

1. rec_height** Not Passed**: The forks rise to the start_height to execute recognition. Once completed, they insert into the pallet directly at the start_height without adjusting the fork height based on recognition results, and then lift to the end_height to finish picking.

2. rec_height >= 0: The forks first rise to the start_height, then move to the designated rec_height to execute recognition. They insert into the pallet at the rec_height before lifting to the end_height to complete the pick.

3. rec_height = -1: The forks rise to the start_height to execute recognition. Based on the recognition results, the system dynamically calculates the actual picking height ($\text{recognition height}+\text{current fork height}\backslash text\{recognition\; height\}\; +\; \backslash text\{current\; fork\; height\}$), adjusts to this height, inserts into the pallet, and then lifts to the end_height. This configuration is ideal for scenarios with high uncertainty regarding cargo placement heights.

Across all three scenarios, the logic for end_height remains identical: it represents the final height of the forks after lifting the cargo off the rack, ensuring the pallet completely clears the rack beam.

Task Completion Timing for Picking

There are two candidate milestones to signify the completion of a picking step:

• A: The moment the forks lift the cargo and it clears the rack.

• B: The moment the forklift backs up and returns to the pre-position.

Early iterations adopted Option B. However, operations revealed that while the forklift was backing up to the pre-position, it continuously occupied the rack aisle. The dispatching system had to wait for this step to finish before issuing subsequent commands, leading to prolonged main aisle occupancy and waiting gaps between tasks.

Switching to Option A yielded significant improvements:

1. The pick is considered complete the moment the cargo is lifted, allowing the dispatching system to immediately plan subsequent actions.

2. The path for the forklift to exit the aisle can be flexibly selected based on the next task's destination, rather than forcing a return to the original pre-position.

3. The forklift waits for its next instruction inside the storage slot instead of sitting at the pre-position and blocking the main aisle.

The same logic applies to the drop workflow, where the completion timing is defined as the moment the forks lower to the end_height and disengage from the pallet.

Drop Workflow

The drop workflow is relatively fixed and does not involve recognition. After a loaded forklift arrives at the drop pre-position:

1. The forks rise to the start_height, which is slightly higher than the target tier's beam to ensure the pallet can be pushed smoothly into the rack.

2. The forklift moves into the storage slot, pushing the pallet horizontally into the target position.

3. The forks lower to the end_height, depositing the pallet onto the beam. The forks disengage from the pallet, completing the drop.

For example, with a drop height of 2.2m: The loaded forklift arrives at the pre-position, the forks rise to a start_height of 2.3m, the forklift moves into the slot to push the pallet in, the forks lower to an end_height of 2.2m to deposit the pallet, and the forklift exits.

During a drop, the start_height is higher than the end_height, which is the reverse of the picking direction—picking lifts the cargo from low to high, while dropping deposits the cargo from high to low.

Proceeding to the Next Destination: Do Forks Need to Lower to Travel Height First?

Early logic dictated a rigid cycle: Complete Pick/Drop $\to \backslash rightarrow$ Return to Pre-position $\to \backslash rightarrow$ Lower to Travel Height $\to \backslash rightarrow$ Travel $\to \backslash rightarrow$ Raise to Pick/Drop Height. The full sequence was executed every single time.

In continuously operating projects, we observed that a large number of tasks were concentrated on picking and dropping loads within the same bay or adjacent bays of racks. In such cases, lowering and then raising the forks represented two redundant, opposing movements. To resolve this efficiency bottleneck, we introduced intelligent fork height adjustment:

1. Picking/Dropping Across Different Tiers in the Same Bay $e\dot{g}\dot{,}pickingfromTier2,droppingtoTier3e\backslash .g\backslash .,\; picking\; from\; Tier\; 2,\; dropping\; to\; Tier\; 3$: Upon exiting the rack slot, the forks adjust directly from the picking height to the drop start_height without lowering to the travel height.

2. Picking/Dropping Across Adjacent Bays: If the distance from the current point to the next target point is less than the configured "pre-lifting distance," the forklift moves directly while maintaining its current height, skipping the lower-then-raise cycle. If the fork height exceeds the configured "maximum safe fork height," it lowers to that safe height $ratherthanthetravelheightrather\; than\; the\; travel\; height$ before moving.

Travel-Time Lifting: From Field Demands to Feature Design

In early versions, the forklift would stop upon reaching the pre-position and wait for the forks to lift or lower to the target height before executing the pick or drop. This waiting time at the pre-position was a clear efficiency bottleneck, particularly prominent in projects with demanding takt times.

Field feedback noted that during manual operations, human drivers began raising the forks while en route, ensuring they were mostly adjusted by the time they reached the pre-position. This real-world insight drove the development of the travel-time lifting feature.

Initially, there was only one "Travel-Time Lifting" configuration item. However, actual projects demonstrated that unloaded and loaded states have distinct requirements for this feature:

1. When unloaded, the forks are light, and travel-time lifting presents low risk, making it safe to enable.

2. When loaded $especiallywithheavyloadsathighlevelsespecially\; with\; heavy\; loads\; at\; high\; levels$, lifting while moving elevates the CoG, raising stability risks. Consequently, some customers requested that it be disabled.

To accommodate this, version 6.5.1 split the configuration into Travel-Time Lifting $UnloadedUnloaded$ and Travel-Time Lifting $LoadedLoaded$ to support independent toggles.

Travel-time lifting consists of two phases:

1. Lifting/Lowering to Travel Height on the Move: After leaving a pick/drop location, the forklift adjusts its forks to the travel height concurrently while moving, rather than stopping at the pre-position to wait for the adjustment to finish.

2. Pre-lifting/Pre-lowering to Action Height Before Pick/Drop: This requires the corresponding travel-time lifting switch to be enabled and the **pre-lifting distance to be set to **$>0\text{m}>\; 0\backslash text\{m\}$. The system begins raising the forks on the move starting at this distance from the pre-position, aiming to have the forks fully adjusted upon arrival.

The theoretical calculation formula for the pre-lifting distance is:

$\text{Distance}=\frac{\text{Target Height}-\text{Current Height}}{\text{Fork Lifting Speed}}\times \text{Forklift Travel Speed}\backslash text\{Distance\}\; =\; \backslash frac\{\backslash text\{Target\; Height\}\; -\; \backslash text\{Current\; Height\}\}\{\backslash text\{Fork\; Lifting\; Speed\}\}\; \backslash times\; \backslash text\{Forklift\; Travel\; Speed\}$

The higher the target height and the faster the forklift travels, the larger the required distance. Currently, this parameter is manually configured based on on-site measurements, and the system does not automatically estimate it yet.

Note: If there is a rotation maneuver along the path, the fork adjustment command will only be issued on the path segment after the rotation is completed to avoid adjusting the forks during a turn.

Exception Handling

Forklift pick and drop operations are divided into two distinct phases:

• Phase 1: Movement from the pre-position to the storage slot, along with the pick/drop action inside the slot.

• Phase 2: Movement from the storage slot back to the pre-position.

The error recovery methods for these two phases differ:

1. Phase 1 Failures (e.g., pick/drop failure): The cargo must first be restored to its state prior to the action before an error retry can be executed. The dispatching system automatically plans the forklift's retreat to the pre-position, eliminating the need for manual vehicle towing.

2. Phase 2 Failures (e.g., forklift stopping along the return path): An error retry can be executed directly, and the forklift will complete the remaining retreat maneuver on its own.

The highest-risk area is the path segment between the pre-position and the storage slot, where the forks are elevated and aisle clearance is constrained. When a forklift strands here, whether waiting or undergoing recovery, the handling must strictly follow established protocols.

In scenarios where a task is canceled after picking but the cargo remains on the forks, the system triggers the "Picked But Not Dropped" exception handling workflow. It supports three resolution methods:

1. Automatically return the cargo to its original storage slot.

2. Automatically deliver the cargo to a preset exception storage area.

3. Manually designate a target storage slot.

All three methods support switching to manual intervention mid-process, and the system will continuously issue alerts until the cargo disposition is fully completed.

Continuous Iteration of Features

From splitting travel height configurations and scenario-specific control for travel-time lifting, to lifting pre-position constraints and redefining pick/drop completion milestones—every design adjustment is propelled by real-world field feedback. While forklift dispatching looks like a fixed set of rules, every new environment introduces new challenges, driving these rules to evolve continuously.

If you encounter any issues or have insights during actual application, feel free to email us at: m4@seer-robotics.ai.