CANopen vs EtherCAT vs Modbus for AGV and AMR Systems

Let's admit it. Communication is easy to underestimate in an AGV or AMR project. It usually becomes important only when the vehicle starts moving and several axes, encoders, brakes, sensors, and controllers have to work together.

For a simple transport AGV, the communication load may be modest. Once the system moves to dual steering, four-wheel steering, lifting, or other coordinated motion, response time and synchronization start to matter much more.

CANopen, EtherCAT, and Modbus are all common choices in industrial automation, but they fit very different jobs inside an AGV or AMR. Read this article, we'll explore these three communication protocols one by one in detail and help you choose the best for your agv robot.

CANopen vs EtherCAT vs Modbus at a Glance

Here is a more practical comparison for AGV and AMR applications.

Item	CANopen	EtherCAT	Modbus
Typical Physical Layer	CAN, typically ISO 11898-2	100BASE-TX Ethernet commonly used	RS-485 commonly used for RTU; Ethernet/TCP/IP for Modbus TCP
Typical Data Rate	Up to 1 Mbit/s for CANopen CC	100 Mbit/s	Depends on implementation; RTU commonly uses serial baud rates, while Modbus TCP follows Ethernet speed
Typical Network Topology	Linear bus with short stubs	Line, tree, star and branch topologies	Multi-drop bus for RTU; standard Ethernet topology for TCP
Real-Time Behavior	Deterministic enough for many standard motion-control applications	Highly deterministic and designed for fast cyclic control	Generally less deterministic for tightly synchronized motion
Synchronization Method	CANopen SYNC object can coordinate synchronous PDO communication	Distributed Clocks provide sub-1 μs network-wide synchronization	No equivalent native distributed-clock mechanism
Motion Profile Support	CiA 402 commonly used for drives and motion control	CoE supports CANopen application profiles, including CiA 402	Usually based on vendor-specific register mapping
Multi-Axis Coordination	Suitable for many standard multi-axis AGV systems	Very strong for tightly synchronized multi-axis motion	Better suited to simpler or less time-critical control
Scalability With More Axes	CAN bandwidth and PDO bus load must be checked as axis count increases	High bandwidth and efficient frame processing suit larger axis counts	Response time can increase as more devices or registers are polled
Diagnostics	Object dictionary, EMCY, heartbeat, drive status	Device state, working counter, link and process-data diagnostics	Exception codes, register/status data and vendor-specific diagnostics
Integration Effort	Moderate; mature ecosystem and broad device support	Usually higher, especially for synchronized motion systems	Usually straightforward for basic register-based communication
Typical AGV / AMR Use	Drive motors, steering motors, servo axes	Multi-steering, high-dynamic AMRs, coordinated multi-axis systems	Sensors, I/O, chargers, lifting units, PLCs and auxiliary devices
Best Fit	Standard AGV/AMR motion control	High-performance synchronized motion	Simple control and non-time-critical communication

CANopen for AGV and AMR Motion Control

CANopen is already common in mobile robot drive systems.

It gives the controller a standardized way to exchange speed commands, position data, current values, status information, and faults with the servo drive.

The controller may need to send speed commands to two drive motors while receiving actual speed, current, encoder position, drive status, and fault information. CANopen handles this kind of communication well without requiring an overly complicated network.

CANopen also uses standardized communication objects such as PDO and SDO.

PDOs are normally used for data that needs to move quickly during operation, such as speed commands, torque commands, position feedback, or status information. SDOs are more commonly used for parameter settings and configuration.

For servo systems, CiA 402 is especially important because it defines a standardized drive and motion control profile. This makes it easier to integrate compatible agv servo drives into a controller architecture instead of building every command from scratch.

CANopen is therefore a strong fit for many:

Differential-drive AGVs
Single-steering-wheel AGVs
Dual-steering AGVs
Forklift AGVs
Low-voltage warehouse AMRs
Heavy-duty AGVs running at moderate speeds

It is not the fastest industrial network available. Sure, that matters in some projects. But many AGVs do not actually need extremely short communication cycles between a large number of synchronized axes.

