From Virtual Trajectory Generation to Real Execution and Validation in a MATLAB-ROS Hybrid Framework for a 6 DOF Industrial Robot

Abstract

This paper presents a lightweight MATLAB-based framework with a graphical interface for modeling, 3D simulation, trajectory generation, and experimental validation of a 6-DOF industrial robot. The platform integrates kinematic modeling using the rigidBodyTree structure, animated visualization, and both predefined and user-defined trajectory planning within a unified environment. A central aspect of the proposed approach is the implementation of a ROS-compatible TCP/IP communication protocol that avoids the need for a full ROS core installation while preserving compatibility with ROS-Industrial standards. This enables bidirectional data exchange between MATLAB and the robot controller within a simplified architecture. Communication performance tests indicate round-trip latency in the tens-of-milliseconds range and consistent StateServer update rates, supporting monitoring, trajectory execution, and digital twin synchronization in non-real-time conditions. Experiments conducted on an ABB IRB120 robot demonstrate a close correspondence between simulated and real motion, with RMSE below 0.0075 rad and MAE below 0.0065 rad across all joints. All data are stored in JSON format to support reproducibility and further analysis. By integrating simulation and real robot execution within a modular architecture, the proposed framework provides a practical tool for education, rapid prototyping, and experimental research in industrial robotics, while offering a basis for future extensions toward advanced control strategies and digital twin applications.

1. Introduction

In the context of Industry 4.0—and its extension into Industry 5.0 emphasizing human–machine interaction, sustainability, personalization, and resilience—the adoption of advanced modeling, simulation, data acquisition, visualization, and real-time communication tools has become essential for both basic automation and fully integrated smart factories [1,2,3,4,5,6]. Technologies such as Artificial Intelligence (AI), Internet of Things (IoT), Augmented Reality (AR), Big Data, and robotics are increasingly embedded into industrial production systems to enhance efficiency and flexibility.

Industrial automation increasingly relies on robotic systems, with over 2.7 million industrial robots operating worldwide as of 2020 [7]. Driven by Industry 4.0, their adoption has expanded robotics research and applications across multiple domains [8]. However, system integration remains complex, requiring reliable modeling and seamless hardware–software interaction. Simulation tools such as MATLAB/Simulink and ROS-based platforms are therefore widely used to enable virtual validation before real-world implementation.

The literature provides extensive contributions on kinematic, dynamic, and joint-level control modeling for industrial robots. Foundational formalisms are presented in [9,10], while forward and inverse kinematics for 6-DOF ABB manipulators have been analyzed using standard and modified Denavit–Hartenberg approaches and validated in CATIA and RobotStudio [11,12]. Additional studies propose geometric inverse kinematics solved directly in MATLAB [13], or rely on the Robotics Toolbox and CAD-based visualization environments [14,15,16,17]. Further works incorporate velocity analysis, dynamics, and trajectory generation using Simscape Multibody, the Robotic System Toolbox, and other MATLAB libraries, often integrating CAD models from AutoCAD, Inventor, or SolidWorks [18,19,20,21,22]. Open-architecture approaches for multi-robot modeling are also reported in [23].

MATLAB remains a widely adopted environment for robotic modeling, simulation, prototyping, and integration with industrial communication protocols such as OPC, MQTT, Profinet, Profibus, Modbus, Ethernet/IP, and TCP/IP [24,25,26,27]. This enables coupling between virtual and physical systems and supports the development of digital twins, such as the TCP/IP-based bidirectional machining system described in [28]. ROS (Robot Operating System [29]) is a widely adopted, continuously evolving open-source ecosystem that supports robotic research, control, trajectory planning, and integration with simulators such as RoboDK, MoveIt, Coppelia, Gazebo, and RViz. Combined with custom interfaces, ROS enables data acquisition, visualization, and human–robot interaction [30,31,32]. Industrial-grade integration is provided through ROS-Industrial (ROS-I [32]), which includes software modules that extend ROS capabilities to commercial robot hardware. However, deploying these frameworks requires advanced installation, configuration, and programming skills, and compatibility issues may arise across ROS versions, packages, and controller-level software options [24,29,32]. In contrast, MATLAB provides an integrated environment that combines modeling, numerical computation, visualization, and rapid prototyping capabilities within a single platform. Unlike simulation environments such as Gazebo, MuJoCo, or PyBullet, which typically require dedicated middleware or programming frameworks, MATLAB enables a more unified workflow, particularly suitable for educational and laboratory contexts where ease of use and rapid deployment are essential.

Recent efforts have explored hybrid MATLAB–ROS architectures to achieve flexible, modular environments for robot modeling, simulation, and control. For example, Ref. [33] demonstrates MATLAB/Simulink–ROS integration for UR5 manipulation with real-time communication between virtual and physical systems. Paper [34] proposes a ROS-based condition-monitoring framework for collaborative robots, emphasizing modular communication in Industry 4.0 environments. Similarly, Ref. [35] integrates MATLAB and ROS for autonomous control and trajectory tracking, highlighting the value of hybrid systems for rapid prototyping. Educational-oriented studies in [36] and [37] further support MATLAB–ROS interoperability, though typically requiring a full ROS middleware installation for node synchronization and execution.

