Assistance in Picking Up and Delivering Objects for Individuals with Reduced Mobility Using the TIAGo Robot

Abstract

Individuals with reduced mobility, including the growing elderly demographic and those with spinal cord injuries, often face significant challenges in daily activities, leading to a dependence on assistance. To enhance their independence, we propose a robotic system that facilitates greater autonomy. Our approach involves a functional assistive robotic implementation for picking, placing, and delivering containers using the TIAGo mobile manipulator robot. We developed software and routines for detecting containers marked with an ArUco code and manipulating them using the MoveIt library. Subsequently, the robot navigates to specific points of interest within a room to deliver the container to the user or another designated location. This assistance task is commanded through a user interface based on a web application that can be accessed from the personal phones of patients. The functionality of the system was validated through testing. Additionally, a series of user trials were conducted, yielding positive feedback on the performance and the demonstration. Insights gained from user feedback will be incorporated into future improvements to the system.

1. Introduction

Ensuring a decent quality of life for individuals with reduced mobility is a significant social issue. This demographic encompasses all individuals with limited motor skills, whether these limitations are temporary or permanent.

A diverse range of populations face mobility issues, including the growing elderly demographic and individuals with spinal cord injuries. The latter can experience a spectrum of impairments, ranging from complete loss of mobility to alterations in basic bodily functions [1,2], depending on the affected area [3]. The necessity of assistance for certain tasks as a result of mobility limitations creates a situation of dependence on daily activities. Typically, assistance for individuals with functional diversity is provided by close family members or healthcare assistants.

In this context, robotics serves as a tool to enhance user independence. This field is known as Assistive Robotics, which is defined as the use of robots to directly and adaptively assist and interact with humans [4]. Assistive Robotics emerges as a means to help people meet their needs and facilitate their daily activities. To achieve this objective, several proposals have been put forth.

Among them, social robotics represents a significant focus, i.e., on developing robots that can provide support and entertainment [5,6,7,8]. This implementation seeks to make the interaction with the user natural and sociable so that the robot is perceived positively and pleases the user. It is crucial for user acceptance that individuals feel at ease and comfortable interacting with the robot, thus enabling its intended functionality [8]. Conversely, if the user is reluctant to interact with the robot, its effectiveness may be hindered [9].

Assistive Robotics has also been developed to assist individuals with reduced mobility aiming at the goal of increasing independence and self-sufficiency. Prostheses and exoskeletons have been developed [10,11,12,13] to provide strength assistance for movement or manipulation, and are widely used in the medical field of rehabilitation. Additionally, other robotic systems are being developed. For example, some propose the use of manipulator robots to assist users in object manipulation tasks [14,15,16,17], while others use mobile robots to serve people as autonomous transport or walking guides in various environments [18,19,20,21,22].

However, the potential of using mobile manipulator robots appears to be broader than that of other types of robots, as they can both manipulate and navigate. Users can remotely operate these platforms, enabling the completion of necessary tasks.

These platforms can be teleoperated by the user to realize the needed tasks. For instance, the teleoperation of a robotic arm can be achieved by implementing an application interface [23], through human gestures [24], or a 3D controller [25].

On the other hand, autonomous use of these devices promises a more useful form of assistance, although it also presents several challenges. The primary challenges [26] arise from the dynamic and unpredictable nature of the environment, the lack of expertise among users, the well-defined and adaptable tasks, and the necessity to ensure the safety and integrity of users and their belongings.

With this aim, some have proposed a multi-functional autonomous platform with a friendly appearance [27], leveraging artificial intelligence, a flexible decision engine, and autonomous navigation. This platform is designed to be completely safe, featuring collision detection and a soft artificial leather covering. Others suggest a multi-robot approach [28] involving a sensorized environment, a mobile social robot, and a mobile dual-manipulator robot that collaborates to assist, accompany, and serve elderly individuals in their homes in an autonomous manner.

