Most warehouse robotics demos show a single arm picking the same box, over and over, from a known position on a clean conveyor. The pick rate is impressive. The confidence score is high. The cycle time is tight. It looks like a solved problem.
It isn't. What those demos show is uniform-SKU picking: one product type, predictable geometry, fixed orientation, consistent weight distribution. That's the easy case. Real distribution centers don't operate that way.
What "mixed-SKU" actually means on the floor
In a real DC, a pallet arriving from a supplier might contain 30 different product types: corrugated boxes of different dimensions, cylindrical containers, flexible poly-mailers, sealed bags with variable fill states, and occasionally something wrapped in shrink film that doesn't hold its shape under vacuum. The robotic system has to identify the item, estimate its pose in 3D space, plan a stable grasp, execute the pick without disturbing adjacent items on the pallet, and place it correctly — all in the time budget that keeps the downstream conveyor fed.
The geometry variation alone creates real challenges for grasp planning. A vacuum-cup end effector optimized for flat corrugated surfaces performs poorly on a cylindrical bottle. A mechanical gripper sized for medium cartons will drop a flexible bag. Hybrid end effectors handle the variety better but require more complex grasp selection logic — which SKU calls for which grasp mode, and how to transition between modes without adding cycle time that undermines the throughput case for automation.
Beyond geometry, surface texture and material properties matter. A vacuum-cup system relies on a seal between the cup and the picking surface. Corrugated cardboard with printing coatings, bottles with labels running over the sealing area, and bags with ridged heat-seal seams all degrade vacuum cup performance in ways that don't appear in spec-sheet testing. Force-torque sensor data becomes essential for detecting marginal grasps before the arm commits to a lift — a partial seal that holds during the vertical lift phase but drops the item during horizontal transport is harder to catch than an outright pick failure.
The pose estimation problem at scale
For a single known item at a fixed position, pose estimation is straightforward. For a pallet with 30 SKU types in arbitrary orientation, occluding each other, under variable warehouse lighting, it's a different problem entirely. The 3D point cloud processing pipeline has to identify candidate items, estimate 6-DOF pose for each, rank them by grasp accessibility (which items aren't blocked by adjacent items on the pallet), and return a pick target within a time budget that doesn't stall the downstream sorter.
That time budget is typically 200–400 ms for point cloud acquisition plus processing. Slower vision pipelines extend cycle time in ways that compound across a full shift. An arm running 550 picks/hr under clean-condition testing drops to 380–430 picks/hr when pose estimation adds 350–400 ms to every cycle — not because the arm is slower, but because the total cycle time, including the vision overhead, is longer. The pick rate the system is sold on and the pick rate the facility actually sees diverge right here.
Why most robotic systems quietly fall apart here
The failure mode is usually not dramatic. Arms don't crash. Pick rates don't drop to zero. What happens is subtler: the facility starts managing around the system's limitations. Irregular items stay on the manual picks list. Deformable packaging goes to a separate conveyor. The SKU coverage that looked complete in the pilot gradually reveals gaps as real operating conditions diverge from controlled conditions.
This workaround behavior is hard to see in the aggregate numbers. The facility reports a pick rate that looks acceptable — because it's only counting the items the system actually picks, not the items that were diverted before they reached the arm. The real SKU coverage percentage — robotic picks as a share of total picks — tells the more accurate story, and it's often significantly lower than the pilot suggested.
The grasp planning problem is hard enough. The scaling problem compounds it. Even a system that handles mixed-SKU picking competently still requires individual programming for each SKU. In a facility with 400 active SKUs across 10 arms, that's 4,000 teach-in sessions to build the initial catalog. Quarterly rotations of 60 new items means another 600 sessions. The programming overhead for mixed-SKU environments is not a minor operational cost — it's often the primary reason facilities cap their robotic deployment at the pilot stage and never scale to full fleet.
The end effector selection problem
No single end effector handles the full range of SKUs in a real mixed-SKU environment. Vacuum-cup designs optimized for flat corrugated surfaces — the majority of uniform-SKU deployments — struggle on round, small, or deformable items. Mechanical parallel-jaw grippers handle a wider geometry range but can't pick from a tightly packed pallet without disturbing adjacent items. Hybrid end effectors combining vacuum and mechanical gripping expand coverage substantially but add weight that eats into the arm's usable payload budget.
For a UR10e at 10 kg payload capacity, a heavy hybrid end effector might consume 2.5–3.5 kg of that budget, leaving 6.5–7.5 kg for actual items. That's fine for most consumer goods but problematic for heavy items near the upper payload range. The FANUC CR-35iA at 35 kg payload has more headroom here, which is part of why it appears in deployments handling mixed-weight catalogs that include both light consumer goods and heavy cases.
The grasp selection logic — which mode does the end effector use for this SKU — needs to be part of the trained model for each item. Training a new SKU on one arm captures not just the approach trajectory and grasp point, but the end effector configuration appropriate for that item's geometry and surface properties. When that model propagates to the fleet, each arm also receives the end effector selection parameters, not just the kinematic ones.
What changes when grasp models can propagate
The two problems — mixed-SKU handling complexity and per-arm programming overhead — are typically treated as separate issues. Fleet-wide propagation addresses the second problem directly: one training session per SKU, distributed to every arm in the fleet. But it also changes the calculus on the first problem.
When adding a new SKU to the fleet costs one 45-minute training session instead of one session per arm, the economic incentive to expand SKU coverage increases. Long-tail SKUs that were manually handled because the programming cost wasn't justified become candidates for automation. The threshold for "is this SKU worth training" shifts significantly when the amortized cost per arm is near zero. A SKU that appears in 0.3% of total picks — too low to justify 10 programming sessions under a per-arm model — becomes economically viable to train when one session is the total cost.
The confidence-gating requirement stays important in mixed-SKU environments. Deformable packaging and irregular shapes have lower first-session confidence scores than rigid geometry. Those SKUs need to stay in follow-up training queues until confidence reaches the 92–95% threshold — not be pushed into production at marginal confidence. A missed pick on a fragile item mid-pallet costs more than a delayed SKU onboarding. The goal is maximizing robotic SKU coverage, not maximizing the speed of catalog build.
The singulation problem in depalletizing
Mixed-SKU depalletizing introduces a challenge that uniform-SKU picking sidesteps: singulation. When a pallet contains items of different sizes and shapes stacked without a defined pattern, the arm's vision system needs to identify which item is on top and accessible without disturbing adjacent items. Items that are slightly leaning against each other, overlapping at corners, or positioned so that the grasp approach vector for the top item requires movement through the space occupied by a neighboring item create collision planning problems that add latency and failure modes not present in organized, uniform-SKU pallets.
This isn't a fundamentally unsolvable problem, but it's one that requires the grasp planner to incorporate collision checking against the full point cloud, not just the target item. At a 200–400 ms vision cycle budget, the time available for collision-aware grasp planning is limited. Systems that skip full collision checking to meet the throughput budget will occasionally initiate picks that result in a neighboring item being knocked off the pallet — a consequence that's difficult to model in pick rate specs but shows up consistently in live depalletizing environments.
How the training session changes for complex SKUs
The training session for a straightforward rigid box on a UR10e is relatively fast: operator demonstrates the pick on the teach pendant using URScript manual mode, the vision system captures the approach geometry from multiple orientations, force-torque sensor data is recorded for the grasp and lift phases, and the model is closed out after 3–5 demonstration picks. Total time: 30–45 minutes per SKU, including model validation.
Training a complex SKU — a flexible mailer with inconsistent fill, a multi-pack with a handle that changes grip geometry, or an oddly shaped item that requires a specific approach vector to avoid tipping — takes longer. Multiple demonstration picks are needed to capture the orientation variance. The operator may need to show the system two or three valid grasp approaches for items that don't have a single obvious pick geometry. Follow-up training iterations after the initial session are common for these SKUs, because the first-pass model rarely achieves full confidence threshold on items where the grasp geometry has high variance.
This training complexity doesn't change the fleet propagation math, but it changes the per-SKU time estimate in the initial catalog build. A facility with 200 simple rigid-box SKUs can build its catalog much faster than one with 200 SKUs spread across packaging types. Build this into the deployment timeline: catalog build time is SKU count × average training time per SKU, and average training time varies by packaging complexity, not just SKU count.
Realistic coverage expectations
We're not saying mixed-SKU picking is a fully solved problem. The long tail of SKU diversity in real distribution centers includes items that remain difficult for current grasp planning systems regardless of how the programming overhead is managed. Items with unpredictable fill states — bags of granular material that shift during handling — have grasp confidence ceilings that reflect the physics of the pick, not the quality of the trained model. Very small items (under 5 cm in the smallest dimension) are genuinely hard for most end effectors at warehouse scale. Extremely fragile packaging that can't tolerate the force of a mechanical gripper and offers no flat surface for vacuum has limited robotic pick options without specialized tooling.
A realistic target for a mixed-SKU distribution center transitioning to a robotic pick fleet is 65–80% robotic pick coverage of total pick volume — with the remainder handled manually for categories where the grasp planning problem isn't tractable with current tooling. That's a substantial improvement over the 30–45% coverage ceiling that per-arm programming overhead typically imposes in practice, but it's not a claim that the problem is universally solved. The goal is to push the programmable boundary as far as the technology supports, and to not let the programming economics be the constraint.
Facilities that see 75%+ coverage tend to share a few characteristics: a SKU catalog that's predominantly rigid or semi-rigid consumer goods packaging, consistent pallet presentation from suppliers, and a regular training cadence that brings new SKUs into the robot catalog within 2 weeks of their arrival in the facility. Facilities that stay below 55% coverage usually have one or more of: high proportion of deformable packaging, inconsistent pallet organization that creates singulation difficulties, or programming backlogs that leave newly arrived SKUs on the manual list for weeks. The coverage number is as much an operational and process outcome as a technology one.