A Solution to the Generalized ROS Hardware IO

Problem – A Generic Modbus/TCP Device Driver

for PLCs, Sensors and Actuators
Arne Wendt Prof. Dr.-Ing. Thorsten Schüppstuhl
Institute for Aircraft-Production-Technology Institute for Aircraft-Production-Technology
Hamburg University of Technology Hamburg University of Technology
Hamburg, Germany Hamburg, Germany
0000-0002-5782-3468 0000-0002-9616-3976
arXiv:2112.11102v1 [cs.RO] 21 Dec 2021

Abstract—The Robot Operating System (ROS) provides a [4], the ROS-Industrial [5] consortium aims to bring ROS to
software framework, and ecosystem of knowledge and community industrial applications and integrate industrial hardware into
supplied resources to rapidly develop and prototype intelligent the ROS ecosystem. Industrial applications, especially automa-
robotics applications. By standardizing communication, configu-
ration and invocation of software modules, ROS facilitates reuse tion in production and handling, are starkly characterized by
of device-driver and algorithm implementations. Using existing their interaction with and physical manipulation of the real
implementations of functionality allows users to assemble their world. Thus, for a successful application of ROS in industrial
robotics application from tested and known-good capabilities. application, there exists a strong demand for integration of
Despite the efforts of the ROS-Industrial consortium and projects actuators and sensors of different modalities.
like ROSIN to bring ROS to industrial applications and integrate
industrial hardware, we observe a lack of options to generically Even tough these components are readily available, and
integrate basic physical IO. In this work we lay out and provide a usually implement well defined and standardized interfaces,
solution to this problem by implementing a generic Modbus/TCP we observe a lack of options to integrate this wealth of existing
device driver for ROS. sensors and actuators from (not limited to, but especially)
industrial applications into the ROS environment in a generic
I. I NTRODUCTION
way. This deficiency is as far ranging, as the integration of
The Robot Operating System (ROS) is a meta-operating sys- a simple button or switch poses a serious hurdle in ROS
tem for robots. It shall provide users with ”hardware abstrac- application development. To our knowledge, no solution to
tion, low-level device control, implementation of commonly- this broader problem, providing IO integration with sufficient
used functionality, message-passing between processes, and scalability, portability and flexibility, exist within the ROS
package management” [1]. Supplied by either ROS itself, or ecosystem today.
as community supplied resources. By building an ecosystem With the following work we want to show a way, and
of knowledge and supplemental community supplied software provide the accompanying tools (software), we deem an ac-
resources, it allows to rapidly assemble and prototype intel- ceptable solution to the problem stated above; in industrial, as
ligent robotics applications. By standardizing communication, well as research and hobbyist applications.
configuration and invocation of software modules, ROS fa-
cilitates reuse of device-drivers, algorithm implementations II. H ARDWARE D RIVERS IN ROS
and tooling. Using existing implementations allow users to Reviewing the official ROS community resources [6] and
assemble their robotics application from tested and known- [7], the ROS industrial resources [8], as well as publicly
good capabilities. available projects on [9], we identify five main categories of
ROS has a strong focus on service-robotics and intelligent drivers: 1
autonomous mobile robotics application, providing out-of- 1) 2D vision sensors (cameras)
the-box solutions to common high level problems like e.g. 2) 1D - 3D depth sensors: mostly LIDaR, ToF and stereo-
path-planning, navigation and execution of (mostly) wheeled vision
locomotion, using the navigation stack [2], as well as tra- 3) Robotic arms/manipulators
jectory planning and execution for multi-axis manipulators 4) Vendor specific ”robotics” platforms
and grippers using MoveIT [3]. These high level solutions
1 We abstain from providing a (exemplary) list of reviewed driver, as we
are complemented by sensor-drivers, enabling the necessary
are neither conducting a systematic review, nor do we believe that a - under
perception for the planning tasks and subsequent execution. all circumstances non-exhaustive - list would be of particular benefit to the
Founded In 2012, and supported by projects like ROSIN reader
978-1-7281-2989-1/21/$31.00 ©2021 IEEE

©2021 IEEE. Personal use of this material ispermitted. Permission from IEEE must be obtained for all other uses, in anycurrent or future media, including
reprinting/republishing this material foradvertising or promotional purposes, creating new collective works, for resaleor redistribution to servers or lists, or
reuse of any copyrighted componentof this work in other works. DOI:10.1109/ETFA45728.2021.9613662
 5) non-ROS-enabled wrappers for (field bus) communication
protocol implementations Hardware General Purpose
GPIO Comm. Protocol Computer
The last category mostly just wraps libraries for ROSs’
dependency management and build system (catkin) and is of
no further interest here. Device A
We can further classify the first four driver categories by

Driver