In this context, we propose an approach to assist people with reduced mobility using the TIAGo robot. The robotic system implemented can navigate around a domestic or healthcare setting and perform picking up, placing, or delivering containers for objects to the user. The user is assumed to be bedridden but with mobility in the upper extremities, allowing them to control the robot from a tablet or personal phone. The primary objective of this approach is to implement a preliminary assistance system that can be tested with users to ascertain their needs and incorporate their feedback into future developments.

2. Materials and Methods

This section outlines the scope of the assistive task we implemented. It also describes the materials used, such as the TIAGo robot and containers for objects. Finally, it provides a detailed explanation of the implementation architecture, covering navigation, vision, manipulation, routine coordination, and the user web app.

2.1. Task and Materials

The assistive task implemented in this work involves picking up containers for objects and placing or delivering them within a home environment. This setting is supposed to be in a common room with furniture, like tables, shelves, and a bed, in which the location and dimensions are known and mapped. The user is supposed to be in bed due to their reduced mobility.

For that purpose, the user can command the robot through a web app running on a tablet or phone. The user can request the robot to pick up a specific container located at a certain point in the room, and then deliver it to the user or place it on another table.

2.1.1. TIAGo

TIAGo (see https://pal-robotics.com/es/robot/tiago/, date accessed 1 August 2024) is a mobile manipulator robot from PAL robotics oriented to research. Different model configurations are available, varying in the end-effector, the number of arms, and the user interface. The model we worked with is shown in Figure 1 and consists of a differential mobile base, a prismatic torso, a manipulator arm with 7 degrees of freedom, a gripper as the end-effector, an RGB-D camera installed on a pan and tilt system at the head position, and an endoscopic camera added to the gripper.

2.1.2. Containers for Objects

The objects required by the user are placed in containers to facilitate their detection, grasping, and delivery. These containers are designed as rectangular boxes with cubic handles, as shown in Figure 2. Its handle is specifically shaped to accommodate the gripper and is 6 cm wide to be compatible with the 8 cm gripper. In addition, the handle has an ArUco marker [29] that can be recognized by the robot using computer vision. This ArUco marker encodes a number that is also useful to distinguish between the available containers.

2.2. Implementation

In this subsection, the software implementation we carried out is explained. Figure 3 shows the architecture of the implementation, which consists of various hierarchical nodes in a ROS Melodic framework (see http://wiki.ros.org, date accessed 14 July 2024). The mid-level nodes send commands to the controllers of the TIAGo robot, while the coordinator node directs the mid-level nodes in a way that organizes the execution of assistance routines, and finally, the web interface node is at the highest level and is responsible for receiving the request from the user and transmitting it to the routine coordinator.

The functionalities provided by each component are detailed below, starting with the mid-level nodes, followed by a detailed description of each routine organized by the coordinator, and finally the web interface.

2.2.1. Mid-Level Nodes

The mid-level nodes process information provided by the sensors and services of the TIAGo robot and issue commands to the actuators and services. These nodes are categorized by their functionality:

• Navigation node: The robot implements the ROS stack navigation (see http://wiki.ros.org/navigation, date accessed 4 June 2024) for autonomous navigation and it is leveraged for use in assistive tasks.
  For this purpose, a map of the environment has to be generated beforehand. Then, on this map, the points of interest (POIs) are saved in a list with an ID associated with them. POIs are those locations where containers can be found like the position of the robot in front of the table, and where the user can be found, which is the position in front of the bed. In this way, the coordinator or web app nodes will request this navigation node to move to a POI by providing its ID.
• Vision node: This node scans images to identify ArUco markers and calculate their 3D positions in space.
  This node constantly executes a loop, scanning RGB images from both cameras (head and gripper) by using the library aruco_ros (see https://wiki.ros.org/aruco_ros, date accessed 13 August 2024), which provides real-time marker-based 3D pose estimation. However, just the corner pixels will be used. When an ArUco marker is detected, the pixel centroid is computed and published along with its number ID by ROS topic. In addition, a modified image with the centroid, ID, and bounding box is plotted for visualization, like in the example from Figure 4.
  Regarding markers detected with the RGB-D camera on the head, their position in space can also be determined. For this purpose, the value of the depth image corresponding to the centroid pixel is used, and the coordinates are computed using the camera’s intrinsic parameters. This information is also published via ROS topics.
• Manipulation node: This node is composed of three sub-nodes to control the head, the gripper, and the arm–torso group, as previously shown in Figure 3.
  The head control enables the routine coordinator to request a specific point in space for the camera to focus on. This is achieved by calculating the values of the pan and tilt controllers based on the intrinsic parameters of the camera.
  The gripper control involves commanding the gripper controllers to either open to their maximum aperture or close until no further movement is achieved, indicating a grip.
  On the other hand, the MoveIt library [30] is used to control the arm–torso group. This allows us to plan safe trajectories that avoid self-collision and to define constraints or virtual obstacles.
• TTS node: This node is for the text-to-speech (TTS). Explanatory behavior is a crucial feature of a human assistive robot [31]. For this purpose, at the beginning of each routine or movement, the coordinator node requests advice through the TTS node on which the task or action is to be performed. This node also receives requests to ‘speak’ social expressions, e.g., salutations, when initiated.
• Diagnosis node: This node collects information about the robot’s state and publishes it to the web app for its display. This information includes the battery level, current state (stop or move), current sub-task (e.g., navigating), localization values, and actuator state (normal or overheat). In case an alert occurs, like a low battery level, this node commands the TTS to inform about the issue.

2.2.2. Routine for Picking a Container from the Table

This routine consists of detecting and picking up a requested container placed on a table. This process is illustrated in the flowchart shown in Figure 5 and in the sequence of frames shown in Figure 6. It is supposed to start with the robot positioned in front of the table where the container is located, and the execution steps are as follows:

• Look for the container: The coordinator initiates the process by searching for the specified ArUco marker ID received by the user’s request. The process is represented by the finite state machine shown in Figure 7. It begins with a simultaneous tilt and scan of the camera using vision and head node services, which continue until the marker is detected. Once detected, the image is centered on the marker, and the coordinates are computed. If the marker is not found during centering, the head moves slightly to re-detect the marker, addressing any issues caused by delays or occlusions in the initial position computation.
• Correct base position: The optimal distance for container pick-up has been empirically determined to be between 0.8 and 0.9 m. Once the marker position is obtained, the base is moved until it falls within this range.
• Gripper centering: The marker position obtained may have some errors, which can cause the gripper to miss the container handle, resulting in a failed pick-up. To avoid this, the camera on the gripper is used. This process follows the finite state machine shown in Figure 8. Once the gripper is positioned in front of the marker, the end-effector moves along the Cartesian axis proportionally to the error between the detected centroid and the image center. If the marker is not detected, a spiral movement in that plane is executed to locate the marker. Once the image is centered, the pose of the end-effector provides a more accurate position of the marker in height and width. The distance to the marker is still obtained from the RGB-D camera.
• Pick up the container: Once the pose of the container is determined, the pick-up process is executed. The goal in this step is to achieve the grasping position shown in the scheme of Figure 9. This involves moving the end-effector in front of the container handle with the gripper open. The end-effector then approaches the grasping frame to the determined ArUco position and closes the gripper. After securing the handle, the end-effector is elevated and retracted to a distance of 0.6 m from the base. The pick-up process concludes by moving the base backward 0.2 m.

2.2.3. Routine for Picking a Container from the Shelf

This routine consists of detecting and picking a requested container placed on a designated shelf. This process is an adaptation of the previous routine for picking a container from a table, adjusted for picking from elevated positions. It follows the flowchart shown in Figure 10 and the sequence of images illustrating the task in Figure 11. Starting with the robot positioned in front of the shelf where the container is located, the steps are as follows:

• Look for the container: This sub-process is the same as the one used for picking from the table and follows the finite state machine shown in Figure 7.
• Correct base position: Again, this sub-process is the same as the one implemented before.
• Gripper centering: This sub-process includes a modification. First, it moves backward 0.3 m to create space for raising the gripper to an elevated position. Then, the previously presented finite state machine from Figure 8 is executed. Once the more precise location of the container is obtained, the robot moves forward 0.3 m.
• Pick up the container: The ‘pick’ described before is executed by grabbing the container with the end-effector and then retreating from the shelf, as shown in Figure 11c.
• Post-pick: Finally, the end-effector is commanded to predefined intermediate safe poses between the high pose and the final retreated pose of Figure 11d. For this trajectory, a constraint of maintaining the orientation is set via MoveIt.

2.2.4. Routine for Picking a Container from the User

This routine facilitates the picking of a container being offered by the user. The process starts with the robot in front of the user’s location and follows the following sequence, represented in Figure 12 and illustrated in the sequence in Figure 13:

• Pre-pick: The routine begins by commanding the arm to a pre-defined configuration as shown in Figure 13a.
• Pick: The end-effector is commanded to move forward. An advisory speech message is issued to the user, instructing them to place the container handle between the finger grippers; after a brief wait, the grab is executed.
• Post-pick: The end-effector is retracted closer to the torso, thereby completing the routine.

2.2.5. Routine of Placing the Container on the Table

This routine involves placing the container on a table. The process starts with the robot positioned in front of the table, with knowledge of its height and distance, and with the container secured with the end-effector. The task is described by the diagram in Figure 14, while in Figure 15 shows the sequence of frames:

• Pre-place: The process starts with moving the end-effector over the designated position.
• Place: The end-effector is lowered to a position 1 cm above the known table height, and the gripper is opened.
• Post-place: Subsequently, the end-effector is raised and retracted, completing the sequence by moving the arm to its home configuration.

2.2.6. Routine of Deliver Container

This is the complete routine that integrates both navigation and manipulation processes. For this task, the user must specify through the interface the ID number of the container to be picked up, the name of the location where it is situated (e.g., table), the destination point for delivery, and, if the container is to be delivered to the user, whether it should be dropped or held for the user to access the contents only.

The sequence is shown in the flowchart of Figure 16; the steps in this routine are as follows:

• Navigate to the container: The routine starts with the robot navigating to the point where the user locates the container.
• Pick up the container: The point at which the container is located determines the routine that is executed. This is one of the previously presented routines, namely picking from a table or shelf, or picking from the user.
• Navigate to the delivery point: With the container securely held, the robot is commanded to navigate to a position near the delivery point. If the point is the bed, upon arrival, the robot notifies the user of its presence and the action it will perform (holding or dropping the container). Then, the robot navigates to the delivery point.
• Deliver container: If the delivery point is a table, the robot performs the previously described routine of placing the container. If the delivery point is to the user, the process is illustrated in Figure 17 and is as follows: The routine begins by moving the end-effector forward to the user. The robot then notifies the user of the action it will perform (either holding or dropping the container). It executes the action by either maintaining its grip or opening the gripper to release the container. After a brief wait, the end-effector is retracted to a distance of 0.6 m. If the action involves dropping the container, the arm is then commanded to return to its home position.
• Navigation to rest: Finally, the robot is commanded to navigate to a rest POI to finish and wait for another request.

2.2.7. User Web App

For the user interface (UI), a react-based web application (see https://es.react.dev/, date accessed 10 June 2024) was created. When this application is launched, it is served in a local port and IP of the robot’s network. Therefore, this UI can be utilized in any device connected to the TIAGo network by accessing this direction, e.g., the personal phone belonging to the user. In another respect, rospylib (see https://roslibpy.readthedocs.io/en/latest/, date accessed 14 July 2024) is used for interfacing with TIAGo ROS software (distro Ferrum, Ubuntu 18.04 LTS and ROS Melodic LTS), whereby the commands transmitted to the robot by the app are conveyed via ROS topics and services.

Furthermore, this UI is designed with accessibility in mind, taking into account the user profile. Consequently, the interaction can be conducted through two actions, namely change and selection, which can be performed, for example, by using the TAB and ENTER keys. This allows the adaptation of the web app to the user’s capabilities and control devices.

The UI has two modes: one for the common user and another for an expert or administrator user. This can be selected on the main page when connecting (Figure 18a) by accessing the admin user or otherwise.

The common user page allows the selection of the ID of the container to be picked, its location, the delivery destination, and the action to be taken if the user is the intended recipient. These options are depicted in Figure 18b. Additionally, the app indicates whether it is connected to the robot’s ROS network and the current state of the robot, so when the robot executes a task, the action and the moving element are noted there.

For the administrator, a greater range of options is available, as shown in Figure 18b. “Automatic” is equivalent to the common user page, while the “Teleop” section enables control of specific movements, including the base, the pick-from-user routine, the opening of the gripper, and sending the arm to its home position. The “Map” section displays the current map and allows for the relocalization of the robot. The “Setting” section prompts the diagnosis information from the robot (battery level, task state, element in movement, localization coefficient, etc.) and allows for the entry of the IP address of the ROS software if it differs from the web server.

3. Results

This section presents the experimental results. Two types of experiments were conducted: one focused on the execution of the different routines and another focused on the iteration with users. Both types of experiments were conducted in a home environment, where there was a table, a shelf, and a bed where the user was or should have been.

3.1. Execution Experiments

A meticulous examination of the execution of the routines was conducted in order to identify any potential shortcomings. Two studies were conducted: one to analyze the main manipulation routine of picking up the container from the table and another to examine the execution of the delivery combinations.

3.1.1. Experiments on Picking from Table

During the execution of the delivery from the table to the user, various initial positions of the container were set. The variation involved changing the initial position of the container relative to the saved POI where the robot navigated to execute the picking routine, differing along both horizontal axes. Figure 19 and

Table 1. Execution results of the pick-from-the-table routine. $x_m$ and $y_m$ are the mean initial coordinates with respect to the robot, $d{x}_m$ is the robot’s travel distance to match the gripping distance, and $t_e$ is the execution time.

${\mathit{y}}_{\mathit{m}}$ (m)	${\mathit{x}}_{\mathit{m}}$ (m)	${\mathit{dx}}_{\mathit{m}}$ (m)	${\mathit{t}}_{\mathit{e}}$ (s)
$0.01\pm 0.00$	$0.89\pm 0.02$	$0\pm 0$	$39.5\pm 1.9$
$0.06\pm 0.01$	$0.74\pm 0.01$	$0.09\pm 0.01$	$51.5\pm 0.8$
$0.01\pm 0.01$	$1.02\pm 0.02$	$-0.08\pm 0.01$	$46.6\pm 1.5$
$0.28\pm 0.00$	$0.85\pm 0.01$	$0\pm 0$	$43.1\pm 1.6$
$0.36\pm 0.03$	$0.75\pm 0.03$	$0.06\pm 0.02$	$59.5\pm 6.4$
$0.30\pm 0.01$	$0.97\pm 0.1$	$-0.08\pm 0.01$	$50.4\pm 1.5$
$-0.23\pm 0.00$	$0.83\pm 0.01$	$0\pm 0$	$46.9\pm 0.8$
$-0.25\pm 0.03$	$0.76\pm 0.01$	$0.07\pm 0.01$	$55.8\pm 2.9$
$-0.22\pm 0.02$	$0.92\pm 0.02$	$-0.06\pm 0.01$	$55.9\pm 5.5$

show the resulting measurements in time.

The results indicate that the robot completes the routine in less time when the container is positioned at the optimal manipulation distance upon arrival at the POI. However, when the container is positioned slightly off-center from the POI, there is a slight increase in execution time. It should be noted that every execution was successfully completed.

3.1.2. Experiments on Delivering

This experiment encompasses the entire delivery routine, including the different combinations of routines. All experiments were successfully completed and

Table 2. Execution results of the routine of delivering the container. The origin is the POI where the container is located, the destination is where to deliver the container, $t_e$ is the mean execution time, and $\sigma$ is the standard deviation of the execution time.

Origin	Destination	${\mathit{t}}_{\mathit{m}}$ (s)	$\mathit{\sigma }$ (s)
table	user	106.73	3.72
shelf	user	121.52	2.88
user	table	91.36	2.26

presents the measurements of the execution time.

A preliminary analysis of the data indicates that picking from the table and shelf appears to be more time-consuming than picking from the user and placement tasks. This discrepancy may be attributed to the additional steps required for container detection, which necessitate a more complex process. Furthermore, picking from the shelf requires additional base corrections and post-pick movements. Conversely, picking from the user and placement tasks involve more predefined movements that do not depend on detection.

However, the efficacy of each task should be noted, including the minimal variation in time, which suggests that the routines are highly reliable in execution.

3.2. User Experiments

To evaluate the usability and usefulness of our assistance approach, we conducted user experiments. These were designed to collect qualitative data on user interactions, performance, satisfaction, and impressions. The following subsections detail the methodology, participant demographics, experimental set-up, and survey results.

3.2.1. Methodology

The user experiments follow a structured methodology to ensure consistent and reliable data collection through user surveys. The experiment is divided into two phases: pre-demo and post-demo:

• Pre-demo: The patients are introduced to the experimental setup and informed about the robot and its technical features, but not about the specific tasks and implementations it can perform, e.g., “the robot has a camera”. They are then asked about the potential for assistance.
• Post-demo: The patients act as users of the robot’s assistance and are asked to command the desired assistance routines from their own mobile phones. They are then surveyed about their satisfaction, the usefulness of the robot, the attractiveness of the user interface, and their future needs and suggestions for improvements.

3.2.2. Participant Demographics

The experiments were conducted with six individuals from the FLM (Spanish acronyms of Fundación de Lesionado Medular), a medical center for the treatment, rehabilitation, and residency of people with reduced mobility due to spinal cord injuries. The patients have limited mobility in their upper bodies. Participants are middle-aged, with a distribution of 60% men and 40% women.

3.2.3. Experiment Set-Up

Experiments were conducted in a common room of the FLM with the set-up presented in Figure 20. The room is equipped with a table, a shelf, and a bed for testing each delivery routine. The assistance task was pre-configured for this environment by mapping the room and storing the POIs. Each participant was introduced to the same robot and set up to ensure consistency. During the demo execution, the patient was placed in his own wheelchair next to the bed to simulate being in bed.

3.2.4. Surveys Results

The results of the user experiments provided valuable insights into user expectations and potential usability issues.

Table 3. The responses of users to surveys about the experiment.

	User A	User B	User C	User D	User E	User F	Mean
Potential (1–5)	4.5	5	4	4	5	5	4.6
Satisfaction (1–5)	4	5	4	4	4	4	4.1
Usefulness (1–5)	4	5	4	3.5	4.5	5	4.3
UI attractiveness (1–5)	5	5	4	3	4	5	4.3

and

Table 4. Improvements and future needs noted by users.

Improvements	Faster execution, UI with larger typography, UI with pictures
Future needs	Voice control, picking up not only containers, opening a closet, picking up from the floor, tasks not only in the main room

present the answers to the surveys and feedback from users. Key findings are as follows:

• In general, participants were satisfied and impressed with the potential, assistance demonstration, usability, and user interface, giving them high scores.
• Regarding the demo execution—although they found it useful, they found that it lacked speed execution. This is interesting because the movements of the robot were executed at this speed for safety as well as safety expectations.
• Regarding their needs after seeing the demo—they expressed a desire for the robot to pick up objects not only from the table and shelf but also from the floor and cupboard. They explained that they often dropped objects and needed assistance from a nurse to retrieve them. They also suggested that the robot should be able to pick up objects from the wardrobe because they needed to pick up clothes from there without help as well.
• Regarding the user interface (UI)—the majority of users were pleased. However, some noted the need for larger typography, while others suggested the inclusion of pictures to facilitate easier understanding.

Despite the small number of participants, it is interesting to note that they came to similar conclusions regarding their expectations, impressions, and needs. This consistency helps to focus future routine implementations and highlights the need to optimize execution time—or at least manage expectations around it—due to safety concerns.

4. Discussion

The overall aim of the presented approach is to implement an assistive system for individuals with reduced mobility that facilitates the picking, placing, and delivery of objects within a domestic environment. For this purpose, a system capable of operating in a dynamic, human-designed space is needed, which requires safe interactions with both humans and the environment. However, the predefined tasks implemented in the system may not fully cover the needs of users, making it essential to conduct tests with potential users. This will help assess the acceptance, usefulness, and performance of the implementation and gather feedback for future improvements.

4.1. System Performance

The experimental results indicate that the assistive system performs well in domestic rooms with the predefined elements for the task (a room with a bedridden user, table, and shelves). The well-established navigation system and the implemented autonomous detection and manipulation routines make it possible to complete the tasks in all tests. However, user testing revealed several challenges. The user reported that while the system was generally compliant with the assistive task, it was slow. There are two main reasons for this slowness: detection and safety.

The former involves detecting the containers and determining their positions in space. The user only gives a hint of where it is, for example on the table, and locating the robot and adapting it to the manipulation of containers takes time. This is reflected in the fact that the routines that include this process are the slowest.

The latter is safety. To avoid collisions with the environment, the robot continues to plan and follow manipulation trajectories that are sometimes not the most optimal. It also executes them at a slow speed, so in the event of a collision, the safety system of the robot can stop the movement before it causes damage to the user or the environment. This is most evident in the shelf-picking task, where the trajectory it follows to lower the arm includes passing through pre-defined configurations that ensure the arm is confined to a safe space and does not tip the contents.

Moreover, physical safety needs to be considered, as well as the perception of safety by the users. Perceived safety improves when the robot’s motion does not occur at a high speed and it is predictable [31]. This was also considered when setting the speed of the robot, accompanied by the continuous explanation with the TTS of the actions, balancing the need for efficiency with the comfort of users.

4.2. User Acceptance and Interaction

An important aspect of user testing is the acceptance of the robot by the users. After the presentation of the robot and before the demo, the users were already positive about the robot and thought it had a lot of potential. After the demo, this appreciation did not diminish, with high scores for satisfaction and usefulness. As mentioned at the beginning, user acceptance is important for the robot to fulfill its function and not to inconvenience the user.

This is complemented by the interaction through the UI. Users found the UI easy and comfortable to use due to its simplicity and the ability to operate it from their personal mobile phones. This eliminated potential technological barriers typically associated with this type of technology, making it as accessible as other devices that connect to their phones.

4.3. Feedback and Future Developments

User feedback is crucial for determining the development path of the assistance task according to their preferences [32]. In this case, the users expressed the need for the robot to be able to reach objects placed at higher levels, such as shelves, and found this feature useful in the demonstration.

However, they noted the inability of the robot to pick up objects from the floor, which was inconvenient as they had to ask for help if they dropped something. They were also interested in the ability to retrieve clothes from the wardrobe. This task would be more challenging to implement due to interactions with doors and the handling of more complex items such as clothes on hangers.

Regarding interaction, although they were satisfied with the control from their personal phones, they suggested the possibility of incorporating voice commands. This could make the interaction more natural and address situations where the user does not have their mobile device with them. Additionally, some noted the need for larger typography, while others suggested the inclusion of pictures to facilitate easier understanding. Despite these suggestions, they felt comfortable and considered the interaction with the UI to be easy.

5. Conclusions

In summary, we present a functional assistive robotic implementation for picking, placing, and delivering containers of objects using the TIAGo robot. The functionality of the application was validated through the execution of several tests. In addition, a series of experiments with users was conducted, who expressed positive impressions of the robot and the demonstration. Furthermore, feedback provided by the users will be incorporated into future improvements.

Developing an assistive system for individuals with reduced mobility holds great promise for improving independence and quality of life. Although initial results and user feedback are encouraging, more assistive tasks may need to be implemented.