PRE2015 4 Groep4: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
No edit summary
No edit summary
Line 342: Line 342:


=Possible issues=
=Possible issues=
-User walks too slow/robot goes too fast --> robot speeds up
-User walks too slow/robot goes too fast --> robot speeds up
-User is heading the wrong direction --> robot talks, if distance too large --> call reception
-User is heading the wrong direction --> robot talks, if distance too large --> call reception
-User wants to go to the toilet --> button on robot
-User wants to go to the toilet --> button on robot
-User walks in front of the robot, instead of behind --> robot talks, if distance too large --> call reception
-User walks in front of the robot, instead of behind --> robot talks, if distance too large --> call reception


limits --> limit1<limit2<limit3
limits --> limit1<limit2<limit3
if x<limit1 --> robot speeds up
if x<limit1 --> robot speeds up
if limit1<x<limit2 --> same speed
if limit1<x<limit2 --> same speed
if limit2<x<limit3 --> robot slows down
if limit2<x<limit3 --> robot slows down
if x>limit3 --> robot stops
if x>limit3 --> robot stops


robot has a velocity not larger than ...
robot has a velocity not larger than ...


turning light active, 1 second before actual turning
turning light active, 1 second before actual turning
braking light active, 1 second before actual braking
braking light active, 1 second before actual braking

Revision as of 14:53, 19 May 2016

Group 4 members

  • (Tim) T.P. Peereboom 0783677
  • (Marleen) M.J.W. Verhagen 0810317
  • (Willeke) J.C. van Liempt 0895980
  • (Victor) V.T.T. Lam 0857216
  • (Huub) H.W.J. van Rijn 0903068

Introduction

In large hospitals, elderly patients and visitors may have trouble reading or understanding the navigation signs. Therefore they may go to the information desk to request help from human caregivers. A more efficient alternative could be: robots that guide elderly patients/visitors safely to their destination in the hospital. In this way, human caregivers can have their hands free to help elderly with more serious problems that robots cannot solve, like helping elderly stand up when they fell over. Robots can guide elderly easily to their destination, when a map of the hospital is programmed into the robot. Even if the patient doesn't know what to do or where to go to, the robot gives clear instructions for example through touchscreen or speakers.

Scenario

An old man wants to visit his wife in the hospital. Due to the abbreviations of locations and his hunchback, he is having trouble with reading the signage, so he asks for help at the information desk. Here he is directed to a guiding robot. This robot carries a touch screen on eye level which asks the user to press "start". The man presses start and the robot asks him to put on the smart bracelet. This question is also displayed on the screen so people with hearing problems can understand the instructions too. The old man puts on the bracelet and presses "proceed". Now the robot asks where the man wants to go and the robot uses voice-recognition to indentify the user's destination. The robot guides the man trough the hospital to his destination. Because of the smart bracelet the robot can keep track of the distance between the user and the robot. When the distance gets too big, the robot will adjust its speed. When arrived at the destination the robot will ask the user if the desired location is reached. If so, the robot will leave the user. When the user wants to leave the hospital again, he can summon one using his smart bracelet. When a robot is finished with a guiding task, it will check if there are other people trying to summon a robot, otherwise it will go back to its base and recharge.

Requirements

  • The robot has to be able to reach each possible destination. Therefore it should be able to open doors and use elevators.
  • The robot should be easy to use. It should be easier and quicker figuring out how the robot works then trying to figure out how to get from A to B yourself.
  • The robot should be able to calculate the optimal route to the destination.
  • It should be clear for the patient that the robot is guiding the patient to the destination.
  • It should be easy to follow the robot.
  • The robot has to be able to detect if the patient is really following the robot.
  • The robot outputs clear visual and audible feedback to the user so the user is well informed about the robot understanding capability and what the user's next action should be.
  • The robots are able to track their location in the hospital.
  • The guiding robot should have a motor that is strong enough.
  • The battery life of the robot should allow it to work several hours continuously.
  • The robot has to be able to avoid collisions.
  • The patient should feel comfortable near the robot. Interaction with the robot should feel natural.
  • The robot should have a low failure rate. It should work most of the time.
  • If the robot stops working or in case of emergency, then it should be possible for the patient to contact help.
  • Design fitting hospital use, easy to clean, as sterile as possible and low risk of hurting oneself on the robot.

