PRE2019 4 Group5: Difference between revisions
m (→Appearance) |
|||
| Line 634: | Line 634: | ||
https://link.springer.com/chapter/10.1007/978-3-319-20892-3_49 | https://link.springer.com/chapter/10.1007/978-3-319-20892-3_49 | ||
==== Functionality==== | ==== Functionality==== | ||
Revision as of 10:25, 27 May 2020
Group members
| Name | Student number | Study |
|---|---|---|
| Danielle Paige Gillam | 1227637 | Psychology & Technology (ICT) |
| Lucia Kalkman | 1335529 | Electrical Engineering |
| Annemijn Cissy van der Lande | 1239822 | Psychology & Technology (Robotics) |
| Dajt Mullaj | 1286722 | Computer Science |
| Fabiènne Pascalle van der Weide | 1004980 | Psychology & Technology (ICT) |
Introduction
Nowadays, more and more automated technology in the vehicles industry is making its entrance in society. With the current situation of COVID-19, people are forced to live in social distancing societies [1], which results for some social groups in major challenges to continue living in a normal and healthy way. One of the major issues society is facing is maintaining the health of people who have to stay home, but still need to receive their medicines. Delivery robots could give an outcome in this situation and might give perspectives for after the COVID-19 influenced society. [2] These robots are already in use, in several situations, environments and forms. Furthermore, they are currently experimenting with these delivery robots for multiple purposes.[3]
Problem Statement
This project will explore how to implement a system of autonomous robots for the delivery of medicine and goods to the elderly and sick people. The system could then be used in hospitals to help the staff with intensive care units and for deliveries from pharmacies directly to houses or elderly homes. To sustain an efficient delivery scheme the project will develop a prototype for a multi compartment robot. Each compartment will contain medicine for a specific delivery, so that in a single trip the robot will visit multiple houses or contain all the drugs for each elder of an elderly home. The prototype will therefore be composed of two main parts, each solving a main problem of implementing delivery robots for medicines. The first part will be a software demonstrating the navigation system of a robot that needs to visit multiple houses before coming back to the pharmacy for the next delivery. The software will be written in NetLogo, a programming language and IDE for modeling agent-based environments. The second part of the prototype will consist in demonstrating the robot’s multi compartment system. To do that an app, written in Swift, will be developed and hardware representing a robot with more compartments will be assembled. The app will have an option to log in as a user or as a pharmacist/caretaker. The robot will have levers mimicking compartments opening or closing and a board to take inputs. As a user you will be able to order medicine through the app, which in turn will display a password to type on the robot’s board. When such action is performed the correct compartment containing the requested medicine will open. The project, moreover, takes into consideration that smartphones are not popular with the elderly. Therefore the latter or the caretaker assigned to an arbitrary elderly home can enter in contact with a pharmacist either by physically going to the pharmacy or by digital means, like with an email, and create a subscription for a delivery plan. They will then receive from the pharmacist a password, and on each delivery the pharmacist will furnish the robot and logging in the app will set the password for the specific compartment to the one agreed upon when the subscription was initiated. The project, as specified before, could also be used to perform deliveries within the hospital's ground in order to prevent the spread of infectious diseases among the healthcare staff.
Objectives
- Research the state of the art of the current autonomous delivery robots.
- Understand the requirements for delivery robots in the medical field.
- Design and implement a navigation system for autonomous delivery robots that finds the shortest path across multiple targets.
- Design and implement a multi compartment system that can lock each compartment by means of a password and communicates with an external application to set said passwords.
- Test both systems to understand their limitations and improve their functionalities.
State of the Art
Delivery robots (for medicine)
The types of robot forms that are currently under study and first use, can be subdivided into two areas: vehicles at the ground and in the air. The great advantage of using air-based delivery robots, like drones, is the reduced amount of interaction. However, traffic regulations are currently undefined. For the ground-based vehicles, both aspects named before are the opposite in here.
Another distinction that can be made, is the environment in which the delivery robot will perform. Currently, there are view hospitals in which robots are used to transport medicines to the patients. This is an example of inside transportation, minimizing path planning and the amount of traffic, but maximizing its demand for room recognition. [4] Also one aptheker has used delivery robots as an experiment by transporting the medicines to care-units where nurses took over the packages. The overall attitude towards this user experience was fine, but is influenced by the fact that both stakeholders had to minimally interact and were not involved in the technical liability issue. This is an example in the field of an outside environment where the robots had to face a lot of traffic and path planning, but less on room-recognition, since it delivered a package to one care unit. [5]
Furthermore, the purpose of transport can vary a lot. At the moment, drones and ground vehicles are mostly transporting goods like food and medicines, both giving an outcome for people who have transport difficulties or are not able to go outside because of their health. In Wuhan for example, the delivery robots are both already in experimenting use. [2] For food, real-time and path planning are really important. Another important aspect is its capacity of carrying a large amount of goods. It is therefore more common that riding vehicles carry these goods, whereas medicines are in smaller amounts but are more often carried by drones due to safety reasons. [6] Time plays a role in this as well, for instance: warm food needs to be delivered fast and vital donor organs need to be brought fast in war areas. [7] We can conclude that the goal of the service provided can therefore play an important role in the design choices.
Lastly, the types of technique can be distinguished, since this varies a lot per delivery robot. We will discuss this by looking at path planning, coördination & recognition, mechanics and AI in general.
Path planning/scheduling
Finding a feasible route of movement can be challenging for autonomous vehicles. Multiple algorithms are therefore proposed to improve its efficiency and safety on their path. These algorithms differ for robots that are returning or non-returning [8]. Also the use of GPS systems is a common tool in scheduling. Furthermore, a newer tool has been designed by making use of pedestrian flow, in which it adapts to the pedestrian potential equation based on the route estimation model [9]. When making a path planning outside, often a SLAM system is used, helping the robot to deal with the huge maps of city centers. It provides a large map of the surrounding environment [10]. This system takes the type of roads into account, traversability and provides a method for localization in dynamic environments [11]. Lastly, there are also central systems already that can map where all other robots are currently located, to generate as a pick up / order system, solving many problems in the communication between robots implementation on a larger scale [12].
Coördination & object recognition
A method for coordination is iGPS, this is working with ceiling cameras [13]. Another commonly used technique combination for coördination and object recognition is making use of artificial intelligence, ultrasonic sensors and cameras [14]. An example of this is the FedEx SameDay Bot — which looks like a cooler on wheels — is designed to travel on sidewalks and along roadsides to deliver small orders to homes and businesses [15]. This type of robot successfully passes objects on their way, like trash cans, skateboards etc. Moreover, another example is Amazon Scout devices; also using cameras and sensors for its planning and cöordination [16]. Furthermore, there are also robots that are capable of recognizing and distinguishing between rooms [17], making use of intelligent machine vision [18].
Mechanics
First of all, when looking at the ground vehicles, they have to face several problems on the road, so good mechanics are essential. At the moment, a wheel and track hybrid robot platform exists which is highly applicable to various urban environments. The developed robot platform has all advantages of track and wheel. Furthermore, this hybrid concept is highly energy-efficient because of its less-friction using wheels only on navigating flatland [19]. Moreover, new developments in the technologies of drone delivery are aircraft design, battery improvements, and control software. They could transform this industry and, consequently, society as a whole [7].
Finally, we should not forget to look at the current attitude people have towards this upcoming innovation. This is dependent on the perspective we look at. Current studies show this broadly, by making a distinction in the type of stakeholder. Random people in traffic for example will have different attitudes towards the robot than the receivers of the good [20]. Also the environmental footprint raises discussions: drones are a relatively sustainable transportation method, but the production is not. [21] However, one thing that is universal is that the delivery robot should be in balance with safety, ease of use, environment, goal and efficiency. Dependent on the welfare of the society, attitudes towards robots might differ. [20]
Limitations and issues
There are multiple problems before autonomous delivery robots can be fully used. In the following part the major issues will be stated that are currently holding back the implementation of delivery robots. One of the main problems is the attitude of society about automated vehicles. There are concerns about the safety of the transport, such things as hacking could cause problems. However, there are other concerns people have. For example whether more people will get unemployed when delivery robots are widely spread. People are also wondering whether a robot can reach every location, climbing stairs or entering a building could be difficult.[22] People also think that for example a sidewalk robot should not hinder pedestrians, which causes even more things to take care of when designing the robot. [6]
Another problem are all the technical issues. Is it possible for a robot to reach a higher efficiency, improve time and reduce cost and energy consumption. Will a robot be as reliable as a human? It should be able to deliver something within the same time and guarantee that the product arrives. [23] The biggest technical issue is the navigation and the interaction with the environment. This means the robot should always know where it is and where it’s goal is, but also what happens around him. What are possible dangers and what is the best possible way to get where it should be. Especially with a lot of individuals who don’t follow the same paths it can be difficult for a sidewalk robot to avoid them all. [9] The current technology is still struggling with this.
The final issues are the regulations. For UAV’s there are special regulations, and they are not allowed to fly everywhere, however, self-driving cars counter the same issues. They are not allowed on the road because of many ethical issues and some technical liabilities. The last option are sidewalk robots, which don’t have to meet as many regulations, but they are also difficult because pedestrians are hard to model and follow less strict paths.[24] All the different regulations in different countries and all the parts that are still very vague make it difficult to really develop delivery robots. Also questions like who is responsible for the robots mistakes make it less attractive to start working on delivery robots.[25]
Stakeholders
There are a number of different stakeholders when it comes to the field of medical delivery robots. Here the main stakeholders within the scopes of users, society and enterprise will be presented and discussed.
Users
The primary users of medical delivery robots are those who directly interact with the robot. Therefore sick or elderly people who require medicine deliveries will fall into this category. These patients will have to have sufficient understanding of how to interact with the robots and respective applications. Pharmacists and nurses will also be considered primary users as they will have to interact with the robot in order to fill it with sufficient supplies for respective patients and understand the operation of the application and robot. These users will be considered the most in the design process as they will use the robot for it's purpose, and so interface design choices as well as technical design choices will be made in order to best accommodate these users.
Society
Within society there are a number of stakeholders, the first being the Government. The Government are responsible for laws and regulations regarding the medical delivery robots, this includes traffic regulations as well as ethical laws.
The second stakeholder that is a part of the societal perspective is nurses caretakers and doctors. As well as being direct users of the robots in terms of stocking them with medicine, the medical delivery robots impact them in a less direct manner too. For example in the midst of a pandemic or an outbreak of disease, the fact that these health care workers are able to send a delivery robot to infected patients means that they reduce the risk of being infected themselves. Hospitals themselves are also stakeholders and due to the fact that hospitals are commonly hotspots for these outbreaks the reduction of infection of their staff will help prevent understaffing. The reduction of the spread of disease will additionally help society as a whole as well as reducing stress on governments.
The final societal stakeholders are people who encounter the medical delivery robots on the streets while they are performing their delivery or pick-up tasks. These individuals play an important role in the fabrication of laws and regulations as their lives will be affected by the robots without any direct gain from them. For example the possibility of disruption in pedestrian traffic or even the vandalisation of the robots will motivate respective regulations. In order to gain this stakeholder perspective a survey will be performed in order to gain insight from these stakeholders and their attitudes towards delivery robots.
Enterprise
Within the scope of Enterprise the main stakeholders are the technical companies which are developing the medical delivery robots as well as the hospitals and pharmacies with which they are partnered.
Ethical Analysis
There are many ethical considerations that come with the use of autonomous robots, especially within the medical world.
This ethical analysis will be loosely based upon the Beauchamp and Childress model which uses the following core principles for considering ethical issues [26] [27]:
- Beneficence
- Nonmaleficence
- Autonomy
- Justice
The most obvious and direct risk of any assistive technology, is the potential of physical harm. However there are also more issues that may be less obvious. In a study conducted on a delivery robot used in multiple departments of a hospital, Mutlu and Forlizzi [28] discovered that different patient groups had different emotional reactions to the robot. Cancer units were not accepting the robot, finding it annoying, while postpartum units were accepting the robot and calling it delightful.
The results of this study suggest that different user populations can have completely different views or experiences with the same robot. These opinions could be due to a number of social or cognitive reasons. Because of the wide variety of possible reactions to robots in these situations it is important to take into consideration a wide range of user perspectives. According to previous experiments [29][30], it has also been demonstrated that some users form emotional attachments to robots that they were interacting with, some even having the impression that a robot would miss them when they were gone, which is beyond the capabilities of modern robots. Humans have a strong tendency to anthropomorphise objects with human-like features like a face or eyes. Such personification may be unintentional, occurring because a caregiver refers to the robot as ‘him’ or ‘her’. This anthropomorphism assigns greater intelligence to the robot than it truly has. The same can be said for robots that communicate via a natural human voice. These emotional attachments are misleading and could be seen as a form of deception and lead to too much trust in the robot which is unethical.
In order to mitigate this deception as best as possible, in the case of our robot technology, it must be made clear from the instance that any user sees the robot that its sole purpose is delivery and not communication or medical advice. This is why the design choice has been made to leave out human features such as a face, eyes and a voice. In addition to this, before any technology is deployed, it is critical to explain to all users involved what the capabilities of the technology are as well as possible. However, this can be unrealistic in the scope of delivery robots as uninformed bystanders (for example people on the streets that encounter the robots) will be exposed to them often, full disclosure can be difficult in these situations.
The risk of further isolation due to decreased human contact due to replacement with robots is also an ethical consideration. Particularly for populations that are known to suffer from isolation, including the elderly. However, in this case the costs of the medical delivery robots outweigh the benefits especially for those who are unable to collect their medication alone due to mobility or cognitive reasons. Here there is a tradeoff between getting vital, possibly life saving medication via an autonomous robot and the risk of further isolating a user and it is clear that the former is too important to disregard the use of these delivery robots.
Another ethical issue with delivery robots that arises is in terms of privacy. These robots will have access to sensitive information about a patient such as their home address and the medication which they take regularly. Because this information also needs to be shared with the pharmacist and in some cases caretakers, it is important in this case for the users to sign an informed consent to understand exactly which information of theirs is accessed. For instance, a user might not realize that the robot’s camera could record video, the camera should therefore be an obvious feature of the robot so that everyone who sees it understands that it has this feature. Furthermore, it is very important to make sure that the capabilities of a robot are sufficiently explained beforehand so that a user has been as well informed of a model of the robot’s abilities as possible.
Another justice-related issue when discussing robotics in socially assistive settings is the notion of responsibility: Who should be held responsible if or when things go wrong? Error in robot functioning could occur due to user error, or an error of the robot itself. The difference is not always clear between these and so there is a blurry line of moral responsibility. For example the user error could be a result of poor instructions or false expectations due to the aforementioned deception. In this case it is difficult to say who should be held responsible if something does not go to plan. In the case of robot error, the problem could be in the design, hardware, or software of the robot, meaning that the responsibility belongs to the designer, programmer, manufacturer, distributor, or retailer. [31] However this is difficult as most software licenses explicitly absolve the software developer of responsibility, and the same goes for most manufacturers. Therefore the role of responsibility is difficult to ascribe to one particular party. However there are more tangible errors that have clear links to responsibility. For example, if the wrong medication is loaded into one of the robots compartments for a particular patient, it is clear that this responsibility belongs to the pharmacist who loaded the robot.
Requirement analysis
User interviews
To identify current problems and requirements of the medicine delivery robot, interviews with potential users were conducted. Interviews with the primary users (elderly), as well as pharmacists, and caretakers took place. The questions used for these interviews and the transcripts can be found here. Below are reported the needs that were gathered from the different interviews with the stakeholders. The needs are presented within the user segment they were collected from.
Elderly needs
| 1. | The robot needs to be user-friendly and understandable for elderly, every action should be intuitive. |
| 2. | A human-like feature (face / eyes) would be nice, but functionality is more important, a voice would be nice. |
| 3. | We need to have a lock system that gets opened by a password/code/app/card that somehow identifies the user. |
| 4. | The password is set up with the pharmacist and is delivered in a written format (letter). |
| 5. | The password should be easy to input in the robot, preferably with a simple keyboard. |
| 6. | Deliver on certain, known time slots. |
| 7. | The robot should be able to notify the user that it is at the door. |
| 8. | The robot needs to alarm someone if it expects something is wrong (door doesn’t get opened for example). |
| 9. | The robot (either drone or walking/driving) should be recognizable as belonging to the pharmacy. |
| 10. | The compartments (or at least one/some) should be cooled, since some medication need that. |
| 11. | Don’t let the robot drop the medicine on the doormat (dangerous for pets). |
| 12. | The robot could carry also some indication about the medicines from the pharmacist inside the compartment, in form of a written note for example. |
Caretakers needs
| 13. | It should be "tested" if someone is still clear-headed and independent enough (also physically) to use our delivery system (or decide the person responsible for this). |
| 14. | (In a care home) The robot should have a way to monitor if people actually correctly took their medicine. |
| 15. | The elderly can entrust the caretaker to keep track of the deliveries, which the caretaker will schedule and set with an app. |
| 16. | Set protocol for “not normal situations”, meaning for example a precise set of action the pharmacist will do to inform the caretaker if some information needed for the delivery are missing before attempting the delivery. |
| 17. | If the password is lost can be resent via sms or letter or notified on the caretaker app. |
| 18. | Ability to plan in advance which medicines must be delivered on which day. |
| 19. | Possibility to subscribe to the delivery service directly at any pharmacy. |
| 20. | A smart system to decide the delivery routes and moments is needed. |
Pharmacists needs
| 21. | Separate sachets or clear labels are necessary to not accidentally swap medicine. |
| 22. | People need to be at home during delivery. Smart route planning / notifications for the users are useful. |
| 23. | Cooled compartments for medication that needs to be kept cold. |
| 24. | Option to offer counselling. |
| 25. | Easy to understand application. |
| 26. | QR codes to offer extra info for the patient. |
| 27. | Tracked deliveries. |
| 28. | Option for patients to give feedback. |
| 29. | Database to keep track of the prescription medicines that still have to be delivered or have been already delivered to a certain patient. |
Personas
David and Maria
David (76) and Maria (73) are married for almost 50 years and are living together peacefully in their terraced house in a village in the Netherlands. David has some trouble with his heart, for which he needs medication every day and Maria has very painful rheumatism for which she has to inject medicine once every few weeks. They both have a smartphone and luckily, their children and grandchildren helped them understand how to use it. When they want to install a new app, they need to ask for help, but once the app is installed and explained they know how to use it pretty well. David and Maria take a stroll every day to keep active, but during the COVID-19 outbreak, they are more careful when it comes to going outside and seeing other people, and they sometimes find it difficult to enter shops or pharmacies as they are relatively crowded.
Tom
Tom is 36 years old. He works in home care and really likes his job. It really pleases him to know that he can help these people stay at home a bit longer by regularly visiting them and helping them with whatever they need. For some people, he only needs to pick up medication (because they are not mobile enough themselves anymore), but after that, they can use them and do everything else on their own. This takes a lot of time, which he prefers to spend with people that really need his assistance with cleaning, taking medication, washing, or just having a nice conversation.
Betty
90 year old Betty still lives at home. Her husband died 12 years ago, but she refuses to leave their home to go to a care home. She’s got too many memories here. In the last few years, her family really saw her health declining. She needs more and more medicine and has dementia on top of that, so she also regularly forgets to take them. That is why they applied for home care. Now, someone comes to visit Betty every day to check on her and help her with tasks that she cannot do herself anymore. The home care helps with cleaning, picks up medication from the pharmacy, helps with managing Betty’s agenda, makes sure she takes her pill on time and whatever she needs besides that.
Samantha
Samantha (31) works in a pharmacy in Eindhoven, she has worked there for 5 years and loves to interact with her regular customers, who are primarily elderly patients. During the Covid-19 outbreak Samantha is worried about how some of these patients are collecting their medication, as many of them have serious medical conditions. Sometimes family members come in to collect it but some elderly patients do not have any family to help them with this task and so they come to the pharmacy themselves. This is particularly worrying because recently the pharmacies have been extremely full as people have begun to panic and buy more medication than usual, and it is difficult to maintain social distance within the pharmacy, leaving the elderly at a higher risk for infection. Samantha believes that the pharmacies should be decongested, both for her and her colleagues safety and her patients. She is willing to try out new techniques to make this possible.
Scenario (key words)
In the pharmacy where Samantha works the robot delivery service is used for some time now. At the beginning of her day, Samantha checks the deliveries for today in her app and fills the coloured drawers with the right medication. The information in the database tells her exactly which medication goes in which compartment, such that each customer get the right medicaiton. The best route is also already calculated by an algorithm, so Samantha and her colleagues have nothing to worry about. When all the compartments for the first delivery are filled, she sends robot on its way, so she has plenty of time for other clients in the pharmacy.
Yesterday, David and Maria received a notification on their phone with a reminder that the robot would visit them today with their medicines. An hour ago, they received another message that the robot is on its way and is expected to be there at a certain time. When the robot arrives at David and Maria's house, they get another notification in their app. They like that they have one simple app in which they can find everything they need. A week ago, they used it to place a new order (of which they were reminded by the app) and they could even change their prefered time slot up to 24 hours in advance. Now that the robot is here, they open the door and the robot says “Hello, good morning! I have your delivery for today. Please enter your unique code”. They open the app and press the button for the code. They enter the code, but it turns out to be wrong. A cross appears on the screen and the robot tells them “Sorry, I’m afraid that is not the correct code, please try again”. They enter it again, and this time it is correct. One time, when they filled in the wrong one three times in a row What happens then? Need to decide on that. Also need to decide if only one code (ownership), or also another one as verification (knowledge) The correct door automatically opens and they get the drawer out. They retrieve their medication and put the drawer back in the robot. The robot wishes them a good day and leaves.
Tom is going to Betty after he received a message in his app that the robot is on its way. With the track and trace feature, he is sure that he is there on time
- When robot arrives, he gets message and follows all the steps (OTP, password/birth date, retrieve medication)
- He helps Betty take her medication for today
- In his app, he checks if the next delivery is already planned and if all the data is correct
- He changes the time window
- Robot goes back to pharmacy after delivered everything
Requirements engineering
Using the stakeholder’s needs that were gathered during the interviews a set of system requirements was constructed. The requirements are semi-formal and are written following the syntax defined in the ISO 29148 standard [32]. When defining such requirements it was ensured that they were consistent, complete and practically feasible. They are therefore directly traceable to the stakeholder’s needs.
The delivery system is composed of three identifiable subsystems: the application from the viewpoint of the pharmacist, the application from the viewpoint of the caretaker, the robot’s compartment system. For each one of these subsystems different requirements were defined. It can be noticed that none of these subsystems is directly managed by the elderly. Indeed, from the needs that were gathered throughout the interview, it became clear that the elderly were not inclined to interact with the system using an application, or any type of software. Therefore the application from the user viewpoint will be used, if possible, by the assigned caretaker and for the latter will be designed. To define the actions the elderly must follow to subscribe to the delivery service, generate a password and, if independent, plan the deliveries a protocol, instead, was defined. In this section however only the requirements of the software and hardware components of the system are analyzed.
Pharmacist’s application
The system in this case is the pharmacist’s application. The application should be able to communicate with a database containing the customer's details and medication’s needs to retrieve the required information and reserve a compartment of the robot for a specific customer.
To clarify the actors that are involved with the system we include a list of actors with their goal:
- Pharmacist: fill the robot’s compartment with the correct medicines.
- Patients database: hold the details and medication’s list for each patient.
- Delivery Robot: reserve a compartment for a specific patient.
To define precisely the requirements is helpful to also identify the inputs and outputs. We use the interpretation that inputs are received from the actors and outputs are sent to the actors.
| Inputs | Outputs | |||||
|---|---|---|---|---|---|---|
| ID | Name | Rational | ID | Name | Rational | |
| IN-P01 | inPatientID | Receive patient details identifiers from pharmacist | OUT-P01 | outQuerySend | Query the database for the patient details. | |
| IN-P02 | inQueryResponse | Receive patient details from database | OUT-P02 | outAvailable | Message to the robot asking which compartments are still available. | |
| IN-P03 | inAvailableP | Receive request to display available compartments from pharmacist. | OUT-P03 | outReserve | Send a message containing the patient information and the desired compartment to the robot for a compartment reservation. | |
| IN-P04 | inAvailableR | Receive a list of the available compartments from the robot. | OUT-P04 | outOpen | Send a request to open a compartment to the robot. | |
| IN-P05 | inReserve | Receive request to reserve a compartment for a specific user from the pharmacist. | OUT-P05 | outClose | Send a request to close a compartment to the robot. | |
| IN-P06 | inOpen | Receive request to open a compartment from the pharmacist. | OUT-P06 | outDepart | Send a request to start the delivery to the robot. | |
| IN-P07 | inClose | Receive request to close a compartment from the pharmacist. | OUT-P07 | outUpdate | Send a message to the database containing the updated customer information (which medicines have been delivered for example). | |
| IN-P08 | inDepart | Receive request to start the delivery from the pharmacist. | OUT-P08 | outPatientDelivery | Send patient details update regarding the delivery date and time to the database. | |
| IN-P09 | inCompleted | Receive signal indicating the completion of a delivery from the robot. | OUT-P09 | outLock | Send a request to lock a compartment to the robot. | |
| IN-P10 | inPatientDelivery | Receive patient details update regarding the delivery date and time from the pharmacist. | OUT-P10 | outUnlock | Send a request to unlock a compartment to the robot. | |
Following are the requirements for this system, which are identified by a unique identifier. Furthermore each requirement has a source indicating from which need it originated.
- R-P1 The application shall display a list of the patients subscribed to the delivery service which is ordered by the date the patient must receive the delivery
Source: Needs 6, 18, 19, 25, 29. - R-P2 When inPatientID is received from the pharmacist, the application shall send outQuerySend to the database within 0.2 s.
Source: Needs 29. - R-P3 When inQueryResponse is received from the database, the application shall display the patient’s details within 0.2 s.
Source: Needs 29. - R-P4 When inAvailableP is received from the pharmacist, the application shall send the message outAvailable to the robot within 0.2 s.
Source: Needs 21. - R-P5 When inAvailableR is received from the robot, the application shall display the available compartments within 0.2 s.
Source: Needs 21, 25. - R-P6 When inReserve is received from the pharmacist, the application shall send the message outReserve to the robot within 0.2 s.
Source: Needs 3, 21. - R-P7 When inOpen is received from the pharmacist, the application shall send the signal outOpen to the robot within 0.2 s.
Source: Needs 3, 21, 25. - R-P8 When inClose is received from the pharmacist, the application shall send the signal outClose to the robot within 0.2 s.
Source: Needs 3, 21, 25. - R-P9 When inDepart is received from the pharmacist, the application shall send the signal outDepart to the robot within 0.2 s.
Source: Needs 6, 22, 25, 27. - R-P10 When inCompleted is received from the robot, the application shall send the message outUpdate to the database within 0.2 s.
Source: Needs 27, 29. - R-P11 When inPatientDelivery is received from the pharmacist, the application shall send outPatientDelivery to the database within 0.2 s.
Source: Needs 6, 18, 20, 22. - R-P12 When the pharmacist requests to lock a compartment, the application shall send outLock to the robot within 0.2 s.
Source: Needs 3. - R-P13 When the pharmacist requests to unlock a compartment, the application shall send outUnlock to the robot within 0.2 s.
Source: Needs 3.
Caretaker’s application
The system in this case is the caretaker’s application. The application should be able to communicate with a database containing the customer's details and medication’s needs to update specific information like desired time for the delivery and notify the caretaker when the robot arrived at destination.
Actors with their goal:
- Caretaker: track the delivery and add patient delivery details.
- Patients database: hold the details and medication’s list for each patient.
- Delivery robot: deliver the medicine to the patient.
- Pharmacist: make sure that the elderly is able to retrieve the medication.
At this moment the application is mostly a tool to track the delivery. Because it doesn’t yet need to offer many important functionalities the inputs and outputs are not specified as that would be too technical. Is important however to specify that the tracking functionality does not yet offer the possibility to monitor the robot step by step during its rute. Indeed the requirements only focus on specifying the delivery method of the delivery system not the routing. Therefore what here is meant by tracking is simply notifying the caretaker when the medicine arrived.
Following are the requirements for this system, which are identified by a unique identifier. Furthermore each requirement has a source indicating from which need it originated.
- R-C1 When the caretaker updates the delivery date and time, the application shall send a message to the database to update its information only if the current delivery has terminated or does not start for at least two hours.
Source: Needs 15, 18, 20, 22, 27. - R-C2 When the caretaker requests to visualize the patient details, the application shall display the patient information, containing which prescriptions have been already delivered for the current period and which not, within 0.2 s.
Source: Needs 14, 29. - R-C3 When the robot arrives at the patient’s home, the application shall display a notification indicating the arrival within 0.2 s.
Source: Needs 7. - R-C4 When the robot departs from the pharmacy, the application shall display a notification indicating the departure and the content of the delivery within 0.2 s.
Source: Needs 7. - R-C5 If the caretaker indicates that the password is lost, the application shall send a message to the pharmacist requesting the password within 0.2 s.
Source: Needs 17.
Robot’s compartment system
The system in this case is the robot’s compartment system. This part represents the delivery robot, more specifically its delivery method. Further on the robot’s compartment system will be simply referred to as the robot, it is therefore important to remember that the requirements that we engineered specify only the behavior of the delivery method, not of a complete functionality of a delivery robot. The robot should be able to communicate with the application for the pharmacist to retrieve patient’s details and reserve compartments and with the application for the caretaker to track the delivery.
The list of actors with their goal is extended to include sensors and other hardware components:
- Pharmacist: fill the robot’s compartment with the correct medicines.
- Patients: elderly that needs to retrieve their prescription medicine.
- Caretaker: track the delivery for a specific patient.
- Position sensor: detects when the robot arrived at a delivery destination. Because we are not interested in developing a moving robot the position sensor is simply a time sensor that sends an input (signaling the arrival to a destination) after a set amount of time from the delivery departure.
- Memory: keep track of which compartment is assigned to which patient and the details needed for the authentication.
- Keyboard: collect the password of a compartment from the environment (patients).
- Device communicator: send and receive signals from the pharmacist’s and caretaker’s apps, which are running on another device.
- Bell: device used to notify the elderly of the arrival of the robot. At this point of the development process is yet not defined if it is an alarm or simply a device communicator that sends an sms.
- Compartment: can open, close and lock the compartment.
- Compartment sensor: checks if the compartment is empty.
In this case it is again necessary to also identify the inputs and outputs. We use the interpretation that inputs are received from the actors and outputs are sent to the actors.
| Inputs | Outputs | |||||
|---|---|---|---|---|---|---|
| ID | Name | Rational | ID | Name | Rational | |
| IN-R01 | inAvailable | Corresponding to OUT-P02, is a message received by the device communicator requesting which compartments are still available. | OUT-R01 | outAvailable | Corresponding to IN-P04, is a message sent by the device communicator indicating which compartments are still available. | |
| IN-R02 | inReserve | Corresponding to OUT-P03, is a message received by the device communicator requesting to reserve a compartment and containing the patient’s details. | OUT-R02 | outOpen | Send a message to a compartment requesting to open the compartment. | |
| IN-R03 | inOpen | Corresponding to OUT-P04, is a message received by the device communicator requesting to open a compartment. | OUT-R03 | outClose | Send a message to a compartment requesting to close the compartment. | |
| IN-R04 | inClose | Corresponding to OUT-P05, is a message received by the device communicator requesting to close a compartment. | OUT-R04 | outDepart | Send a message to the device communicator to indicate to the caretaker that the delivery departed. | |
| IN-R05 | inDepart | Corresponding to OUT-P06, is a message received by the device communicator requesting to start the delivery. | OUT-R05 | outArrived | Send a message to the device communicator to indicate to the caretaker that the delivery arrived. | |
| IN-R06 | inArrived | Receives a signal from the position sensor indicating the robot arrived at the delivery destination. | OUT-R06 | outDest | Send a message to the memory indicating that the medicine has been delivered at the current destination. | |
| IN-R07 | inDest | Receives a message from the memory indicating which is the next destination. | OUT-R07 | outBell | Send a signal to the bell to notify the patient of the arrival of the robot. | |
| IN-R08 | inPasswod | Receives an input from the keyboard indicating which password has been imputed by the patient. | OUT-R08 | outLock | Send a message to a compartment requesting to lock the compartment. | |
| IN-R09 | inLock | Corresponding to OUT-P09, is a message received by the device communicator requesting to lock a compartment. | OUT-R09 | outUnlock | Send a message to a compartment requesting to unlock the compartment. | |
| IN-R10 | inUnlock | Corresponding to OUT-P10, is a message received by the device communicator requesting to unlock a compartment. | ||||
| IN-R11 | inNoResponse | Is a message received by the position sensor (remember the latter is really only a time sensor) when the robot has arrived at the destination but no password has been tried for five minutes. | ||||
| IN-R12 | inEmpty | Signal received from the compartment sensor indicating the compartment is empty. | ||||
Following are the requirements for this system, which are identified by a unique identifier. Furthermore each requirement has a source indicating from which need it originated.
- R-R1 The compartment on the robot shall be each identified by a different number and a different color.
Source: Needs 21. - R-R2 When a medicinine is placed in a compartment, the robot shall ensure that the medicine does not gain or lose more than a 1℃ for at least 5 hours.
Source: Needs 10, 23. - R-R3 When inAvailable is received from the device communicator, the robot shall send outAvailable to the device communicator within 0.2 s.
Source: Needs 21. - R-R4 When inReserve is received from the device communicator, the robot shall save in the memory the details of the patient and the assigned compartment within 0.2 s.
Source: Needs 3, 21. - R-R5 When inOpen is received from the device communicator, the robot shall send outOpen to the requested compartment within 0.2 s.
Source: Needs 3, 21. - R-R6 When inClose is received from the device communicator, the robot shall send outClose to the requested compartment within 0.2 s.
Source: Needs 3, 21. - R-R7 When inLock is received from the device communicator, the robot shall send outLock to the requested compartment within 0.2 s.
Source: Needs 3, 21. - R-R8 When inUnlock is received from the device communicator, the robot shall send outUnlock to the requested compartment within 0.2 s.
Source: Needs 3, 21. - R-R9 When inDepart is received from the device communicator, the robot shall send outDepart to the device communicator within 0.2 s.
Source: Needs 6, 15, 22, 27. - R-R10 When inArrived is received from the position sensor, the robot shall send outArrived to the device communicator within 0.2 s.
Source: Needs 6, 15, 22, 27. - R-R11 When inDest is received from the memory, the robot shall send outDepart to the device communicator within 0.2 s.
Source: Needs 6, 15, 22, 27. - R-R12 When inPassword is received from the keyboard, the robot shall send outUnlock and outOpen to the specific compartment only if the password is correct.
Source: Needs 3, 5. - R-R13 When inArrived is received from the position sensor, the robot shall send outBell to the bell within 0.2 s.
Source: Needs 7. - R-R14 When inEmpty is received from the compartment sensor and the compartment is open, the robot shall send outClose and outLock to the compartment within 0.2 s.
Source: Needs 1. - R-R15 When inNoResponse is received from the position sensor, the robot shall send a notification to the pharmacist and the caretaker (through the device communicator) within 0.2 s.
Source: Needs 8, 16. - R-R16 When inPassword has been received from the keyboard and inEmpty has been received from the compartment sensor, the robot shall send outDest to the memory within 0.2 s.
Source: Needs 20, 27. - R-R17 The robot shall have drawn the pharmacy symbol over its structure.
Source: Needs 9.
Use case diagrams
Security Requirements
Access control policy
The access control policy[33] captures the meaning of the intended high level policy by somehow specifying who (subject) is trusted with which resource (object) to do what (allowed actions).
- The pharmacist maintains a database containing the information about the elderly subscribed to the delivery system (with also the delivery dates and times).
- Doctors can add, remove and modify the information about the elderly subscribed to the system (but not the delivery dates and times).
- The elderly can read only the information about themselves.
- The elderly can modify the delivery times and dates regarding their deliveries.
- The elderly can read their compartment’s password when the delivery departs.
- The pharmacist reads and sets the compartment’s passwords for each delivery.
- The caretaker can read only the information about the elderly they look after.
- The caretaker can modify the delivery times and dates regarding the deliveries of the elderly they look after.
- The caretaker can read the compartment’s password when a delivery for the elderly they look after departs.
Role Based Access Control Matrix
The different high level policies can be expressed in terms of rights that users within a certain role have. The role based access control matrix gives a simple specification of the access control policy. In this matrix there is a row for each role and a column for each resource. This results in a field for each combination of a role and a resource. The rights that that the subject has on that resource, i.e. allowed actions, are filled in this field.
| Role \ Resource | Elderly details | Password | Date and time delivery |
|---|---|---|---|
| Pharmacist | Read | Read/Write | Read/Write |
| Doctor | Read/Write | No access | Read |
| Elderly | Read | Read | Read/Write |
| Caretaker | Read | Read | Read/Write |
Authentication
We previously defined the access control policies with roles different users could take. However a role is just an example of a property (or attribute) of a user, to which we might link a right to. Using the concept of attribute, the NIST (The National Institute of Standards and Technology (NIST), a US federal institute) electronic authentication guide[34] defines an identity as:
An identity is a set of attributes that uniquely describe a person within a given context.
In our delivery system when the robot arrives at the target delivery house, the system must have two processes that derive from the definition above: identification (finding the identity of the user) and authentication (proving that the user indeed belongs to a claimed identity). The first process can be implemented by asking the user to insert a username, for example, or the identity can be automatically deduced from the target delivery information contained in the system. Regarding the second processes, instead, our system needs to perform two types of authentications: a first more general type regarding how the user is going to open a compartment (compartment authentication) and a second type more e-authentication regarding how users can connect to the database and prove their identity (database authentication).
Compartment authentication
[MOVE HERE PART OF LOCK SYSTEM SECTION]
Database authentication
The first phase of the e-identification is a registration process. For example the doctor can issue some credentials that link the user’s identity (attributes) to tokens (things the applicant controls), or the database provider can issue the credentials and tokens for the pharmacists.
In the next phase a claimant tries to authenticate to a verifier. To do that the users must show control over the tokens and the corresponding credentials then establish their identity.
Different e-authentications systems have different levels of assurance. The NIST guidelines[34] introduce four levels:
- For Level 1, the lowest level, there is no need to check the identity during registration as such authentication at this level gives no guarantees about the identity itself, only some assurance that the same claimant is involved. While sending secrets or passwords on the network without any protection (i.e. ‘in plaintext’) is not permitted, strong cryptographic mechanisms are not required at this level.
- Level 2 introduces requirements for the registration; the applicant should show, which may be done remotely, possession of a valid ID number (e.g. from a passport, bank account, etc.). The information linked to this ID number is compared to the current ID application. For example the name in your passport is compared to the name you register under as a student. A single factor token for remote authentication, such as a password (what you know) or a card that does not require a pin to use (what you have), is sufficient.
- Level 3, multi-factor remote network authentication, requires that at least two authentication factors are used. This could be with a single token using multiple factors such as a card that requires a pin to use or the combination of multiple tokens such as a password and a card without pin. The information to be provided during registration remains the same but now the registration authority must verify the provided information (for example check the bank records against the provided account number).
- Level 4, the highest level, requires that registration is in person and using a primary, government issued ID (e.g. a passport) with a picture and a second ID (such as a verified bank account number). The registration authority must verify the primary ID at the issuer or at other reliable sources. Non-repudiation of the application must also be provided (e.g. by taking a photo or fingerprint of the applicant); the applicant should not be able to deny making the application. In the authentication phase strong cryptographic proofs using multiple factors are needed to demonstrate control over the token(s).
Because our system treats sensible information regarding its users and transports extremely important goods (prescription’s medicine), it will be developed towards an assurance level of 4.
Passwords
The delivery system will make use of a password to open the different compartments. An important requirement for the security of the system is that:
- The password should remain secret, and only known to the elderly.
In order to better specify this requirement is necessary to make use of the concept of entropy[33], which captures how hard a secret is to guess. If the entropy (expressed in the number of bits needed to represent the hidden information) is n then one needs on average half of 2n guesses to find the secret. Therefore a more specific password requirement is:
- Achieve an entropy where the attacker, if guessing, must try at least 50000 passwords to open the compartments and 100000 passwords to log in someone else's account within the database.
To combat weak passwords, furthermore, an extra requirement is:
- The password must be randomly generated.
Because the database needs to check the identity of the users connecting to it, a list of unprotected passwords might have to be stored in. However this makes the database an attractive target for an attacker. A commonly used solution to protect stored passwords is to only store the hashes of the passwords, not the passwords themselves. Hash functions produce a fixed size output for any length input and are one way (irreversible) and collision resistant[33] (hard to find inputs that give the same output). When a claimant provides a password the database hashes it and compares it with the hash value stored for the claimed identity. A well chosen hash is collision resistant and therefore this method is just as good as comparing the entry directly with the identity’s password. Therefore the last password requirement is:
- Save the hashes of the passwords in the database, rather than the unprotected passwords, for verification purposes.
Specifications
Total system overview
Classification users
Planning and time schedule optimization
The vehicle routing problem is studied a lot by different researchers. Usually, it is represented by weighted simple graph. The nodes are customers and the arcs the shortest paths computed according to a single criterion (like traveling cost, distance or traveling time). An alternative approach exists, which is multigraph representation [35]. This approach takes multiple attributes into account and can thus also plan the optimal route with operational constraints. A popular example of this is the Vehicle Routing Problem with Time Windows (VRPTW). Here, customer requests to deliver within a specific time window are satisfied and still the optimal route is found. This is, for example, really important with perishable products.[36] Some research is also done into path planning with Heterogeneous Multirobot Teams already. [37]
For our delivery robots, the multigraph representation seems to be a good approach. Users need to be able to indicate a prefered time window (just like with DHL/PostNL and other delivery services now), but it is not feasible to guarantee that delivery is at the exact same time every time. Of course the window can be indicated long before the actual delivery, so if it is a regular customer, this window can be the same every time.
Pharmacy app
Appearance
Functionality
User app
Appearance
https://ieeexplore.ieee.org/abstract/document/8340033
https://link.springer.com/chapter/10.1007/978-3-319-59427-9_17
https://link.springer.com/chapter/10.1007/978-3-319-20892-3_49
Functionality
Robot compartment system
Appearance
Functionality
Approach
To achieve the objectives of the project five main parts of the development process have been defined: research, requirements analysis, specification analysis, implementation and testing. To better tackle each phase regular group meetings every week have been set. During these meetings the tasks for the current development processes phase are assigned to each team member.
Group organization
Each week a different group member occupies the position of chairperson. The responsibility of the chairperson is to establish an agenda before the meeting and mediate the discussion through the topics that are set in the agenda. Furthermore the chairperson must take the minutes of every meeting during that week and act as a representative of the group during the tutor meeting. The chairperson role rotates through the members in the team.
| Week 1 | Week 2 | Week 3 | Week 4 | Week 5 | Week 6 |
|---|---|---|---|---|---|
| Mijntje | Dajt | Danielle | Fabiènne | Lucia | Mijntje |
Development process
The first phase of the development processes of the project is the research. During the latter the literature is consulted to establish the state of the art. Moreover the problem statement is specified and the different stakeholders are analysed. A comprehensive plan is set to fix the deadlines of the other phases.
The second phase is the requirements analysis. This is a fundamental step of the development processes as the requirements will define the functionality of the project. A cost-benefit and risk assessment analysis will cover the requirements for every part of the project. The ethical evaluation will focus on the requirements for the application and the compartment system prototype, while the survey will focus on the requirements for the navigation simulation.
The third phase of the development processes is the specification analysis. During this phase the requirements are formalized using UML diagrams. The design of the user interface of the app is defined and the hypothetical maps that the delivery robots must navigate are designed in NetLogo.
The fourth phase is the implementation. The application code is written in Swift, creating an app compatible with devices supporting iOS, the hardware for the compartment system is assembled and the NetLogo program for the delivery simulation is written.
During the fifth and final phase of the development process the system is tested and a demo is finally created.
Planning
From the approach a plan for the development process was created. The plan is illustrated in the following figure using a Gantt table.
Task Division
During each development process phase the different task composing it are subdivided between the group members.
| Research | Requirements | Specification | Implementation | Testing | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Task | Group member | Task | Group member | Task | Group member | Task | Group member | Task | Group member | ||||
| Determining subject | All | Risk Assessment | ... | App Users | ... | App User | ... | Test system | ... | ||||
| Set up Wiki | Fabiènne | Cost-Benefit Analysis | ... | App enterprise | ... | App enterprise | ... | Make demo video | ... | ||||
| Approach | Dajt, Danielle | Ethical perspective | ... | Robot compartment system | ... | Robot compartment system | ... | Update Wiki | ... | ||||
| Planning | Fabiènne, Dajt | Make survey | ... | Navigation | ... | Navigation system | ... | ||||||
| Literature search | All | Analyse data survey | ... | Update Wiki | ... | Update Wiki | ... | ||||||
| Introduction | Mijntje, Fabiènne, Dajt | Update Wiki | ... | ||||||||||
| State of the Art | Lucia, Mijntje | ||||||||||||
| Stakeholder analysis | Danielle | ||||||||||||
| Update Wiki | Fabiènne, Danielle, Dajt | ||||||||||||
Milestones
By the end of week 2 the problem statement, introduction, stakeholder analysis and state of the art must be completed. This will conclude the research phase.
By the end of week 3 the survey on people’s attitudes towards our proposal and delivery robots in general, the risk assessment, and different analysis must be completed. This will conclude the requirements phase.
By the end of week 4 the analysis/conclusions of the survey and a semi-formal model of the system must be completed. This will conclude the specification phase.
By the end of week 6 the first implementation of the apps, lock system and navigation system must be completed. This will conclude the implementation phase.
By the end of week 7 the adjusted version of the apps (after testing/interviewing) and a demo video must be completed. This will conclude the testing phase.
Deliverables
The final product will be a system to distribute/deliver medicine to those in need (elderly in most cases), including:
- An application with the choice to log in as a user to order medicine and open the compartments of the delivery robot or as the pharmacist/hospital/doctor/distributor to set the passwords for the compartments and the targets the delivery robot must visit.
- A hardware system to secure and open the compartments, which can communicate with the application.
- A NetLogo program in which an agent, representing a delivery robot, finds the shortest path among multiple targets within an environment modelling the map of a city or an indoor environment, for example an ICU.
Logbook
Week 1
| Name | Total hours | Tasks |
|---|---|---|
| Danielle | 3.5 | Introduction lecture [1.5], meeting [0.5], literature research (source 5-11) [1.5] |
| Lucia | 3 | Introduction lecture [1.5], meeting [0.5], literature research (source 22-26) [1] |
| Mijntje | 3 | Introduction lecture [1.5], meeting [0.5], literature research (source 18-21) [1] |
| Dajt | 3.5 | Introduction lecture [1.5], meeting [0.5], literature research (source 14-18) [1.5] |
| Fabiènne | 4 | Introduction lecture [1.5], meeting [0.5], literature research (source 1-4, 11-13) [1.5], wiki page [0.5] |
Week 2
| Name | Total hours | Tasks |
|---|---|---|
| Danielle | 7.5 | Meeting [2], images (Approach/Stakeholder) [1.5], stakeholder analysis [2], update wiki [0.5], tutor meeting [0.5], interview questions [0.5], informed consent editing [0.5] |
| Lucia | 8 | Meeting [2], state of the art [5], hardware research [0.5], tutor meeting [0.5] |
| Mijntje | 9.5 | Meeting [2], state of the art [7], tutor meeting [0.5] |
| Dajt | 9 | Agenda [0.5], meeting [2], approach [2], planning (tables) [2.5], problem statement [0.5], update wiki [1], tutor meeting [0.5] |
| Fabiènne | 8 | Meeting [2], literature research (source 27-30) [0.5], planning [0.5], references [1.5], update wiki [2], tutor meeting [0.5], contacting people to interview [0.5], interview questions [0.5], informed consent forms [0] |
Week 3
| Name | Total hours | Tasks |
|---|---|---|
| Danielle | 9.5 | Contacting pharmacists [1.5], conducting interviews [3.5], transcribing interviews [1.5], update wiki [0.5], meeting [1], tutor meeting [0.5], summarize needs interviews [1] |
| Lucia | 5 | Meeting [1], tutor meeting [0.5], conducting interview [1], transcribing interview [0.5], summarize findings [0.5], contacting pharmacists-to-be [0.5], research compartments [1] |
| Mijntje | 1.5 | Meeting [1], tutor meeting [0.5], due to illness no other work done |
| Dajt | 9.5 | Meeting [1], tutor meeting [0.5], contacting elderly and caretakers [1.5], conducting interviews [5], transcribing interviews [1.5] |
| Fabiènne | 12.5 | Preparation interviews [0.5], conducting interviews [2], transcribing interviews [3], update wiki page [2], meeting [1], tutor meeting [0.5], summarize needs interviews [1], research lock system [1.5], research cognitive classification [1] |
Week 4
| Name | Total hours | Tasks |
|---|---|---|
| Danielle | 9.5 | Tutor meeting [0.5], meeting [1.5], ethical analysis [4], appearance [2], personas [0.5], research [1] |
| Lucia | 10 | Tutor meeting [0.5], meeting [1.5], requirements design and hardware engineering [6], research tracking [2] |
| Mijntje | 10.5 | Tutor meeting [0.5], meeting [1.5], classification responsibility [3], appearance [1.5], research GP - pharmacist system [2.5], reading others material [1.5] |
| Dajt | 11 | Tutor meeting [0.5], meeting [1.5], security research [2], requirements engineering [5], needs [1], update wiki [1] |
| Fabiènne | 10.5 | Tutor meeting [0.5], agenda [1], meeting [1.5], personas [0.5], update wiki page [2], lock system [2.5], route planning/optimizations [1.5], scenario [1] |
Week 5
| Name | Total hours | Tasks |
|---|---|---|
| Danielle | 12.7 | Tutor meeting [0.7], meeting [1], overview decisions [1.5], research into password system [1], research database [3.5], creating database [3], Programming User App [2] |
| Lucia | 9.2 | Tutor meeting [0.7], meeting [1], consulting users [1], research lock system [6], meeting with Mijntje about lock system [0.5] |
| Mijntje | 11.7 | Tutor meeting [0.7], meeting [1], overview decisions [1], consulting users [1.5], prototypes lock system [1], prototypes complete robot [4], Research Database responsibility [2], meeting with Lucia about lock-system [0.5] |
| Dajt | 12.3 | Tutor meeting [0.7], meeting [1], overview decisions [1.5], consulting users [1.5], security [2], user case diagrams [1.5], Programming Pharmacist App [4] |
| Fabiènne | 11 | Tutor meeting [0.7], meeting [1], overview opinions [1.3], consulting users [2], research dimensions [2], read other materials [1.5], update wiki [1], user app UI [1.5] |
Week 6
| Name | Total hours | Tasks |
|---|---|---|
| Danielle | 1.2 | Meeting [0.7], tutor meeting [0.5] |
| Lucia | 1.7 | Meeting [0.7], tutor meeting [0.5], meeting with Ruud vd Bogaert [0.5] |
| Mijntje | 1.7 | Meeting [0.7], tutor meeting [0.5], meeting Fabiènne user app UI [0.5] |
| Dajt | 1.2 | Meeting [0.7], tutor meeting [0.5] |
| Fabiènne | 4.8 | Meeting [0.7], tutor meeting [0.5], update wiki [0.5], flats/doors problem [0.5], capacity [0.1], meeting Mijntje user app UI [0.5], user app UI [1.5], test user app (+ prep) [0.5] |
Week 7
| Name | Total hours | Tasks |
|---|---|---|
| Danielle | ... | ... |
| Lucia | ... | ... |
| Mijntje | ... | ... |
| Dajt | ... | ... |
| Fabiènne | ... | ... |
Week 8
| Name | Total hours | Tasks |
|---|---|---|
| Danielle | ... | ... |
| Lucia | ... | ... |
| Mijntje | ... | ... |
| Dajt | ... | ... |
| Fabiènne | ... | ... |
Week 9
| Name | Total hours | Tasks |
|---|---|---|
| Danielle | ... | ... |
| Lucia | ... | ... |
| Mijntje | ... | ... |
| Dajt | ... | ... |
| Fabiènne | ... | ... |
References
- ↑ Holstein, B. (2020). Coronavirus 101. The Journal for Nurse Practitioners : Jnp, 2020 Apr 10. https://doi.org/10.1016/j.nurpra.2020.03.021
- ↑ 2.0 2.1 Okyere, M. A., Forson, R., & Essel-Gaisey, F. (2020). Positive Externalities of an Epidemic: The Case of the Corona Virus (COVID-19) in China. Journal of Medical Virology, 1–4. https://doi.org/10.1002/jmv.25830
- ↑ Skorup, B., & Haaland, C. (2020). How drones can help fight the coronavirus. Ssrn Electronic Journal, (2020). https://doi.org/10.2139/ssrn.3564671
- ↑ Peleato, F., Prabakar, M., & Kim, J.-H. (2013). Smart Global Positioning System for Autonomous Delivery Robots in Hospitals. 2013 29th Southern Biomedical Engineering Conference. doi: 10.1109/sbec.2013.79
- ↑ Summerfield, M. R., Seagull, F. J., Vaidya, N., & Xiao, Y. (2011). Use of pharmacy delivery robots in intensive care units. American Journal of Health-System Pharmacy, 68(1), 77–83. doi: 10.2146/ajhp100012
- ↑ 6.0 6.1 de Groot, S. (2019).
- ↑ 7.0 7.1 Frachtenberg, E. (2019). Practical drone delivery. Computer, 52(12), 53–57.
- ↑ Bärtschi, A., Chalopin, J., Das, S., Disser, Y., Geissmann, B., Graf, D., … Mihalák, M. (2016). Collaborative Delivery with Energy-Constrained Mobile Robots LK - https://tue.on.worldcat.org/oclc/8087243524. In TA - TT -. Springer SE -.
- ↑ 9.0 9.1 N. Nishino, R. Tsugita, D. Chugo, S. Yokota, S. Muramatsu and H. Hashimoto (2016). Robot navigation according to the characteristics of pedestrian flow. IECON 2016 - 42nd Annual Conference of the IEEE Industrial Electronics Society, 5947-5952.
- ↑ K. Song et al. (2018). Navigation Control Design of a Mobile Robot by Integrating Obstacle Avoidance and LiDAR SLAM. IEEE International Conference on Systems, Man, and Cybernetics (SMC), 1833-1838.
- ↑ Kummerle, R., Ruhnke, M., Steder, B., Stachniss, C., Burgard, W., & 2013 IEEE International Conference on Robotics and Automation, ICRA 2013 Karlsruhe, DEU 2013 05 06 - 2013 05 10. (2013). A navigation system for robots operating in crowded urban environments. Proceedings - Ieee International Conference on Robotics and Automation, 3225-3232, 3225–3232. https://doi.org/10.1109/ICRA.2013.6631026
- ↑ Berbeglia, G., Cordeau Jean-François, Gribkovskaia, I., & Laporte, G. (2007). Static pickup and delivery problems: a classification scheme and survey. Top, 15(1), 1–31.
- ↑ Hada, Y., Takase, K., Gakuhari, H., & Herneldan, E. (2004). Delivery service robot using distributed acquisition, actuators and intelligence. IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS) (IEEE Cat. No.04CH37566). doi: 10.1109/iros.2004.1389865
- ↑ Freehill-Maye, L. (2019). The delivery drivers. Foodservice Director, 32(12), 30–30.
- ↑ Redman, R. (2019). Walmart, target, walgreens to pilot fedex delivery robot. Supermarket News, (feb 28, 2019).
- ↑ Costelloe, K. (2019). Amazon selects irvine for scout robot delivery. Orange County Business Journal, 42(33), 4–4.
- ↑ K, L. N., Kumaran, D. N. M., G, R., Arshadh, H., I, D., & V, C. (2019). Design and fabrication of medicine delivery robots for hospitals. Ssrn Electronic Journal, (2019). https://doi.org/10.2139/ssrn.3432156
- ↑ Ranft, B., & Stiller, C. (2016). The role of machine vision for intelligent vehicles. Ieee Transactions on Intelligent Vehicles, 1(1). https://doi.org/10.1109/TIV.2016.2551553
- ↑ J. Kim, Y. Kim, J. Kwak, D. Hong and J. An (2010). Wheel & Track hybrid robot platform for optimal navigation in an urban environment, Proceedings of SICE Annual Conference 2010, 881-884.
- ↑ 20.0 20.1 Kyriakidis, M., Happee, R., & de Winter, J. C. F. (2015). Public opinion on automated driving: results of an international questionnaire among 5000 respondents. Transportation Research Part F: Psychology and Behaviour, 32, 127–140. https://doi.org/10.1016/j.trf.2015.04.014
- ↑ Jarotwan, K. (2018). Analysis of environmental impacts of drone delivery on an online shopping system. Advances in Climate Change Research, 9(3), 201–207. https://doi.org/10.1016/j.accre.2018.09.001
- ↑ Io, H. N., Lee, C. B., & 2019 IEEE International Conference on Industrial Engineering and Engineering Management, IEEM 2019 2019 12 15 - 2019 12 18. (2019). What are the sentiments about the autonomous delivery robots. Ieee International Conference on Industrial Engineering and Engineering Management, 50-53, 50–53. https://doi.org/10.1109/IEEM44572.2019.8978921
- ↑ Simmons, R., Goodwin, R., Haigh, K. Z., Koenig, S., & Sullivan, J. O. (1996). A Layered Architecture for O ce Delivery Robots.
- ↑ Marks, M. (2019). Robots in Space: Sharing Our World with Autonomous Delivery Vehicles. SSRN Electronic Journal. doi: 10.2139/ssrn.3347466
- ↑ Hoffmann, T., & Prause, G. (2018). On the regulatory framework for last-mile delivery robots. Machines, 6(3), 33–33. https://doi.org/10.3390/machines6030033
- ↑ T. Beauchamp and J. Childress, Principles of Biomedical Ethics. New York: Oxford Univ. Press, 2001.
- ↑ D. Feil-Seifer and M. J. Matarić, "Socially Assistive Robotics," in IEEE Robotics & Automation Magazine, vol. 18, no. 1, pp. 24-31, March 2011, doi: 10.1109/MRA.2010.940150.
- ↑ T. Beauchamp and J. Childress, Principles of Biomedical Ethics. New York: Oxford Univ. Press, 2001
- ↑ A. Tapus, C. Tapus, and M. Mataric, “The use of socially assistive robots in the design of intelligent cognitive therapies for people with dementia,” in Proc. Int. Conf. Rehabilitation Robotics (ICORR-09), Kyoto, Japan, June 23–26, 2009, pp. 924–929.
- ↑ S. Turkle, “Relational artifacts/children/elders: The complexities of cybercompanions,” in Proc. COGSCI 2005 Workshop Toward Social Mechanisms of Android Science. Stresa, Italy, July 2005, pp. 62–73.
- ↑ D. Feil-Seifer and M. J. Matarić, "Socially Assistive Robotics," in IEEE Robotics & Automation Magazine, vol. 18, no. 1, pp. 24-31, March 2011, doi: 10.1109/MRA.2010.940150.
- ↑ ISO/IEC 9126-1:2001 Software Engineering | Product Quality | Part 1: Quality Model. ISO/IEC, 2001. https://www.iso.org/standard/22749.html
- ↑ 33.0 33.1 33.2 https://www.win.tue.nl/~tozceleb/2IC60/lecture_notes.pdf
- ↑ 34.0 34.1 William E. Burr, Donna F. Dodson, Elaine M. Newton, Ray A. Perlner, W. Timothy Polk, Sarbari Gupta, and Emad A. Nabbus. Electronic authentication guideline. NIST Special Publication 800-63-2. https://doi.org/10.6028/NIST.SP.800-63-2
- ↑ Ben Ticha, H., Absi, N., Feillet, D., & Quilliot, A. (2017). Empirical analysis for the VRPTW with a multigraph representation for the road network. Computers & Operations Research, 88, 103–116. https://doi.org/https://doi.org/10.1016/j.cor.2017.06.024
- ↑ Wang, X., Sun, X., Dong, J., Wang, M., & Ruan, J. (2017). Optimizing Terminal Delivery of Perishable Products considering Customer Satisfaction. Mathematical Problems in Engineering, 2017, 8696910. https://doi.org/10.1155/2017/8696910
- ↑ Mathew, N., Smith, S. L., & Waslander, S. L. (2015). Planning Paths for Package Delivery in Heterogeneous Multirobot Teams. IEEE Transactions on Automation Science and Engineering, 12(4), 1298–1308. https://doi.org/10.1109/TASE.2015.2461213