For those systems, CANopen can offer a very good balance between performance, cost, wiring, and development effort. CANopen and CAN bus are also widely used in AGV servo-drive applications because of their robustness and relatively low wiring complexity.

EtherCAT for Higher-Performance AGV and AMR Systems

EtherCAT becomes more attractive when timing and synchronization start to matter more.

Unlike CANopen, EtherCAT is based on Ethernet technology and is designed for fast, deterministic industrial communication. It is particularly useful when several servo axes need to operate together with very small timing differences.

Think of a four-steering-wheel AGV.

The vehicle may have four steering motors and four drive motors. During turning, each steering axis needs to reach the correct angle while each agv drive wheel follows the required speed. If these axes do not coordinate well, the vehicle can experience wheel scrub, steering resistance, unnecessary motor current, or unstable movement.

This is where EtherCAT has an advantage.

Its distributed clock mechanism can support very accurate synchronization between devices. The controller can manage multiple axes with predictable communication timing, which is useful for:

Four-wheel steering AGVs
Omnidirectional mobile robots
High-speed AMRs
Multi-axis lifting and driving systems
Robots requiring tightly coordinated motion
Mobile manipulators with several servo axes

EtherCAT is increasingly used in higher-performance AMR architectures where faster update rates and deterministic timing are needed.

But EtherCAT also comes with a cost.

The controller must support EtherCAT. The servo drives must support it too. Configuration and commissioning can also be more involved than a basic CANopen network.

For a slow-moving warehouse AGV with two drive motors, EtherCAT may be more capability than the application actually needs.

That does not make EtherCAT worse. It simply means communication performance should match the robot architecture instead of being selected only because one protocol looks more advanced on paper.

Where Modbus Fits in AGV and AMR Systems

Modbus is one of the most widely recognized industrial communication protocols. It is simple, mature, and supported by lots of devices.

In AGVs and AMRs, however, its role is often different from CANopen or EtherCAT.

Modbus RTU commonly runs over RS485, while Modbus TCP runs over Ethernet. Both are useful for exchanging status values, parameters, commands, and other relatively straightforward data.

For example, Modbus can be used with:

PLCs
I/O modules
Battery management interfaces
Chargers
Sensors
Auxiliary actuators
Lifting equipment
Monitoring devices

It can also be used with servo drives in some systems. HKT ROBOT servo and motion products, for example, support communication options including CANopen, EtherCAT, Modbus (RS485) depending on the configuration.

Still, Modbus is generally less suitable when several servo axes require tight real-time synchronization.

Communication Needs Change With the AGV Architecture

The drive architecture has a big influence on protocol selection.

A two-wheel differential AGV is relatively straightforward. Each drive motor needs speed or torque control, and the controller adjusts the left and right wheel speeds to steer the vehicle.

CANopen is often enough for this type of system.

A single steering-wheel AGV adds another controlled axis. The steering motor requires position control while the drive motor controls vehicle speed. CANopen still fits well in many cases.

Now add several steering wheels.

A four-wheel steering platform may require coordinated steering angle, wheel speed, encoder feedback, and position updates across multiple servo axes. At that point, network synchronization becomes much more important.

A general guideline looks like this:

AGV / AMR Architecture	Communication	Main Reason
Two-wheel differential AGV	CANopen	Moderate axis count, reliable servo control
Single steering-wheel AGV	CANopen	Drive + steering axis are easy to manage
Dual-steering AGV	CANopen / EtherCAT	Depends on synchronization and update rate
Four-steering-wheel AGV	EtherCAT / CANopen	Multiple steering and drive axes need coordination
High-dynamic AMR	EtherCAT	Faster updates and tighter synchronization
Heavy-duty low-speed AGV	CANopen	High bandwidth often not necessary
Lifting / rotating module	CANopen / EtherCAT / Modbus	Depends on motion complexity
Sensors, I/O and auxiliary systems	Modbus	Simple data exchange is often enough

This is a design guideline, not a fixed rule. Controller support, servo-drive capability, software platform, safety functions, and future expansion should still be checked before the network is fixed.

Speed Is Not the Only Difference That Matters

