PRE2023 3 Group5

Medical Robot

Group Members

Name	Student ID	Department
Yuting Dong	1546104	Computer Science
Jie Liu	1799525	Computer Science
Zhiyang Zhang	1841734	Mechanical Engineering
Samir Saidi	1548735	Computer Science
Feiyang Yan	1812076	Computer Science
Nikola Mitsev	1679759	Computer Science

Introduction

Problem Statement

Nowadays, there is an increasing amount of elderly or impaired people whose health conditions or disabilities prevent them from taking care of themselves. Meanwhile, a large number of them have no choice but to live alone entirely or for most of the time. For some people, especially those with limited mobility, even walking in their own home is a struggle. They can easily get hurt if they are not taken care of properly, and there's a likelihood that their family may remain unaware of potential harm. There have been occasions where individuals fall over at home without anyone noticing which might lead to severe consequences. The caretaker is thus a necessary role that must be present in our society to ensure the well-being and quality of life for individuals facing these challenges. However, contemporary families often face the dual dilemma of struggling to allocate time for caregiving responsibilities and encountering financial barriers that hinder their ability to engage professional caregivers. Consequently, a significant portion of the population in need is left without the essential care they require.

Objectives

Considering the current situations that the individuals with limited mobility are facing, we've decided to design a home robot with a primary focus on safety monitoring that is easily accessible to individuals. The robot should be able to have an eye on the individuals while they are walking and take actions when they fall over but couldn't manage to get up on their own. The main goal of the robot is to ensure the safety of the user and reach out for help whenever needed. On one hand, the robot closely monitors the individual's mobility at home and swiftly responding to instances of falls. On the other hand, it enhances the overall safety of individuals living at home and provide peace of mind for both users and their caregivers or family. Moreover, the robot can also easily be applied in public areas such as hospitals or nursing homes for the same purpose. However, it may raise privacy concerns if the data recorded by the robot is not kept secure.

As an initial idea, the design of the robot should cover these features:

1. Built-in program: The robot should be designed as a digital program that can be easily installed on household cameras.

2. Fall Detection and Response System: The robot is implemented with high-accuracy human detection and fall detection artificial intelligence algorithms to detect instances of falls and decision-making abilities to react to the instances accordingly.

3. Emergency Communication: The robot incorporates a communication system that allows itself to alert family members, caregivers, or emergency services in case of a fall that cannot be managed by the users themselves.

4. User-Friendly Interface: A user-friendly interface should be designed for the caregivers or family members, which is preferably an application or a portal that can be installed in smartphones. Alerts and updates can be sent to the smartphones remotely. It is also possible to access the settings of the robot through these platforms for example to remotely control the camera or to input room-specific information to ensure comprehensive camera coverage throughout the designated areas.

5. Privacy Protection Measures: The robot is integrated with robust data encryption protocols and privacy features to address concerns related to the recording and storage of personal information, ensuring the user's privacy is maintained.

State-of-the-art

Literature review

Dementia is a syndrome primarily defined by the deterioration of one's cognitive ability beyond what would be expected of biological aging, affecting one's learning and memory, attention, executive function, language, motor perception and social function (Shin, 2022). As a result, this condition can make it difficult, or even impossible, for one with dementia to live independently, often requiring the assistance of a professional caretaker or an informal caretaker (family) in the later stages of the condition. As one would expect, this puts strain on a country's healthcare system, both in terms of personnel and finances; in 2023, the WHO (World Health Organization) estimated that 55 million people worldwide were living with dementia, and they expect this number to nearly triple to 155 million by 2050 (World Health Organization, 2023). The WHO (2023) additionally estimated that the cost of dementia care in 2019 amounted to $1.9 trillion. That is why there is currently a growing demand for robotic caretakers, with a wide range of assistive functionalities, for example, keeping the patient company, reminding them of various tasks, or calling emergency services or other trusted people when the need arises. In 2023, the market for elderly care assistive robots was valued at $2.5 billion, and was projected to grow at a rate of 12.4% to $8.1 billion by 2033 (Saha, 2023).

The increasing aging population faces many challenges, but people with dementia in particular, due to their deteriorating cognitive function, often have difficulties identifying fall risks and can accidentally trip and fall over objects in their home (Canadian Institute for Health Information, n.d., Dementia UK, n.d., Fernando et al., 2017) It is well known that falling is a high danger to elderly people, presenting risk of injury, hospitalization, and can even lead to death. In fact, such accidental falls are one of the leading causes of hospitalization and death in elderly populations (Stinchcombe et al., 2014, Kakara, 2023, Centers for Disease Control and Prevention, n.d.). Moreover, there are challenges involving emergency response coordination, which can lead to delays in the patient being given treatment after falling (Hesselink et al., 2019). Therefore, there is certainly a need to protect elderly people living alone at home from such risks, both via proactive measures involving identifying fall risks and notifying the user (and possibly removing fall risks autonomously, with a sufficiently advanced robot design), but also, by notifying emergency services and the caretaker(s) of the patient if they have fallen and need assistance or hospital care. Since it has been shown that slower EMS responses is associated with increased mortality (Adeyemi et al., 2023), a robot capable of preventing falls would help relieve some of the burden on the healthcare system, caretaker(s), and allow the patient to live more independently.