Stakeholders

Stakeholders are those who are involved in the development of the system. The two main stakeholders are the technology developers and the hospitals. The hospital can be separated into different stakeholders: the workers (nurses, doctors and receptionists), visitors, the board of the hospital and the patients. The primary stakeholders are the visitors, workers and developers. Secondary stakeholders are the government, the board and patients. Collaboration between developers, users and workers is needed. The influence of patients that are hospitalised must be considered, they must not experience nuisance with the use of the technology in the hallways.

User needs

Given that the user space is a hospital environment, a user would like to be treated with care. Therefor we stated a few things as necessary for the user. First of all the robot needs to behave in a friendly way. This means its way of communicating with the user should be as neutral as possible, such that the user feels at ease with the robot. Secondly, the robot should be able to adjust its speed to the needs of the user. For instance, younger people tend to be quicker by foot than elderly. The route calculated should be as safe and passable for the user as possible, with efficiency as second priority such that it does not take longer than necessary to reach the user's goal. Another thing the user needs is a way to communicate to a human if needed, think of situations like the robot being lost together with the user, it needs to be able to tell this to a human operator such that the user can be helped.

USE-aspects

The impact of the guiding robot on the USE aspects is explained here.

Users

The users of the new guiding robot are generally elderly people who have trouble with finding the way in the hospital. Without this robot they would have to ask employees to guide them. Employees may not have time to guide the elderly all the way to the destination. So elderly can still get lost if they don't fully understand the intructions of the employees. They could come too late to an appointment due to this. It is important that the users feel comfortable near the robot. Users may otherwise refuse to let the robot guide them.

Society and enterprise

The robot can help patients who have trouble with finding the way to arrive in time. Therefore less patients would arrive too late to an appointiment. This may make the hospital more efficient and could reduce costs. However the robot should be able to avoid obstacles. Other people in the hospital should not be hindered by the robot.

Tasks and approach (old; Before week3)

In order to test the design and system of the guiding robot, we had two possibilities: use the real robot Amigo or make a simulation. The 3D simulation is chosen, since it would be a more easy suitable way to test than in a real hospital. The simulation will be a first person 3D game where the player will be the test subject. The player is looking through the eyes of an elderly patient or visitor in a hospital.


For making the simulation, the following aspects have to be considered:

1. Unity/Blender The simulationgame will be done in Unity and the 3d models (hospital as environment and character as user) will be made in Blender

2. Catharina hospital map A real hospital map is used for the simulation. The Catharina hospital is prefered since it is close to the TU/e in case tests have to be performed. The 3D environment will be modeled after this map as well

3. Eindhoven Airport robot Literature study and research about the Eindhoven airport will be done to find the flaws of the airport guiding robots, so they can be avoided in the design

4. Interaction The player (user) 'speaks' by inputting a certain sentence and the robot should respond accordingly and correctly through the speakers.

5. Virtual bracelet A 3d model of the bracelet will be made that the character (user) can put on.

6. Same starting point and same destination For now, each simulation will be performed with the same start and end. Later on more starting and destinations may be added.

7. Obstacle avoidance Whenever the robot notices something hinders its way, it should avoid it or move around it.

8. Distance between user and robot (keeping track) Robot constantly checks distance between user and robot (radius). In case distance (radius) is too large, the robot waits or comes to the user. This keeping track of the user can be done with smart bracelets. The robot sends a signal to the bracelet, and the bracelet sends a signal back to the robot. The robot measures the time between sending and receiving and the distance can be calculated by multiplying speed of signal and time.

9. Malfunction/call human In case the robot malfunctions, there should be an alternative for example calling a human caregiver or another well functioning robot.

10. Touchpad and speaker A touchpad and speaker from the robot are used to give instruction to (for example about putting on the bracelet) and have a conversation with the user

11. App for touchpad A program has to be written that allows the user to use the touchpad

12. Survey before/during/after test (feedback) To get feedback about the design and system. A few aspects that can be asked are comfort, ease of use, time-efficiency etc.

13. Elevators in hospital During the guiding the robot has to make use of elevators in case switching between different floors is necessary