Beyond integration frameworks, recent research in robotic modeling and control has increasingly focused on data-driven and adaptive methods to improve motion accuracy, flexibility, and robustness. For instance, adaptive PID control, neuro-adaptive control, and safe experimentation dynamics algorithms have been applied to flexible-joint manipulators to ensure stable performance under uncertainty [38,39,40]. Reinforcement learning and model-free adaptive control schemes are also gaining traction for trajectory-tracking and dynamic-compensation tasks [41,42]. Moreover, virtual and augmented reality environments are being used to enhance robot programming, path design, and human–robot interaction [43,44,45]. While these approaches advance the intelligence and interactivity of robotic systems, the present work focuses on developing a lightweight MATLAB-based integration framework that can later serve as a foundation for implementing and validating advanced control algorithms.

A lightweight ROS bridge between MATLAB and an industrial robot controller was proposed in this work, enabling hardware-integrated bidirectional communication through a ROS-compatible TCP/IP workflow without requiring a native ROS environment or middleware. This approach maintains the interoperability advantages of ROS while simplifying deployment and improving accessibility for educational and research applications. To demonstrate the platform, a 6-DOF ABB IRB120 robot was used, integrated through the ABB ROS Server Code. The IRB120 is widely employed as a laboratory-grade industrial robot due to its compact size and flexibility, making it suitable for training, development, and testing of advanced robotic applications [46,47,48]. The manufacturer provides extensive resources, including specifications, design and operation manuals, and simulation environments such as RobotStudio and RAPID. Additionally, CAD models in multiple formats are available to facilitate integration into 3D modeling and virtual simulation environments [49,50,51,52,53].

The MATLAB-based application includes a graphical user interface for modeling, 3D simulation, and real-world execution validation and virtualization of a 6-DOF (degrees of freedom) industrial robot, without requiring ROS to be installed on the host computer. In this context, the application comprises several functionalities: (1) kinematic modeling of the industrial robot with predefined trajectory generation and animated 3D simulation; (2) visualization of the end effector’s 3D trajectory and time-dependent joint positions and velocities; (3) integration of an ROS software package with the robot controller without requiring a native ROS Core; (4) command of the real robot movement by specifying several waypoints for the desired trajectory; (5) monitoring the joint movements of the physical robot via TCP/IP bidirectional communication messages; (6) validation of the robot’s execution of the provided task through data acquisition; and (7) comparative graphical display and saving in JSON format of relevant data (joint positions and Cartesian trajectory) for both virtual and physical model.

Although robot control through MATLAB and ROS is widely used, most existing solutions rely on a full ROS middleware infrastructure (ROS Core, nodes, message compilation, and synchronized middleware), which introduces significant software dependencies, reduces portability, and may increase communication latency. In contrast, the experimental evaluation of lightweight, ROS-compatible communication architectures that eliminate ROS Core while preserving interoperability has received comparatively limited attention.

In this context, this work investigates the design and experimental validation of a simplified communication framework, focusing on system integration, communication performance, and virtual-to-real trajectory consistency. It should be noted that the contribution of this work is not related to the development of novel control or motion planning algorithms, but rather to the implementation and validation of a lightweight integration approach.

The main contributions of this study are as follows:

• The design and experimental validation of a lightweight ROS-compatible communication architecture that enables bidirectional interaction between MATLAB and an industrial robot controller without requiring ROS Core or native middleware.
• A systematic evaluation of communication performance (latency, stability, and update rates), demonstrating that the proposed approach can reliably support trajectory execution and monitoring tasks.
• The integration of kinematic modeling, 3D simulation, trajectory generation, and real-robot validation within a unified MATLAB-based framework.
• Experimental validation on an ABB IRB120 industrial robot, demonstrating high correspondence between simulated and real trajectories, confirming the feasibility of virtual-to-real transfer in a simplified architecture.

The paper is structured as follows. Section 1 introduces the context and main contributions. Section 2 presents the MATLAB-based kinematic modeling of the industrial robot. Section 3 describes the system architecture and the integration of the manufacturer-specific software without requiring the full ROS system. Section 4 details the ROS-compatible TCP/IP communication protocol and the functionalities of the graphical interface. Section 5 reports the simulation and experimental results, including real-robot validation. Section 6 provides a comparative discussion of the findings, and Section 7 presents the conclusions and future research directions.

2. Modelling the Industrial Robot

This section briefly presents the aspects of kinematic modelling of an industrial robot in the MATLAB R2024b environment.

Table 1. Industrial robots with similar specifications.

Manufacturer	Robot Model	Payload [kg]	Reach [mm]	Repeatability [mm]	Weight [kg]
ABB	IRB120	3	580	±0.01	25
KUKA	KR6 R700	6	706	±0.03	50
FANUC	LR Mate 200iD	7	717	±0.01	25
Yaskawa	GP7	7	927	±0.01	34
UR	UR3e	3	500	±0.03	11.2
Staubli	Tx2-40	2	515	±0.02	29

