When an operations team selects robot arms for a new pick deployment, the hardware decision is usually made on payload capacity, reach, cycle time, and price. What's less often evaluated upfront is the controller software interface — and that's the layer where software compatibility lives or dies.
This guide covers what to check for each major arm family before deploying a software layer across a mixed-brand fleet. The assumption is that the software layer sits above the arm controller and communicates via the controller's external interface — it does not replace or patch the arm's native controller stack. Understanding what each controller exposes, at what latency and cycle rate, and under what safety constraints, is the pre-deployment homework that prevents go-live surprises.
Universal Robots — e-Series
UR arms communicate with external software primarily through URScript (the UR scripting language) and the External Control plugin for ROS2 integration. The e-Series (UR3e, UR5e, UR10e, UR16e) uses Polyscope as the controller OS. Minimum version for most third-party software integration is Polyscope 5.11; earlier versions have known issues with the RTDE interface reliability under high-frequency polling.
The UR Real-Time Data Exchange (RTDE) interface provides sensor feedback, joint states, and program state over a 125 Hz loop. Software layers that need force-torque feedback should confirm the UR FT sensor (or third-party FT sensor via RTDE) is included in the build-of-materials and that the FT sensor is calibrated to the mounted end effector weight before any grasp confidence measurements are taken from it.
The UR10e at 10 kg payload and 1300 mm reach covers the majority of mixed-SKU warehouse scenarios. The UR16e at 16 kg payload and 900 mm reach suits shorter-reach, heavier-item applications. One practical note on the UR16e: the reduced reach (900 mm vs. 1300 mm) affects workspace coverage on wide pallets — confirm the reach envelope matches the pick zone geometry before specifying UR16e over UR10e. External control commands sent via URScript need to handle the watchdog timer correctly; the UR controller will stop the arm if the external command loop drops a heartbeat. Build this handling into the integration from the start, not as a later patch.
FANUC CR series — Collaborative cobots
The FANUC CR series (CR-4iA through CR-35iA) uses the R-30iB Plus controller. Third-party software integrations connect via the FANUC Robot Interface or the ROS-Industrial driver. The R-30iB Plus supports Ethernet/IP and socket messaging; the integration path for software layers is typically a socket-based connection to the controller's KAREL or TP program stack. KAREL is FANUC's on-controller programming language — the external software typically sends motion targets and receives joint state feedback via socket, with KAREL handling the motion execution natively inside the controller.
One note on the CR-35iA specifically: at 35 kg payload, it's the highest-capacity collaborative arm in widespread warehouse use. It handles cases and bulk items that require full-arm force limiting — the built-in power-and-force limiting (PFL) must be verified in the controller configuration before a software layer sends Cartesian motion commands outside the standard envelope. The CR-35iA operating in collaborative mode has a maximum TCP speed of 250 mm/s; software-commanded motions that reference higher speeds will be clamped by the controller. Design your motion profiles around the collaborative speed limit, not the arm's maximum kinematic speed.
The FANUC CR-14iA is the most common model in mixed-SKU warehouse deployments — its 14 kg payload handles the majority of consumer goods and cases, and the R-30iB Plus controller has a well-documented integration path. The CR-4iA and CR-7iA are useful for small-item, high-speed picking but face payload constraints on anything approaching 5 kg with end effector overhead. Check payload budget (arm payload minus end effector weight) before specifying either model for catalog categories with heavier items.
ABB IRB series — OmniCore and IRC5
ABB IRB arms run on either the OmniCore (newer) or IRC5 (legacy) controllers. The integration interface used by most external software layers is ABB's Externally Guided Motion (EGM) — a real-time Cartesian and joint-state streaming interface over UDP. EGM latency is typically 4 ms at the controller network interface, making it suitable for sensor-guided pick operations where force-torque feedback needs to influence motion in near real-time.
RobotStudio (ABB's programming environment) is used for controller configuration and firmware updates. Third-party software that uses EGM needs to have its UDP endpoint whitelisted in the IRC5/OmniCore safety configuration before it can send motion references. Confirm this is done during pre-installation network assessment — not on installation day. ABB's safety configuration requires an authorized engineer access level to modify; if the facility doesn't have an ABB-trained engineer on staff, this step needs to be scheduled with an ABB service provider before installation begins.
The ABB IRB 2400 is a common industrial arm in warehouse depalletizing applications — not a cobot, so it requires fixed guarding or area scanning in the work envelope rather than PFL-based collaborative operation. The IRB 1200 is a smaller-footprint model for confined pick stations. For deployments where human-robot collaboration is required at the pick station (ISO/TS 15066), confirm whether the selected ABB model supports the required safety rating before specifying it for a shared workspace.
Yaskawa Motoman — YRC1000 and MotoROS2
Yaskawa arms on the YRC1000 controller integrate via MotoROS2, the ROS2 driver package maintained by Yaskawa and the ROS-Industrial consortium. MotoROS2 exposes the arm's joint states, motion controller, and I/O over ROS2 topics and action servers. The ROS2 integration path is well-maintained and has reasonably detailed documentation through the ROS-Industrial GitHub; this makes the integration path more transparent than controller-proprietary socket interfaces but also means the integration quality depends on the ROS2 version and MotoROS2 version being compatible — confirm the version matrix before specifying a Yaskawa installation alongside existing ROS2 infrastructure.
The HC10 and HC20 are Yaskawa's human-collaborative cobots — power-and-force limiting models rated for side-by-side workspace deployments. These require MotoROS2 with the PFL mode preserved: the software layer must not override the collaborative operating mode or send velocity commands that exceed the safety-rated speed limits configured in the YRC1000 safety parameters. The YRC1000 controller maintains a separate safety-rated parameter set for collaborative operation; the external software layer communicates through the standard motion interface but the controller enforces the safety limits. A software layer that attempts to bypass or override these limits will be rejected by the controller — design the motion profiles with the HC-series collaborative speed envelope in mind from the start.
The GP7 and GP12 are Yaskawa's standard industrial arms in the weight class common to consumer goods picking. Neither is a cobot — they require guarded workspaces. The GP25 handles heavier catalog items at 25 kg payload. For a mixed-brand fleet that includes both Yaskawa industrial arms and Yaskawa cobots, confirm that the software layer correctly identifies which controller safety profile is active on each arm before sending motion commands. Sending industrial-speed motion profiles to an HC-series arm in collaborative mode will trigger a safety fault.
KUKA LBR iiwa — Sunrise.OS and FRI
KUKA LBR iiwa arms run Sunrise.OS (Java-based), with external integration via the KUKA Fast Robot Interface (FRI). FRI is a real-time UDP interface for joint-impedance control and external joint-position references. It requires a dedicated Ethernet port on the controller and a matched FRI client library on the controlling computer — the FRI client must be version-matched to the FRI server running on Sunrise.OS.
FRI connection requires an active Sunrise.OS application with FRI enabled — this is configured in Sunrise Workbench and deployed to the controller. Third-party software using FRI must target the correct FRI protocol version (LBR iiwa 7 and LBR iiwa 14 both support FRI 1.x). Confirm the FRI configuration during controller commissioning, not at go-live. One practical issue with FRI: the real-time loop requires the controlling computer to respond within the FRI cycle time (typically 1 ms or 5 ms depending on configuration). If the controlling computer is handling multiple arms or running a heavy vision pipeline, confirm CPU headroom for the FRI response cycle before go-live.
The LBR iiwa's joint-torque sensing is one of its distinguishing features for sensitive assembly and handling applications. In warehouse picking contexts, this sensitivity is valuable for handling fragile items where force monitoring during the grasp and lift phases reduces damage risk. The trade-off is that the KUKA LBR iiwa carries a higher per-unit cost than most other cobots in this payload class — its presence in a warehouse fleet is usually justified by specific handling requirements rather than general-purpose picking.
What to check before deployment
Regardless of arm family, a software compatibility check before installation should cover the following areas.
Controller firmware version. All five arm families have minimum controller firmware versions for stable third-party software integration. Running below minimum firmware is a common source of intermittent communication failures that are difficult to diagnose after go-live. Confirm firmware before installation, not during commissioning.
Network interface availability. Some controller models share the external control network port with the teach pendant or with safety monitoring. Confirm whether the external control interface requires a dedicated port or can share the existing network connection. Shared ports can create timing conflicts that manifest as motion delays under load.
Safety configuration for external control. Every arm family has a safety parameter set that governs what external software is allowed to command. Confirm that the safety configuration permits the external motion commands the software layer will send — both in terms of speed limits and workspace envelope. Changes to safety configuration require authorized access and may need to be done by a certified service provider for the relevant arm family.
VLAN and firewall rules. Facility networks commonly have VLANs separating OT (operational technology) and IT traffic, with firewall rules that may block the ports the arm controllers use. UDP traffic for EGM and FRI is particularly vulnerable to firewall drops that don't generate obvious errors. Map the required ports for each arm family against the facility network diagram before installation day. These checks take an hour per arm in pre-installation review and prevent go-live delays that can take days to untangle once the arms are physically installed.
Mixed-brand fleets: the normalization challenge
A fleet running three UR10e arms, four FANUC CR-14iA arms, and two Yaskawa HC10 cobots has three different controller interfaces, three different coordinate system conventions, and three different safety configuration approaches. A software layer that sits above all of them needs to normalize across these differences — translating grasp model parameters trained on one arm family into motion references that the other families can execute correctly.
This normalization is the hardest part of mixed-brand fleet software deployment and the part most often underestimated in pre-deployment planning. It's not just about protocol translation — it's about ensuring that a grasp model learned under UR kinematics produces equivalent end-effector behavior when re-expressed under FANUC CR kinematics. Joint-space parameters, approach vector conventions, and force-torque reference frames differ across manufacturers. A propagated model that looks correct in UR space but isn't properly normalized for FANUC will produce pick failures on the FANUC arms that are difficult to diagnose without understanding the normalization layer. Pre-deployment validation of the normalization across each arm family combination in the fleet is not optional — it's the commissioning step that determines whether fleet propagation actually works in a mixed-brand environment.
Payload and reach: checking the physical fit before the software fit
Software compatibility matters only if the physical arm is appropriate for the application. The controller integration work is wasted if the arm's payload budget is consumed by the end effector, or if the reach envelope doesn't cover the full pick zone geometry.
Payload check: net picking payload = arm rated payload minus end effector weight. A UR10e at 10 kg payload with a 3 kg hybrid vacuum/mechanical end effector has a 7 kg net payload. Check the heaviest items in the catalog against this figure. For the FANUC CR-35iA at 35 kg, the same calculation gives more headroom, but the CR-35iA's collaborative speed limits (250 mm/s TCP in PFL mode) mean higher-payload picks take longer in terms of cycle time than a non-collaborative arm at the same payload rating.
Reach check: confirm the arm's reach covers the full pallet pick zone plus the place position without requiring a base repositioning. A UR10e at 1300 mm reach covers a standard 48 × 40 inch pallet from a single base position if the base is positioned correctly. The UR16e at 900 mm reach may require a closer base position that reduces workspace for the operator. The Yaskawa GP25 at 1730 mm reach handles larger pick zones but its higher payload at 25 kg is often oversized for light-goods picking — run the numbers on whether the oversizing is justified by the catalog or simply results in an arm running below its physical optimum.
Network architecture for a mixed-brand fleet
Multiple arm families on the same facility network creates a network architecture problem that's distinct from configuring any single arm. Each manufacturer uses different port ranges, different protocols (TCP socket vs. UDP streaming vs. Ethernet/IP), and different timing requirements for communication latency.
UR arms using RTDE and URScript communicate over TCP on port 30004 (RTDE) and port 30001/30002 for socket control. FANUC R-30iB Plus uses port 60008 for the FANUC Robot Interface and additional ports for KAREL socket connections. ABB EGM uses UDP on a configurable port (typically 6511). Yaskawa MotoROS2 uses ROS2 DDS, which requires multicast or unicast configuration depending on the DDS implementation. KUKA FRI uses UDP on port 30200 by default.
On a flat facility LAN, these different protocols can coexist without issue. On a segmented network with VLAN boundaries and OT/IT firewall rules — which is the correct security architecture for an industrial environment — each arm family's protocol requirements need to be explicitly permitted across the relevant network segments. Map the port and protocol requirements for each arm family against the facility network diagram before installation. This mapping exercise takes 2–3 hours with the facility IT and OT teams and prevents the most common go-live failure mode: arms that are physically installed and mechanically functional but unable to receive control commands because their network traffic is blocked.
Controller versioning and maintenance windows
Software layers deployed against arm controller firmware have version dependencies. The integration tested against Polyscope 5.11 may behave differently on a controller that's been updated to Polyscope 5.14. The ABB EGM interface has changed behavior across OmniCore firmware revisions. FANUC R-30iB Plus socket messaging has changed error-handling behavior across controller firmware versions.
Establish a firmware update policy for the fleet before deployment. The practical options are: (a) freeze controller firmware at the tested-and-validated version and only update after regression testing the integration, or (b) track controller firmware updates and re-validate the integration on each update before pushing to the full fleet. Option (a) is simpler operationally but creates lag on security patches. Option (b) requires a staging environment where firmware updates can be tested against the software integration before fleet deployment. Neither approach is universally correct — it depends on the facility's security posture and the availability of a staging arm for validation. Document the chosen policy before go-live; the alternative is discovering the policy gap when a controller auto-updates during a maintenance window and the integration breaks in production.