14. Navigation system/structure of signage The usual navigation signs of a real hospital will be implemented in the following way. Locations in the hospital where a navigation sign is placed is considered as a node. The hallway that is referred by that sign is considered as a branch. The main entrance is the root and each node is connected to child nodes through branches. The different departments are the so-called 'leafs'. For example, the node 'Main entrance' has a navigation sign that tells the visitor to go to the left hallway (branch) for routes 1-50 and go to the right hallway (branch) for routes 51-100. At the end of these two hallways are again signs (child nodes) that have other hallways (subbranches) connected to it. The sign at the end of the left hallway tells the visitor to go to the left subhallway (subbranch) for routes 1-25 and the right subhallway (subbranch) for routes 26-50. The sign at the end of the right hallway tells the visitor to go to the left or right subhallway (subbranch) for routes 51-74 and 75-100 respectively.

Tasks and approach (new; after week 3)

Smart bracelet

The smart bracelet is worn on the user's wrist. In this way the robot can keep track of the distance radius between the user and the robot. The basic idea of the bracelet is as follows: the robot sends a signal to the smart bracelet and the robot starts the timer. The smart bracelet receives the signal and immediately sends a signal back to the robot. The robot receives the signal and stops the timer. The timer indicates the time interval between the robot sending and receiving the signal. However, this timer is twice as much as the actual travel time. Hence this time has to be divided by 2. The distance radius between the user and robot can be calculated as follows: x=v*t/2, where x is the distance radius between the user and robot, v is the travelling speed of the signal, t is the time between the robot sending and receiving the signal, the factor 1/2 is for correcting the double travelling time.

Literature research has to be performed to find out which electronic components are necessary and which kind of signal we want to use (for example light, (ultra)sound, wifi, infrared, however light and sound are direction dependent and reflect as well).

An example could be the myRIO device that uses wifi as signal and use it in the MATLAB environment. MATLAB starts a timer when sending a signal to the myRIO. The myRIO receives this signal and immediately sends a signal back to MATLAB. MATLAB stops the timer when receiving the signal and the elapsed time between MATLAB sending and receiving the signal is measured. The actual travel time is half of the measured time, since the measured time is twice as large (back and forth).

In order to find out the travelling speed of the signal, reference measurements ('eiken' or 'eikpunten' in dutch) have to be performed as follows: 10 time intervals are measured between the robot sending and receiving the signal with 10 known distances between robot and smart bracelet. The traveling speed v is obtained by v=x/t, where t is half the measured time or x is the double distance. These speeds can be plotted and the average speed can be used for new real future measurements

Robot

A decision has to be made between using real robots (for example the amigo or a robocup robot) or building our own robot with an arduino, motor, battery, wheels, webcam, sensors and platform. We decided to choose for a robocup robot for the following reasons:

  • It is more robust than the amigo; it has bumpers
  • navigation is already implemented, we need a hospital map
  • obstacle avoidance is already implemented, since the robocup robots avoid each other when they play football. We have to define what is an obstacle and what is not.

What still has to be implemented by us are:

  • Tracking of the user by using a smart bracelet and calculate time between sending and receiving
  • interaction/conversation between robot and user. Robot gives instructions through speaker and touchscreen. In case elderly stops following the robot, because he/she stops walking or walks into another direction, the robot should communicate with the user or information desk, so that a human caregiver can continue guiding the user..

Actions robot should take in case of malfunctions It could happen that the robot has electrical problems, wifi problems and/or mechanical problems, like broken sensor, broken link wifi connection, broken motors. Then the robot should call another robot or call the information desk for human caregivers so that they can continue guiding the user.

Planning (old; Before week 3)

week 2

  • Literature study: Marleen, Willeke
  • USE-aspects: Huub, Tim
  • Define objectives: Victor

week 3

  • Create 3 different hospital map: Willeke, Tim
  • Describe app interface: Huub
  • Create 3 scenarios: Victor
  • Describe state-of-the-art guiding robots: Marleen

week 4

  • Start with Blender: Victor, Marleen
  • Start with app: Huub
  • What should robot do in case of emergency/malfunction: Willeke
  • Rethink requirements
  • Describe smart bracelet: Tim

week 5

  • Finish map in Blender: Victor, Marleen
  • Continue app: Huub
  • Continue wiki: Willeke, Tim
  • Evaluation point

