PRE2017 1 Groep1: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
----
Group 1 Composition:
Bern Klein Holkenborg, Mechinical Engineer
Clara Butt, Mechinical Engineer
Sjoerd van Heesbeen, Mathematician
Luke van Unen, Software Scientist
----
<table cellspacing=1
<table cellspacing=1
   style="float:right; margin: 0 0 0 1em; border: 1px solid #a2a9b1;background-color: #f9f9f9; padding: .7em;">
   style="float:right; margin: 0 0 0 1em; border: 1px solid #a2a9b1;background-color: #f9f9f9; padding: .7em;">
<tr><td colspan="2" style="border-color: #a2a9b1; padding: 0.2em 0.4em; text-align: center;"><b>Members of group 3</b></td></tr>
<tr><td colspan="2" style="border-color: #a2a9b1; padding: 0.2em 0.4em; text-align: center;"><b>Members of group 3</b></td></tr>
<tr><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">Karlijn van Rijen</td><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">0956798</td></tr>
<tr><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">Bern Klein Holkenborg, Mechanical Engineer</td><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">0956798</td></tr>
<tr><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">Gijs Derks</td><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">0940505</td></tr>
<tr><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">Sjoerd van Heesbeen, Mathematician</td><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">0940505</td></tr>
<tr><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">Tjacco Koskamp</td><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">0905569</td></tr>
<tr><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">Luke van Unen, Software Scientist</td><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">0905569</td></tr>
<tr><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">Luka Smeets</td><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">0934530</td></tr>
<tr><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">Jeroen Hagman</td><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;">0917201</td></tr>
</table>
</table>
= Introduction =  
= Introduction =  
The technology of robotics is an unavoidable rapidly evolving technology which could bring lots of improvements for the modern world as we know it nowadays. The challenge is however to invest in the kind of robotics that will make its investments worthwhile instead of investing in a research that will never be able to pay its investments back. In this report we are going to investigate into a robotics technology that we think is worthwhile looking into. In this chapter it will be explained what the societal issue is that we want to tackle, what we want to achieve for this issue and how we plan on achieving this.
In this project, problems are solved from a societal perspective. Engineers usually look at engineering problems, but fail to notice that either the problem is of no issue for the user or society, or the problem may be irrelevant for the problem the user or society has. This project explores the utility of just that: looking from a user's need. For the course a problem is posed which is be detailed below.  


== Problem Definition ==
== Problem Definition ==
When you travel by train on a regular basis you might have noticed that when people in a wheelchair need to exit or entry the train it goes rather slow. Before they can get on or off the train the train personnel is needed first to get some sort of ramp to make the disabled people able to board or deboard the train. When someone in a wheelchair is on board or wants to go on board of the train the train might even be delayed because of this. As we know trains in the Netherlands tend to be too late every time and therefore every obstacle that is getting in the way of letting them ride on time, should be taken care of. The wheelchair problem is definetely one of them. Imagine you are in a wheelchair and want to board the train. First you have to look for someone of the staff to ask if they can help you board the train. Someone of the staff will then get the ramp and help you board the train when it has arrived. When you have reached your destination and you want to exit the train again someone of the staff at the trainstation has to get the ramp and help you deboard the train. As you can see it is a lot more difficult for people with a handicap to be able to easily travel by train. Every time they want to travel by train they are dependent of other people. The feeling of constantly being dependent on others is for most people the worst part of living with a handicap. Because of this dependency the threshold for these people to travel by train is much higher. When they stop using the train it might have an impact on their social being which might cause loneliness and even depression. We as group 3 want to improve the service at trainstations for disabled people by using the technology of robotics.
The world is more populated than it ever has been, and so is the Netherlands. With as much as seventeen million people to govern, control and live is difficult and tranlate to many issues. Society is build from many different people with own ideals, ideas and way of living. Friction between people or friction between them and the law is more common the more people there are, and now with more people than ever this is a real issue. The police force acting as a regulator for these problems contributes a significant factor in deminishing the problems arraising from society. However, the police has issues growing in effective employees to regulate the society, due to management problems and financial problems. Historically, problems with too few (or too much) personell has been solved by automation. So why is the police force not as automated as it maybe should be? In the past, these automated problems were often repetetive or non-complicated, whereas a police task is hugely complex: Every situation is different, there are safety concerns and the police works with humans, not objects.  