Protocol comparisons often become too focused on communication speed.

That misses a big part of the engineering decision.

For an AGV designer, integration effort can matter just as much.

A fast EtherCAT network brings little benefit if the existing vehicle controller only supports CANopen. Likewise, selecting a servo drive with a CAN connector does not automatically mean it supports CANopen.

The physical interface and the communication protocol are not the same thing.

A CAN-based servo drive may use CANopen, J1939, or a proprietary CAN protocol. If the vehicle controller expects CANopen, the servo drive must support the same protocol and object structure.

This is one reason protocol compatibility should be confirmed from actual controller and servo-drive documentation rather than from the connector type alone.

The same applies to Modbus.

RS485 describes the physical communication layer. It does not by itself tell you which communication protocol is running over it.

Small details like this can save a lot of commissioning time later.

Protocol Selection Should Start With the Whole Drive System

In reality, communication isn't just a servo-drive specification; it belongs to the whole vehicle architecture.

The agv motor, servo drive, encoder, controller, gearbox, and drive wheel all work together.

For example, an AGV may use an absolute encoder on the steering axis to retain steering position information. The servo drive must support that encoder, while the communication network must allow the controller to command and monitor the steering axis correctly.

The same applies to agv differential drive units.

Motor torque and gearbox ratio determine mechanical output, but the controller still needs reliable speed feedback and command execution to keep the two wheels working together.

At HKT ROBOT, we normally look at the complete application instead of selecting a drive component from load capacity alone. Vehicle weight, payload, speed, wheel diameter, gear ratio, encoder, brake, installation space, and control requirements all affect the final drive-system configuration.

Conclusion

CANopen, EtherCAT, and Modbus all have a place in AGV and AMR systems, but they solve different problems.

CANopen offers a strong balance for many mobile robot servo systems. EtherCAT is better suited to demanding multi-axis motion where synchronization and deterministic communication matter more. Modbus remains useful for simpler communication and auxiliary devices.

The important part is not choosing the most powerful protocol. It is choosing one that fits the servo system, controller, vehicle architecture, and actual motion requirements.

For AGV and AMR designers, that usually leads to a more reliable system — and much less trouble during commissioning.

At HKT ROBOT, our servo and drive solutions support different communication options, including CANopen, EtherCAT, and Modbus (RS485). The protocol can be selected based on the control system and vehicle architecture, so the motor, servo drive, encoder, gearbox, and communication interface work together as one complete motion system.

If you're planning a new agv or amr project, contact us with your vehicle specifications for a suitable motor, drive, gearbox, and wheel configuration.

Frequently Asked Questions

1. Can CANopen and EtherCAT be used in the same AGV?

Yes. A vehicle can use different communication networks for different subsystems. For example, EtherCAT may handle synchronized servo axes while CANopen connects local drives or auxiliary modules. The controller architecture must support both networks.

2. Can one CANopen bus control both steering motors and drive motors?

Yes. Multiple servo drives can share one CANopen network, provided the node count, PDO configuration, bus load, and update rate are properly designed. The practical limit is often set by required control-cycle performance rather than the physical number of nodes.

3. Does EtherCAT reduce AGV wheel slip?

No. EtherCAT can improve command synchronization, but wheel slip is mainly a mechanical traction issue. Wheel material, normal load, acceleration, floor condition, and drive torque have a much larger effect.

4. Should the communication protocol be selected before the servo drive?

Usually they should be selected together. The vehicle controller, servo drive, encoder interface, supported motion modes, safety functions, and communication protocol all need to be compatible. Choosing one component first can create unnecessary integration work later.

5. Is CANopen still suitable for high-payload AGVs?

Payload alone does not determine the protocol. A 20-ton AGV moving slowly with a limited number of axes may still work well with CANopen. Motion complexity and synchronization requirements matter more than vehicle weight.

6. What happens if the AGV controller and servo drive use different CANopen profiles?

Integration may become much more difficult. Even if both devices support CANopen, the supported object dictionary, CiA 402 implementation, PDO mapping, operating modes, and vendor-specific objects still need to be checked.