ROS
the following properties: ...
A well defined hardware-interfaces with same semantic
output (data class) and small variable-parameter-vector Device N
B high market penetration of targeted hardware, or low
availability of competitive products
Where an example for category A would be the usb_cam
Fig. 1. Schematics of information flow from hardware IO to ROS, showing
driver [10], providing an interface from v4l/v4l2 (Video components and properties to identify, as well as their relations and interfaces;
for Linux (2)) compatible cameras to ROSs’ standardized class or set of GPIO capable hardware, as Device A to Device N
sensor_msgs/Image format. Category B would be cov-
ered by (mostly) vendor specific drivers for e.g. LiDAR-
Scanners, like SICK(cmp. [11]), or Intel Realsense depth to the two generic interface modalities, logic IO for discrete
cameras (cmp. [12]). The two categories are non-exclusive binary states, and analog IO for the representation of a closed
though: Common drivers for each (most) all e.g. ABB or continuous interval of values, it is trivial to see property A to
Universal Robots industrial robotic arms (cmp. [13], [14]), not apply in this case as well.
or iDS uEye cameras (cmp. [15]), fit both categories. The lack of physical interfaces on current computing plat-
The first category poses a high incentive for the community forms poses a serious technical hurdle to the implementation
and community developed drivers, as standardized interfaces of ROS drivers for sensors and actuators; without additional
usually increase the available options and this decrease the hardware and specifications, an integration is impossible.
price; ultimately increasing availability and accessibility. The The lack of a ubiquitously available hardware interface, and
second category allows for two driving mechanism in driver knowing property A to not apply, further lowers the interest
development: First, manufacturers targeting the ROS com- of the community to drive a generic driver development.
munity as a market. Second, a demand for specific sensor To provide a solution to the generalized problem of a
modality or properties, driven by the community. flexible, portable and scalable hardware IO integration into
ROS has ever been targeting *NIX based computer plat- the ROS ecosystem, we first need to identify a set or class of
forms in general, and the Ubuntu platform in particular [16]. possible hardware interfaces providing the necessary general
It is thus not surprising to observe another common property purpose IO (GPIO) capabilities, a common communications
across the available ROS drivers: protocol to mediate between hardware and software layer,
and subsequently define and implement a generalized software
C ROS drivers target Hardware with interfaces commonly
abstraction on top of its concepts. The general structure of
found on general purpose computing platforms, e.g
which is show in fig. 1
Universal Serial Bus (USB), serial COM interfaces
(RS232/RS485/UART) or Ethernet connections. IV. C HOOSING A H ARDWARE I NTERFACE AND
C OMMUNICATIONS P ROTOCOL
III. P ROBLEM S TATEMENT
Providing general purpose IO capability and transferring
Basic industrial IO components (sensors and actuators) acquired data or accepting setpoint values over a standard-
usually expose their functionality as one input or output ized communications protocol is a common application in
per individual function; either logic/digital (on/off) or analog industrial automation system. Vendors like e.g. Beckhoff, Wago
(continuous range of values). These interfaces adhere to the and Phoenix Contact, provide bus couplers for all major
basic specifications of {5V, 10V, 24V } for digital and logic industrial communication protocols and busses. These devices
IO, and voltage and current signal in the ranges of [0V, 10V ] themselves are then expandable in their IO capabilities by
and [4mA, 20mA] for analog signals as defined by [17], [18]. adding additional IO-modules; the same applies to PLCs. Bus
When comparing the above mentioned interfaces to property coupler and PLC manufacturers usually provide a wealth of
C of available ROS drivers, we can immediately observe a IO modules for their respective platform, enabling sufficiently
problem: general purpose IO in respect to the problem at hand. Conse-
Recent general purpose computing platforms do not quently, for the remaining part of the work, we will assume the
provide individual connections for general purpose device-class of bus couplers to be the best representation of a
logic or analog signal inputs. solution to the hardware-facing portion of the overall problem;
For common IO components or simple applications like mapping GPIOs to a standardized protocol. Further evaluation
switch/contact readout, we can further imagine property B to and selections will be made with bus couplers as the primarily
not be fulfilled. Applying the abstraction of all functionality targeted hardware.

©2021 IEEE. Personal use of this material ispermitted. Permission from IEEE must be obtained for all other uses, in anycurrent or future media, including
reprinting/republishing this material foradvertising or promotional purposes, creating new collective works, for resaleor redistribution to servers or lists, or
reuse of any copyrighted componentof this work in other works. DOI:10.1109/ETFA45728.2021.9613662
 To provide an as generic as possible solution to the gen- TABLE I
