1. Introduction
Bilateral teleoperation (BT) is a control methodology ensuing a constant bidirectional flow of information between a local master device, managed and directly handled by a human operator, and a remote slave device, tasked to interact with an environment where direct human intervention is logistically or physically challenging, impractical, or impossible [
1,
2,
3,
4]. The classical application fields for BT range from aerospace and adverse-ground exploration [
5,
6] to precision handling [
7], telemedicine [
3,
4,
8,
9,
10,
11,
12], and telesurgery [
4,
10,
11,
12].
In a bilaterally teleoperated system (BTS), the bidirectional exchange of data enables the operator to directly perceive and remotely interact with the environment, allowing for telepresence, and enhancing precision and dexterity with situational awareness. However, the performance of BT systems can be significantly affected by factors such as communication delays, transmission errors, and mechanical limitations of the hardware, necessitating the development of advanced control strategies and optimization algorithms [
13,
14,
15] to ensure stability, flexibility [
16], stability through robustness [
17] or predictiveness [
18,
19], and security [
2,
20]. Among the earliest approaches proposed to cope with communication delays is the move-and-wait strategy, which decouples motion commands and force feedback by allowing the master device to send position commands, wait for the slave execution and feedback, and only then resume operation [
2,
21].
As first theorized by Ferrell and Sheridan [
1], BTSs contain three main control loops, as shown in
Figure 1:
A local control loop (in red in
Figure 1): it is closed among the human end user, the master device, and, optionally [
7], a local computer. The master system offers the end user feedback through a presentation subsystem. The end user, through the Human–Machine interface (HMi), observes this feedback, evaluates, and then articulates their goal, planning future movements within an environment independent of the remote one. This loop often incorporates a virtual and possibly augmented model of the system, frequently implementing a Digital Twin (DT);
A remote control loop (in green in
Figure 1): it is closed among the environment, the slave device, and, optionally, a remote computer. In this loop, control procedures required for routines that do not require direct human intervention enable automatic and unsupervised operation of the device, which is able to interact with the environment by means of actuation and sensoring subsystems;
A teleoperation control loop (in blue in
Figure 1): closed by all the above-mentioned elements, it represents the main loop for BT, enabling user telepresence through Human–Machine Interaction (HMI) with the master device, a bidirectional flow of information strongly dependent on the communication medium, and task execution and feedback from the slave device.
In the field of telesurgical operations, BT is implemented in procedures where the surgeon, physically separated from the operating table, performs movements on the master device, which are translated into commands for a remote slave robot. Through bilateral teleoperation, the system ensures real-time visual, haptic, and auditory feedback, enhancing precision and minimizing the impact of physiological tremors [
22]. A slave-teleoperated system is often implemented in minimally invasive surgery (MIS). MIS procedures shorten recovery and hospitalization times, reduce wound complications, and improve scar cosmesis [
11,
23]. MIS often involves laparoscopic procedures [
24,
25] adopting a Remote Center of Motion (RCM) rule to minimize surgical incision. The BT architecture also facilitates real-time collaboration and expertise sharing between surgeons located at different medical centers [
4,
11]. This includes telementoring, in which an expert provides remote guidance throughout the procedure, and teleproctoring, where a mentor actively supervises or assumes partial control over specific surgical steps [
3,
26,
27]. However, telesurgery also presents significant challenges, particularly concerning communication latency, data integrity, system robustness, and patient safety, which have driven extensive research in both hardware design and advanced control strategies [
4,
11,
12].
Several telesurgical robotic platforms have been developed and clinically tested over the years. One of the earliest systems was the ZEUS Robotic Surgical System (
Computer Motion,
Goleta,
CA,
USA), which enabled remote laparoscopic procedures and played a foundational role in the evolution of surgical robotics [
28,
29]. The da Vinci Surgical System (
Intuitive Surgical Inc.,
Sunnyvale,
CA,
USA) represents the most widely adopted platform worldwide, offering high-precision minimally invasive procedures with sophisticated visualization and motion scaling capabilities [
3,
4,
10,
12,
30]. The Senhance Surgical Robotic System (
Asensus Surgical,
Durham,
NC,
USA) introduces features such as head and eye-tracking camera control to enhance the surgeon’s situational awareness and navigation [
31,
32]. More recently, the Hugo RAS (
Medtronic,
Minneapolis,
MN,
USA) was introduced, providing modularity, portability, and advanced digital integration aimed at expanding access to robotic-assisted surgery across diverse healthcare settings [
33].
In this context, one of the authors previously proposed various master device architectures for RCM-constrained laparoscopic procedures [
34,
35], while recent work by the present research team has focused on the modeling, control, and evaluation of a prototype iteration called the Quasi-Spherical Parallel Manipulator (qSPM) [
36,
37,
38,
39], as shown in
Figure 2. The device’s 1
URU-2
RRR architecture enables haptic feedback and dexterous maneuvering of the end effector (EE) [
36], while various control methodologies have been implemented on both the teleoperation and local control loops [
36,
37,
38]. The spherical parallel architecture shares similarities with other systems present in the literature, such as [
40,
41].
This paper, conceived as an extended version of [
37], focuses on the reset functionality of the device. In this control mode, the system automatically resets the master device to its workspace center
to facilitate practical and precise coupling with the slave system. Centering the master device provides the surgeon with a neutral and ergonomically favorable starting posture, minimizes the risk of joint limit saturation during prolonged procedures, and ensures optimal correlation between master and slave workspaces, especially after interruptions, handoffs, or re-initializations. A properly implemented reset function could thus reduce intraoperative adjustment time, a challenge that must be faced by the surgeon [
42,
43].
This paper is organized as follows:
Section 2 presents the fundamental kinematics and control principles of the device, introduces the reset mode, describes its integration within the overall control architecture, and outlines the methodologies adopted for performance evaluation.
Section 3 and
Section 4 present and discuss, respectively, the results obtained from the preliminary testing of the device using these methodologies. The latter section concludes the paper by summarizing the key findings and providing perspectives for future developments.
3. Results
This section is devoted to presenting the results of (Ex1), (Ex2), and (Ex3), introduced in
Section 2.5, derived from the control structure from
Section 2.3 and applied following
Section 2.4.
The PTP algorithm described in
Section 2.3 is successfully applied to both (Ex1) and (Ex2), introduced in
Section 2.5 and illustrated in
Figure 9a,b, respectively.
Table 2 presents the time performance metrics (mean and standard deviation (Std)) obtained from the Python 3.11 script executed within the ROS environment described in
Section 2.3.3. The evaluation considers three path morphologies: direct, cis or trans, and a general case, as detailed in
Section 2.3.2.
Figure 10 shows significant reference and feedback signals from the four trials of (Ex3), namely
and
, as angle
is used for the computation of forward kinematics, as described in [
36]. Finally,
Table 3 shows the performance of said results in terms of
settling time and average tracking error
, demonstrating how the device successfully resets to workspace center
, as established in
Section 2.3.2.
4. Discussion and Conclusions
This paper has focused on the reset mode testing of the Quasi-Spherical Parallel Manipulator (qSPM) as an extended version of a previous work of the same authors [
37]. After presenting the necessary kinematics and control insights for the device’s architecture, this paper focused on the experimental evaluation of said control mode, featuring a PTP joint path planning algorithm constrained in
Section 2.3.2 and (7), implemented in
Section 2.3.3, and schematically portrayed in
Figure A1. The algorithm was then preliminarily evaluated with three different experiments, (Ex1), (Ex2), and (Ex3), regarding the first considerations of both the calculation and operational performances. The results presented in
Section 3 contribute to the following varying observations.
Regarding (Ex1),
Table 2 demonstrates optimal performance outcomes, demonstrating how the simplified optimization problem is able to output feasible paths within aspect
from random points in the aspect’s surface
(3) to aspect center
in milliseconds (<10 ms). Therefore, as previously mentioned in
Section 2.5, the experiment demonstrates the feasibility of the reset control mode in all the points inside
as the experiment, being applied on
, is conservative. This poses the basis of a responsive and receptive mode, an aspect of paramount importance for the telesurgical application field.
The effectiveness of this resetting mode was further evaluated in (Ex2). As shown in
Table 2, when both
and
lie on the surface
, the optimization task becomes more demanding, resulting in higher computation times compared to (Ex1). Nonetheless, feasibility is maintained for all the tested cases, and the computation times remain within the same order of magnitude (<10 ms) of (Ex1). Even if this evaluation setup is currently not yet implemented in the resetting control mode, this experiment demonstrates the robustness of the optimization algorithm, which is capable of outputting feasible joint space PTP paths within all points
.
Regarding (Ex3),
Table 3 shows promising preliminary results. Even if the implementation of the reset mode has not yet been optimized, as described in
Section 2.3.3, the device is able to smoothly reset in its central position in a matter of seconds, with
settling time
and an average residual error
, presented in
Section 3, less than
. The nature of the error can be attributed to sensor precision, whose resolution is equal to
, as presented in
Table A2, and other unmodeled errors entering the system, such as clearance and friction, a peculiar problem introduced in [
39].
Considering the promising outcomes of (Ex2), future developments will certainly focus on the full implementation of a PTP control mode within any point of
. In fact, this feature could play a key role in future developments, enabling the surgeon to smoothly readjust the master device within the local control loop, described in
Section 1, to a more ergonomic position while minimizing the time the slave device remains stationary. Since the device will also include axial displacement actuation to enable full RCM functionality, future developments could focus on integrating this additional degree of freedom into the control mode, allowing the entire device to be adjusted according to the end user’s preferences. Furthermore, smoother position control strategies could be employed, beyond the trapezoidal velocity profile implemented in the motor firmware, in order to improve precision and reduce jerk. As previously noted, the optimization algorithm is still preliminary and will undergo a full parameter optimization and thorough testing during the next development phase to refine the control action and avoid the risk of local optimality within
.