PRE2019 4 Group5

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 , 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. These robots are already in use, in several situations, environments and forms. Furthermore, they are currently experimenting with these delivery robots for multiple purposes.

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. 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.

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. 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. 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. 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 . 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 . 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 . This system takes the type of roads into account, traversability and provides a method for localization in dynamic environments . 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 .

Coördination & object recognition

A method for coordination is iGPS, this is working with ceiling cameras . Another commonly used technique combination for coördination and object recognition is making use of artificial intelligence, ultrasonic sensors and cameras . 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 . 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 . Furthermore, there are also robots that are capable of recognizing and distinguishing between rooms , making use of intelligent machine vision .

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 . 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 .

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 . Also the environmental footprint raises discussions: drones are a relatively sustainable transportation method, but the production is not. 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.

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. 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.

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. 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. 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. 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.

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.

USE perspectives

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.

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 transciptions can be found here. Below, the main findings and conclusions regarding the most important features are summarized.

Practical

• Should be user friendly and understandable
• Delivery time should be known / tracked/ communicated / the same every time
• Routes and times should be calculated efficiently
• Notify user when arrived at location
• Cooled compartments
• Clear labels / sachets so medicine don't get swapped
• QR codes or notifications and tips through an application to give extra information
• Feedback from customers should be implemented
• Option to offer counselling (could be implemented through a chat function)

Safety