Naturally, a user-centered approach must be taken when designing solutions, with focus on making the human-computer interaction as user-friendly as possible. In fact, one of the major challenge impeding the large-scale adoption of elderly care social robots into care homes and in cases of independent living is the complexity of many current robots causing more trouble for caregivers and patients rather than relieving them of it; according to Koh (2021), the multiple visual, auditory and tactile interaction of social robots presents challenges and confusion for people with dementia. This makes the focus on user-friendly HCI even more important. Part of this disconnect between the expected and actual relief of burden seems to stem from how current solutions focus on too many things at once and attempt to make a general care robot, rather than specializing in one area. Furthermore, having a complex user interface is a pitfall, as previously discussed, increased complexity creates added confusion for people living with dementia. Despite these pitfalls and challenges, many case studies and state-of-the-art reviews have shown the effectiveness of a variety of elderly care robots (Carros et al., 2020, Raß et al., 2023, D'Onofrio et al., 2017, Søraa et al., 2023, Johnson et al. 2014, Vercelli et al., 2018). Therefore, by identifying the needs of our user and the stakeholders, it should be possible to create a simple-to-use, yet effective, robot that addresses our problem.

Due to gaps in the literature, and the inherent difficulty of this problem, existing solutions can also fall short. For example, Igual et al. (2013) identify several challenges and issues regarding current fall detection systems. Some of the challenges, according to them, include decreased performance in real-life conditions, usability of the system, and a reluctance by its user to accept using it. Furthermore, the issues identified include the limitations of smartphones in smartphone-based detection systems, privacy concerns, difficulty in comparing performance between different systems due to different data-gathering methods, and testability of the system. As such, there are many opportunities for improvement, and our robot should aim to be such an improvement.

Despite the evidence supporting the effectiveness of such robotics in the field of elderly care, papers have also shown its benefits to be overstated. For example, Broekens et al. (2009) showed that although there is some evidence that companion type robots have positive effects in healthcare for elderly people with respect to at least mood, loneliness and social connections with others, the strength of this evidence is limited, due to a variety of factors. However, this mainly applies to companion social robots, which our robot is not. So, we expect that our robot should still provide many benefits to our user group as long as it is designed with them in mind.

As a result of the above, we highlight the need for our proposed solution, because it aims to address some of the challenges and issues that were previously raised, and provides something new that current products do not. With this in mind, we give a brief overview of such current products below, discussing their advantages and, where applicable, where they fall short. We later provide an analysis of our user group, as well as address various ethical concerns that must be taken into account while designing the robot.

Current products

2D-Lidar-Equipped Robot

The LiDAR system continuously scans the environment, creating map of the surroundings. The robot is programmed to recognize the typical shapes and positions of a person standing, sitting, or lying down. If the LiDAR system detects a shape that matches the profile of a person lying on the ground, the robot can interpret this as a person having fallen. The action of the robot is not specified once a fallen person is detected; the paper is more concerned with the detection itself, this was tested in simulations discussed in the paper.

Mobile robot with Microsoft Kinect

The robot includes 3 main components: a Microsoft Kinect sensor, a simple mobile robot, and a PC. The Kinect sensor is mounted on top of the robot and rotates to scan the environment. The sensor data is sent to the connected PC, which processes the information. The PC is programmed to recognize patterns in the sensor data that indicate a person has fallen. This could be based on the shape, position, or movement of the detected objects. If the system detects a fallen person, it sends notifications to a medical expert, authorities, and family members. The main issue with this design is the re-detection of a fallen person, and the difference of detecting a fallen person between different types of robots.

Sensors embedded in the house

The infrared sensors are embedded into the floor throughout the area where fall detection is needed. The system is programmed to recognize the patterns of infrared radiation that indicate a person has fallen. If the system detects a fallen person, it sends a signal to a robot. This robot is equipped with features to assist a fallen person. The robot navigates to the location of the fallen person. It can do this because the system knows which sensors detected the fall, and therefore where the person is located. Once the robot reaches the person, it asks if help is needed. This could be done using a built-in speaker and speech recognition technology. The robot can provide assistance in several ways. by providing the fallen person with a mobile phone or by helping the person stand up using the handles on the robot itself.

Image recognition robots

In this scenario, a LOLA companion robot is repurposed for fall detection. The LOLA robot is originally designed to provide companionship and assistance to people, especially the elderly or those with special needs. A camera is attached to the robot; this allows the robot to visually monitor its environment. The robot uses two algorithms to interpret the images taken by the camera: a Convolutional Neural Network (CNN) and a Support Vector Machine (SVM). The CNN is a type of deep learning algorithm that is especially good at processing images. It can be trained to recognize complex patterns in the images, such as the shape and posture of a human body. The SVM is a type of machine learning algorithm that’s used for classification and regression tasks. In this case, the SVM could be used to classify the output of the CNN. There is no specific reaction of the robot in case a fallen person is detected, the paper was focused on the detection itself.

Wearable Fall Detection Devices

One existing scheme: Apple Watch . If the Apple Watch detects a hard fall, it taps the user on the wrist, sounds an alarm, and displays an alert. The user can choose to contact emergency services or dismiss the alert. If the user's Apple Watch detects that they are moving, it waits for them to respond to the alert and will not automatically call emergency services. After that, if the watch detects that they have been immobile and unresponsive for about a minute, it will call emergency services automatically.

USE analysis

The design of the robot must be taken in coordination with a variety of stakeholders, and not just our target user (who we have defined to be elderly people with mild memory loss due to dementia, living alone at home). Examples of such stakeholders are: formal/professional caregivers, informal caregivers (such as family members), and doctors. Each of these stakeholders have different needs and priorities regarding the care of our target user, and thus, will have different perspectives that will ultimately influence how we design our robot.

Users

Target Group 1: Elderly and Impaired Individuals Living Alone. According to the World Health Organization (WHO), the number of people aged 65 or older is expected to more than double by 2050, reaching 1.6 billion. The number of people aged 80 years or older is growing even faster. From the statistics of Centers for Disease Control and Prevention (CDC), one out of four older adults will fall each year in the United States, making falls a public health concern, particularly among the aging population. Each year, about 36 million falls are reported among older adults each year, resulting in more than 32000 deaths, and one out of every five falls causes an injury, such as broken bones or a head injury.

Needs:

1. In-time fall detection: This is the primary concern for this group. A fall can have serious consequences, and they need a solution that can quickly detect falls and summon help.
2. Ease of use: As this group of people are mainly over 65, learning how to use a complicated product is unrealistic.
3. Automatic running and accurate result: The monitor and call help should be be done automatically and accurately; otherwise, it would give more burden to users and caregivers.
4. Privacy and safety: As this robot needs to monitor the activities of users, they prefer their data will not be stored or stored in somewhere safely. And this robot will not restrict and interfere activities of users.

Target group 2: The caregiver and families. Some family members in developing countries do not have enough time to look after the old because of reasons like severe work overtime; while developed countries are also experiencing the shortage of caregivers. These target groups could be the potential users, as they also expect a method to lighten their burden.

Needs:

1. Reliable assistant: It is stressful and tired for them to keep an eye on the activities on the elderly. Even the professional caregivers cannot focus all their attention on the old, so they prefer a reliable assistant robot to help them while they are doing other things, like preparing medicines. And also the notification from the robot must be reliable, otherwise it wound be another burden for them.
2. Remote monitoring and real-time information: They may want to use the robot to check the situation of the old when emergency happens such that they can take the next step immediately.

Another considerations for users: The product should be cheap enough such that most families can afford it.

Analysis on interviewee 1

Background information: Customer data analysis department in a financial bank. Children are working in the US. He does exercise regularly, mainly plays tennis. There was a family member who experienced a severe fall which caused bone fracture. Also, the interviewee has the experience of using service robot and generative AI tools.

Feedback from the interviewee: He is interested in using a robot to monitor the fall of the user via camera as it is more convenient comparing to other methods, like wearable devices. He prefer that the user could interact with the robot using voice commands, as he wants to keep the robot at a safety distance. Then, the interviewee clearly pointed out that he wanted the robot to contact the emergency contact via a phone call or similar methods, as other methods are easy to be ignored. Also, the interviewee also mentioned that he preferred that the robot shall have a non-human like face, and a cute face would be more ideal, as he did not want a human-like robot followed him everywhere, which is horrible especially at night. The interviewee exhibited many concerns related to the robot. The first one is the safety problem, he was afraid that the robot will block, hit or collide with him, causing more falls. The second concern is that he worried about the privacy and the company will misuse the data. As most data is from user's daily, he did not want his data is used by company, even it is for researches.

Analysis on interviewee 2

Background information: She is retired and used to be a government department officer. And she has one child who works in the same city where she lives but only visits her once a week. She likes play tennis. She has experienced several falls at home but not very often, and she does not have too much experience of interacting with robots.

Feedback from the interviewee: She is quite concerned about falling because she lives alone and no one can help her immediately when she falls. She is positive towards the idea and interested in having such a robot which uses camera to detect falling of her. But she is worried about the privacy problem, and she hopes that her photos will not be stored and be used for other intentions. She expects that the robot can make a phone call to her son and also to the emergecy, because she thinks other methods, like SMS notification are not quick and efficient. Moreover, she does not want the robot following her all the time. She hopes she can control the robot and set when the robot can follow her. About the appereance of the robot, she does not want a huge object at home which ocupies too much space. She also concerns about the accuracy of the detection and worries if the robot can avoid obstacles.

Analysis on interviewee 3

Background information: The interviewee is a middle school teacher around 40 years old who lives with with her mother and a caregiver. She is experiencing a severe leg illness and her mother has Parkinson's diseases, so she hires a caregiver to look after her mother and do housework for her. Her mother experienced a fall many years ago, while she falls once or twice a year, but they are not very severe and she has got used to this thing.

Feedback from the interviewee: She was open to the robot as she hoped to see an increasing variety of devices for detecting falls. Secondly, she preferred the robot to have a non-human-like appearance and use voice commands to control it when an emergency happens, although she was skeptical about its accuracy. She did not object to collecting user data and sending it to the company, as long as it is under the law and the company can use the data to improve accuracy. But the most concern from the interviewee is the accuracy and reliability of the robot. She does not believe that the robot with camera can detect the fall accurately. She has experience using Siri, a voice assistant made by Apple company, but the accuracy disappointed her, so she has doubts about detecting the fall with the camera. The second concern that she mentioned frequently after seeing our prototype was the fall of the robot. She was afraid that the robot was too tall and heavy, as many obstacles at home could let the robot fall, and once it fell, it would be troublesome to help the robot up.

Society

As the living standards keep increasing, and more medical resources are publically available, the life expectancy in many countries increases. This results in more aging population in more developed countries. This population needs more care from the public. However, the number of care givers does not meet the need of the aging population. A report shows that by 2030, there will be a shortage of 151000 caregivers in the US . Therefore, governments are interested in investing in automatic care robots, to undertake some responsibilities of caring the elderly. In addition, the elderly are more and more willing to live independently at home instead of needing someone to take care of all the time. They would like to have a robot that can do some jobs of caregivers. But at the same time, people are concerned about the potential problems such as data leakage and acceptance from the society. These problems need to be addressed in the design of the robot.

Needs:

1. Social acceptance: This robot should be socially accepted by the public, so that most elderly will be willing to use this product. Some people might think that installing a robot at home that monitor them every day is not safe and will be an invasion of privacy.
2. Data privacy: The potential problem of data breach should be considered by the government.

Enterprise

Robotic companies are the main stakeholders. As the elderly population grows, there will be more and more potential customers. Fall detection robots suit the needs of these customers. Hence, the robotic companies are interested in developing such robot products. Hospitals will also be interested in fall detection robots to some extents. Lack of caregivers is also affecting the revenue of hospitals. If there are fall detection robots that can detect fall of patients, hospitals can spend less time monitoring the patients.

Needs:

1. No failure case: If the robot fails to detect a fall of the user, it will have a great negative impact on the developer companies and hospitals. This is because the society will lose their trust on such robots. Therefore, the companies would like to ensure that the robot is always able to detect the fall.
2. Price: As there are fewer human caregivers, companies started investing robots for replacement. But if the price of a robot is higher than hiring a human caregiver, then there will be no need to purchase such a robot. Therefore, the price must be affordable for users.

Requirements

Design specifications

Rae et al. (2013) found that the persuasion of a telepresence robot was less persuasive when the robot was shorter than the user. Thus, for requirement 1.1, we decided that the robot should be about the same height or slightly taller than the user, to minimize the loss of persuasion that may occur when the robot is shorter than the user. For requirement 1.2, this is merely an estimate based off the Atlas robot made by Boston Dynamics, which weighs 75-85 kilograms depending on its version, thus, we took the average across the 3 versions (75, 80, 85 kg respectively). For requirement 1.3, we would like the robot to be able to move (Req 1.8), and in order to do so it needs wheels, which, ideally, can also be rotated (Req. 1.9). Normally, at least 2 wheels are sufficient, but 3 or 4 wheels would also work. The design of our robot also has a body containing a microphone, speaker and camera at its front (Req 1.5 + 1.7) and a charging port at the back to recharge its battery (Req 1.6), with the inside of the body housing all of the electronics and wiring (Req. 1.4). Since we would like the robot to be able to make a video call to the caretaker or family members upon fall detection, the robot needs to have at least those elements.

Index	Description	Priority
1.1	The robot shall have a height of at most 1.7 meters.	Must
1.2	The robot shall have a weight of at most 80 kilograms.	Must
1.3	The robot shall be mounted on a base containing at least two wheels.	Must
1.4	The robot shall have a body casing to house its electronics.	Must
1.5	The robot shall be equipped with a camera on its body.	Must
1.6	The robot shall have a rechargeable battery as a power source.	Must
1.7	The robot shall have a screen, microphone and speaker capable of making video calls.	Must
1.8	The robot shall be able to move using its wheels.	Must
1.9	The robot shall be able to rotate its wheels.	Should

The test plan is as follows:

Index	Precondition	Action	Expected Output
1.1	None	Measure the height of the robot.	The height of the robot is at most 1.7 meters.
1.2	None	Measure the weight of the robot.	The weight of the robot is at most 80 kilograms.
1.3	None	Inspect the robot's structure.	The robot has a base containing two wheels.
1.4	None	Inspect the robot's structure.	The robot has a body casing and electronics inside of it.
1.5	None	Inspect the robot's structure.	The robot has a camera on its body.
1.6	The robot is powered on.	Charge the robot using the provided charger.	The robot begins to charge its battery with no issues.
1.7	The robot is powered on.	Pretend to fall down, such that the robot calls the designated contact.	The designated contact responds, you can see, hear, and talk to them with no issues, and vice versa.
1.8	The robot is powered on.	Set up the robot and move in any direction.	The robot starts to move.
1.9	The robot is powered on.	Set up the robot and move in one direction, then turn in any angle and continue moving.	The robot starts to move, then turns, and moves in a new direction.

Functionalities

In terms of core functionality we would like the robot to be able to continuously monitor the user (Req 2.10) to detect falls (Req 2.1) and notify caretakers or family members as soon as possible. The timeframe was decided to be 30 seconds long (Req 2.2), after researching some other devices on the market, we see that on average, they contact emergency services or caretakers within 30 seconds of detecting a fall and the user not responding. We would like the user to be able to cancel the notification if desired (Req. 2.8), in case the fall was not serious. However, in cases where the robot detects that the user is completely immobile for 10 seconds, then it must immediately notify the caretakers or family members without waiting for the full 30 seconds (Req 2.9). We decided on this 10 second time frame, also because of similar devices on the market having similar time ranges - we simply took the average of these times.

We decided to make the notification in the form of a VOIP/Wi-Fi video call to the designated emergency contact, or a SIM-card based call if the robot does not have access to the Internet (Req 2.3). This is because having a video call adds to the level of reliability of the robot and can allow for a more dynamic two-way interaction between the user and their emergency contact. However, if the contact is unavailable, the robot will instead immediately call local emergency services instead and request help (Req 2.4). In this case, it will instead send a text message to the contact (Req 2.5) and attach a photo (Req 2.7), but in any case, the information relayed must contain at least the name, date of birth, and location of the user (Req 2.6) to allow emergency services or a professional caretaker to identify the user and assist them. The reason we included these three attributes is because in most medical settings in the Netherlands, one's name and date of birth (and possibly address) is required to access the services of the clinic the user is registered to. In some cases BSN and the name of the huisarts may additionally be required for emergency services, but we could not find a definitive answer about this protocol. If it turns out that it is required, then we would need to also add this information to Req. 2.6.

In terms of processing and data storage, the robot should not be able to store data or send it online to a server, due to privacy concerns by the user base which were identified during the interviews (Req. 2.11, 2.12).

Index	Description	Priority
2.1	The robot shall be able to detect falls.	Must
2.2	When the robot detects a fall, the robot shall notify the designated emergency contact within 30 seconds.	Must
2.3	The notification shall be in the form of a VOIP video call to the emergency contact, or a SIM-card based call if an Internet connection is unavailable.	Must
2.4	If there is only one emergency contact which has not responded to the call, or if there are two or more emergency contacts and at least two have not responded to the call, the robot shall instead call local emergency services (112, 911, etc.).	Should
2.5	When the robot detects a fall, and the emergency contact has not responded (as described in 2.4), the robot shall send a text message to the emergency contact.	Could
2.6	The notification (text or call) that the robot sends shall contain the name, date of birth, and location of the user.	Must
2.7	When the robot detects a fall, and the emergency contact has not responded (as described in 2.4), the robot shall take a picture of the fall and send the picture to the designated emergency contact via SMS.	Could
2.8	When the robot detects a fall, the robot shall have a mechanism to allow the user to cancel the notification within 30 seconds.	Should
2.9	When the robot detects a fall, the robot shall additionally detect if the user is immobile, and if they are immobile for at least 10 seconds after the fall detection, it shall send the notification to the emergency contact within 1 second of determining the user is immobile.	Should
2.10	The robot shall monitor the user continuously using the camera mounted on its body.	Must
2.11	All data that the robot processes or sends shall be stored locally on a hard drive.	Must
2.12	The robot shall delete any video data within 1 minute after it has been processed.	Must

The test plan is as follows:

Index	Precondition	Action	Expected Output
2.1	The robot is powered on.	Pretend to fall down.	The robot detects the fall and notifies you of it.
2.2	The robot is powered on.	Pretend to fall down.	The robot detects the fall and notifies the designated contact within one minute.
2.3	The robot has detected a fall.	To test the video call, simply wait until the robot notifies the contact. To test the SIM call, turn off the internet, repeat the fall, and wait until the robot notifies the contact.	The video call and SIM call both successfully connect to the emergency contact with no issues.
2.4	The robot has detected a fall.	Wait until the robot notifies the contact. Make sure the emergency contact(s) has/have not responded.	The robot notifies local emergency services.
2.5	The robot has detected a fall.	Wait until the robot notifies the contact. Make sure the emergency contact(s) has/have not responded.	The emergency contact(s) receive(s) a text message from the robot.
2.6	The robot has sent a text message (2.5)	Inspect the text message.	The text message contains the name and location of the user.
2.7	The robot has sent a text message (2.5)	Inspect the text message.	The text message contains a picture of the fall.
2.8	The robot has detected a fall.	Tell the robot to cancel the notification.	The robot cancels the notification process and goes back to idly following you around.
2.9	The robot has detected a fall.	Stay immobile for 10 seconds.	The robot sends a notification to the emergency contact within 1 second.
2.10	The robot is powered on.	Move or pretend to fall down.	The robot responds appropriately (1.8/1.9 or 2.1).
2.11	None	Inspect the robot's internal hard drive.	The robot has processed or sent data in the hard drive.
2.12	None	Inspect the robot's internal hard drive.	The only video data remaining is from 1 minute before the robot was turned off in order to inspect it.

User Interface

The user interface for the robot should be very light and focused mainly on achieving its core functionality. Thus, we have decided to use a voice controlled system (Req 3.1), due to our user group having difficulties with complex technology which would present challenges for them interacting with our robot otherwise. This is also supported by our interviews. The voice controlled system would have a predefined set of commands that it would respond to, and it would respond to them only if preceded by its name, then the command (Req 3.2). This is to prevent the robot from accidentally being told to do something that the user did not ask for, for example, if it hears something interpreted as a command from somewhere else (TV for example). Speech data is interpreted by a natural language processing algorithm and classified into one of the predefined commands from 3.6. This does not mean the robot will only respond to these exact commands; it should be able to interpret speech for nuance, for example, "Yeah no, I'm fine" must be interpreted as "Do not need help" by the robot. The robot should be able to change, add, and delete emergency contacts in order to perform its function (Req 3.3, 3.4, 3.5).

Index	Description	Priority
3.1	The robot's interface shall be controlled using voice commands.	Must
3.2	The robot shall only respond to commands beginning with its name.	Must
3.3	The robot shall have a mechanism for changing the designated emergency contact, such as a family member or caretaker.	Must
3.4	The robot shall have a mechanism for adding multiple emergency contacts.	Must
3.5	The robot shall have a mechanism for deleting emergency contacts (but not if there is only one contact)	Must
3.6	The robot shall respond to commands classified as follows: "Need help", "Do not need help", "change emergency contact", "add emergency contact", "delete emergency contact", "end call", "mute microphone", "mute camera".	Must

The test plan is as follows:

Index	Precondition	Action	Expected Output
3.1	The robot is powered on.	Attempt to use any of the predefined voice commands, beginning with its name	The robot responds appropriately (3.6)
3.2	The robot is powered on.	Attempt to use any of the predefined voice commands, beginning with its name	The robot responds appropriately (3.6)
3.3	The robot is powered on.	Tell the robot to change an emergency contact.	The robot responds by asking you which contact you would like to change.
3.4	The robot is powered on.	Tell the robot to add a new emergency contact.	The robot responds by asking you information about the contact.
3.5	The robot is powered on.	Tell the robot to delete an emergency contact.	The robot responds by asking you which contact you would like to delete, or, if there is only one contact, that it cannot delete the contact.
3.6	The robot is powered on.	Attempt to use each of the predefined voice commands, beginning with its name	The robot responds appropriately.

Safety

The safety of the user is important, thus, we have included some requirements to ensure that. The most important is prevention of false negatives (Req 4.1), which refer to falls not being detected. Because it is impossible to make a system that is 100% reliable, we have elected to ensure a 99% reliability rate, that is, that the rate of false negatives in the system cannot be more than 1%. We believe that any higher than that and the system becomes too unreliable for our users to use. (waiting until we have figured out how the robot will follow the user)

Index	Description	Priority
4.1	During training, the rate of false negative falls shall be at most 1%.	Should

The test plan is as follows:

Index	Precondition	Action	Expected Output
4.1	The robot is powered on.	Inspect the training statistics of the robot.	The rate of false negative falls is no more than 1%.

Performance

The below requirements are gathered from various estimates of specifications that a computer would need to have in order to efficiently perform the various algorithms and functionalities described in this section. While sensor fusion is currently a "should have", we suspect it will become a "must have" seeing as camera and accelerometer data is typically combined using sensor fusion and the resulting output is used to identify falls. However, this will become more clear in the implementation phase.

Index	Description	Priority
5.1	The robot shall have a CPU which is at least quad-core and has a minimum clock speed of 2.5 GHz.	Must
5.2	The robot shall have an integrated or dedicated GPU with at least 700 CUDA cores (or equivalent).	Must
5.3	The robot shall have at least 16 GB of RAM.	Must
5.4	The robot shall have a hard drive with at least 250 GB of available space.	Must
5.5	The hard drive that the robot uses shall be a solid-state drive (SSD).	Should
5.6	The robot shall have a dedicated sensor fusion processing unit to support tasks requiring sensor fusion.	Should
5.7	The robot shall have a network card with support for Wi-Fi.	Must
5.8	The robot shall be powered with a rechargeable battery with a battery life of at least 16 hours before needing to recharge.	Must

The test plan for the above is fairly straightforward, only needing simple inspection of the hardware specifications for all components specified above. Therefore, we will not display a full test plan.

Algorithm

The robot uses various algorithms to accomplish its functionalities. It must use an object detection algorithm with functionality that allows it to identify falls (Req 6.1, 6.2) and a pathfinding algorithm to move and monitor the user (Req 6.3). Furthermore, for the voice interface, it would need a voice processing algorithm, text-to-speech algorithm, and a natural language processing algorithm (Req 6.4, 6.5. 6.6) to be able to receive commands from, and interact with, the user.

Index	Description	Priority	Notes
6.1	The robot shall use an object detection algorithm in order to identify objects and people in its environment.	Must	Algorithms 6.1 - 6.6 could additionally have constraints based off time/memory complexity, as well as considerations to be taken based off the environment the robot is to operate in.
6.2	The robot shall use the algorithm in 6.1 to identify when an object or person has fallen.	Must
6.3	The robot shall use a pathfinding algorithm in order to move from one location to another.	Must
6.4	The robot shall use a natural language processing algorithm in order to interpret and classify commands.	Could
6.5	The robot shall use a text-to-speech algorithm in order to talk to the user.	Could
6.6	The robot shall use a voice processing algorithm in order to recognize speech.	Could

Completing the test plans of the previous sections means that the test plans for this section should all work correctly. In particular, most requirements of section 2 will test 6.1 and 6.2, requirements 1.8 and 1.9 will test 6.3, all requirements of section 3 will test 6.4, 6.5 and 6.6.

Further requirements on these algorithms are shown below:

Object detection and fall detection

The algorithm must be a real-time algorithm. That is, it must be able to continuously track and identify the user. Furthermore, the algorithm should be robust in detecting people, for example, in different lighting conditions, different people, or obstacles that could obscure its view. False positives are not too harmful, as the user can cancel the notification easily, but false negatives must be avoided as much as possible, as mentioned previously. The algorithm itself would need to be trained as it will likely be a neural network based one, but, there should be little to no calibration required on the user's side, because of possible difficulties in understanding how to work with the robot.

Pathfinding

The algorithm must be able to make a safe, efficient path from point A to point B for the robot to take. It must be able to integrate itself with the object detection algorithm to identify obstacles and path around them. Furthermore, it must be able to dynamically adjust the path as needed, because of our safety requirements previously listed. In terms of efficiency, there should be some method to split the search space into smaller, more manageable clusters, such that the time and space complexity do not become too high.

Natural language processing

Accuracy is of course the most important part here, thus, the algorithm should be able to accurately interpret the input it is given and classify it into one of the given commands. The robot interface will be developed in English, thus, it should at least be able to understand English text, but in the future, if the robot is to be localized, the algorithm should also be able to understand other languages. It should be robust enough to understand different English dialects and the differences in them (American English vs. British English, for example, figures of speech can differ across these and other dialects). The algorithm could also have the ability to learn from the user, that way, it is able to classify commands faster.

Text-to-speech

The algorithm should be able to convert text into clear, understandable speech for the user. Correct intonation, stress, emphasis and enunciation is highly valued, but not an absolute requirement. As with the previous requirements, the algorithm should work for English text.

Voice processing

The algorithm must be able to recognize speech and translate it into text for the NLP algorithm to process. The algorithm should still work in the presence of noise, for example, speech coming from the TV should be ignored or suppressed. To do this, it could distinguish the user's voice from others' voices.

Specification

The robot is specified by four different types of UML diagrams: sequence, use case, state machine and activity. The diagrams were chosen as they cover all the necessary aspects of the robot from interaction with actors to the robots internal implementation.

1. Sequence diagram: model the communication between different interaction partners, sequence diagram contains different types of messages (synchronous, asynchronous, response message, create message). For this particular sequence diagram we show all possible sequences of interactions. We show synchronous messages with a normal arrow, and asynchronous message with a dotted arrow.

2. Use case diagram: The use case diagram describes the behavior of a system from the view of the user. For our implementation we show the view points of every actor, without addressing the internal implementation.

3. Activity diagram: The activity diagram focuses on modeling procedural processing aspects of a system. It specifies the control flow and data flow between various steps the actions required to implement an activity.

4. State machine diagram: The State machine diagram can be used to show the states in which a system or an object can find itself during its “life cycle”, that is, from its creation to its destruction. The diagram also shows the conditions under which the transitions between these states occur.

Ethical analysis

The introduction of this home robot designed for safety monitoring, particularly for individuals with limited mobility, raises several ethical considerations that must be carefully addressed. As is mentioned previously in the introduction section, data security is one of the main concerns when it comes to information collecting using cameras and remote data sharing. Other than that, the user (mainly the individuals being monitored) may feel the loss of their full independence and autonomy under monitoring. The introduction of these kinds of robots may also result in people's excessive reliance on technologies, which can potentially reduce their sense of responsibility for their loved ones. The issues and the possible solutions will be discussed as follows:

1. Privacy concerns: The primary ethical concern is related to privacy. The built-in camera program, while essential for safety monitoring, may intrude on the personal privacy of individuals within their homes since it involves the collection and processing of sensitive health-related data. It is crucial to implement robust privacy protection features, ensuring that users have control over camera access and that visual data is securely stored. Clear communication and transparency regarding data usage and storage are essential and the users should be well-informed about every aspect of the technology regarding privacy before opting to use it.

2. Program performance: It is essential for the program to be sufficiently accurate especially when it is dealing with health-related tasks. Any misjudgments or mistakes in decision-making may result in severe consequences. It may raise the problem of accountability and responsibility, as the program developer in this case is supposed to take full responsibility for any unexpected failure of the program. Therefore, the program must undergo strict testing protocols to ensure its precision and reliability.

3. Compromised autonomy: While the robot aims to enhance safety and well-being, the autonomy and privacy of the user are to some extents compromised. Being constantly monitored even by their loved ones has deprived individuals of their personal space. Striking a delicate balance between providing necessary care and preserving personal freedom is paramount. Obtaining consent from individuals before deploying the technology in their homes is crucial.

4. Dependence on technology: With the help from technology, it is no longer necessary for the family members to be physically present most of the time to attend to the user. People's dependence on technology will be more and more significant until they are not taking enough responsibilities for their loved ones. Nevertheless, providing companionship, particularly for elderly individuals, holds equal importance. Moreover, once most of the caretaking jobs have been taken over by technologies, there is a potential risk of human caretakers losing their jobs.

5. Affordability and continuous improvement: It is critical to ensure that the home robot is affordable and accessible to a broad range of individuals. The technology is aimed to solve health-related problems for the entire society rather than the privileged few. The developer hold the responsibility to control the investment on the product and to limit the cost. At the same time, it would be a good practice for the developer to gather feedback and stay responsive. Continuous improvement is desired to address any unforeseen ethical challenges.

Design

Our fall detection system is based on a home robot. Thus, we started out with some simple sketches as follows to get some ideas for how the robot could look like. This is shown in the picture below.

A sketch of the robot.

The sketch on the left shows the robot in full. The robot has three main parts: a "head" with a camera, attached to a body with a screen (which houses all the electronics inside), which is attached to a base that has wheels attached to it. The sketch on the right side provides a possible method as to how the parts would be connected together. The wheels should be able to move in a 360 degree angle to allow for more efficiency and mobility for the robot.

After making sketches, we decided that although the robot's design serves its purpose, a more user friendly design could be created. Thus, we adjusted it such that the screen is now the "head" of the robot, which now has arms. The wheels are still attached to the base of the robot, but, they are now hidden underneath the base. We decided on this as our design for the time being, and created CAD models to demonstrate how the robot might look like. The technical drawings have been generated from the CAD model as shown below.

The robot mainly consists of 3 parts, base, body and a head with screen. The battery will be contained in the base to power the robot. Three wheels are installed at the bottom of the base for movement of the robot. The cameras and the electronics are inside the body. Two cameras together with a small lighting system can be seen at the front side of the body. The head of the robot is mainly a screen that is served as a simple user interface. The user can pick up video calls through the screen.

Prototype

Unfortunately, due to the restrictions of the project, it is not possible for us to implement all of the requirements we've developed. As a prototype, we have picked some significant features and functions that will be implemented by the end of the this project.

Implementation

Index	Description	Category
2.1	The robot shall monitor the user continuously and be able to detect falls.	Functionalities
2.2	When the robot detects a fall, the robot shall notify the designated emergency contact within 30 seconds.	Functionalities
2.3	The notification shall be in the form of a VOIP video call to the emergency contact, or a SIM-card based call if an Internet connection is unavailable.	Functionalities
2.4	If there is only one emergency contact which has not responded to the call, or if there are two or more emergency contacts and at least two have not responded to the call, the robot shall instead call local emergency services (112, 911, etc.).	Functionalities
2.5	When the robot detects a fall, and the emergency contact has not responded (as described in 2.4), the robot shall send a text message to the emergency contact.	Functionalities
2.6	The notification (text or call) that the robot sends shall contain the name and location of the user.	Functionalities
2.7	When the robot detects a fall, and the emergency contact has not responded (as described in 2.4), the robot shall take a picture of the fall and send the picture to the designated emergency contact.	Functionalities
2.8	When the robot detects a fall, the robot shall have a mechanism to allow the user to cancel the notification within 30 seconds.	Functionalities
2.9	When the robot detects a fall, the robot shall additionally detect if the user is immobile, and if they are immobile within 5 seconds of the fall detection, it shall send the notification to the emergency contact within 1 second of determining the user is immobile.	Functionalities
2.12	All data that the robot processes or sends shall be stored locally on a hard drive.	Functionalities
2.13	The robot shall delete any video data immediately after it has been processed.	Functionalities
4.3	During training, the rate of false negative falls shall be at most 1%.	Safety
5.6	The robot shall have a dedicated sensor fusion processing unit to support tasks requiring sensor fusion.	Performance
6.1	The robot shall use an object detection algorithm in order to identify objects and people in its environment.	Algorithm
6.2	The robot shall use the algorithm in 6.1 to identify when an object or person has fallen.	Algorithm

As you can see from the selected requirements in the table above, most of the elements belong to functionalities, which will be the major part of our implementation. The prototype will be based on a laptop using the build-in camera to simulate the camera on the robot. We will be using pre-trained models to realize the functionalities related to human and fall detection. The other functionalities will be implemented by ourselves. The implementation specifications will be described below. (note that now the picked requirements are preliminary, the group will discuss and decide the final implementation list next week)

2.1, 4.3, 6.1, 6.2: specifications of the model

Fall detection Algorithm

The algorithm detects a person not falling down

The algorithm detects a person fell down

We used two libaries implemented using yolov7 object detection model. The first one is a package for human pose estimation. It can activate laptop camera to detect real-time human pose skeleton. The second one is a package to detect a person falling down in a video. We combined two packages to detect the real-time human fall and show it on screen.

1. yolov7

Yolov7 is the most accurate as well as the fastest object-detection AI model. Its github repository provides several branches for object recognition, pose estimation, lidar and other functionalities. It can perform detection on videos and images provided by users. Also, it leaves the space for users to customize the algorithm. For example, users can train the model on their own datasets, or modify some keypoints to have different biases on object recognition. Therefore, it is a good model for us to use in this project to detect the human fall. However, it can only detect poses of images and videos, but our robot needs to detect human falling in real-time. Hence, some integration with other algorithms is needed.

2. yolov7-pose-estimation

This library is a modification of yolov7. The main reason we use this model is that it is able to apply yolov7 pose detection on web cam in real-time. This perfectly suits our need because with this library we can detect the pose of an elderly in real time. And the last step is to identify when the elderly will be recognized as being falling down.

3. yolov7_keypoints

This library is another modification of yolov7. It uses a fall detection algorithm to detect the human fall. It extracts some human body key points and calculate the y coordinate difference between shoulder, hip, and foot. When the height difference between shoulder and hip, hip and foot, shoulder and foot is small, it recognizes as a fall down.

Therefore, we integrated the second and the third library to solve the problem of detecting a human fall in real time. Now we are able to use a web cam to detect whether a human falls down.     

Others: describe how we are going to demonstrate. For example, assign one emergency contact to be the number of one of the group members, the emergency service being the number of another group member. We need to combine the algorithms so that they function simultaneously to satisfy all requirements. We describe how it works here.

Test plan & results

We make a test plan and make sure it covers everything listed in the implementation. Then we perform testing and record the results.

Approach

In order to reach the objectives, we split the project into 5 stages. The five stages are distributed into 8 weeks with some overlaps. Everyone in the team is responsible for some tasks in these stages.

1. Research stage: In week 1 and 2, we mainly focus on the formulation of problem statements, objectives, and research. We first need to make a plan for the project. The direction of this project is fixed by defining the problem statement and objectives. Doing literature research helps us to gather information of state-of-the-art, the advantages and limitations of current solutions.
2. Requirements stage: From week 2 to week 4 we will do user analysis to further determine the goal and requirements of our product. We will collect information about user needs by surveys and interviews. The surveys and interviews can contain information found in the research stage. For example, how does the user think about the current solution, what improvements can be made.
3. Specification stage: This stage is in week 3 and 4, in which we create the specification of our product using techniques such as UML diagrams and drawing user interface. From the user analysis and the research, we can create the specification in more detail. After this, a test plan will be made so that the product can be tested to see whether it meets the requirements and the specification.
4. Implementation stage: The prototype of our product will be implemented in this stage from week 5 to week 7. We plan to only create the digital part of the product due to time constraints. Also, a more formal test plan will be constructed for later use.
5. Testing stage: In week 7 and 8, the prototype will be tested by the test plan and we can examine whether the product reaches our goal and solves the problem. The finalization on the prototype, presentation and wiki page will be done in this stage.

Planning

We created a plan for the development process of our product based off of the previously described approach. This plan is shown in the Gantt chart below:

A Gantt chart of our development plan.

Task Division

We subdivided the tasks amongst ourselves as follows:

Research			Requirements			Specification			Implementation			Testing
Task	Group member		Task	Group member		Task	Group member		Task	Group member		Task	Group member
Define problem statement and objectives	Everyone		User Analysis	Jie		Create UML Diagrams	Nikola		Implement the prototype	Everyone (TBD)		Test the prototype	Everyone (TBD)
Setup the Wiki page	Yuting		Create Survey	Jie & Feiyang		Define user interface	Samir & Zhiyang		Create formal acceptance test plan	Everyone (TBD)		Work on presentation	Everyone (TBD)
Literature research	Everyone		Analyse Survey	Jie & Feiyang		Make a test plan	Samir		Finalize prototype	Everyone (TBD)
Write Section "Approach"	Yuting		Write Formal Requirements	Everyone
Write Section "Planning"	Samir
Write Introduction	Zhiyang
Write Section "State of the Art"	Samir & Nikola
Perform Stakeholder Analysis	Everyone
Update Wiki	Everyone

Milestones

By the end of Week 1 we should have a solid plan for what we want to make, a brief inventory on the current literature, and a broad overview of the development steps required to make our product.

By the end of Week 3 we should have analysed the needs of our users and stakeholders, formalized these needs as requirements according to the MoSCoW method, and have a clear state-of-the-art.

By the end of Week 4 we should have specified the requirements as UML diagrams, blueprints, etc., created a basic user interface, and created an informal test plan.

By the end of Week 6 we should have created a formal acceptance test plan.

By the end of Week 7 we should have finished the implementation of our product's prototype.

By the end of Week 8 we should have tested the product according to the acceptance test plan, finished the presentation, finalized the prototype, and finalized our report.

Deliverables

The final product will be a robot that is programmed to detect when a user falls and alerts emergency services if they do. Furthermore, we would like it to be capable of identifying fall risks and alerting the user of them, but we do not yet know if this can also be done within the course timeframe.

Logbook

Week 1

Name	Total hours	Tasks
Yuting	6	Introduction lecture (1), meeting (1.5), Approach section (1.5), literature study (2)
Jie	6	Introduction lecture (1), meeting (1.5), Approach section (1.5), literature study (2)
Zhiyang	6	Introduction lecture (1), meeting (1.5), Introduction section (1.5), literature study (2)
Samir	6	Introduction lecture (1), meeting (1.5), Gantt chart (1), Planning section (1.5), Literature research (1)
Feiyang	5	Introduction lecture (1), meeting (1.5), literature study (2.5)
Nikola

Week 2

Name	Total hours	Tasks
Yuting	5.5	Feedback session + meeting (1.5), brainstorming on new ideas (1), Research (2), Analysis of target groups(1)
Jie	7	Feedback session + meeting (1.5), brainstorming on new ideas (1), Analysis of target groups(3), State of the art section(1)
Zhiyang	6.5	Feedback session + meeting (1.5), brainstorming on new ideas (1), rewriting Introduction (2), Ethical analysis section (2)
Samir	10.5	Feedback session + meeting (1.5), brainstorming on new ideas (1), State of the art section (8)
Feiyang	4.5	Feedback session + meeting (1.5), brainstorming on new ideas (1), Analysis of target groups(2)
Nikola

Week 3

Name	Total hours	Tasks
Yuting	10	Feedback session + meeting (2), research on solutions (2), requirements (2), group meeting on Thursday (2), user analysis (2)
Jie	10.5	Feedback session + meeting (2), research on solutions (2), group meeting on Thursday (2), interview questions (2), interview (1), translate result(0.5), analysis feedback(1)
Zhiyang	10.5	Feedback session + meeting (2), group meeting on Thursday (2), CAD model (5), update requirements and CAD drawings on Wiki (1.5)
Samir	6.5	Feedback session (0.5), group meeting on Thursday (2), sketching (4), updating wiki (1)
Feiyang	7	Feedback session + meeting (2), research on solutions (2), group meeting on Thursday (2), interview (1)
Nikola

Week 4

Name	Total hours	Tasks
Yuting	13	Feedback session + meeting (2), research on fall detection algorithms (6), meeting Thursday (1), study and implement the algorithm (4)
Jie	5	Feedback session + meeting (2), interview the third interviewee (1), interview analysis (1), algorithm search (1)
Zhiyang	9	Feedback session + meeting (2), contact the robotics person (1), agenda meeting Thursday (1), meeting Thursday (1), select requirements for implementation (4)
Samir	12	Feedback session + meeting (2), research and update requirements (7), meeting Thursday (1), test plans (2)
Feiyang	6	Feedback session + meeting (2), research on algorithms (2), interview analysis (1), meeting Thursday (1)
Nikola

Week 5

Name	Total hours	Tasks
Yuting
Jie
Zhiyang	9	Feedback session + meeting (2), agenda Thursday meeting (1), researching and implementing programmable calling and messaging (6)
Samir	5	Feedback session + meeting (2), research and update requirements (3)
Feiyang
Nikola

Week 6

Name	Total hours	Tasks
Yuting
Jie
Zhiyang
Samir
Feiyang
Nikola

Week 7

Name	Total hours	Tasks
Yuting
Jie
Zhiyang
Samir
Feiyang
Nikola

Week 8

Name	Total hours	Tasks
Yuting
Jie
Zhiyang
Samir
Feiyang
Nikola

Appendix

Interview Questions:

Q1: Have you or your family members experienced a fall at home?

Follow up: How concerned are you about the possibility of falling in your home?

Q2: Have you ever had an interaction with an intelligent robot?

Follow up 1: how would you describe the experience?

Follow up 2: Did you see any device for detecting the fall?

Follow up 3: How comfortable are you with the idea of having a robot assist you in your home?

Questions after the interviewee understands our product.

Q3: What are your initial thoughts about a robot that can detect falls using a camera?

Follow up: How do you feel about a robot following you to ensure it captures all areas through its camera?

Q4: What features do you think would make it easier for you to use this fall-detection robot?

Follow up: How would you prefer to interact with the robot? For example: using voice commands like communicating with Siri, or touch screen interaction, like iPad.

Q5: How important is the privacy of your home to you? Are you comfortable with a robot having a camera for fall detection?

Follow up 1: Under the personal privacy data protection law, what data do you think can be stored, and what data do you think can be sent to the server for further analysis.

Follow up 2: What measures would you like to see in place to ensure the security of the information collected by the robot?

Q6: How do you currently handle the sudden fall of yourself (how do you notify others if you cannot stand up on you own) and how do you know that your family members have a severe fall and need further assist?

Follow up: When emergency happens, do you have any preferences about the method of contacting? For example, making a phone call to an emergency contact or SMS notification.

Q7: Do you have any safety related concerns about the robot following the user?

Follow up: And do you think this would be annoying if there is a robot following you all the time? If so, what distance would you prefer that the robot shall stay away from the user?

Q8: Do you think this robot could enhance the user’s daily life and independence?

Follow up: Have you ever thought about the alternative way to detect the fall, like using wearable devices like Apple Watch to detect.

Q9. Do you have any suggestions for the appearance of the robot?

Q10: What do you think is the suitable price range for this robot?

Literature study

1. (Existing product regarding robot that dispensing pills) The robot, managed via an app, securely stores and dispenses medication, provides verbal reminders, and can alert caregivers if doses are missed. It features facial recognition and motion detection to ensure the right person receives the medication. The device complies with patient privacy laws and is positioned as a health care solution amid the growing trend of remote health care technology. Rosen, A. (2019), This robot makes sure you remember to take your pills. CUTTING EDGE | MAGAZINE, available at: https://www.bostonglobe.com/magazine/2019/03/29/this-robot-makes-sure-you-remember-take-your-pills/.
2. (Introducing a new technology and a new way of remote health care) Telemedicine, an emerging technology, enables remote medical consultations through video conferencing or digital imaging systems, fostering coordination and collaboration in diagnosing and treating diseases. A three-tier pervasive telemedicine system utilizes a wireless body area network (WBAN) for continuous healthcare monitoring, with users obtaining vital signals in Tier 1 and transmitting them to healthcare providers in Tier 3 through personal gateways (Tier 2), such as smartphones. Tiers 1 and 2 serve as the client side, providing mobile health (mHealth) services, while Tier 3 represents the server side. Shuwandy, M. L., Zaidan, B. B., Zaidan, A. A., & Albahri, A. S. (2019). Sensor-based mHealth authentication for real-time remote healthcare monitoring system: A multilayer systematic review. Journal of medical systems, 43, 1-30.
3. (Potential challenges raised by telemonitoring technology) Issues include the absence of suitable sensors, concerns about system size and weight, identification of invalid data, battery life, bandwidth, network coverage, and data transmission costs. Adoption challenges are highlighted, such as privacy concerns and potential insurance-related issues. Cultural adjustments in healthcare organizations and the need for new data analysis methods are also mentioned. Nangalia, V., Prytherch, D. R., & Smith, G. B. (2010). Health technology assessment review: Remote monitoring of vital signs-current status and future challenges. Critical Care, 14, 1-8.
4. (Possible design ideas and the drawbacks in remote health-care technology) Several related work and design techniques have been presented. Zhou, B., Wu, K., Lv, P., Wang, J., Chen, G., Ji, B.& Liu, S. (2018). A new remote health-care system based on moving robot intended for the elderly at home. Journal of healthcare engineering, 2018. Available at: https://www.hindawi.com/journals/jhe/2018/4949863/.
5. (Ethical concerns regarding telehealth) The paper discusses challenges related to integrating telehealth into healthcare systems. Concerns about data protection and privacy are raised due to increased access to sensitive patient data. Ethical issues arise regarding patient autonomy and the potential substitution of physical presence in healthcare. Botrugno, C. (2019). Towards an ethics for telehealth. Nursing ethics, 26(2), 357-367.
6. (Collaborative Robot for Remote Dementia Care in Home) This paper shows a teleoperation of a remote care robot at home. This robot is designed for elderly people with dementia. Care givers can use this robot to provide care remotely. They can monitor the patient via robot vision, and control the robot arm via motion tracking. For instance, they can grab medicine and pills for the patient. https://ieeexplore.ieee.org/abstract/document/9116811/authors#authors
7. (Human-Robot Interaction with the Elderly) Some researchers conducted an experiment of replacing a human care giver with a humanoid care robot for 10 weeks. The conclusion is that the elderly are willing to interact with the robot, but they think that the robot cannot replace a human care giver because of techniqual issues, lacking warmth, acceptance, and unexpected situations. https://dl.acm.org/doi/abs/10.1145/3313831.3376402
8. (Patient Monitoring and Medicine Dispenser Robot) This robot is an assistive medical robot for doctors to take care of patients remotely. It combines the pill dispensing and patient monitoring. Doctors can set the prescription for patients. The robot will then remind patients to take pills at required time. It will at the same time recored the patient's temperature via infrared and store it in a database for further analysis. https://pubs.aip.org/aip/acp/article/2494/1/030004/2827068/Patient-monitoring-and-medicine-dispenser-robot
9. (A design of a robotic system to dispense pills) This article introduces the algorithm of a automatic pill dispensing robot. It provides pills to the patient according to a schedule, and remind the patient with sound, light signals and text messages. The signals remain until the patient takes the pills and presses a button. If the patient does not take pills on time, the robot will contact the nurse. https://www.sciencedirect.com/science/article/pii/S0149291817302023
10. (The Role of Healthcare Robots for Older People at Home) This paper discusses problems healthcare robots are facing and what solutions are there. We need to consider the acceptance of healthcare robots by the elderly and privacy issues when designing the robot. The elderly at home can face many different problems. For example, physical problems, mental issues, dimentia and so on. Different robotic solutions need to be considered to solve these problems. https://link.springer.com/article/10.1007/s12369-014-0242-2
11. Robots in elderly care can be used to provide companionship and improve quality of life of elderly people affected with cognitive impairment/dementia, and can assist them in independent everyday living, by monitoring their health and monitoring the environment to detect dangerous situations, like fall risks, and can be used to remind them of medicines, appointments, tasks, etc. Vercelli, A., Rainero, I., Ciferri, L., Boido, M., & Pirri, F. (2018). Robots in elderly care. DigitCult-Scientific Journal on Digital Cultures, 2(2), 37-50. https://digitcult.lim.di.unimi.it/index.php/dc/article/view/54
12. Yang et al. identified 10 grand challenges in robotics in 2018: New materials and fabrication schemes, biohybrid and bioinspired robots, power and energy, robot swarms, navigation and exploration, AI for robotics, brain-computer interfaces, social interaction, medical robotics, and robot ethics and security. Of particular interest to us is: navigation and exploration, AI for robotics, social interaction, and medical robotics. Yang, Guang-Zhong & Bellingham, Jim & Dupont, Pierre & Fischer, Peer & Floridi, Luciano & Full, Robert & Jacobstein, Neil & Kumar, Vijay & McNutt, Marcia & Merrifield, Robert & Nelson, Brad & Scassellati, Brian & Taddeo, Mariarosaria & Taylor, Russell & Veloso, Manuela & Wang, Zhong & Wood, Robert. (2018). The Grand Challenges of Science Robotics. Science Robotics. 3. eaar7650. 10.1126/scirobotics.aar7650.
13. A review of the literature on assistive social robots in elderly care by Broekens, Heerink and Marcel found that there is some evidence that companion type robots have positive effects in healthcare for elderly people with respect to at least mood, loneliness and social connections with others. However, the strength of this evidence is limited, since (a) most studies have been done in Japan, with (b) a limited set of companion robots, i.e., Aibo and Paro, and (c) research designs are not robust enough, usually not described in enough detail to repeat, and confounding causal variables cannot be excluded. However, the review concludes that it is still worthwhile to invest in research methods to better examine the efficacy of social robots in elderly care. Broekens, Joost & Heerink, Marcel & Rosendal, Henk. (2009). Assistive social robots in elderly care: A review. Gerontechnology. 8. 94-103. 10.4017/gt.2009.08.02.002.00.
14. The KSERA (Knowledgeable SErvice Robots for Aging) project integrates smart home technology and a socially-assistive robot to extend independent living for elderly people, in particular those with COPD. The project achieved the goal of integrating smart home technology and socially-assistive robots to allow the extension of independent living for elderly people. The results showed that (1) the KSERA system and Nao robot are likable, (2) the attitude toward the Nao robot is highly correlated with the attitude toward the system, and (3) communication through a robot is preferred over interaction with the individual technical elements of a smart home. Johnson, D.O., Cuijpers, R.H., Juola, J.F. et al. Socially Assistive Robots: A Comprehensive Approach to Extending Independent Living. Int J of Soc Robotics 6, 195–211 (2014). https://doi.org/10.1007/s12369-013-0217-8
15. Direct social robots could decrease loneliness by creating conversational opportunities and, as prior literature (Turkle, 2011) shows, even a sense of attachment, especially as they develop technologically in the future. Additionally, in a study where a humanoid robot Zora was piloted in elder care services, the care personnel noted that, unlike a human caregiver, the robot does not get tired, it always responds in a friendly way, and it repeats things over and over if needed. Furthermore, the robot does not take things personally (Melkas et al., 2020). Breazeal (2004) mentions that one of the advantages of social robots is that they do not have any “social baggage” and therefore do not judge. In addition, it may be less stigmatizing for an older person to receive care from a robot than from a human (Prieto-Flores et al., 2011). Jari Pirhonen, Elisa Tiilikainen, Satu Pekkarinen, Marjut Lemivaara, Helinä Melkas, Can robots tackle late-life loneliness? Scanning of future opportunities and challenges in assisted living facilities, Futures, Volume 124, 2020, https://doi.org/10.1016/j.futures.2020.102640.
16. The use of SARs in mental health research is not yet widespread, new robots and programming are constantly changing, adapting, and expanding. The use of SARs in mental health research and mental health interventions is nascent and has thus far been restricted to specific populations with limited measurement and scope. There is an abundance of opportunity in this area for growth, expansion, and exploration to triangulate SARs usability and efficacy data as the next step in advancing this field. Scoglio A, Reilly E, Gorman J, Drebing C. Use of Social Robots in Mental Health and Well-Being Research: Systematic Review, J Med Internet Res 2019;21(7):e13322. URL: https://www.jmir.org/2019/7/e13322. DOI: 10.2196/13322

(Please use APA 7 for bibliography)