shows small-sized industrial serial manipulators with similar specifications produced by various manufacturers. As presented in [49,50], the ABB IRB120 robot used in the paper case study falls into this category, weighing only 25 kg. Despite its size, it has all the functional characteristics of other industrial robots, and its motions are provided only by rotation joints.

A kinematic description of the ABB IRB120 robot can be easily obtained by following the Denavit–Hartenberg (D-H, [9,10]) methodology or other variants of the standard convention. The D-H formalism leads to forward and inverse mathematical dependencies between joint positions (joint variables) and the representation of the end effector’s position and orientation (pose) (Cartesian variables). This accounts for the robot’s dimensional and geometrical specifications.

Figure 1 shows the dimensional specifications of the real robot [49], the robot in the Robot Studio environment, and the coordinate frames attached to the mechanical structure by applying the D-H formalism.

Following the association of the coordinate frames, the kinematics of the robot are formulated using the standard Denavit–Hartenberg (DH) convention, where each homogeneous transformation matrix T_i−1,i from Equation (1) is defined by four parameters: link twist α_i, link length a_i, joint offset d_i, and joint angle θ_i. The parameters for the ABB IRB120 industrial robot are presented in

Table 2. The Denavit–Hartenberg parameters for the IRB120 robot.

Joint	θi (rad)	di (mm)	ai (mm)	αi (rad)
1	θ1	290	0	−pi
2	θ2 − pi/2	0	270	0
3	θ3	0	70	−pi/2
4	θ4	302	0	pi/2
5	θ5	0	0	−pi/2
6	θ6	72	0	0

.

With the help of these parameters, if necessary, the homogeneous transformation matrices between intermediate frames can be determined, and the resulting pose of the TCP can be computed as shown in Equation (1) by post-multiplying all these matrices. This characterizes the kinematic model of the industrial robot.

$$\begin{array}{l}{T}_{i-1,i}=\left[\begin{array}{cccc}\cos {\theta }_i& -\sin {\theta }_i\cdot \cos {\alpha }_i& \sin {\theta }_i\cdot \sin {\alpha }_i& a_i\cdot \cos {\theta }_i\\ \sin {\theta }_i& \cos {\theta }_i\cdot \cos {\alpha }_i& -\cos {\theta }_i\cdot \sin {\alpha }_i& a_i\cdot \sin {\theta }_i\\ 0& \sin {\alpha }_i& \cos {\alpha }_i& d_i\\ 0& 0& 0& 1\end{array}\right]\\ \Rightarrow T_{0,6}=T_{0,1}\cdot T_{1,2}\cdot T_{2,3}\cdot T_{3,4}\cdot T_{4,5}\cdot T_{5,6}=T_t=\left[\begin{array}{cccc}{n}_x& o_x& a_x& dx\\ n_y& o_y& a_y& dy\\ n_z& o_z& a_z& dz\\ 0& 0& 0& 1\end{array}\right]\end{array}$$

(1)

In Equation (1), the n = [n_x n_y n_z]^T (normal), o = [o_x o_y o_z]^T (orientation), and a = [a_x a_y a_z]^T (approach) vectors represent the orientation, and p = [dx dy dz]^T denotes the relative position of the last coordinate frame attached to the robot’s flange in the current situation with respect to the reference frame attached to the base of the robot.

From the standpoint of the forward kinematics, if all the joint variables are known, there is only one solution for the end effector’s position and orientation. If, however, the 3D global coordinates are specified and the local variables are assumed to be determined, then several solutions are possible. These solutions are based on the decoupling method, geometric, analytical, or numerical formalisms. The subsequent discourse does not intend to extend the mathematical investigation of the kinematic model or the dynamics and torques, as these are well covered in the literature [9,10,11,12,13,14,18,19,20,54,55], but rather to utilize the digital modelling facilities employed in the realized application. Kinematic modeling plays a critical role in ensuring positioning accuracy, which directly influences the reliability of trajectory execution and the estimation of performance indicators such as energy consumption.

The most widespread implementations used for digital modelling of robots in MATLAB are based on two toolboxes: the Robotics Toolbox for MATLAB (RTM) with symbolic representation by P. Corke [15,16,17], and the Robotics System Toolbox (RST), integrated into recent versions of MATLAB, which has the advantage of 3D representation with CAD element structures [21,22]. Both representations for the IRB120 robot are shown in Figure 2.

MATLAB’s Simscape Multibody is an excellent tool that provides a multibody simulation environment for three-dimensional mechanical systems, including robots. Robots can be modeled as multibody systems using blocks representing bodies, joints, constraints, force elements, and sensors. The rigidBodyTree model, which represents the connectivity of several rigid bodies (as rigidBody objects) with associated joints (as rigidBodyJoint objects), can be imported (using the importrobot function [24]) from URDF, Xacro, SDF files, text, or Simscape Multibody models.

