Abstract
Reliable and high-throughput communication between field robots and cloud services remain a key challenge in precision agriculture, where remote rural areas often lack consistent high-bandwidth connectivity. In this work, we introduce a new dual-link edge-to-cloud data transfer framework that combines long-range Low-Power Wide Area Networking (LPWAN) for essential control and monitoring with IEEE 802.11 Wi-Fi that carries bulk data over a Zenoh protocol. In addition, a data router dynamically switches the robot between 'Transfer Mode', in which sensor streams and imagery data are being forwarded via Wi-Fi, and 'Storage Mode', in which data are locally recorded in Robotic Operating System (ROS) 2 bags to prevent loss when connectivity degrades. To preemptively detect Wi-Fi link failures and issue routing instructions to the data router, an onboard anomaly detection node monitors heartbeat timing using a machine learning-based algorithm, namely the XGBoost model. Field trials demonstrate that (1) Wi-Fi transfers maintain sub-100 ms latency within 240 m of the gateway, (2) Long Rang (LoRa) communication persists reliably beyond 350 m with ≈0.1 s latency, (3) the router achieves an average of 0.8 s overlap when entering Storage Mode, and (4) the anomaly detector successfully flags link degradation ahead of an outage. Our framework scales to multi-robot deployments via ROS 2 namespaces and Zenoh multicast, laying the groundwork for resilient swarm operations in rural environments.
keywords Autonomous Agricultural Robot Anomaly Detection IoT-cloud continuum LoRa Zenoh
At a glance
A short structured summary of the article, written from its abstract and conclusions.
- Problem: field robots in rural farmland need to exchange data with cloud services, but high-bandwidth connectivity there is patchy and links drop as the robot moves away from the gateway.
- Approach: a dual-link framework in which long-range LoRa (LPWAN) carries essential control and monitoring messages, while Wi-Fi carries bulk sensor and image data over the Zenoh protocol, built on ROS 2.
- Data router: switches the robot between Transfer Mode (forward data over Wi-Fi) and Storage Mode (record locally in ROS 2 bags) so no data is lost when Wi-Fi degrades.
- Link-failure prediction: an onboard XGBoost-based anomaly detector monitors heartbeat timing and flags Wi-Fi degradation before an outage, triggering the router.
- Field results: Wi-Fi latency stayed under 100 ms within 240 m of the gateway; LoRa stayed reliable beyond 350 m at about 0.1 s latency; the router averaged 0.8 s overlap when entering Storage Mode.
- Scope and future work: designed to scale to robot swarms via ROS 2 namespaces, Zenoh and LoRa multicast (not yet validated on a fleet); developed as a use case for the EU Horizon ICOS meta operating system.
Cite this article
Please cite the published version in the proceedings of IoTAI 2025: The Second International Conference on IoT-AI: https://www.thinkmind.org/library/IoTAI/IoTAI_2025/iotai_2025_1_60_20046.html. An archived copy has the DOI 10.5281/zenodo.17735730.
IEEE (plain text)
I. Esfandiyar and K. Młodzikowski, "Dual-Link Data Resilient Edge-to-cloud Communication Framework for Agricultural Robots," in Proc. IoTAI 2025: The Second International Conference on IoT-AI, IARIA, 2025, pp. 27-34. ISBN: 978-1-68558-286-9.
BibTeX
@inproceedings{Esfandiyar2025DualLink,
author = {Esfandiyar, Iman and Młodzikowski, Kamil},
title = {Dual-Link Data Resilient Edge-to-cloud Communication Framework for Agricultural Robots},
booktitle = {IoTAI 2025: The Second International Conference on IoT-AI},
publisher = {IARIA},
year = {2025},
pages = {27--34},
isbn = {978-1-68558-286-9},
url = {https://www.thinkmind.org/library/IoTAI/IoTAI_2025/iotai_2025_1_60_20046.html},
doi = {10.5281/zenodo.17735730},
keywords = {Autonomous Agricultural Robot; Anomaly Detection; IoT-cloud continuum; LoRa; Zenoh}
}RIS
TY - CONF TI - Dual-Link Data Resilient Edge-to-cloud Communication Framework for Agricultural Robots AU - Esfandiyar, Iman AU - Młodzikowski, Kamil T2 - IoTAI 2025: The Second International Conference on IoT-AI PB - IARIA PY - 2025 SP - 27 EP - 34 SN - 978-1-68558-286-9 UR - https://www.thinkmind.org/library/IoTAI/IoTAI_2025/iotai_2025_1_60_20046.html DO - 10.5281/zenodo.17735730 KW - Autonomous Agricultural Robot KW - Anomaly Detection KW - IoT-cloud continuum KW - LoRa KW - Zenoh ER -
1 Introduction
Precision farming and autonomous machinery are two concepts that are becoming increasingly prevalent in modern agriculture, to simplify key aspects of agricultural work by transferring physically demanding tasks to machines and maximizing crop yields, therefore conserving resources [1]. Tasks such as weed and pest control or precise plant fertilization are among those performed by autonomous machines in agriculture, such as unmanned autonomous robots. For the detection of environmental and/or soil parameters, the robots are equipped with Internet of Things (IoT) sensors that can detect objects on site, generating a substantial amount of data. The analysis, utilization and storage of this data requires the availability of extensive computing resources, which can be provided through cloud computing [2]. However, a challenge arises in the transfer of data from the robot to the cloud, as an internet connection in the fields is often unreliable or unavailable [1]. Given the expansive and sparsely populated areas typically utilized for agricultural purposes, there is a clear necessity for a communication solution capable of operating over considerable distances while simultaneously transmitting substantial quantities of data. The sole use of LPWAN technologies are not a viable option due to the high data volumes involved. While LPWAN enables data to be send over the necessary distances, their data rates and payload sizes are inadequate for transmitting more than a few kilobytes per day [3]. Even in the licensed domain of LPWAN solutions, the throughput would be insufficient. Conversely, application layer protocols operating over Wi-Fi do not achieve the required distance, yet can accommodate the necessary data volume [4]. To deliver the necessary data while maintaining a constant connection to the edge/cloud, we propose the integration of both solutions in an agricultural use case that incorporates an autonomous robot into the edge/cloud continuum.
In this paper, we propose a novel data transfer method that employs unlicensed spectrum physical layer LoRa to transmit control messages as well as minimal vital messages to an agricultural robot, thereby providing information regarding the robot status and its location at a self-provided gateway and enabling an emergency shutdown of the system if necessary. Additionally, the recently, from the eclipse foundation and Zettascale developed Zenoh protocol is utilized for data exchange between the three participants of the data exchange, namely the robot, the gateway and the cloud.
Zenoh is a publisher/subscriber/query protocol designed to operate in the microcontroller to cloud continuum, supporting peer-to-peer, routed and brokered communication via WiFi [5].
To detect packet loss during data transmission in an agricultural setting, where the distance between the robot and the gateway is rather high, to minimize the distance traveled by the robot, we employ an anomaly detection mechanism in the robot to assess whether data transmission works properly or if it is better to start recording backup data. The performance of the proposed system is evaluated through field experiments, which demonstrates the efficacy of the data exchange between the robot and the gateway.
The rest of the paper is organized as follows. Section 2 presents the related work. Section 3 shows the system architecture. Section 6 describes the experiment methodology. Section 7 discusses the experiment results. Finally, Section 8 concludes the paper.
3 Agricultural Robot
The agricultural robotic platform, AgroRob, is designed to autonomously navigate fields for precision farming tasks such as crop spraying and weeding. Equipped with advanced sensors, communication modules, and a modular software architecture, it ensures reliable localization, efficient operation, and seamless data exchange with the cloud-based systems. This section details the autonomous functionalities, hardware setup, software architecture, and communication protocols employed by the robot.
3.1 Robot Autonomous Functionality
The agricultural platform (AgroRob) autonomously navigates fields for precise crop spraying and weeding. It achieves accurate localization by fusing data from dual Global Navigation Satellite Systems (GNSS) modules, an Inertial Measurement Unit (IMU), and wheel odometry. This enables it to follow crop lines and share its position with a cloud-based system. A Deep Neural Network (DNN) model processes camera images to detect crops and weeds, for precise spraying. Computer vision minimizes chemical use, reducing fertilizer and herbicide consumption while improving efficiency and sustainability.
3.2 Robot Hardware
The robot features an onboard computer managing control and communication. It includes localization sensors, cameras, a Wi-Fi router, and a LoRa transmitter for cloud data transfer. Communication occurs via a Controller Area Network (CAN) to USB adapter, handling status updates and control commands. Figure 1 illustrates the hardware setup.
3.3 Robot Software
The robot’s software is developed using ROS 2 [14], utilises peer-to-peer communication via the Data Distribution Service (DDS). Modules, such as mission handling, localization, and navigation, communicate via UDP or TCP, based on Quality of Service (QoS) settings. Data is transmitted through a publish-subscribe model for broadcast communication or services for direct interactions. Certain topics enable cloud communication for control and monitoring, as shown in Figure 2.
3.4 Messages
LoRa communication involves sending string data. Messages to the gateway contain three comma-separated values, totalling up to \(29bytes\):
ID: Unique packet identifier.
Coordinates: Latitude and longitude.
Time: UTC timestamp.
The gateway sends two boolean control commands under \(0.5Hz\):
Data Control Command: Chooses Wi-Fi transmission or local logging.
Emergency Stop Command: Immediately halts the robot.
Wi-Fi communication transmits operational data, including sensor readings, mission status, and field analysis, essential for robot performance and agricultural insights.
4 Data Transfer and Storage
As shown in Figure 3, our proposed data transfer method assumes that both the robot and the gateway can communicate using LoRa and Wi-Fi, with both systems having independent GNSS localization available via a u-blox ZED-F9P GNSS module onboard. The robot is equipped with an industrial Wi-Fi router, the NR600 from NavigateWorx, along with a Heltec WiFi LoRa 32 V3 module, while the gateway features a Nighthawk® AXE3000 Wi-Fi USB adapter and a Heltec WiFi LoRa 32 V3 module. In addition, the gateway is also equipped with internet connectivity through a 5G/LTE modem.
Both the robot and the gateway are performing localization using GNSS. Robot geolocation is sent through LoRa to the gateway. Based on this information and its own position, the gateway calculates the distance to the robot. This data together with heartbeat delay calculated based on UTM time is then used by Data Router software to switch between two states:
Transfer Mode: While the robot is in an efficient range and strength of Wi-Fi connection with the gateway, it operates in Transfer Mode. Selected data (represented by ROS2 topics) is being sent over Wi-Fi to the gateway using a Zenoh bridge.
Storage Mode: Conversely, when there is a risk of losing the Wi-Fi connection between the robot and the gateway, the robot is switched to Storage Mode. In this mode, the Zenoh bridge is turned off to minimise the risk of data interception. The data that normally in Transfer Mode would be sent to the gateway is instead being recorded using ROS2 bags and stored locally for future synchronization. The proposed communication flow is presented in Figure 4.
4.1 Data router
Every time the gateway receives a geolocation of the robot (latitude \(\phi\) and longitude \(\lambda\)) through LoRa, it calculates the distance between itself and the robot using the following equations:
\begin{align} c &= \frac{1}{\sqrt{\cos^2(\phi) + (1 - f)^2 \cdot \sin^2(\phi)}}\tag{1}\\ s &= (1 - f)^2 \cdot c\tag{2} \end{align}
\[\begin{aligned} x &= (R \cdot c + h) \cdot \cos(\phi) \cdot \cos(\lambda) \\ y &= (R \cdot c + h) \cdot \cos(\phi) \cdot \sin(\lambda) \\ z &= (R \cdot s + h) \cdot \sin(\phi) \end{aligned}\]
Given two points: \(\text{gateway} = (x_G, y_G, z_G)\) and \(\text{robot} = (x_R, y_R, z_R)\), the Euclidean distance \(d_{GR}\) is:
\[d_{GR} = \sqrt{(x_G - x_R)^2 + (y_G - y_R)^2 + (z_G - z_R)^2}\tag{3}\]
Where:
\[\begin{aligned} R &= 6356752.3142~\text{(Earth radius)} \\ f &= 1/298.257223563~\text{(Earth flattening factor)} \\ \phi&~\text{is the latitude}\\ \lambda&~\text{is the longitude} \end{aligned}\]
The calculated distance, together with the value of delay calculated based on the timestamp of messages received from the gateway is continuously fed to the anomaly detection software. The software analyzes this data in real-time to detect any abnormalities in communication behaviour. Upon identifying an anomaly, it issues commands to the data router on the robot. The data router then switches between Storage Mode and Transfer Mode as needed, ensuring an overlap between data recording and transmission to prevent any potential data loss.
In cases of Storage Mode data loss is mitigated through local storage on the edge device. However, since the operational data of the agricultural robot primarily consists of numerical values and image data that are processed locally, the volume of stored information remains relatively low and does not necessitate large-scale storage solutions. It should be noted, however, that the local storage of data is inherently constrained by the physical storage capacity of the edge device. Despite this limitation, retaining operational data is essential for the robot’s continued functionality—for example, to maintain a record of the location and status of individual crop instances, which is critical for planning and executing future operations on the same field plots.
5 Anomaly Detection
Our anomaly detection system employs a machine learning approach to identify abnormal behaviour in Wi-Fi data transmission. The system monitors robot’s heartbeat timing data and the distance between the robot and the gateway, to detect potential failures or malfunctions. It implements a two-stage process: first, a model training phase using XGBModel with KMeansScorer to learn normal operational patterns from historical data; second, a detection phase, where the AnomalyDetectionNode continuously analyzes incoming data against these learned patterns in real time.
The detection mechanism combines IQRDetector and ThresholdDetector methodologies to identify statistical outliers, publishing alerts when anomalies exceed a configurable percentage threshold. Operating independently on ROS2, the system samples data at regular intervals (configurable, set to 2 seconds in the current implementation) and maintains a sliding window of observations to balance detection sensitivity with computational efficiency.
For reproducibility, the XGBModel was trained on 3285 heartbeat intervals. The model uses lags=64. Anomaly scores are produced by a KMeansScorer with \(k=20\) clusters and a 32-sample window (component_wise=False).
By continuously analyzing heartbeat timing and flagging outliers in real-time, the anomaly detector enables the robot to switch preemptively between Transfer and Storage modes, beginning local data logging before Wi-Fi breaks down and reenabling Zenoh the instant link quality recovers, thus eliminating data gaps and negative overlaps. Moreover, when sustained anomalies indicate worsening channel conditions, the system can dynamically throttle non-critical streams (e.g., reduce image resolution) to preserve essential telemetry, while simultaneously relaying “link degrading” alerts back to the operator over LoRa. If anomaly rates cross a critical threshold, the detector can even trigger an immediate emergency-stop command, ensuring both data integrity and operational safety without human intervention.
Our implementation incorporates adaptive sensitivity adjustments based on environmental conditions and operational context. During periods of known network congestion or when the robot traverses areas with documented Wi-Fi interference, the system automatically adjusts detection thresholds to reduce false positives while maintaining vigilance for genuine anomalies.
This approach allows for early warning of developing issues before they cause critical failures, making it possible to act accordingly to prevent data loss as much as possible. The modular design of the system also enables easy integration of additional detection algorithms as they become available, ensuring future extensibility.
6 Experiments Methodology
This section describes the methodology used to evaluate our approach’s performance and accuracy. The experiments test the hypothesis under various conditions to ensure comprehensive and real-world-representative results.
6.1 Experiment Setup
In our experiments, we mimic real-world applications. The gateway is stationary while the robot moves toward and away from it as shown in Figure 5.
To ensure accurate time synchronization for one-way communication measurements, messages are timestamped using GNSS-based UTC time [15], as both the robot and the gateway are equipped with GNSS receivers. The gateway also functions as an Real-Time Kinematic (RTK) base station, providing localization corrections to the robot for improved accuracy. GPS signals serve as a common time reference, enabling timestamp comparisons to calculate one-way communication delays, especially when switching between LoRa and Wi-Fi. This method avoids complexities in round-trip measurements, which can obscure path delays in asymmetric networks.
Two series of connectivity and data transfer experiments were conducted:
1. The robot moves away from the gateway while transmitting data via both LoRa and Wi-Fi (using the Zenoh bridge). As the distance increases, Wi-Fi eventually goes out of range. During this process, data is logged, including timestamps of messages generated by the robot and received at the gateway. This information is used to analyze transfer characteristics and to generate training data for the anomaly detection model.
2. The same procedure is repeated with the anomaly detection and data routing system enabled; the result is illustrated in Figure 8.
6.2 Experiment Metrics
Key performance metrics include:
Communication Latency:
Wi-Fi: The time taken for data transfer over Wi-Fi within range. It is computed as: \begin{align} \Delta_t &= t_{\mathrm{curr}} - t_{\mathrm{stamp}}\tag{4}\\ \tau &= t_{UTC_G} - t_{UTC_R} + \Delta_t\tag{5} \end{align} Where: \[\begin{aligned} &t_{curr}~\text{is the current ROS2 time,}\\ &t_{stamp}~\text{is the UTC message timestamp,}\\ &t_{UTC_G}~\text{is UTC time on the gateway,}\\ &t_{UTC_R}~\text{is UTC time on the robot,}\\ &\tau~\text{is the delay.} \end{aligned}\]
LoRa: Measured similarly, with UTC time added to LoRa messages.
Packet Loss:
LoRa: Reliability of position data sent from the robot. Packet loss is calculated by tracking message ID gaps.
Network Coverage:
Wi-Fi: Maximum reliable connection distance.
LoRa: Maximum distance for reliable command reception.
Range-based Switching: Effectiveness of transitioning between Wi-Fi and LoRa.
Data Overlap:
As described in Section 4.1, switching between Transfer Mode and Storage Mode must ensure data overlap. The target overlap is \(1 s\), though factors like Zenoh bridge stand-up time may influence it.
Zenoh to Bag: Time between the first message stored in rosbag2 on the robot and the last received at the gateway. A positive value indicates overlap, while a negative value means data loss.
Bag to Zenoh: Time between the first message received at the gateway and the first stored in rosbag2. A positive value means overlap; a negative value indicates loss.
These evaluation metrics ensure a balanced assessment of the method’s performance. Each configuration underwent multiple runs to ensure consistency and account for variance. The final results are reported as averages with standard deviations, where applicable.
7 Experiments Results
A series of field test experiments have taken place involving the robot moving away from the gateway while measuring the defined metrics of Wi-Fi and LoRa at the gateway.
7.1 WiFi and LoRa delay
Figure 6 illustrates the delay experienced by both Zenoh and LoRa communication over time and distance from the gateway. In this experiment, the distance between the robot and the gateway is gradually increased. As the distance between the two devices increases, the average delay of the Zenoh messages also increases until approximately 240 meters, at which point connectivity to the gateway is lost. The distance is then extended to 350 meters, which has no impact on the delay of the LoRa messages.
In order to regulate the transfer of data via Wi-Fi and to facilitate local logging, a threshold of 50 meters was implemented for Wi-Fi transmissions in the course of the following experiments. The results of this can be observed in Figure 7a. In this experiment, the distance between the robot and the gateway initially increases and subsequently decreases. Upon reaching the threshold of 50 meters, the Wi-Fi transmissions are terminated, while the LoRa control messages continue to be exchanged. Figure 7b illustrates the number of Wi-Fi packets received and LoRa packets lost. The impact of the threshold can be observed here, as Wi-Fi packets are only transmitted when the distance is less than 50 m and the delay therefore remains below 0.1s. However, at a distance of 60 m, loss of LoRa packets occurs. The packet loss has no influence on the delay of the subsequent LoRa packets as this value fluctuates around 0.1 s for LoRa packets.
In order to regulate the transfer of data via Wi-Fi and to facilitate local logging, a threshold of 50 meters was implemented for Wi-Fi transmissions in the course of the following experiments. The results of this can be observed in Figure 7a. In this experiment, the distance between the robot and the gateway initially increases and subsequently decreases. Upon reaching the threshold of 50 meters, the Wi-Fi transmissions are terminated, while the LoRa control messages continue to be exchanged. Figure 7b illustrates the number of Wi-Fi packets received and LoRa packets lost. The impact of the threshold can be observed here, as Wi-Fi packets are only transmitted when the distance is less than 50 m and the delay therefore remains below 0.1s. However, at a distance of 60 m, loss of LoRa packets occurs. The packet loss has no influence on the delay of the subsequent LoRa packets as this value fluctuates around 0.1 s for LoRa packets.
(a) WiFi and LoRa packet delays
(b) WiFi Received packets and LoRa packet lost
Time overlap between data sent over Wi-Fi and stored in rosbag2 was measured in multiple experiments. The results are presented in Table 1. The data shows that the average time of data overlap for switching from Transfer Mode to Storage Mode is \(0.8\) seconds. This means that for an average of \(0.8\) seconds data is stored both locally at the robot and sent over Wi-Fi (using Zenoh) to the gateway. Therefore, the process of starting bag recording takes an average of \(0.2\) seconds (as the desired overlap was set to \(1\) second).
In the second case, where the system switches from Storage Mode to Transfer Mode, the average overlap is \(-1.0667\) seconds. The negative value indicates that there was a gap between the data stored locally on the robot and the data sent using the Zenoh bridge. The result is illustrated in Figure 8.
Such a result indicates that a much higher overlap is needed when switching from Storage Mode to Transfer Mode. The most probable cause of this behaviour is the stand-up time of the Zenoh bridge, as the process is stopped each time the system switches to Storage Mode.
| Transfer\(\rightarrow\)Storage [s] | Storage\(\rightarrow\)Transfer [s] | |
|---|---|---|
| Avg. | 0.8000 | -1.0667 |
| Std. | 5.19\(\times 10^{-9}\) | 1.0263 |
| Diff. | 0.2000 | 2.0667 |
7.2 Anomaly detection model performance
The performance of the anomaly detection model was evaluated using standard classification metrics: precision, recall, and F1-score. These metrics were calculated by comparing the predicted labels (pred_labels) against the ground truth labels (gt_labels). The calculations were performed using the precision_score, recall_score, and f1_score functions, with the zero_division parameter set to 0 to handle any potential division by zero issues gracefully. The results of these evaluations are summarized in Table 2, providing a view of the model’s ability to correctly identify anomalies in Wi-Fi communication while minimizing false positives and false negatives.
| Precision | Recall | F1-score | |
|---|---|---|---|
| Score | 0.951 | 0.966 | 0.958 |
8 Conclusion and Future Work
This study presents a novel data transfer method that integrates LoRa communication with Wi-Fi to enhance the operational capabilities of autonomous agricultural robots. Utilizing LoRa for essential control messages and minimal status updates facilitates reliable communication in rural areas, where connectivity is frequently limited. The results indicate that employing LoRa to support Wi-Fi communication can significantly improve the functionality of robots operating in remote regions.
In this work, we demonstrated the viability of our framework using a single robotic platform while inherently retaining the capability to support multiple robots and instances. Our architecture leverages the Robot Operating System’s namespace and topic remapping features, allowing each robot to publish and subscribe to uniquely prefixed topics (e.g., /robot_<ID>/cmd_vel), thereby isolating and managing concurrent Wi-Fi message streams. A single instance of the Zenoh bridge at the gateway is sufficient to ingest and process these parallel communications. Once received, messages are archived in the cloud along with their originating edge-device identifiers. Conversely, command messages can be targeted to individual robots by publishing to the appropriate namespaced topic.
Moreover, our framework accommodates LoRa communications: multicast downlink enables the simultaneous delivery of identical packets to a group of robots via a single gateway module. In principle, one gateway can orchestrate the bidirectional data flow for an entire robotic swarm, seamlessly linking edge devices with the cloud.
While the framework already supports multi-robot and multi-communication mechanisms, empirical validation within a true swarm setting remains to be conducted. Future work will focus on: (1) deploying and stress-testing the system with a heterogeneous fleet of robots; (2) evaluating network performance and latency in high-density LoRa multicast scenarios; (3) extending the cloud-storage schema to incorporate advanced metadata and secure access controls; and (4) optimizing the system’s behaviour during communication mode switching, specifically addressing the stand-up time of the Zenoh bridge. In the current implementation, the Zenoh bridge process is terminated when switching from Transfer Mode to Storage Mode and restarted when switching back. This reinitialization introduces additional latency due to the Zenoh bridge’s stand-up time, affecting the continuity of data transfer. To mitigate this, we propose developing an improved switching mechanism that avoids re-executing the Zenoh process.
This work contributes to the development of use-case scenarios for the validation of the IoT Cloud Operating System (ICOS), a meta operating system under development within the European Union’s Horizon program. A notable limitation of the proposed framework is that, when data is stored locally in the absence of Wi-Fi, the logged data must be transferred to the cloud manually. It is anticipated that ICOS will ultimately manage the data transmission functionalities associated with this use case, encompassing data transfer and storage between edge devices and the cloud.
Acknowledgment
This project has received funding from the European Union’s HORIZON research and innovation program under grant agreement No 101070177.
References
About this page
This page reproduces the full text of the article. Minor editorial differences from the typeset article may exist; the version of record is published in the proceedings of IoTAI 2025: The Second International Conference on IoT-AI at https://www.thinkmind.org/library/IoTAI/IoTAI_2025/iotai_2025_1_60_20046.html. An archived copy has the DOI 10.5281/zenodo.17735730.
Machine-readable versions: Markdown full text · BibTeX · RIS · llms.txt