PRE2017 1 Groep1: Difference between revisions
No edit summary |
No edit summary |
||
Line 2: | Line 2: | ||
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;">Bern Klein Holkenborg, Mechanical Engineer</td><td style="border-color: #a2a9b1; padding: 0.2em 0.4em;"> | <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;"></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;"> | <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;"></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;"> | <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;"></td></tr> | ||
</table> | </table> | ||
Revision as of 23:13, 10 September 2017
Members of group 3 | |
Bern Klein Holkenborg, Mechanical Engineer | |
Sjoerd van Heesbeen, Mathematician | |
Luke van Unen, Software Scientist |
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.