week 6

  • Finish characters in Blender: Victor, Marleen
  • Finish app: Huub
  • Continue wiki: Willeke, Tim

week 7

  • Continue Blender: Victor, Huub, Marleen
  • Continue wiki: Willeke, Tim

week 8

  • Simulation Blender: Victor, Huub
  • Start on presentation: Willeke
  • Continue wiki: Marleen, Tim

week 9

  • Buffer

Chef Blender: Victor Chef app: Huub Chef wiki: Marleen Chef presentation: Willeke

App: what does the user see on the touchscreen of the robot Blender: simulation of guiding by robot. Robot keeps track of distance between robot and user and asks questions if distance between user and robot becomes too large.

Planning (new; after week 3)

week 4

  • Find the necessary electronics for the smart bracelet: Victor
  • Start with creating the app: Marleen, Huub
  • Think of what the robot should do in case of emergency or malfunction (Q2): Willeke, Tim
  • Finish the pieces about the requirements: ?
  • Describe how the smart bracelet works: Victor
  • Make an appointment with Tech United: Everyone

week 5

  • Build the smart bracelet: Victor, Marleen
  • Evaluation, do we still miss things?: Everyone
  • App: Huub
  • Wiki: Willeke, Tim

week 6

  • Communication link between robot and smart bracelet: Victor, Marleen
  • Finish the app: Huub
  • Wiki: Willeke, Tim

week 7

  • Reaction on user behaviour (action) + reaction on user feedback: Victor, Huub, Marleen
  • Wiki: Willeke, Tim

week 8

  • Buffer week 7 + testing: Victor, Huub
  • Presentation: Willeke
  • Wiki: Marleen, Tim
  • Survey: Everyone

week 9

  • Buffer

Chef smart bracelet: Victor Chef app: Huub Chef wiki: Marleen Chef presentation: Willeke

App: what does the user see on the touchscreen of the robot Smart bracelet: used during guiding user by robot. Robot keeps track of distance between user and robot by using smart bracelet and robot asks questions if distance between user and robot becomes too large. How smart bracelet works: 'Tasks and approack (new; after week 3)'-->'smart bracelet'

Objectives

Objectives of systems

  • Guiding elderly patients and visitors of a hospital safely, comfortably and quickly to their destination
  • Reducing amount of human caregivers who guide patients and visitors, so they can have their hands free to help patients with more serious problems
  • Keeping accompany with lonely elderly, so they can have someone to interact with and have a conversation with
  • Keeping track of the user
  • Avoid obstacles
  • Provide a suitable solution in case the robot malfunctions
  • Using touchpad with app and speakers in order to communicate with the user or to give instructions to the user

Objectives of simulation

  • Putting our design to the test and verify our expectations
  • Using test results to improve the system


App

For the interaction between the user and the robot an app based interface is used. This app will be programmed in Android Studio. When starting on the app, the following things should be discussed: Which features should it hold? How can we make it user friendly? Who are the users?

The design of the app is based on the desing of the Catharinaziekenhuiz website.

interface

Below the interface of the app is described, with all the features it should hold.



Homescreen:

  • Welkom
    • start button
    • change language (this should be a pop up screen, afterwards you return to the homescreen in the selected language)

Next screen

  • Ik ben een
    • Patiënt, Bezoeker

Patiënt

  • ik heb een afspraak
    • Op welke polikliniek heeft u een afspraak? Voor bloedprikken of het inleveren van andere lichaamsvochten, is het niet nodig een afspraak te maken.
      • Menu with all the polis in a scroll menu, the possiblity to type in the poli
  • Ik heb geen afspraak*
    • U heeft geen afspraak, maar wel een verwijzing
      • Voor een afspraak op één van onze poliklinieken kunt u bellen naar de betreffende polikliniek of afdeling. Tussen 08.30 en 16.30 uur zijn onze poliklinieken telefonisch bereikbaar.
    • U heeft geen afspraak en ook geen verwijzing
      • Voordat u een afspraak kunt maken op een van de poliklinieken, moet u eerst een verwijzing hebben van uw huisarts. Maak hiervoor eerst een afspraak met uw huisarts.