eralized problem, we want the following requirements to be M AXIMUM D EVICE N UMBER AND S PECIAL H ARDWARE R EQUIREMENTS
I NDICATION FOR E THERNET BASED C OMMUNICATION P ROTOCOLS
met: ( PARTLY BASED ON [20])
Scalability:
• Support hardware interfaces with an extendable IO count; Protocol Max. no. Devices Special Hardware Required
enabling vertical scalability
Profinet 60 yes
• Support a scalable number of small (cheap) devices to
EtherNet/IP 90 yes
increase IO count; enabling horizontal scalability
Modbus/TCP - no
Portability: EtherCAT 180 yes
• Not target one specific device OPC UA - no
• Not target vendor-specific hardware or communication MQTT - no
protocols
• Prefer technical solutions without the need for specialized
communications hardware With the results, as given in table I, we can further narrow
• Be hardware-agnostic regarding the hardware platform the selection to the three solutions not capping the maximum
running ROS device number and not requiring special hardware for opera-
• Shall use commonly available hardware interfaces on the tions.
hardware platform running ROS, e.g. USB, serial COM, 1) Protocol Overview: Properties of the three remaining
Ethernet or WiFi contenders will be described briefly; focusing on conceptual
Flexibility: differences and feature set, as well as a short analysis on the
• Provide a single integrated conceptual solution to generic
availability of protocol implementations in suitable hardware
logic and analog IO devices.
• Allow for mapping of hardware/protocol data to basic
OPC UA: The OPC Unified Architecture defines a layered
ROS message types and topic trees architecture for communications between devices [23]. While
the specification mostly defines concepts and behaviors, stan-
A. Communications Protocol dardized mappings ( [24]) to concrete technical implementa-
Bus couplers and PLCs usually implement fieldbus in- tions exist and provide the flexibility to choose the application
terfaces. The resulting challenge is the identification of an specific optimal technologies. At its core, OPC UA specifies
interface to be used in combination with the hardware running a methodology for information modelling, specified in [25].
ROS. As analyzed by [19], recent developments of fieldbuses With this information model, OPC UA allows to describe,
- and communication protocols in industrial applications in among other information, the available data/variables to be
general - show an increase in the use of ethernet media access read from and written to a server (device), modelling e.g.
(MAC) and physical layer (PHY). Reviewing the current hierarchical relationships and annotating values with datatype,
bus coupler offerings of major manufacturers (as above in physical unit and a (unique) name/identifier. Providing a
section IV) we support these findings, while simultaneously descriptive information model of the provided data is a highly
identifying Ethernet and RS232/RS485 based solutions as desirable trait of the OPC UA communication stack, as it
the only commonly available protocols with a suitable PHY. allows for automatic and dynamic configuration of a driver
As manufacturers are increasingly adopting ethernet based (or client in general) from the devices’ information model.
solution, and serial COM ports are on the decline on recent Implementations of OPC UA servers are commonly avail-
computer hardware, we rule out the use of serial COM able in recent PLCs. Reviewing the functionality of imple-
protocols in favor of ethernet based solutions. mentations provided by Wago, Beckhoff and Siemens, we find
The resulting list of commonly available and standardized that only variables present in a PLC program may be exposed
communication protocols using an ethernet PHY, providing over OPC UA. No direct access to IO modules attached to
cross-vendor-compatibility, is given as column one of table I. the PLC is possible via OPC UA without mapping these to
Analyzing the properties of the potential candidates, with the a variable. While OPC UA server support in PLCs seems in
help of [19]–[22], we can further compare their benefits and place, reviewing the OPC foundations’ list of certified products
deficiencies and select an optimal solution to our problem. [26], we identify only a single device2 implementing bus
The compared properties and their rating will be made in coupler like behavior and exposing its attached IO modules
reference to the satisfaction of our requirements. We identify directly via OPC UA.
the following parameters and their associated impacts as a first MQTT: The Message Queuing Telemetry Transport
set of filters relevant to our problem and requirements: (MQTT) [27] provides means of network communication built
on the TCP/IP stack, targeted at IoT applications. MQTT is
• Maximum number of devices per protocol; impacts scal-
a pure transport and messaging implementation and does not
ability and portability to existing environments
define payload data serialization. Without a standardized and
• Requirement for special hardware; impacts portability
requirements 2 Beckhoff EK9160

