How to calculate swept path for an oversize blade trailer
Swept path is the shape a vehicle traces through a bend, measurably wider than its footprint parked at rest. For a standard truck that shape is a manageable calculation. For a blade trailer running 60 to 85 metres of overhang on a steerable rear dolly, getting it wrong is the difference between a haul plan that works and a rig jackknifed into a drainage ditch three miles from the turbine pad.
This is the practical version of how planners build that number, and where the calculation starts to lie to you if the underlying road data is wrong.
The inputs before you open any software
You can't model a swept path off a vehicle spec sheet alone. You need:
- Kingpin-to-rear-axle distance (or, for extendable blade adapters, the full articulated wheelbase at the extension length you'll run)
- Tractor wheelbase and turning radius, usually from the OEM's turning circle diagram
- Track width of both tractor and trailer axles
- Steering angle at the rear dolly, which on a self-steering blade trailer can be close to 90 degrees and is what lets a 70 m blade take a bend a straight trailer never could
- Road geometry at the actual bend: centerline radius, lane width, shoulder condition, and any superelevation
Most of these come from the trailer manufacturer and the transport engineer's rig configuration. The road geometry is where projects get sloppy, because it's tempting to pull a radius off a plan drawing from five years ago instead of what's on the ground today.
The offtracking math, roughly
For a simple single-axle trailer taking a bend of radius R with wheelbase L, offtracking (how far the rear axle cuts inside the front path) approximates to:
Offtracking = R − √(R² − L²)
That formula holds for a short rigid unit taking one bend at a fixed wheelbase. Once the rear dolly starts steering on its own, the math gets harder to do by hand: the dolly corrects the path mid-turn, and L itself shifts depending on which blade is loaded and how far the adapter is extended. This is why every serious heavy-haul transport engineer runs the move through dedicated swept path software (AutoTURN, Transoft, or equivalent) rather than hand-calculating it, feeding in the rig's actual steering lock and axle spacing rather than a textbook approximation.
The output is a swept path corridor: a shaded band showing exactly where the outer edge of the blade and the inner edge of the trailer tires will fall through every bend on the route. Compare that corridor against the available road width, including any bend widening, and you get a pass or fail for each turn.
Where the model needs a reality check first
The swept path software is only as good as the road width and bend radius you feed it. If the centerline data is from an old survey, a widened intersection, a bridge approach rebuilt last year, or a bend that's narrower than the drawing shows because a utility pole got relocated into the verge, the model will happily tell you the move clears when it doesn't.
That's the gap a desk-level constructability read is built to close before anyone commits a rig to the road. Checking bend radii, lane width, bridge spans, and laydown space against current high-resolution imagery catches the stretches where the swept path model's inputs don't match what's really there on the ground, before a pilot car gets sent out to find that the hard way. A route-and-site constructability check against current imagery does that pass across the whole corridor, not just the bend someone already flagged as tight.
Run the swept path analysis on the rig configuration you'll run for the move. Then confirm the road it's being run against is the road that's really there.
If you've got a route to clear before the haul plan gets locked, that's exactly what Constructability Screening is for.