Bezoeker

  • op welke afdeling wilt u een bezoek brengen?
    • menu with the sections
      • op welke kamer moet u zijn?
      • Ik weet niet op welke kamer ik moet zijn?
  • Ik weet niet op welke afdeling ik moet zijn?
  • Visiting times can be checked when the section is know.

Ik weet niet waar ik een bezoek wil brengen

  • Possibility to fill in the patient
  • We should ask if this is possible concerning privacy


Smart bracelet

2 arduino's and two transceivers (transmitter and receiver in 1), 1 for robot, 1 for smart bracelet

robot (continuously) sends signal and starts timer

bracelet receives signal and responds with other signal (continuously)

robot (continuously) receives signal and stops timer


measure time is back and forth, so actual time is half of it

, hence radius distance of user and robot is = v*t/2


if distance is smaller than or equal to required, robot keeps leading

if distance is larger than required, robot slows down (robot follows)


robot has indicator that blinks a few seconds before it turns left or right (turning light)

robot has indicator that turns a few seconds before it brakes (brake-light)


we already have one arduino, so we have to buy another arduino and buy two transceivers

since we want transceivers (transmitter and receiver in 1) that is programmable, we decided for arduinos with compatible transceivers. Arduino options could be: arduino uno, nano, micro. Arduino compatible transceivers could be Nrf2401, Nrf24L01


first we have to talk to Tech United to obtain more information about the football robots. The second Arduino uno and two arduino compatible receiver Nrf2401, Nrf24L01, those three have to be bought, or we may borrow from the LaPlace building, lab room LG0.60 or Flux building floor 0. Both buildings are located on the campus of the University of Technology Eindhoven (TU/e). The used signal between both the receivers is probably WiFi-signal, hence during the operation a WiFi-network link has to be set up and the corresponding network has to be selected and connected to.


http://playground.arduino.cc/InterfacingWithHardware/Nrf2401

https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo

http://forum.arduino.cc/index.php?topic=92271.0

http://www.societyofrobots.com/robotforum/index.php?topic=7599.0


Turtle

The simulation of our idea will be made by using a Turtle from Tech United. The Turtle and its programming of Tech United can be used and changed too our idea. With the use of a DEV-notebook we can program and simulate our idea. When the results are desirable the simulation with the real Turtle can be made. Below a few things we will use that are already programmed are listed:

  • The Turtle knows the field and its own position on the field.
  • The Turtle sees a black object as an obstacle, which it will avoid.
  • The Turtle sees a yellow object as the ball.
  • The Turtle is programmed using positions and not using velocity.

We will work in Eclipse on the role_attacker_main.c file.

How will the simulation look like?

Voor de simulatie wordt de Turtle van Tech United. Met behulp van een DEV-notebook kunnen we de werking programmeren en simuleren. Wanneer een gewenst resultaat wordt verkregen, kan de simulatie met de Turtle worden uitgevoerd. De Turtle met de programmering van Tech United mag gebruikt worden en bewerkt.

  • De Turtle kent het voetbalveld en kan zijn positie op het veld bepalen.
  • De Turtle ziet een zwart voorwerp als een obstakel en ontwijkt deze.
  • De Turtle ziet een geel voorwerp als de bal.
  • De Turtle word geprogrammeerd met posities en niet met snelheden.
  • Wij kunnen werken in Eclipse in role_attacker_main.c

Hoe moet de simulatie werken De Turtle is bekend met het veld en zijn positie op het veld. Het doel is dat de Turtle van een positie A naar een positie B beweegt. Tijdens de verplaatsing zal hij obstakels (Zwart) ontwijken. De user (geel) moet geleid worden van A naar B.

Possible issues

-User walks too slow/robot goes too fast --> robot speeds up

-User is heading the wrong direction --> robot talks, if distance too large --> call reception

-User wants to go to the toilet --> button on robot

-User walks in front of the robot, instead of behind --> robot talks, if distance too large --> call reception


limits --> limit1<limit2<limit3

if x<limit1 --> robot speeds up

if limit1<x<limit2 --> same speed

if limit2<x<limit3 --> robot slows down

if x>limit3 --> robot stops


robot has a velocity not larger than ...


turning light active, 1 second before actual turning

braking light active, 1 second before actual braking