©2021 IEEE. Personal use of this material ispermitted. Permission from IEEE must be obtained for all other uses, in anycurrent or future media, including
reprinting/republishing this material foradvertising or promotional purposes, creating new collective works, for resaleor redistribution to servers or lists, or
reuse of any copyrighted componentof this work in other works. DOI:10.1109/ETFA45728.2021.9613662
widely adopted serialization, MQTT alone cannot ever satisfy has good support on PLCs, support in bus couplers – as
our requirement for flexibility. Sparkplug [28] is a specifica- object of consideration (compare section IV) – is negligible.
tion for topic organization of the MQTT publish-subscribe- The overall support of MQTT is considered negligible as
architecture and serialization of MQTT payloads, intended to well. The low number of hardware options supporting vertical
provide compatibility of devices and applications in industrial scalability, makes both OPC UA and MQTT not fulfill our first
IoT (IIoT) applications. Sparkplug provides means to discover requirement of portability and thus effectively not satisfying
device capabilities and provided data, as well as device/node the requirement of vertical scalability itself. Modbus/TCP,
discovery on the network. on the other hand, constitutes a technically inferior solution,
While MQTT alone and in conjunction with Sparkplug seem while showing significantly higher adoption and availability
to provide a desirable performance over competing protocols of supported hardware, thus fulfilling the requirements of
(cmp. [21], [22]) we are unable to identify a serious3 number portability and vertical scalability. The fitness for horizontal
of devices implementing Sparkplug. scalability, usually enabled by low cost – commonly implying
For the remainder of this work, MQTT will be used to refer low resources – of supporting devices, can be assumed to
to the combination of MQTT and Sparkplug. be inversely proportional to the complexity of a technology.
Modbus/TCP: Modbus/TCP, at its core, allows to call Assessing each protocols complexity in comparison to each
defined methods on a remote device and receive the corre- other, we can establish following order from least complex to
sponding function call result. Methods for data access build most: Modbus/TCP, MQTT, OPC UA. Using this scale as an
on the Modbus data model; both specified by [29]. This basic indicator for horizontal scalability, Modbus/TCP constitutes
data model distinguishes between bit and register values, while the preferred choice.
methods for read and write operation for each singular or Based on the above evaluation, we identify Modbus/TCP as
multiple of these values are provided. While Modbus does the currently optimal solution to our problem, and choose it
not provide any standardized means to communicate meta as the common denominator for integrating hardware IO with
information like data type or physical unit, Modbus/TCP current general purpose computing hardware running ROS.
enabled devices commonly adhere to the data types specified As its core functionality, Modbus/TCP allows read and write
by IEC-61131-3 [30]. access to memory regions – usually representing IO states or
Apart from specialized Modbus/TCP-bus couplers, virtually program variables – on a device. While not specifying data
all PLCs and bus couplers with an ethernet connection provide types and being able to deduce the data type from register
a Modbus/TCP server/slave implementation. Modern PLCs data itself, most Modbus/TCP enabled devices adhere to the
using a IEC-61131-3 compatible runtime, without a vendor data types specified by IEC-61131-3. While the nature of Mod-
supplied server, may add Modbus/TCP compatibility as a bus/TCP requires the specification of addresses to be polled
software package/module [31]. for data, thus demanding additional efforts for configuration,
2) Protocol Selection: As all three protocols are publicly this property allows to map these individually requested values
available and open standards, and are either based on – to ROS topics with a specified data type.
or provide capability to leverage – standard ethernet based Being an old protocol, in comparison to its contestants,
communications, we assume all three to directly satisfy all Modbus/TCP still has wide support - not limited to industrial
but our first requirements in regards to portability. Further, applications. Internet of Things (IoT) cloud solution providers
all protocols do support transmission of individual data points like Microsoft Azure [32], AWS IoT SiteWise [33] or Alibaba
and types for representation of analog and digital IO, thus Link IoT Edge [34], support data integration for Modbus/TCP
satisfying our requirements in relation to flexibility. devices.
MQTT and OPC UA, each seem to provide technically opti-
mal solution to the integration and exchange of IO information
B. Hardware Compatibility Consideration
with hardware acquisition devices, for the problem at hand.
Both provide bidirectional data transmission, either explicit Our requirements for portability forbid the selection of spe-
or implicit discovery mechanisms, and data typing. The goal cific hardware devices. Consequently the hardware interface
of providing an actually applicable solution, prohibits the is represented by a class of devices implementing our chosen
evaluation of communication protocols independently of the communications protocol.
availability of suitable hardware. The fulfillment of our re- The simplicity of the Modbus/TCP protocol and its founda-
quirements relating to scalability is tightly coupled to hardware tion on the TCP/IP protocol stack allow for good compatibility
availability, and cost/simplicity of protocol implementation on across a wide range of platforms. As support and availability
devices to enable horizontal scalability. of implementations in PLCs and bus couplers has been the
Based on the analysis of available implementations in driving factor in the protocol selection, compatibility for these
hardware, we conclude that neither OPC UA nor MQTT are classes of devices is granted.
sufficiently supported by available hardware. While OPC UA For horizontal scalability, low cost and power IoT devices
3 To the best of our knowledge, only two product lines of PLCs and one
and hardware platforms provide a solution, while receiving
bus coupler do natively support MQTT and Sparkplug; namely groov EPIC good support for Modbus/TCP compatibility. This class of
and groov RIO by Opto 22 and the Wago PFC200 series devices is targeted by operating systems like FreeRTOS [35]

©2021 IEEE. Personal use of this material ispermitted. Permission from IEEE must be obtained for all other uses, in anycurrent or future media, including
reprinting/republishing this material foradvertising or promotional purposes, creating new collective works, for resaleor redistribution to servers or lists, or
reuse of any copyrighted componentof this work in other works. DOI:10.1109/ETFA45728.2021.9613662
with available ports of Modbus/TCP clients like FreeMOD- /device ROS Modbus/TCP Device Driver ROS Topics
BUS [36], as implemented e.g. by the ESP-IDF (Espressif IoT std_msgs/Bool
/device/out_Z
Development Framework) [37] for the ESP32 System on Chip

Coils
platform. Bringing Modbus/TCP capability to these low power
and low cost microcontroller platforms, increases availability
and allows horizontal scalability through low cost. std_msgs/Bool

Discrete Inputs
/device/in_A

Modbus/TCP Device

Registers / Memory
Generally, all device and operating system combinations
providing a TCP/IP protocol stack are able to serve as the
base for a Modbus/TCP IO device.

Input Registers
V. I MPLEMENTATION std_msgs/Float64
t(v,T) /device/measure_v
Despite the listing of Modbus/TCP as a hardware interface
protocol in the proposed ROS Industrial roadmap, since at