From a modeling perspective, the rigidBodyTree concept internally implements kinematic relationships according to the standard Denavit–Hartenberg (DH) convention and performs dynamics computations using the Newton–Euler formulation, ensuring compatibility with the classical methods used in robotics modeling. This allows both analytical and numerical computation of forward and inverse kinematics, Jacobians, and dynamic properties without requiring manual equation derivation.

For the IRB120 robot, advanced 3D modelling using software such as CATIA, SolidWorks, or Inventor is not necessary, as its 3D model is available as a predefined rigidBodyTree-compatible model in the RST library of MATLAB (via the loadrobot function [24]). Specific functions can then be used to perform kinematic calculations of intermediate configurations, attachment of end effectors, determination of TCP position and orientation, dynamic calculations, trajectory generation, and 3D simulations with static or dynamic visualization of the robot.

Additionally, detailed numerical sensitivity analysis of the virtual kinematic model can be further derived from the geometric Jacobian computed within the rigidBodyTree structure, but, in the real system, additional deviations depend on the physical robot’s repeatability, presented in Table 1 (±0.01 mm for the ABB IRB120), and the accuracy of the IRC5 control system.

3. Proposed System Architecture

The application developed in this research project has two primary functions. Firstly, it can model and simulate industrial robots. Secondly, it can monitor kinematic parameters and control predefined motions of the real robot. These functions enable the creation of a bidirectional virtual replica of the robot. The application is based on existing education and research laboratory equipment, including a robotic assembly station with an ABB IRB120 robot and a compact IRC5 controller (with RobotWare 6.06), which enables testing and experimentation (see Figure 3). Another objective of the application is to integrate as few additional software options as possible for the RobotWare system.

In this context, it is important to note that solely the specific ABB ROS software package, known as ABB ROS Server code, from the ROS-I is utilized, with the native ROS system being excluded. Consequently, the TCP/IP communication protocol is already integrated into this ABB ROS software package [32]. The ABB ROS package is integrated using the RAPID language and employs a socket interface and multiple parallel tasks. To enable communication with the running ABB ROS package on the IRC5 controller, the following software options should be activated in Robotware: 623-1 Multitasking, 616-1 PC Interface (672-1 Socket Messaging in older versions of RobotWare). It should be noted that the use of additional software options on the RobotWare system of the IRC5 controller is not required, including the use of other frameworks or middleware platforms for mediating communication with the application developed in the MATLAB environment for the virtualization of the physical system.

Recent versions of RobotWare incorporate a novel feature called Externally Guided Motion (EGM). However, this feature requires a licensed activation, which is currently unavailable for our test equipment. The EGM bypasses the path planner, thereby giving the motor reference generator direct control. In addition to the ABB ROS Server code used, the ROS-I includes a more recent open-source version of this package. The purpose of this version is to facilitate interaction between robot controllers and ROS1 or ROS2-based systems by providing ready-to-run ROS nodes. However, this version also requires additional software packages (abb_libegm and abb_librws) and RobotWare versions more recent than 6.07.01, thereby enabling direct motion control of ABB robots via the same Externally Guided Motion (EGM) interface. These considerations constitute a possible further application development or future research topic.

In short, the application described in this paper was adapted to an existing experimental setup comprising the ABB IRB120 robot and the IRC5 controller with Robotware 6.06. At the same time, the goal was to reduce the number of software components while maintaining bidirectional communication. The proposed architecture implements a lightweight communication bridge using the ABB ROS Server Code directly on the IRC5 controller. This eliminates the need for ROS core and node configuration, message compilation, or topic synchronization on the MATLAB side, significantly simplifying deployment for laboratory or educational environments.

Table 3. Comparative perspective with standard MATLAB-ROS framework.

Aspect	Standard MATLAB–ROS Framework	Proposed MATLAB-ROS Framework
ROS core	Yes	No
Communication mechanism	ROS topics/services	TCP/IP, ROS-compatible messages
Platform dependency	Linux/ROS environment	Platform-independent (with MATLAB)
Setup complexity	Medium to High (ROS configuration and package build)	Low (MATLAB client)
Real-time capability	Non-real-time (ROS-based)	Non-real-time (TCP/IP socket)
Educational suitability	Moderate (requires ROS knowledge)	High (MATLAB application)

presents a comparative perspective and generalization of the proposed lightweight bridge with the standard MATLAB–ROS framework.

Although the experimental validation was conducted on an ABB IRB120 robot using the IRC5 controller, the architecture is conceptually extendable to other industrial manipulators. The modeling and simulation components, implemented via MATLAB’s rigidBodyTree structure, are robot-agnostic and compatible with both DH and URDF model definitions. Here, only the communication layer requires adaptation to the specific manufacturer data exchange interface (e.g., Modbus, Profinet, or other ROS-compatible drivers). Therefore, the proposed framework can serve as a general template for integrating digital modeling, trajectory execution, and data monitoring across various industrial robotic systems.

