Overhead Crane AGV Collision Avoidance Algorithm

In shared-floor operations where overhead cranes and AGV/RGV vehicles work side by side, the collision-avoidance algorithm is what determines both safety and throughput. Unlike fixed-limit interlock systems, these algorithms continuously compute optimal motion parameters for each device to actively steer around conflicts. This article compares three mainstream approaches—DWA, VO, and APF—and presents a recommended hybrid strategy.

DWA Dynamic Window Approach: Engineering Implementation

The Dynamic Window Approach (DWA) samples the velocity space (v, w) of the crane or AGV, evaluates a cost function for each sampled velocity pair, and selects the (v, w) with the highest score as the motion command for the next cycle. The velocity space is defined as v∈[0,v_max] and w∈[-w_max,w_max], with a typical sampling resolution of 30 divisions for linear velocity and 30 for angular velocity—yielding 900 (v, w) combinations per sampling pass.

Cost function G(v,w)=a·heading(v,w)+b·dist(v,w)+c·vel(v,w). The heading term measures the angular deviation between the direction of travel and the target direction (smaller deviation is better); the dist term measures the distance to the nearest obstacle along the trajectory (greater distance means safer); the vel term reflects linear speed (higher speed improves efficiency but reduces obstacle-avoidance capability). All three terms are normalized to [0,1] and combined as a weighted sum. On an NVIDIA Jetson Orin NX, Kelude's DWA implementation—written in C++ with CUDA-accelerated parallel sampling—achieves an execution time of approximately 120–180ms per cycle (including data acquisition, velocity sampling, cost evaluation, and command output), comfortably meeting the 200ms cycle requirement. Parallel evaluation of 90 (v, w) pairs takes just 8ms.

DWA adaptations for overhead crane applications: An overhead crane has only one degree of motion freedom (along the crane rail in the X direction), so the velocity space reduces to a one-dimensional sample set v_x∈[0,v_max] (angular velocity w is always zero). This cuts the sample count from 900 to 30 and shortens the computation cycle to 30–50ms. On the other hand, the crane's braking distance is longer than an AGV's (approximately 0.5m at 1m/s), so the dist weight in the cost function should be increased to b=0.5 (vs. b=0.3 for AGV scenarios) to ensure sufficient braking safety margin. Kelude's standard DWA parameters for overhead cranes—a=0.3, b=0.5, c=0.2—have been validated across six deployed projects.

DWA vs VO vs APF: Collision-Avoidance Comparison

The three algorithms differ significantly in their suitability for crane–AGV collaborative scenarios. DWA performs best in dynamic, unknown environments (its cost function balances heading, distance, and velocity objectives); VO offers the highest precision in multi-device speed coordination (based on velocity-cone geometry); APF delivers the lowest computational load and fastest response in static, pre-mapped path planning. The comparison below systematically evaluates all three across five dimensions—mathematical foundation, computation cycle, hardware requirements, dynamic adaptability, and implementation complexity—to help engineers select the right algorithm for their specific site conditions.

Engineering Implementation of the VO Velocity Obstacle Method

The core of the Velocity Obstacle (VO) algorithm is to define, in velocity space, the set of velocities that would lead to a collision. Definition: the velocity obstacle for device A relative to device B, VO(A,B) = v_A | (p_B - p_A)/t ∈ D(p_B - p_A, r_A + r_B), where p_A/p_B are the position vectors of the two devices, r_A/r_B are the radii of their circumscribed circles, and t is the prediction horizon. In plain terms: if device A moves at velocity v_A and device B at velocity v_B, then the relative velocity of B as seen from A, v_rel = v_A - v_B, falling inside the VO region means a collision will occur within the next t seconds.

PLC Implementation of VO: The S7-1500 PLC runs the VO algorithm in roughly 150 lines of SCL code. Every control cycle (100 ms), the VO regions for all device pairs (N × (N-1)/2 pairs in total) are computed sequentially. The current velocity of each device is then checked against every VO region. If a velocity falls inside a VO region, an escape velocity—the closest safe velocity to the VO boundary—is calculated and issued to that device as a speed limit command. For six devices, this amounts to about 15 pairs × roughly 50 instructions per pair = 750 instructions, which the S7-1500 executes in approximately 2–3 ms. When DWA and VO run concurrently, the PLC handles the VO portion (2–3 ms) while a Jetson module handles DWA (120–180 ms), with data exchanged over Profinet.