Out.Reg.
least 2015 [38], [39], there exists no generic implementation
of a driver for the ROS ecosystem.
To provide a solution to the generalized IO problem, based
on Modbus/TCP, we choose to implement a driver with the Fig. 2. Basic ROS Modbus/TCP driver principle. Mapping Modbus/TCP
items to individual ROS topics. Data interpretation from registers show as
following major properties: conversion-method t, converting from register value v to ROS compatible
• each driver-node instance represents each one slave de- representation with data type T .
vice or subset of a slaves’ mapped IOs
• each driver with associated mapping uses an individual TABLE II
topic namespace IEC 61131-3 TYPES TO ROS std_msgs MAPPING
• map each configured IO to a separate topic
• support read access for discrete inputs and input regis- IEC 61131-3 std_msgs/ IEC 61131-3 std_msgs/
ters(status registers) BYTE Bool[8] DWORD Bool[32]
• support read/write access for coils and output regis-
WORD Bool[16] LWORD Bool[64]
ters(holding registers)
• perform data conversion for register data from IEC
SINT Int8 DINT Int32
61131-3 to ROS std_msgs types (or arrays thereof) INT Int16 LINT Int64
and vice versa USINT UInt8 UDINT UInt32
The first three properties achieve a separation of concerns in UINT UInt16 ULINT UInt64
functionality and allow to follow ROS’ ideas of reusability and REAL Float32 CHAR Char
composition. The remaining properties establish a sufficient LREAL Float64 STRING String
base functionality for a generic driver in the targeted domain.
Mapping IOs to their own topics each is the best representation
of our generic driver approach, while enabling integration of
is implemented. For this we will use the simplified and
IOs via ROSs’ topic remapping functionality.
abstracted class relationship diagram from fig. 3, omitting
fig. 2 shows an example of the drivers functionality. We
intermediate classes responsible for state management and
map a Modbus/TCP device to ROS namespace /device, a
implementing behaviors not relevant to the overall operation
coil (logic output) as /out_Z, a discrete input as in_A and
principle. We further want to assume all behavioral differences
a 4 word (8 bytes) wide input register as /measure_v. The
to be implemented by class inheritance and specialization,
4 words of the input register are interpreted as IEC 61131-3
while implementing the shown interfaces in fig. 3. We begin
LREAL (long real, 64bit floating point number), corresponding
with a brief description of the non-ROS classes, followed by
to ROSs’ std_msgs/Float64. The driver polls the slave
a description of the process for reading and writing data.
device at a constant rate and publishes the acquired values
to the mapped topics. On reception of messages on a topic
mapping an output, the received value will be transformed The driver itself provides an abstraction over one
if necessary, by applying the inverse of t (compare fig. 2); Modbus/TCP device with a selection of mapped IOs.
compatible and driver-supported (implemented) IEC 61131-3 The ROS node holds and manages an instance of a
types and corresponding ROS std_msgs types are shown in ModbusSlaveDevice, provides configuration and manages
table II. ROS publishers und subscriptions (rospy.Publisher and
rospy.Subscriber in fig. 3).
A. ROS to Modbus/TCP interface ModbusSlaveDevice: Abstracts a Modbus/TCP de-
Following, we will give an overview of how the data vice. Manages and persists a connection to the Modbus/TCP
acquisition process from a slave device to ROS topics, slave, holds class instances of all mappings from Modbus
and the process of writing data from a topic to a slave addresses to ROS topics and associated RangeReaders.

©2021 IEEE. Personal use of this material ispermitted. Permission from IEEE must be obtained for all other uses, in anycurrent or future media, including
reprinting/republishing this material foradvertising or promotional purposes, creating new collective works, for resaleor redistribution to servers or lists, or
reuse of any copyrighted componentof this work in other works. DOI:10.1109/ETFA45728.2021.9613662
 ModbusSlaveDevice L ISTING I
- client : ModbusClient
E XAMPLE DEVICE MAPPING , CORRESPONDING TO THE EXAMPLE
DEPICTED IN FIG . 2
- mappings [] : Mapping
+ fetch () name: device
+ write (name, value) : str, <T>
address: mbdev
unit: 1
<<Interface>>
RangeReader
rate: 20
<<Interface>>
Mapping - inputs [] : Mapping mapping:
+ read (client) : ModbusClient coils:
- name
- address out_Z: 1
- callbacks [] : function <<Interface>>
+ decode (decoder) : Decoder Decoder
discrete_inputs:
+ write (client, value) : in_A: 10001
ModbusClient, <T> - data: bytes
+ decode () input_registers:
measure_v:
address: 30001
rospy.Publisher type: LREAL
rospy.Subscriber
+ topic
+ publish (data) : <T> + callback : function

Fig. 3. Simplified and abstracted class relationship diagram of the Mod-