• Decide who is allowed to use this service / who should decide this?
• (In care home) way to monitor if people correctly take their meds
• A lock system that identifies the user (password/code/app/card)
• Alarm someone if something is wrong (door isn't opened)
• Don't drop medication on doormat (pets might eat it)

Appearence

• Human-like features (eyes / face) could be nice, but are no must
• A voice is appreciated
• Recognizable as belonging to pharmacy

Specifications

Lock system

Authentication

Security of information (or in our case medication) is one of the concerns that have kept organizations busy since the usage of the internet began to grow. Authentication ensures that a user is who they claim to be. A lot of preceding studies distinguish three types of authentication factors [ref1][ref2]:

• Knowledge-based factors (something you know)
• Possession-based factors (something you have)
• Biometric-based factors (something you are)

Some studies also acknowledge a fourth type:

• Somewhere you are / someone you know

Single factor authentication [ref2]

Examples of single factor authentication are possessing an ID card and swiping it to gain access into a facility or the traditional user-password scheme. The latter has the following features:

• Easy to implement
• Requires no special equipment
• Easy to forget
• Can be susceptible to shoulder surfing
• Security based on password strength
• Lack of identity check
• Cost of support increases

However, regarding security, there are some issues with this form of single factor authentication. There are a lot of rules to generate strong passwords, but this makes them a lot more difficult to remember. People write them down to remember them, which makes them way less secure. Therefore, multi-factor authentication might be the solution.

Multi-factor authentication [ref2]

Multi-factor authentication makes use of two or more of the factor categories (and not using multiple examples of the same factor). A well known example is inserting a credit card (something you own) and typing in the pin code (something you know). Another example that is used a lot (in E-banking or investment sectors) is the combination of a password (something you know) and a token (something you own). This is the concept of a One Time Password (OTP) and it is a lot less susceptible to cracking than a static password. Randomly choosing this OTP is very important, because predicting the new password would be too easy if it is not random. In addition, OTPs are too difficult to remember, so an additional type of technology is needed.

As a third factor, biometric authentication can be used. This can provide identification or verification. Examples are fingerprint recognition, face recognition, voice recognition and iris scan. It is easy to use, but generally still quite expensive. A big advantage is that it provides real evidence about the person's identity compared to passwords/knowledge/items that can be stolen.

The fourth factor (either somewhere you are or someone you know) is used a lot less often than the other three.

ref1: https://ieeexplore.ieee.org/abstract/document/6633936 ref2: https://link.springer.com/content/pdf/10.1007%2F978-3-642-31552-7.pdf (page 556-563)

Existing technologies

In a medicine delivery robot, one important aspect is a way to secure the boxes / compartments that contain the medication. Below, some of the existing technologies that use something comparable are listed.

DHL/PostNL Lockers

In 2017, the first DHL Lockers could be seen in the Netherlands . Instead of a delivery at your home, you can choose to let your package be delivered in one of their yellow lockers. In the Netherlands, there are 3000 DHL Locker points, so there is always one close to your house and they're accessible day and night. If you've sent your parcel to a locker, a unique code will be texted or emailed to you. With this code, you can open your locker. PostNL has a comparable service. Their orange lockers can also be used to send or receive parcels and can also be opened with a unique code (that gets send to you by email or SMS).

BENU pharmacies

BENU is one of the leading healthcare providers in the Netherlands. One service BENU pharmacies provides is the take out machine for all kinds of medication . The service is free, you don't have to wait in line when picking up medication and in most pharmacies it is possible to pick up medicine 24/7 when using this machine. The medicine can be achieved by entering a unique code (sent to you by SMS or e-mail) and your birth date for veryfication.

Keycards and digilocks

A number of companies specialized in digital locks for doors, vaults and other property . Add eleboration

Interviews

In the interviews with potential users, multiple options for the authentication were mentioned. One idea that a lot of people came up with was a simple password or (4-digit) code. This can be either a personal, static password or another password per delivery (in literature described as OTP). The advantages of one password for each user is that is is always the same and thus easy an not too confusing. On the other hand, it is easy to forget (although a bit less with a 4 digit code) and it is easy to crack and used by other people. An OTP is a lot more secure than a static password and entering it is still easy. It is already used in a lot of existing services and can be used by anyone who has email, a mailbox or a phone (so basically everyone). Drawbacks of an OTP is that an email can sometimes be hard to find, can end up in the spam folder, or can be deleted by accident. Physical mail can get lost or opened by the wrong person. Also, if a person gets a lot of deliveries, all the different messages with different passwords might get confusing.

One suggestion from a participant was to let the delivery robot ask a personal security question. The user could answer this questions, which would open the compartment. This seems very easy and intuitive, but turned out not to be preferred by some other interviewees. In addition, speech recognition might be more difficult to implement than other options and it would be a challenge to decide who sets the questions or to check if it’s secure enough.

According to a lot of participants, the use of a keycard for opening something is the easiest method of all. It is possible that someone loses it, but that happens less often than forgetting a password. The action is really simple and understandable for everyone. It is, however, more difficult and perhaps expensive to give every user their own keycard. If only regular clients can use this system, it would not be optimal, but implementing different systems within one robot would also quickly get costly.

Another way of opening secured compartments, currently already used in some delivery robots, is through an app on your smartphone. People had varying responses to this suggestion. Some thought it would be a really good option. Every person always has his phone nearby and even elderly use them quite often and know how to (up to a certain level). Other participants did not really like this idea, because they thought some (older) people really struggle with smartphones and would not be able to use the service optimally. Also, you would have a problem if the battery of your phone just died when the delivery is ready. One great benefit of using an app is that it has a lot more functionality than other options. In addition to having a function to open the compartment, it can contain a possibility to place new orders, to follow your current order, or to gain more information about your medication.

Conclusion (have to discuss about this within the group)

• two-factor necessary (wrong medicine can be disastrous + medication expensive)
• have to decide between
  • OTP + birth date (used in the machine that pharmacies already have)
  • Keycard + code (OTP?) / birth date
  • App + ? (OTP?)
  • digid login? (password + OTP)
  • Other ideas?
• If OTP, how communicate (SMS/email/physical mail (or own choice of user)
• If people are too old / confused to use email/SMS, maybe let caretaker handle this (see section on classification users)

Classification users

Participant 1 (care home)

Here, codes from 1 to 4 are used to indicate how much assistence people need with their medication. The codes are established by a nationwide medication safety policy.

Code 1. Completely independent, takes care of everything on their own

Code 2. Has the roll with medication in own management. Carers and/or pharmacy delivers roll weekly

Code 3. The medication is given per separate time

Code 4 The medication is given per separate time and carers make sure it is taken as well

With human insight, people working in the care home decide the code for every resident. People with cognitive problems usually have code 3 or 4. With code 1 or 2, the user is responsible for taking their medicine. With code 3 or 4 the carer is. For the content of the baxterrolls, the pharmacy and/or GP are responsible.

MMSE score

https://www.sciencedirect.com/science/article/pii/S0004951405700349

"The Mini-Mental State Exam (MMSE) is a brief test of cognitive impairment used widely to screen for dementia. The original test, developed by Folstein et al (1975), includes questions about orientation, attention, recall, and language. Galasko et al (1990) developed a shorter version of the test (Modified MMSE) that is as sensitive as the complete test.

A score of 23 out of a possible 30 is recommended as the cut-off score for dementia (Folstein et al 1975)."

CPS Score

Has an equivalent MMSE score

https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/NursingHomeQualityInits/Downloads/NHQIPAC_QM_Appendix2.pdf

The CPS scores range from 0 to 6, with 0 indicating intact cognitive function and 6 very severe impairment.

CPS_1 = Borderline intact;

CPS_2 = Mild impairment;

CPS_3 = Moderate impairment;

CPS_4 = Moderately severe impairment;

CPS_5 = Severe impairment;

CPS_6 = Very severe impairment.

Planning and time schedule optimization (keywords)

[ref1]

• Vehicle routing problem studied a lot
• Represented by weighted simple graph. Nodes are customers, arcs are shortest paths computed according to a single criterion (traveling cost, distance or traveling time).
• Alternative approach, multigraph representation (multiple attributes because operational constraints)
• Vehicle Routing Problem with Time Windows (VRPTW)
• Satisfy customer requests to deliver specific time window

For example really important with perishable products [ref2]

Research with Heterogeneous Multirobot Teams [ref3]

For our project:

• Users need to be able to indicate prefered time window (just like with DHL/PostNL/other delivery services now)
• 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)

ref1: https://www.sciencedirect.com/science/article/pii/S0305054817301636

ref2: https://www.hindawi.com/journals/mpe/2017/8696910/

ref3: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7194856

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.

Chairperson Rotation

Week 1	Week 2	Week 3	Week 4	Week 5	Week 6
Mijntje	Dajt	Danielle	Fabiènne	Lucia	Mijntje

Development process

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.

Gantt table of the planning

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 (Monday and Saturday) [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 (Monday and Saturday) [2], state of the art [5], hardware research [0.5], tutor meeting [0.5]
Mijntje	9.5	Meeting (Monday and Saturday) [2], state of the art [7], tutor meeting [0.5]
Dajt	9	Agenda [0.5], meeting (Monday and Saturday) [2], approach [2], planning (tables) [2.5], problem statement [0.5], update wiki [1], tutor meeting [0.5]
Fabiènne	8	Meeting (Monday and Saturday) [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	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 [0.5]
Lucia	...	...
Mijntje	1.5	Meeting [1], tutor meeting [0.5], due to illness no other work done
Dajt	...	...
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	1	Tutor meeting [0.5], meeting [0.5]
Lucia	1	Tutor meeting [0.5], meeting [0.5]
Mijntje	1	Tutor meeting [0.5], meeting [0.5]
Dajt	1	Tutor meeting [0.5], meeting [0.5]
Fabiènne	7	Tutor meeting [0.5], agenda [0.5], meeting [0.5], personas [0.5], update wiki page [1], lock system [2.5], route planning/optimizations [1.5]

Week 5

Name	Total hours	Tasks
Danielle	...	...
Lucia	...	...
Mijntje	...	...
Dajt	...	...
Fabiènne	...	...

Week 6

Name	Total hours	Tasks
Danielle	...	...
Lucia	...	...
Mijntje	...	...
Dajt	...	...
Fabiènne	...	...

Week 7

Name	Total hours	Tasks
Danielle	...	...
Lucia	...	...
Mijntje	...	...
Dajt	...	...
Fabiènne	...	...