Figure 4 illustrates the system architecture and highlights both the hardware components and, particularly, the virtualization component provided by the application developed in the MATLAB environment. Two software applications are shown here. The first is the ABB ROS software package, written in the RAPID language, specifically for robot programming. This application has been installed in accordance with the recommendations for using the ABB ROS Server [32]. It runs on the IRC5 controller and executes a given set of trajectories. The second application is developed by the authors in the MATLAB environment, runs on a PC/laptop, and is responsible for monitoring, controlling, and virtualizing the robotic experimental setup.

In Figure 4 the IRC5 controller is equipped with a FlexPendant panel, which facilitates local manipulation, programming, and tracking. Additionally, it can be connected to another computer for local programming and troubleshooting in Robot Studio. In the following, the robotic experimental setup consists of the IRB120 robot and the IRC5 compact controller is designated as the physical model of the system. The component responsible for virtualization at the PC/Laptop station is hereafter referred to as the robot’s virtual model. The two components communicate via TCP/IP sockets.

The IRC5 controller has the RobotWare 6.06.01 operating system installed, and the 623-1 Multitasking and 616-1 PC Interface software options are enabled. These are necessary for the integration of the ABB ROS software package since its Rapid code uses a socket-based interface and several parallel tasks, ROS_StateServer, which provides joint position and robot status information by broadcasting joint and status data; ROS_MotionServer, which receives information about waypoints on the trajectory to be realized by the real robot and constructs the desired trajectory to be sent for execution; and T_ROB1, which executes the trajectory by controlling the robot (issues motion instructions to the real robot).

The PC/laptop is equipped with MATLAB (release 2024b), which includes toolboxes for graphical display, graphical interfacing, robotics, and communication. With these resources, the virtualization application is implemented, which comprises several components, including:

• A graphical interface module that allows the parameterization of the desired motions to be executed by the real robot and their tracking;
• A transmission module used for sending joint parameters corresponding to the waypoints on the desired trajectory;
• A reception module used for receiving the joint parameters corresponding to the actual trajectory performed by the robot;
• A virtualization module allowing the construction of a digital model of the robot and the simulation and visualization of its motion for desired and actual trajectories.

The subsequent sections describe the application’s functionalities and implementation aspects.

4. Implementation Details

This section describes the implementation aspects of the proposed framework, focusing on the integration of the industrial robot controller, the communication architecture, and the MATLAB-based virtual environment. Rather than providing a step-by-step implementation guide, the emphasis is placed on the functional components and their interaction within the overall system architecture.

4.1. Functional Aspects of the ROS Component on the IRC5 Controller

The ABB ROS software package for the IRC5 controller is highly compatible with most ABB robots, providing scalability to the developed system. In this case, it is used with the IRB120 robot. Typically, running ROS-I software creates a ROS node for the industrial robot, using a manufacturer-independent interface to control its motion and obtain joint-state feedback. In this context, the ABB ROS software package is used as a lightweight communication layer, enabling interaction with the robot controller without requiring a full ROS middleware installation. This design choice simplifies deployment while preserving compatibility with ROS-based communication principles.

In general, ROS-I supports several modes of operation for communicating motion instructions to industrial robots. The ABB ROS package uses a trajectory download mode, in which a set of joint positions defining a given trajectory is first downloaded to the robot controller and then executed by the robot. This trajectory includes the velocity and execution time for each position. Once a trajectory has been executed, the robot stops and waits to download the next one.

In all operating modes, the ROS-I node communicates with the manufacturer-dependent controller via the Simple Message protocol. This protocol contains binary data that typically runs over TCP sockets, but can also use serial or UDP channels.

These mechanisms define the operational basis for integrating the ABB ROS package within the proposed framework. The controller configuration involves multiple tasks (ROS_StateServer, ROS_MotionServer, and T_ROB1, shown in Figure 4) responsible for motion execution and state monitoring, as well as socket-based communication services. These components enable bidirectional data exchange, including trajectory transmission and acquisition of joint and status information. The controller configuration includes task initialization, signal definition, and parameterization of the communication modules, as described in [32].

The ROS_StateServer and ROS_MotionServer tasks implement the communication interfaces required for state monitoring and trajectory transmission. The former provides continuous feedback regarding joint positions and robot status, while the latter manages the reception and storage of trajectory waypoints to be executed by the robot. The T_ROB1 task is responsible for motion execution, ensuring that the received trajectories are applied consistently at the controller level.

Overall, this configuration enables a simplified yet effective communication architecture, supporting the integration of the physical robot within the proposed virtual–physical framework.

4.2. Communication Between the Physical and Virtual Model

Communication between the physical robot and the virtual MATLAB model is achieved through a TCP/IP-based architecture using a simple message protocol. The system supports bidirectional data exchange, allowing both trajectory transmission to the robot and acquisition of execution data for monitoring and analysis. This communication layer represents a key component of the proposed framework, enabling the integration between simulation and real-world execution.