fetch() method. This in turn triggers the individual pro-
bus/TCP slave device wrapper ModbusSlaveDevice. cesses described above: Triggering all read() methods of
the RangeReaders, which will start the decoding process for
all mappings on data reception, in turn leading to a call of the
The fetch() method triggers read operations for all publish() method of the respective rospy.Publisher.
RangeReaders.
Mapping: Each input and/or output and its associated B. Configuration
topics are represented by a class instance implementing the Creating a device abstraction and mapping its hardware IOs
Mapping interface. Mappings are (for the sake of simplicity, to ROS topics, is accomplished by defining the abstraction
assumed to be) specialized on discrete inputs, input registers, as device configuration. The configuration may be supplied
coils and output registers, as well as the type of register data. in ROSs’ standard configuration file format YAML, or JSON.
The decode() method will fetch the registers’ value from Assuming a slave with hostname mbdev, Modbus unit 1
a Decoder and call all associated callbacks with the and matching IO addresses, we can create a device mapping,
decoded value. Calling write() method will encode the representing the example in fig. 2 as in listing I.
passed data according to type and instantly trigger a write
operation to the Modbus/TCP slave. The complete drivers’ implementation can be acquired and
RangeReader: Aggregates read operations for multiple studied at [40].
Mappings to one read operation of a continuous memory
region, reducing polling operations and network traffic. De- VI. P ERFORMANCE A NALYSIS
pending on slave behavior, reads from discontinuous memory Translating from ROS messages to Modbus/TCP and vice
regions can be aggregated while discarding unmapped mem- versa, we will use the time difference between TCP-packets,
ory. for ROS messages to Modbus/TCP write-request, and Mod-
Decoder: Container, owning and representing the raw bus/TCP read-responses to ROS messages, being available
data returned by a RangeReaders’ read() operation. on the network as the relevant performance metric. Read-
Implements data decoding functionality from raw data to and write requests from the driver node will be handled
requested type. Mappings decode their value from the by a dummy Modbus/TCP slave, accepting all request and
Decoder depending on type. responding with a success-responses, returning 0-values in
1) Writing Outputs: The driver node attaches the respec- case of read operations. All data is generated and captured in
tive Mappings’ write() method as callback function to its own docker container, transferring data over the container
a ROS subscriber (rospy.Subscriber) instance for the internal loopback interface. Each container is running the
associated topic. The Mapping class specialization handles complete software stack necessary for data acquisition, where
encoding of the data in relation to its type and triggers a write n is the number of configured inputs or outputs for the case
operation on the provided ModbusClient instance. examined:
2) Reading/Polling Inputs: Polling a slave is performed • 1 local roscore
by the driver node by calling the ModbusSlaveClients’ • 1 driver node

©2021 IEEE. Personal use of this material ispermitted. Permission from IEEE must be obtained for all other uses, in anycurrent or future media, including
reprinting/republishing this material foradvertising or promotional purposes, creating new collective works, for resaleor redistribution to servers or lists, or
reuse of any copyrighted componentof this work in other works. DOI:10.1109/ETFA45728.2021.9613662
 TABLE III Experiments yield a ∆t0 = 158µs(σ = 17µs) for writing
P ERFORMANCE EVALUATION RESULTS FOR discrete inputs AS DESCRIBED coils, and ∆t0 = 163µs(σ = 15µs) for holding registers.
IN SECTION VI-A

VII. D ISCUSSION
No. Inputs ∆t0 ∆tP
By providing a generic implementation of a Modbus/TCP
1 341µs (σ = 94µs) - driver for ROS we provide a solution to the generalized IO
32 471µs (σ = 192µs) 182µs (σ = 9µs) problem in ROS. While the provided driver only abstracts the
workings of the communication protocol and data interpre-
TABLE IV tation (i.e. handling byte and word orders), we believe this
P ERFORMANCE EVALUATION RESULTS FOR input registers AS DESCRIBED to be of great benefit to ROS developers. Using the driver,
IN SECTION VI-A
ROS developers mostly stay in their domain, using high level
programming languages on general purpose computers, writ-
No. Inputs ∆t0 ∆tP
ing configuration files in standardized formats and interfacing
1 388µs (σ = 86µs) - the ROS by use of ROS topics. Mapping individual IOs as
32 522µs (σ = 203µs) 187µs (σ = 10µs) individual topics allow for great portability and flexibility
while keeping the requirements for the driver low. Adapting
topic descriptors to those required by a specific application
• n rostopic nodes as publisher or subscribers can easily be achieved using ROSs’ remapping methods;
• 1 Diagslave [41] Modbus/TCP slave simulator thus allowing simple code and application component reuse.
• 1 tshark (Wireshark) instance for data capture Aggregating data from multiple individual IOs to higher
This test setup allows to capture measures for the actual delay level message/data types, conveying semantic information, we
introduced by the driver and the ROS stack, while being consider trivial in the instant all data is available to a developer
independent of network induced delays and the performance via ROS topics.
of the used Modbus/TCP slave. Even though Modbus/TCP may seem like an outdated
Reading and/or writing occurs at a frequency of 10Hz, choice and solution for the problem at hand, it is the most
while capturing network traffic for 100s, resulting in each widespread protocol understood by suitable hardware devices,
1000 individual read or write operations to be evaluated. All when compared to OPC UA and MQTT as the identified
containers are ran with a limit of 1GB RAM and 2 CPUs, competitors. Modbus/TCPs’ simplicity results in good com-
running on a Windows 10 Pro host machine with an Intel® patibility with a number of devices and allows good horizontal
Core™ i7-8550U @ 1.80GHz CPU and 8GB of RAM. scalability of the solution across devices. With IoT cloud ven-
dors supporting Modbus/TCP (compare section II), we do even
A. Reading expect to see an increase in Modbus/TCP implementations
To evaluate read-performance, the driver node is configured for low cost devices. The simultaneously good support for
for either one or 32 discrete inputs or input registers. For Modbus/TCP in industrial applications and good availability
input registers, interpretation of a registers’ value as a 16 bit of bus couplers and compatible PLCs ensures applicability of
integer value is chosen. Reading coils or holding registers our solution in industrial applications. This support, combined
uses the same implementation as discrete inputs or input with the wealth of available IO modules, further ensures a high
registers and is thus not evaluated individually. For all inputs flexibility in IO choices and rapid prototyping of applications.
each one rostopic subscriber is instantiated. The average time The performance evaluation shows the introduction of a
difference between Modbus/TCP read-responses and first (or time delay < 0.5ms for the first value of a Modbus/TCP
only) ROS-message ∆t0 and average time difference between read-request to be available on the ROS network, with sub-
subsequent ROS-messages ∆tP , for each single- and 32-value sequent readings of a request being available after < 0.2ms
read operations, is given in table III for discrete inputs and consistently. In our experience, these values are at least an
table IV for input registers. order of magnitude lower than the response times of actual
Modbus/TCP slaves. The performance penalty introduced by
B. Writing the driver is thus assumed to be negligible in ROS applications.
Publishing to the /write topic associated with an out- We have successfully used our solution with multiple Wago
put will directly invoke a write request to the Modbus/TCP and Beckhoff PLCs and bus couplers, each with a range of
slave; thus, only single value writes are technically possible different IO modules. The created IO capabilities have been
and evaluated. For each evaluation, a rostopic publisher is used to control and read e.g. a robotic gripper, switches and
instantiated, writing the value 0 (or the boolean equivalent high resolution distance sensors. The integration of each new
false). For writing holding registers std_msg/Int16 is device being in the range of minutes.
chosen as datatype, as in section VI-A. Evaluating write
performance, analogously to section VI-A, ∆t0 represents the VIII. C ONCLUSION
time difference between a ROS-message and the associated We have delivered the concept and necessary implemen-
Modbus/TCP write-request being available on the network. tation of a solution to the generalized problem of hardware