Limitations of VO and How We Address Them: VO assumes the other device is moving in a straight line at constant speed—so when the other device suddenly accelerates, decelerates, or changes direction, the VO prediction breaks down. Two refinements address this: ① Adding acceleration constraints—the VO calculation factors in the other device's maximum acceleration range, expanding the velocity cone into an accelerated velocity obstacle (Accelerated VO); ② Shortening the prediction horizon t—reducing t from 5 seconds (typical for overhead crane scenarios) to 2 seconds trades look-ahead time for prediction accuracy. At t = 2 seconds, VO collision prediction accuracy is about 92%; at t = 5 seconds, it drops to 78%. Kelude recommends t = 3 seconds as the default, achieving an overall accuracy of roughly 88%.

Hybrid Algorithm Case Study: Multi-Vehicle Coordination

A coordinated dispatching project at an automotive final assembly workshop involved 6 overhead cranes, 12 AGVs, and 4 RGVs, covering the full material handling flow from stamping parts offloading to the welding workshop. The production line layout: crane spans of 28–31.5 m, AGV travel aisles 2.5–3 m wide, 6 crane-to-AGV transfer stations, and 4 AGV-to-RGV handoff points. Peak throughput reached about 280 transfers per hour (averaging 12.8 seconds per transfer). Cranes handle inter-bay lifting and transport, AGVs manage floor-level movement, and RGVs handle long-distance rail transfer. The three equipment types intersect at 18 points across the line, making collision risk management particularly challenging.

Algorithm Configuration: A Jetson Orin NX (100 TOPS) runs DWA (AGV local path planning, 200 ms cycle), the S7-1500 PLC runs VO (multi-vehicle speed coordination, 100 ms cycle), and APF provides global path guidance (computed once per task dispatch, ~10 ms). The three algorithms work in concert: APF generates the global path → VO performs conflict detection and generates speed constraints → DWA samples within those constraints to output the optimal (v, ω) command. The dispatching PLC and Jetson communicate over Profinet IRT (2 ms cycle), with a measured link latency of approximately 280 ms.

Delivered Results: Zero collision incidents over 12 consecutive months of operation. Average task wait time dropped from 25 seconds (manual dispatching) to 12 seconds (a 52% reduction). Crane idle rate fell from 41% to 23%, AGV idle rate from 38% to 19%, and overall material flow efficiency on the line improved by 37%. Kelude Heavy Industry offers custom algorithm development services, including site survey, simulation, algorithm selection, Jetson deployment, PLC development, and a four-stage testing and acceptance process.

Four-Stage Simulation Testing and Validation for Collision Avoidance

Before deployment, any collision avoidance algorithm must pass a four-stage simulation and validation process.

Stage 1 — Pure Software Simulation (Gazebo + RViz): A 3D simulation environment is built in ROS 2 with crane and AGV models, importing the actual plant layout (including crane rails, travel paths, and transfer station coordinates). The system runs 200 randomized transport tasks (including 5% urgent tasks and 3% equipment fault scenarios), tracking collision counts and path efficiency. Pass criteria: zero collisions and average path efficiency ≥ 85% of manual dispatching.

Stage 2 — Hardware-in-the-Loop (HIL) Simulation: The Jetson edge box and PLC running the actual deployment code are connected to the simulation environment. The Jetson receives simulated equipment status messages from the PLC (via Profinet), runs the DWA + VO algorithms, and outputs speed commands to virtual devices. Key test focus: verifying that Profinet communication latency meets the 100 ms cycle requirement, and that algorithm execution time on real hardware stays within cycle budgets (DWA ≤ 200 ms, VO ≤ 100 ms).

Stage 3 — No-Load On-Site Testing: Cranes and AGVs run unloaded on the actual production line for 48 hours under continuous safety supervision, logging false trigger rates and abnormal behavior counts.

Stage 4 — Loaded Trial Run: Speeds are gradually increased to rated values, followed by a 168-hour (7-day) continuous run. The dispatching system's built-in KPIs track average task wait time, conflict rate, and on-time delivery rate, with before-and-after comparisons over one-week windows. Kelude Heavy Industry provides the full four-stage testing service, issuing a test report at the end of each stage.

Frequently Asked Questions