allows graph node-edge-based generalized communications.
HAL modulates the system’s actual implementation, which
may depend on specific hardware or programming language,
and improves compatibility with other systems and reusabil-
ity. Node connections can be inter-device since ROS 1
uses a custom TCP/IP protocol, and ROS 2 is based on
Data Distribution Service (DDS), which is more secure and
appropriate for industrial use cases [1]. However, ROS itself
does not provide robotic system architectures, and the user
should design graph communications. Even though a robot is
compatible with ROS, it does not mean it is indeed developed
using ROS inside, but the ROS node is prepared for a generic
external communication medium.
Yet Another Robot Platform (YARP) is an open-sourced
middleware to provide HAL and unified communications
between modules along with robotics libraries to provide
control infrastructure of the robots [6].
In industry, proprietary platforms and programming lan-
guages are developed for a particular family of products, such
as KUKA Robot Language (KRL) for KUKA robot arms [7],
and B&R Automation Studio for their programmable logic
controllers (PLC) [8]. They provide uniform and abstracted
access to devices with integrated robotics API libraries
and safety systems, although proprietary systems require
licensing and specific hardware.
B. Hardware Oriented Middleware
Open Robot Control Software (OROCOS) is an open-
sourced robotic control framework focused on real-time
performance [9]. Although ROS 2 has enhanced real-time
capability, OROCOS has superior latency and jitters in Inter-
Process Communication (IPC), particularly with modified
Linux kernels such as Xenomai [10]. OROCOS framework
includes standard APIs for robotics in C++, such as kine-
matics, Bayesian filtering, state machines, etc.
IPC can restrict the system’s real-time operation and cyclic
speed since data cannot be referred by memory address, and
the data must be copied and serialized to another process
[11]. Hard real-time system guarantee a response time with
a certain maximum deviation, while soft real-time system
bounds average response time [12]. Many attempts toward
soft real-time requirements, including OROCOS, have been
done in RT-Middleware [13] and TZC [11].
Hard real-time is significantly strict and requires low
latency hardware, a real-time operating system (RT-OS),
and strict time synchronization, primary for safety purpose
[12]. The automation industry has developed proprietary
PLC to achieve low-latency hard real-time programming
environments by custom designing from hardware to RTOS,
such as B&R Automation studio [8]. XBotCore is an open-
sourced hard real-time software platform for EtherCAT-based
robots [14].
One of the most successful educational purpose middle-
ware is the LEGO Mindstorms series [3]. Their Graphical
Programming Language (GPL) is suitable for students and
beginners unfamiliar with programming. The GPL grants a
coding environment as if the users are assembling bricks. For
more advanced users, LEGO Mindstorms supports C++ and
Python. However, their costs, limited simulation, and propri-
etary hardware barriers introducing them into classrooms or
moving onto different or custom hardware.
C. Middleware for Multi-Agent and Cloud Robotic
Various middleware has targeted to enhance HAL into
a robot, task or team scale to simplify programming at
different levels and modulate them to reuse. Task-level GPLs,
RAZER, etc., are toward end-users so they can program
a robot during operations and without an engineer [15].
They can help facilitate automation and robotics technolo-
gies to lesser-technical creative industries with human-robot
interaction in mind [16]. ManiWare is dedicated to team-
level abstraction and synchronization for manipulators to
conduct teamwork operations among different arms [17].
CORNET integrates unmanned aerial vehicle physics and
network simulators to realize a cyber-physical system of
multi-agent drones [18].
Cloud robotics offers offloading computation-intensive
tasks and access to cloud resources such as CPU, GPU,
storage, and a global map [19]. Multi-agent and collaborative
robots can benefit from cloud infrastructure. XbotCloud is
a cloud-integrated system designed for XbotCore-operated
robots [20].
III. REMS CONCEPT AND PRINCIPLE
A. Concepts
Our middleware , REMS, design primary concepts are the
following:
•The Zen of Python to robotics
•Provide robotic framework off-the-shelve
•Moduled robot definitions and implementations
•Scalable from one to multi-agent
The concept of Pythonic programming is about simple,
concise, and readable coding. Each class and method have a
clear role in the system. With other common middleware,
learning curves are steep at the beginning because users
should learn the specific syntax, language, process, etc. of the
middleware that are not standard or uncommon elsewhere,
i.e., IDL in ROS. Even setting up and installing a ROS pack-
age is already a significant achievement due to complicated
version dependencies [2]. The robotics domain spreads not
merely to computer science but to people with a mechanical
or electrical engineering background. In education settings, it
can take away vital opportunities to learn more about theories
and algorithms by spending time on technical details that are
only applicable in a limited field area.
Developers should put considerable design efforts into
software architecture to integrate various components in
robotics. Providing a robot control pipeline simplifies the
initial setup and implementation time. The architecture itself
can educate learners on what parts should be in the robot
system as well as basic concepts of programming, such as
abstraction and modularity.
Abstraction in a robot is more complex than said. What
defines a robot to be and what does not, are not clear