Two communication channels are implemented on the controller side: one dedicated to state monitoring and another for trajectory transmission. The monitoring channel continuously provides joint positions and status information of the robot to the MATLAB client at a rate of 0.02 s, while the control channel is used to transmit trajectory waypoints that define the motion to be executed by the robot. The initial point, intermediate points, and final point of the trajectory are identified by a specific parameter in the client’s message.

The trajectory transmission process is based on a sequence of waypoints, each containing joint configurations and execution timing information. These waypoints are transmitted from the MATLAB application to the robot controller, where they are stored and subsequently executed. To ensure reliable communication, the process includes confirmation mechanisms that validate the correct reception and processing of transmitted data.

The communication protocol defines several message types, including joint data, status data, trajectory points, and acknowledgment messages. These messages are encoded as binary packets with a structured format consisting of a header and associated data fields. This structure ensures efficient transmission while maintaining consistency between the physical and virtual models.

Figure 5 illustrates the communication workflow for both data acquisition and trajectory transmission, highlighting the interaction between the MATLAB client and the robot controller through the implemented protocol. The diagram also illustrates the functions employed for communication in the RAPID code or MATLAB code. Figure 6 presents the general structure of the binary messages used within this communication framework. The binary data packets for the Joint data message and the Status data message, as detailed in Figure 6a,b, are used in the acquisition workflow presented in Figure 5a. The binary data packets for the trajectory transmission, as detailed in Figure 6c,d, are used in the trajectory transmission workflow presented in Figure 5b. Both the Physical Model and the Virtual Model participate in these procedures, and the required functions are also shown in the diagrams in Figure 5.

Trajectory waypoints are transmitted in a predefined sequence, ensuring correct ordering and execution of motion commands on the robot controller. This sequencing mechanism guarantees that the generated trajectories are consistently reproduced during physical execution.

Overall, the implemented communication mechanism enables consistent and synchronized interaction between the virtual simulation environment and the physical robot. This capability is essential for validating trajectory execution and analyzing system performance within the proposed framework.

4.3. MATLAB Client Application for Monitoring and Controlling the Industrial Robot

The MATLAB application represents the central component of the virtual environment, integrating kinematic modeling, trajectory generation, simulation, and real-time communication with the industrial robot. It enables bidirectional interaction between the Physical Model (IRB120 robot with IRC5 controller) and the Virtual Model, supporting both motion execution and data acquisition. The application provides functionalities for defining and simulating robot trajectories, transmitting motion commands to the controller, and monitoring execution through continuous acquisition of joint and status data. In addition, it supports comparative analysis between simulated and real robot behavior, as well as data logging for further processing.

The graphical user interface (Figure 7) offers an integrated environment for trajectory configuration, execution, and visualization. It allows the definition of different trajectory types, including predefined geometric paths and point-to-point motions, parameterized in either joint space or Cartesian space. Trajectory generation is performed using interpolation of motion points, ensuring compatibility with the trajectory execution mode implemented on the controller. When trajectories are defined in Cartesian space, inverse kinematics is employed to obtain the corresponding joint configurations.

For visualization purposes, the application simulates robot motion in three-dimensional space and provides time-based representations of joint positions and velocities. This enables a direct comparison between the planned (simulated) and executed (measured) trajectories.

The communication with the robot controller is implemented using TCP/IP sockets, supporting both trajectory transmission and real-time data acquisition. The exchanged data are encoded according to the communication protocol described in the previous section.

Overall, the MATLAB application functions not only as a control interface but also as an experimental platform for evaluating the consistency between virtual simulation and physical robot execution. This capability is essential for validating the proposed framework and analyzing system performance.

5. Test and Results

The experimental validation involved implementing the proposed framework on a real ABB IRB120 industrial robot using RAPID programming and ROS-Industrial (ROS-I) components. The system functionalities described in Section 4—including modeling, simulation, trajectory execution, and monitoring—were evaluated using four representative trajectories (Figure 8). For clarity, the results corresponding to the circular trajectory are presented in detail.

Figure 9 illustrates the MATLAB graphical interface used for trajectory definition and simulation. The circular trajectory is generated using 100 sampled points and can be applied either to the virtual robot model or transmitted to the physical system for execution.

During simulation, the robot motion is visualized in a 3D environment, along with the evolution of joint positions and velocities. Joint velocities are estimated numerically using discrete differentiation of joint positions with respect to time.

For real robot execution, communication between the MATLAB application and the IRC5 controller is established via TCP/IP over an Ethernet connection, using dedicated ROS_MotionServer and ROS_StateServer interfaces. These components enable bidirectional data exchange for trajectory transmission and real-time monitoring, as illustrated in Figure 10.

Figure 10a shows the waiting state of the initialized servers upon restarting IRC5. Figure 10b,c highlight the TCP/IP client connections created in the MATLAB application for transmitting and monitoring the execution of the desired trajectory. Figure 10b shows the client transmitting the 100 trajectory waypoints, then disconnecting once the messages have been sent. Figure 10c shows the client connection for robot monitoring, followed by disconnection. These two functionalities can be performed independently within the MATLAB application, without being correlated, if, for example, only the execution of a given trajectory by the robot or only the monitoring of the robot’s operation is desired.