== Objective ==
== Objective ==
As already mentioned in the problem definition it is our goal to improve the assistance for disabled people at train stations. In order to achieve this goal we need to specify what is actually meant by improve. To see what the best eventual goal would be the wishes of the users need to be considered. The primary users are of course the disabled people, however the indirect user, which is the train staff, also has their own wishes. To be able to know what the users want their opinion is needed, which will be discussed under the USE chapter. Here our view of the ideal solution will be explained. As explained before the dependency on others is one of the main problems and therefore it would be best if everyone could board the train all by their self without the help of any staff. Another problem was the time it takes to board the train and therefore we want a solution that is as fast as possible but of course also entirely safe to use. Another important part are the manufacturing costs, which of course are preferred to be low. Also the product should be easy to use and not wear off too quickly since reparation costs will be high on a robotic system.
As described above, to keep up with population growth, the police force has to evolve to a (partly) automated force. The objective for the project is just that. A robot should be created to automate an otherwise employee intensive police task. This without bringing user or society in harm. The robot should be save to interact with, useful and should be able to cope with every situation it faces. Already there are real police robots wandering in the streets (Dubai), however they often lack in almost every situation compared to human officer. The goal of the project would be far to enthusiastic to design such a robot. In this project, a specific police task will be tackled. To define this better, a few examples: Speeding control, a mobile robot could check wherever, whenever for speeds. An automated alchohol check can be done, a robot could be set up to automatically check if a driver is allowed to drive or not. A robot that monitors a vehicle chase, a mobile robot unit will likely be faster, cheaper and more varsetile than a police helicopter will ever be. The specific police task tackled will be chosen later based on an interview with the police.


== Approach ==
== Approach ==
The approach for the project will be discussed in this section. First of all the users wishes should be the main design criteria. To find out what the wishes of the users are there 2 questionnaires will be made, one for the disabled people and one for the train staff. The results of these questionnaires will be used for a thematic analysis. From the conceptual designs the one that fits the wishes of the users best and is the best solution according to the other design criteria will be chosen. After the best conceptual design is chosen a literature research will be executed about the options of the design. When the literature research is completed a prototype will be designed which will represent the final solution of the project. With the prototype it can be seen what things of the design should be adapted to improve the design.
To tackle the best problem, it has to be investigated how and why a police task is done and how this could be automated. An interview with the police should clearify both that, and should also narrow down the problem to a single task. The task should be investigated in detail. As before, why and how is it done, what rules are there, what is to be kept in mind during the task, how do people react to the task, is it safe to automate it in the proposed method. When all the parameters are defined, a robot can be designed both technically and functionally. After designing the robot, the design has to be verified by both the police and users which can be done by enquete, interview and maybe even a prototype test.
To make sure that the project will be finished in time milestones have been made which show what we want to finish in every week from now on. The list of milestones can be seen in the planning.
 


= USE =
= USE =

Revision as of 23:09, 10 September 2017

Members of group 3
Bern Klein Holkenborg, Mechanical Engineer0956798
Sjoerd van Heesbeen, Mathematician0940505
Luke van Unen, Software Scientist0905569

Introduction

In this project, problems are solved from a societal perspective. Engineers usually look at engineering problems, but fail to notice that either the problem is of no issue for the user or society, or the problem may be irrelevant for the problem the user or society has. This project explores the utility of just that: looking from a user's need. For the course a problem is posed which is be detailed below.

Problem Definition

The world is more populated than it ever has been, and so is the Netherlands. With as much as seventeen million people to govern, control and live is difficult and tranlate to many issues. Society is build from many different people with own ideals, ideas and way of living. Friction between people or friction between them and the law is more common the more people there are, and now with more people than ever this is a real issue. The police force acting as a regulator for these problems contributes a significant factor in deminishing the problems arraising from society. However, the police has issues growing in effective employees to regulate the society, due to management problems and financial problems. Historically, problems with too few (or too much) personell has been solved by automation. So why is the police force not as automated as it maybe should be? In the past, these automated problems were often repetetive or non-complicated, whereas a police task is hugely complex: Every situation is different, there are safety concerns and the police works with humans, not objects.

Objective

As described above, to keep up with population growth, the police force has to evolve to a (partly) automated force. The objective for the project is just that. A robot should be created to automate an otherwise employee intensive police task. This without bringing user or society in harm. The robot should be save to interact with, useful and should be able to cope with every situation it faces. Already there are real police robots wandering in the streets (Dubai), however they often lack in almost every situation compared to human officer. The goal of the project would be far to enthusiastic to design such a robot. In this project, a specific police task will be tackled. To define this better, a few examples: Speeding control, a mobile robot could check wherever, whenever for speeds. An automated alchohol check can be done, a robot could be set up to automatically check if a driver is allowed to drive or not. A robot that monitors a vehicle chase, a mobile robot unit will likely be faster, cheaper and more varsetile than a police helicopter will ever be. The specific police task tackled will be chosen later based on an interview with the police.

Approach

To tackle the best problem, it has to be investigated how and why a police task is done and how this could be automated. An interview with the police should clearify both that, and should also narrow down the problem to a single task. The task should be investigated in detail. As before, why and how is it done, what rules are there, what is to be kept in mind during the task, how do people react to the task, is it safe to automate it in the proposed method. When all the parameters are defined, a robot can be designed both technically and functionally. After designing the robot, the design has to be verified by both the police and users which can be done by enquete, interview and maybe even a prototype test.

USE

User aspect

Society aspect

Enterprise aspect

Retrieved from "https://dsdwiki.wtb.tue.nl/index.php?title=PRE2017_1_Groep1&oldid=45030"