The control implementation for all cyber–physical experiments is presented in
Figure 18. The
n robots are placed in two different workspaces. Every workspace has a web camera (Model
, Logitech, Lausanne, Switzerland) with a resolution of
pixels, installed at a height of 400 mm, that generates a viewing area of around 750 mm × 400 mm. Every camera is connected to a PC computer (Model Core
, Intel Corp., Santa Clara, CA, USA). The PC reads the Aruco tags (OpenCV-contrib module, OpenCV.org, Palo Alto, CA, USA) at a sample rate of
s, detecting the
of the robots and calculating the position and orientation of every robot using a visual processing library (OpenCV 4.8.0, OpenCV.org, Palo Alto, CA, USA). The positions and orientations are processed by the computer in the workspace for the real robots, and this same information is sent to the internet through an IoT protocol (MQTT v3.1.1 and 1.6.9, Eclipse Foundation, Ottawa, ON, Canada). using different brokers. The communication is bidirectional, and the two workspaces are connected via the internet. The control law was programmed in each PC using Python (Version
, Python Software Foundation, Wilmington, DE, USA), sending the control inputs to every robot using Bluetooth wireless communication. Note that the control setup is low-cost and scalable. Also, the experimental setup is modular using commercial components, allowing its expansion to more robots and workspaces.
Figure 19 is an example of the control implementation using the experimental platform of the topology and the formation structure of the four-robot diamond shape based on the topology shown in
Figure 5.
5.1. Unicycle-Type Robots
The control approach was tested in a low-cost experimental robotic platform composed of the four mobile robots shown in
Figure 20. Each unicycle-type robot was integrated with two DC motors (Micro metal gear motors HP 6v 1000:1, Pololu Corporation, Las Vegas, NV, USA) with plastic wheels, controlled by a microcontroller (ATmega32U4-based microcontroller, Arduino SA, Somerville, MA, USA). with Bluetooth wireless communication to a PC. The robot case was made with a 3D printer with an Aruco tag on top. The unicycle robots measure 100 mm × 100 mm; this size was selected during development to provide a versatile, easily maneuverable platform that is well suited for both academic and research environments.
A detailed breakdown of the main hardware components and their estimated prices is given in
Table 7. The total cost per unit is estimated to be in the range of USD 40 to 70, which is significantly lower than similar platforms described in the literature (typically USD 80 to 150).
This cost-effective design reduces the experimentation cost for multiple robots or multiple workspaces and also facilitates easy replication and scalability in academic and research settings.
The kinematic model of the unicycle-type robots shown in
Figure 20 is given, according to
Figure 21, by
with
, where
is the 2D coordinate of the robot and
is its orientation angle with respect to the horizontal axis. The
and
are the longitudinal and rotational control inputs with respect to the middle point of the axis wheels. These two body-level velocities can be converted to the velocities of the wheels through
where
and
are the angular velocities of the right and left wheels, respectively,
r is the radius of the wheels, and
L is the distance between the wheels.
The frontal point is chosen as control output, shown in
Figure 21 with
where
. Its dynamics are given by
where
. Since
, it is possible to linearize the dynamics of
using the control
with
as an auxiliary control. Note that in the closed-loop control (
26) and (
27), the dynamics is reduced to
and the nonlinearities are eliminated, resulting in the single integrator given by (
3). Therefore, the control approach can be extended to the unicycle-type robots using the control law (
27), where
is defined by the Equations (
4)–(
6) but dependent on the coordinates
of the robots. For the experimental work case developed in
Section 5.4, the parameters of the robots constructed for the experimental platform in this study are
mm,
mm, and
mm. Here,
r is defined as the radius of the robot’s wheel,
ℓ is the distance to an auxiliary frontal point, and
L is the distance between the centers of the two wheels. These values are determined by the size of the robot and the commercial components used. Additionally, due to the selected motor type Pololu© 6V with a 1000:1 gear ratio and a maximum speed of 33 RPM and given the wheel radius of
mm, the robot and control programming impose a maximum wheel angular velocity of
rad/s and a minimum value of
rad/s, which is approximately
of the motors’ maximum speed.
5.4. Experimental Results
Using the experimental platform, several experiments were conducted with the formation configurations presented in the simulation
Section 4 (
Figure 3,
Figure 4 and
Figure 5). Based on the numerical simulations, a unit gain (
,
and
) was selected for the physical experiments. Each experiment was carried out with a different sampling time (
), which determines both the calculation frequency and the rate at which data are transmitted to the MQTT broker. Sampling times of
and
s were tested. It is important to note that several of these sampling rates exceed the previously studied data transmission rate of the MQTT system (an average of
s) and the camera sampling rate (
s). This introduces expected errors and delays in the data, as discussed in the numerical simulation section regarding the robustness of the control model. In addition to testing different
parameters, the experiments were carried out using two distinct MQTT brokers: a popular commercial broker,
test.mosquitto.org, and a custom-developed broker hosted in Google Cloud. The errors of all experiments were quantified using comparative tables based on the integral of the
norm (sum of absolute errors) and the
norm (sum of squared errors).
Figure 24 shows the experimental results of the simulation with
. The desired trajectory of the leader robot
is given by
in millimeters, and the MQTT broker selected for this specific experiment was the comercial MQTT broker
test.mosquitto.org. The robots converge to the desired formation pattern, which is observed by the robots’ trajectories in
Figure 24a and the error convergence shown in
Figure 24b. Note that the errors of the real robots are smaller than the errors of the virtual robots in the experimental data. The control inputs are depicted in
Figure 24c, and note that the control input is saturated at a maximum value
and a minimum value of
. Note that the control performance is affected by the resolution of the camera, the sample time, and the non-modeled dynamics presented by the floor friction and other real effects.
Figure 25 illustrates the longitudinal velocity values
V relative to the midpoint between the wheel axes; see
Figure 25a. Furthermore,
Figure 25b presents the angular velocities,
and
, corresponding to the right and left wheels of each robot, respectively. Note that the angular wheel velocities are saturated at a maximum value of
rad/s and a minimum value of
, due to the maximum speed that the physical motors on the experimental platform can achieve.
In this first formation topology, as shown in
Figure 3, several experiments were performed by varying the sample rate
to assess the stability and convergence rate of the control strategy. The simulations were carried out using different
values of
, and
, and all the different dt values were evaluated with different MQTT brokers:
test.mosquitto.org and a custom-developed broker hosted on Google Cloud. For each simulation, the
and
norms were calculated by summing the absolute errors and squared errors, respectively, taking into account errors from both workspaces and from both real and virtual robots. The results of the different broker test are shown in the graphs in
Figure 26 and summarized in
Table 9. Additionally, graphs were generated that depict the instantaneous sum of squared errors (computed by aggregating the errors of each real or virtual robot across both workspaces) to compare which sampling times and MQTT broker configurations offer the greatest stability and the fastest convergence, despite system delays and other challenges inherent in physical robot experiments. These results are illustrated in
Figure 27.
Figure 28 shows the second experiment with a
; the desired trajectory of the leader robot
is given by
in millimeters and the same MQTT broker, namely
test.mosquitto.org. The robots converge to the desired formation pattern, which is observed by the robots’ trajectories in
Figure 28a and the error convergence shown in
Figure 28b. Note that the errors of the real robots are smaller than the errors of the virtual robots in the experimental data. The control inputs are depicted in
Figure 28c, and note that the control input is saturated at a maximum value
and a minimum value of
. Note that the control performance is affected by the resolution of the camera, the sample time, and the non-modeled dynamics presented by the floor friction and other real effects.
Figure 29 illustrates the longitudinal velocity values
V relative to the midpoint between the wheel axes; see
Figure 29a. Furthermore,
Figure 29b presents the angular velocities,
and
, corresponding to the right and left wheels of each robot, respectively. Note that the angular wheel velocities are saturated at a maximum value of
rad/s and a minimum value of
due to the maximum speed that the physical motors on the experimental platform can achieve.
In the second formation topology, as shown in
Figure 4, several experiments were performed by varying the sample rate
to assess the stability and convergence rate of the control strategy. In this formation, new experiments were also carried out using different
values and with different MQTT brokers. For each simulation, the
and
norms were calculated by summing the absolute errors and squared errors, respectively, taking into account errors from both workspaces and from both real and virtual robots. The results of the different broker test are shown in the graphs in
Figure 30 and summarized in
Table 10. Additionally, graphs were generated that depict the instantaneous sum of squared errors (computed by aggregating the errors of each real or virtual robot across both workspaces) to compare which sampling times and MQTT broker configurations offer the greatest stability and the fastest convergence, despite system delays and other challenges inherent in physical robot experiments. These results are illustrated in
Figure 31.
Figure 24 shows the experimental results with a
; the desired trajectory of the leader robot
is given by
in millimeters and the MQTT broker
test.mosquitto.org. The robots converge to the desired formation pattern. The robots’ trajectories are observed in
Figure 32a, and error convergence is shown in
Figure 32b. Note that the errors of the real robots are smaller than the errors of the virtual robots in the experimental data. The control inputs are depicted in
Figure 32c, and note that the control input is saturated at a maximum value
and a minimum value of
. Note that the control performance is affected by the resolution of the camera, the sample time, and the non-modeled dynamics effects.
Figure 33 illustrates the longitudinal velocity values
V relative to the midpoint between the wheel axes (see
Figure 33a). Furthermore,
Figure 33b presents the angular velocities,
and
, corresponding to the right and left wheels of each robot. Both are saturated at a maximum value of
and a minimum value of
, due to the maximum speed that the physical motors of the real robots can achieve.
In the third formation topology, as shown in
Figure 5, several experiments were performed by varying the sample rate
to assess the stability and convergence rate of the control strategy. In this formation, new experiments were also carried out using different
values and with different MQTT brokers. For each experiment, the
and
norms were calculated by summing the absolute errors and squared errors, respectively, taking into account errors from both workspaces and from both real and virtual robots. For each simulation, the
and
norms were calculated by summing the absolute errors and squared errors, respectively, taking into account errors from both workspaces and from both real and virtual robots.The results of the different broker test are shown in the graphs in
Figure 34 and summarized in
Table 11. Furthermore, graphs were generated that depict the instantaneous sum of squared errors (computed by aggregating the errors of each real or virtual robot across both workspaces) to compare which sampling times and MQTT broker configurations offer the greatest stability and the fastest convergence, despite system delays and other challenges inherent in physical robot experiments. These results are illustrated in
Figure 35.
As shown in the numerical simulations and the results presented in
Table 9,
Table 10 and
Table 11 for the different topologies and formations, as well as in the simulations conducted with various sampling times
, and also using different MQTT brokers, a lower sampling time
, ideally approaching zero, even with more communication errors, yields a faster and more pronounced convergence. This is evident in the figures illustrating the norms
and
for the three configurations in
Figure 26,
Figure 30, and
Figure 34.
Furthermore, an analysis of the
and
norm tables from the three experiments shows no significant differences between the commercial broker
test.mosquitto.org and the Google Cloud broker. In particular, in all experiments, the Google Cloud broker yielded slightly lower
and
norm values, indicating reduced errors with this MQTT service. This result is directly related to the latency and transmission speeds measured in
Section 5.2, where
test.mosquitto.org exhibited an average latency of
s, while the Google Cloud broker showed a latency of
s, as illustrated in
Figure 22.
It is also important to mention that although the Google Cloud broker has a higher standard deviation in transmission time and occasionally experiences significant delays of
and 2 s, the control strategy remains robust enough to benefit from its lower average latency and faster sampling times.
Figure 27,
Figure 31, and
Figure 35 display the instantaneous sum of squared errors for both brokers in the three different topologies; for
test.mosquitto.org, the error is relatively constant with occasional peaks due to communication delays and platform limitations, whereas the Google Cloud broker exhibits a general lower error value but is less consistent and more erratic. However, when integrating the absolute and squared errors to compute the
and
norms, the values are lower for the Google Cloud broker compared to the commercial alternative. Regarding convergence speed, the control model and the numerical simulation results, illustrated in
Table 1,
Table 2 and
Table 3 for the different topologies and formations, as well as the simulations conducted with various controller gains values (
,
,
), show that higher controller gains yield a faster and more pronounced convergence. Thus, increasing the gain results in a more rapid convergence of the system. Another critical factor is the latency introduced by the MQTT broker communications and the delays associated with the computer vision system. As shown in the numerical simulations and the results presented in
Table 4,
Table 5 and
Table 6 for the different topologies and formations, as well as the simulations conducted with various delay values at
, a lower delay, ideally approaching zero, leads to a faster and more pronounced convergence. Finally, additional factors that affect the convergence speed in the experiments include the maximum velocity of the robot. As explained in
Section 5.1, given the maximum speed of 33 RPM and a radius of the wheels of
, the control system limits the maximum angular velocity of the wheels to
. Moreover, the initial positions of the robots play a significant role; starting from positions that are distant from the desired trajectory or formation will increase the convergence time due to the imposed speed limitations.
Another important detail to consider is that the errors observed in the real robots are smaller than those measured in the virtual robots in the experimental data. This difference is attributed to the inherent communication delays affecting the virtual robots whose positional data include the latency of data transmission, whereas the real robots only experienced the delay associated with the computer vision-based positioning system. Moreover, due to the formation and relative vectors, the virtual robots in workspace 1 incurred a double communication delay: the first delay originated from the virtual robots in workspace 2, and the second arose from the additional latency when transmitting the relative position data of the real robots in workspace 2 back to workspace 1. This results in two accumulated delays in the overall experimental cycle.