In the context of data acquisition and monitoring of the robot’s operation within the MATLAB application, a virtual representation of the physical robot is constructed by developing a digital model that mirrors the initial simulation. However, the animated display of joint motion and evolution is derived from the actual data received from the IRC5 controller and the physical robot. The TCP Cartesian representation is subject to the same kinematic calculation, given that the binary data received from the controller exclusively contains information regarding the joint positions. As illustrated in Figure 11, the actual physical robot trajectory is shown alongside the requested circular trajectory.

The relevant data for both simulation and monitoring purposes related to the joint positions and TCP trajectory are saved in structured JSON files:

{

“time”: […],

“joints_positions”: […],

“joints_velocities”: […],

“tcp”: […]

}

The saved data facilitate the comparison of the evolution of the joint positions for the two models: the simulated model and the virtualized physical model, as well as the desired TCP trajectory transmitted using joint positions to the IRC5 controller and the actual TCP trajectory determined from real measurement data received from the physical system (Figure 12).

The data presented in Figure 12 indicate a strong correlation between the imposed and executed trajectories. The observed deviations remain within a small range and can be attributed primarily to communication delays, sampling differences, and the non-synchronized nature of execution and data acquisition. Before computing the error metrics, the simulated and experimentally acquired signals were temporally aligned using identifiable reference points in the trajectory execution. This alignment ensures that corresponding motion states are compared, thereby reducing the impact of communication delays and synchronization offsets on the evaluation results.

As illustrated in Figure 13, the monitoring option can be used independently of any imposed trajectory to acquire independent manipulation motions for some joints. The initial four joints (J1, J2, J3, J4) are actuated successively over the 100 samples monitored.

Since the experiments were conducted on an industrial robot with well-documented performance characteristics, the results are consistent with the expected repeatability specifications provided by the manufacturer. This supports the applicability of the framework in controlled laboratory and educational environments.

Quantitative validation was also performed using RMSE (Root Mean Square Error) and MAE (Mean Absolute Error) between the simulated and real joint positions, complementing the visual comparison of the simulated and executed trajectories. These were computed for each of the six joints over the entire trajectory and are presented in

Table 4. Quantitative validation using RMSE and MAE for the circular trajectory test case.

Joint	RMSE (rad)	MAE (rad)
Joint 1	0.0051	0.0041
Joint 2	0.0047	0.0041
Joint 3	0.0075	0.0065
Joint 4	0.0058	0.0046
Joint 5	0.0028	0.0024
Joint 6	0.0029	0.0024

. The average RMSE across all joints was 0.0048 rad, indicating a close correspondence between simulated and real joint trajectories.

Communication Performance Evaluation

The temporal behavior of the communication channel was evaluated in two independent experiments, each consisting of 1000 samples. The first experiment measured the Round-Trip Time (RTT) associated with transmitting joint-command packets from MATLAB to the IRC5 controller via port 11000. In this test, MATLAB continuously sent 1000 waypoint messages, and the elapsed time between each packet transmission and its acknowledgment was recorded. The statistical indicators summarized in

Table 5. Communication Performance Statistics.

Metric	RTT (ms)	StateServer (ms)
Mean	33.924	20.319
Median	31.776	15.680
Standard deviation	6.759	18.020
Minimum	20.396	0.511
Maximum	65.782	62.996

show that RTT values remained within the tens-of-milliseconds range, with an average delay of approximately 34 ms and relatively low jitter (σ ≈ 6.76 ms). This behavior is consistent with a non-real-time Ethernet link and is suitable for supervisory or low-frequency closed-loop control at approximately 5–10 Hz. Throughout the experiment, no packet loss or malformed messages were observed, indicating stable operation of the MATLAB–ROS_MotionServer communication loop under the tested conditions.

A second experiment characterized the timing dispersion of the ROS_StateServer broadcast that provides joint and status updates via port 11002. Over 1000 samples, the broadcast interval followed the statistical behavior reported in Table 5, with a mean period of approximately 20 ms—supporting potential monitoring rates of 40–50 Hz. However, the observed timing variability (σ ≈ 18.02 ms) reflects the non-deterministic nature of TCP-based RAPID broadcasting and the absence of hard real-time guarantees. As a result, the StateServer interface is well suited for online monitoring, estimation, digital twin updates, or data logging. However, it is not appropriate for high-bandwidth feedback control applications requiring strict real-time constraints. In such cases, the control loop must remain within the IRC5 motion controller or rely on deterministic communication solutions.

Consistent with these findings, the measured communication performance indicates that the proposed framework is most suitable for trajectory uploading, validation, monitoring, and offline or low-frequency supervisory control from MATLAB (≈ 5–10 Hz). The observed StateServer jitter, inherent to non-real-time network operation, limits its applicability for high-frequency feedback control, where deterministic timing behavior is required.