©2021 IEEE. Personal use of this material ispermitted. Permission from IEEE must be obtained for all other uses, in anycurrent or future media, including
reprinting/republishing this material foradvertising or promotional purposes, creating new collective works, for resaleor redistribution to servers or lists, or
reuse of any copyrighted componentof this work in other works. DOI:10.1109/ETFA45728.2021.9613662
IO integration into ROS systems. All while delivering a solid [16] T. Foote and K. Conley, Target Platforms, ROS.org Std. ROS
rationale for the choice of Modbus/TCP as the underlying REP-0003. [Online]. Available: https://www.ros.org/reps/rep-0003.html
[17] Analogue signals for process control systems; Part 2: Direct Voltage
technology. Signals, IEC Std. 60 381-2.
As OPC UA and the combination of MQTT and Spark- [18] Analogue signals for process control systems; Part 1: Direct Current
plug do provide significant advantages over Modbus/TCP, we Signals, IEC Std. 60 381-1.
expect these technologies to replace a Modbus/TCP based [19] P. Gaj, J. Jasperneite, and M. Felser, “Computer communication within
implementation in the future. Building on these technologies industrial distributed environment—a survey,” IEEE Transactions on
Industrial Informatics, 2013.
allows to reduce configuration to an absolute minimum by [20] P. Danielis, J. Skodzik, V. Altmann, E. B. Schweissguth, F. Golatowski,
leveraging the information model provided by the server in D. Timmermann, and J. Schacht, “Survey on real-time communication
case of OPC UA and the metrics definition of Sparkplug birth via ethernet in industrial automation environments,” in Proceedings of
the 2014 IEEE Emerging Technology and Factory Automation (ETFA).
certificates respectively. IEEE, 92014.
The main value of this work is seen in the simplicity of the [21] S. Profanter, A. Tekat, K. Dorofeev, M. Rickert, and A. Knoll, “OPC
provided tools, and in presenting and delivering the idea, of UA versus ROS, DDS, and MQTT: Performance evaluation of industry
using standardized industrial protocols to the ROS community; 4.0 protocols,” in 2019 IEEE International Conference on Industrial
Technology (ICIT). IEEE, 22019.
for researchers and hobbyists alike. Being aware of the options
[22] J. Hottell, “Efficient IIoT communications: An OPC UA, HTTP, modbus
available to solve a particular problem and receiving minimal and MQTT benchmarking discussion,” 30.04.2019, unpublished.
support in terms of tooling, has a great potential for keeping [Online]. Available: https://www.cirrus-link.com/wp-content/uploads/
individuals from rolling custom communication protocols over 2019/05/Johnathan-Hottell-IIoT-Protocol-Benchmarks.pdf
[23] UA Specification Part 1 – Overview and Concepts, OPC Foundation Std.
non-scalable communication channels (e.g. using USB/UART 10 000-1, Rev. 1.04, 22.11.2017.
and platforms like Arduino as IO hardware), and thus creating [24] UA Specification Part 6 – Mappings, OPC Foundation Std. 10 000-6,
solutions adhering to the core idea of ROS: Creating reusable Rev. 1.04, 22.11.2017.
solutions to recurring problems. [25] UA Specification Part 5 – Information Model, OPC Foundation Std.
10 000-5, Rev. 1.04, 22.11.2017.
Future Work [26] OPC Foundation. (08.07.2021) Find products. [Online]. Available:
https://opcfoundation.org/products
Future work is expected in the optimization of read
[27] MQTT Version 3.1.1, OASIS Std., 29.10.2014. [Online]. Available:
and write processes, including batch writing of near- http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
simultaneously published output data, and reducing traffic [28] Sparkplug™ Specification: MQTT Topic & Payload Definition, Eclipse
and load on the Modbus/TCP slave by building dynamic Foundation Std., Rev. 2.2, 11.10.2019.
readers and querying subscribed topics only. Further, a notable [29] MODBUS APPLICATION PROTOCOL SPECIFICATION, Modbus Or-
ganization Std., Rev. 1.1b3, 26.04.2021.
improvement of the configuration process may be achieved by [30] Programmable controllers; Part 3: Programming languages, IEC Std.
interpreting the configuration files of Modbus slave simulation 61 131-3.
and testing tools (e.g. WinModbus [42] or UnSlave [43]). [31] CODESYS modbus TCP device SL. [Online]. Available: https:
//store.codesys.com/codesys-modbus-tcp-device-sl.html
R EFERENCES [32] Microsoft. Modbus. [Online]. Available: https://azuremarketplace.
[1] ROS introduction. [Online]. Available: http://wiki.ros.org/ROS/ microsoft.com/en-us/marketplace/apps/microsoft iot.edge-modbus?tab=
Introduction overview
[2] ROS navigation stack. [Online]. Available: https://github.com/ [33] AWS IoT SiteWise launches support for Modbus TCP and EtherNet/IP
ros-planning/navigation protocols with enhancements to OPC-UA data ingestion. [Online].
[3] I. A. Sucan and S. Chitta. Moveit. [Online]. Available: http: Available: https://aws.amazon.com/de/about-aws/whats-new/2020/12/
//moveit.ros.org aws-iot-sitewise-launches-support-for-modbus-tcp-ethernet-ip-protocols/
[4] ROS-Industrial and ROSIN. [Online]. Available: https://www. [34] Connect a modbus slave device to an edge instance over
rosin-project.eu/ros-industrial-and-rosin modbus TCP. [Online]. Available: https://www.alibabacloud.com/help/
[5] ROS-INDUSTRIAL. [Online]. Available: https://rosindustrial.org/ doc-detail/101055.htm
[6] ROS documentation. [Online]. Available: http://wiki.ros.org/ [35] FreeRTOS™: Real-time operating system for microcontrollers. [Online].
[7] ROS discourse – drivers. [Online]. Available: https://discourse.ros.org/ Available: https://www.freertos.org/
c/drivers/54 [36] Embedded Experts GmbH. FreeMODBUS: A portable MODBUS
[8] ROS industrial/supported hardware. [Online]. Available: http://wiki.ros. ASCII/RTU and TCP implementation. [Online]. Available: https:
org/Industrial/supported hardware //www.embedded-experts.at/en/freemodbus/about/
[9] ROS device drivers. [Online]. Available: https://github.com/ros-drivers
[10] usb cam: A ROS driver for V4L USB cameras. [Online]. Available: [37] “ESP-IDF – IoT development framework.” [Online]. Available:
https://github.com/ros-drivers/usb cam https://www.espressif.com/en/products/sdks/esp-idf
[11] sick scan: an open-source project to support the laser scanner of [38] ROS-industrial consortium roadmapping. [Online]. Avail-
the company SICK using the ROS-framework. [Online]. Available: able: https://github.com/ros-industrial-consortium/roadmapping/blob/
https://github.com/SICKAG/sick scan master/RoadmappingDocument.md
[12] realsense-ros: Intel(R) RealSense(TM) ROS wrapper for D400 series, [39] ROS industrial roadmap. [Online]. Available: http://wiki.ros.org/
SR300 camera and T265 tracking module. [Online]. Available: Industrial/Roadmap
https://github.com/IntelRealSense/realsense-ros [40] A. Wendt. (02.11.2020) ros modbus device driver. [Online]. Available:
[13] abb driver: ROS driver for ABB IRC5/RW5 or RW6 controllers. https://github.com/bitmeal/ros-modbus-device-driver
[Online]. Available: https://github.com/ros-industrial/abb driver
[41] Diagslave modbus slave simulator. [Online]. Available: https://www.
[15] ueye cam: A ROS nodelet and node that wraps the driver API for
modbusdriver.com/diagslave.html
UEye cameras by IDS imaging development systems GmbH. [Online].
Available: https://github.com/anqixu/ueye cam [42] Abbeytek Ltd. WinModbus. [Online]. Available: http://www.winmodbus.
[14] Universal robots ROS driver: Driver enabling ROS operation of com/new/
UR robots. [Online]. Available: https://github.com/UniversalRobots/ [43] UnSlave. [Online]. Available: https://unserver.xyz/products/
Universal Robots ROS Driver modbus-slave-simulator/

©2021 IEEE. Personal use of this material ispermitted. Permission from IEEE must be obtained for all other uses, in anycurrent or future media, including
reprinting/republishing this material foradvertising or promotional purposes, creating new collective works, for resaleor redistribution to servers or lists, or
reuse of any copyrighted componentof this work in other works. DOI:10.1109/ETFA45728.2021.9613662