Regarding communication performance, latency and packet synchronization were analyzed through timestamp monitoring. The results indicate stable transmission within tens of milliseconds, which is adequate for trajectory validation and monitoring tasks in non-real-time environments, while maintaining consistent data delivery under the tested experimental conditions.

6. Discussion

The central motivation of this work is to investigate whether a lightweight, ROS-compatible communication architecture—implemented without ROS Core, native middleware, or node orchestration—can sustain reliable trajectory execution, communication stability, and consistency between simulated and real robot behavior. This question is relevant because most existing MATLAB–ROS and ROS-Industrial pipelines rely on complex middleware infrastructures, whose synchronization mechanisms, dependency management, and message-passing overhead can influence latency and system integration complexity.

The experiments reported in this study are not intended to evaluate the intrinsic accuracy of the ABB IRB120, which is well established in the literature, but rather to assess the impact of removing the full ROS infrastructure on execution performance. The results indicate that the proposed TCP/IP ROS-compatible communication approach is capable of maintaining trajectory-tracking accuracy and stable communication behavior under the tested conditions. These findings suggest that a simplified communication layer can support reliable system operation while reducing implementation complexity. To provide a clearer positioning of the proposed framework relative to existing approaches, a qualitative comparison with representative robotic systems is presented in

Table 6. Comparison Between Proposed Framework and State-of-the-Art Approaches.

Approach	Middleware Requirement	Communication Load	Real–Robot Validation	Key Limitation
MATLAB–ROS Full Frameworks [33,34,35,36,37]	Full ROS installation	High	Yes	Complex setup, high dependency on ROS version
Digital Twin Architectures [28]	Custom TCP/IP	Medium	Yes	Reduced flexibility; tied to specific hardware
Robot Toolbox-Based Solutions [15,16,17]	None	Low	Limited	No real bidirectional communication
MATLAB–Simscape Approaches [18,19,20]	None	Medium	Partial	High computational load.
Proposed MATLAB–ROS Lightweight Bridge	No ROS core required	Very Low	Yes (ABB IRB120)	Minor message-format adaptation for other brands.

.

Full ROS-based frameworks [33,34,35,36,37] typically provide high scalability and modularity, but require multi-node orchestration and more complex configuration. Digital-twin solutions [28] enable strong physical–virtual synchronization, often at the cost of increased system specificity. Modeling-oriented approaches [15,16,17,18,19,20] offer accurate kinematic and dynamic analysis, but may lack integrated real-time execution capabilities. In contrast, the framework proposed in this work combines kinematic modeling, 3D simulation, and real-robot execution within a simplified communication architecture. The performance evaluation, based on RTT and StateServer timing tests, indicates low-latency and stable bidirectional communication under the considered experimental conditions.

It should be noted that, due to the use of a non-real-time network and the presence of communication jitter, the system cannot be considered strictly deterministic. However, the observed behavior is sufficiently stable and repeatable to support trajectory execution and monitoring tasks within the targeted application scope.

In addition to communication performance, the obtained RMSE (<0.0075 rad) and MAE (<0.0065 rad) values indicate a high level of correspondence between simulated and real robot motion. These results support the applicability of the proposed framework for rapid prototyping, educational use, and laboratory-scale experimental environments, while acknowledging that further validation under more complex trajectories remains an important direction for future work.

7. Conclusions

This work presented a lightweight MATLAB–ROS-based framework that integrates modeling, 3D simulation, trajectory generation, and physical execution for a 6-DOF industrial robot. By implementing a ROS-compatible TCP/IP communication layer that does not require a native ROS installation, the system enables bidirectional data exchange between the virtual and physical domains within a simplified architecture.

The MATLAB-based graphical interface provides a unified environment for simulation, trajectory execution, and visualization, supporting both educational use and experimental research without requiring advanced ROS expertise.

Experimental results indicate a close correspondence between simulated trajectories and the physical motion of the ABB IRB120 robot. Quantitative indicators, including RMSE values below 0.0075 rad and MAE below 0.0065 rad, support this observation. Communication tests further show round-trip latency within the tens-of-milliseconds range and consistent StateServer update behavior under the tested conditions. Together, these results suggest that the proposed framework can support trajectory validation and monitoring tasks in non-real-time environments.

Although the proposed framework demonstrates consistent performance under the evaluated conditions, several limitations define its current scope. The communication layer relies on ABB-specific ROS Server Code, which limits direct compatibility with other robot platforms. In addition, the system does not provide deterministic real-time synchronization, restricting its applicability in high-speed or time-critical control scenarios. The validation was conducted using predefined, smooth trajectories in controlled laboratory conditions; further evaluation using more complex trajectories and varying network conditions would strengthen the generality of the results.

Future work will focus on extending the communication architecture to additional industrial robot platforms through multi-protocol interoperability (e.g., Profinet, OPC UA, or native ROS nodes). Further research will also investigate real-time synchronization mechanisms, trajectory optimization strategies, and integration with digital twin environments. These developments aim to expand the applicability of the framework and support more advanced robotic applications within Industry 4.0 and Industry 5.0 contexts.