PRE2020 4 Group1
Project Title t.b.d.
<div#bodyContent sup {
font-size: smaller; vertical-align: baseline; position: relative; bottom: 0.33em;
}
- bodyContent sub {
font-size: smaller; vertical-align: baseline; position: relative; bottom: -0.25em;;
}>
Team members
Members | Student ID | Faculty | |
---|---|---|---|
Kashan Alidjan | 1224924 | Electrical Engineering | k.m.s.alidjan@student.tue.nl |
Sijt Hooghwinkel | 1228761 | Automotive | s.j.c.hooghwinkel@student.tue.nl |
Damaris Jongbloed | 1241057 | Computer Science | d.a.jongbloed@student.tue.nl |
Emma van Oppen | 0963999 | Computer Science | e.y.v.oppen@student.tue.nl |
Laura Verbeek | 1428063 | Biomedical Engineering | l.h.e.verbeek@student.tue.nl |
Introduction
In 2020 the Dutch government spent 8.9 billion euros on roads, railways and waterways.[1] In the Netherlands, there are 125,575 kilometres of roads, which amounts to 27000 euros per km. People new to the Netherlands often claim how well-maintained our roads are, and the Netherlands ranks second in road quality worldwide.[2] Road quality is valued highly in the Netherlands due to a large number of cyclists. Minor damage will not be noticeable in a large car, but small cracks can lead to dangerous situations on a bicycle. [3] Unfortunately, there are still plenty of kilometres of bad quality, with potholes and cracks. This is where this project intends to present a solution. The aim is to present a device which can measure the density of road damage, upload this to a central database and aid the government agencies in repairing severely damaged roads.
Objectives
The main objective of this project is to develop a device that measures road surface quality by detecting irregularities in the pavement, such as potholes and cracks, that are encountered while driving around. This device can be placed onto a vehicle and will collect data on these irregularities using several different sensors, such as an accelerometer and a GPS module.
Through the use of crowdsourcing, the collected data, along with GPS locations, can be used to visualize the locations of potholes, cracks and other damage to the road’s surface, thus creating a mapping of the overall road quality. This data can be used to quickly assess where the damage is the most severe and which roads are in need of repair. As such, road maintenance can be planned more immediately when problem areas are detected, which can contribute to an increase in road safety.
- Collect data on potential locations of potholes, cracks and other road surface damage.
- Visualize the locations of detected road damage by overlaying the collected data on a map.
- Enable quick assessment of where the damage is most severe and repair is necessary.
- The device must be cost effective to enable widespread usage.
USE analysis
Users
The public roads in The Netherlands are not maintained by one organization. The management is mainly shared between Rijkswaterstaat (highways), provinces and local municipalities. The two latter are responsible for the “N” roads, non-highway roads.
People that have the device installed on their vehicle can be considered as passive users as they do not have to interact directly with the device if they wish. They will need to monitor the physical state of the device and have the device replaced/repaired if needed. The users can also actively interact with the App to see their contribution and edit wrongful detections of the system (false positives) or add locations where the system has not detected anything (false negatives).
Society
Societal stakeholders are all road users.
Enterprise
If a road repair needs to be done a contractor will be used to perform this repair.
Depending on the means of installation and technical knowledge that is required to perform installation (TBD!), this may need to be done by a garage. Several garages could be selected to have an inventory of the devices to install on customers cars during their general inspection (APK) or with a service.
Car insurance companies are also stakeholders in this project. Car owners could make use of their insurance policy to claim for damages on their vehicle because of bad roads. Better quality roads would mean insurance companies would have to compensate fewer people.
State of the art / Research
TODO
Plan
Approach & Milestones
To meet our goals, we subdivided our research into 12 milestones. For each milestone, a short description is given to clarify what needs to be done to reach the milestone.
- Find a subject: to do the project, we need to determine the subject that we will focus on. For this, we should think about what type of research we want to conduct (e.g. literature analysis, experimenting, designing, building a prototype…). Other things to keep in mind are:
- What are the strengths and weaknesses of the group?
- Which projects are possible to do within 8 weeks?
- Literature study: the second milestone is to gain knowledge about the possibilities already used for our problem. In this literature study, we will look at the State-of-the-Art, and what the pros and cons are of these solutions to the problem. This knowledge can be applied to improve our own research.
- Conceptual design: in the third step, we make multiple designs for the problem. For each design we will look at the pros and cons to find the best design. We can choose the best design or combine the strengths of multiple designs to form a new concept.
- Functional description: once we know what the concept will look like, we need to figure out which components are needed to build the main parts of the design, and we have to look up which components/materials are available in the store or online. For example: how is the product supplied with power? A battery? An accu? Furthermore, we should start working on the software.
- Final design concept: using the knowledge about the materials found in (4), functional description, we should revise the conceptual design and make some adjustments if needed. The conceptual design will be refined to make the final design concept.
- Detailing: the next step is detailing, which means that we should look at the specifications of all the components. Using the same example as in (4), functional description, which battery or accu is sufficient to keep the product working for an X amount of time. In this step it is also important to look at the dimensions of all the components to fit them all in the casing.
- Mock-up: making a mock-up of the concept using cheap materials and/or a CAD design.
- Software: once the functional description is made, a start should be made on the software. The software should be finished before the realization (9).
- Realization: once we are satisfied with the prototype, we should order the components and start building the concept (make a BOM). First all components should be tested independently before putting the concept together. Hardware and software are combined.
- Testing: the prototype should be tested. (Minor) adjustments can be made in the software and/or hardware to refine the product.
- Results and evaluation: evaluation of the results of the test will give insight in the quality of the product. Possible areas of improvements are mentioned in the evaluation, as well as the strengths of the design.
- Final presentation and discussion: finalize the wiki page and prepare for the final presentation.
Deliverables
The deliverables for this project consist of the following items:
- The physical prototype
- An app that collects the data output of the product
- A demonstration of the product, shown during the video presentation
- The wiki page containing main topics, such as:
- Problem statement
- USE aspects
- Product
- Planning
- A video presentation regarding the product, process and most important findings.
Planning
Week | Milestone | Milestone name | Task | Responsible | Deadline |
---|---|---|---|---|---|
1 | 1 | Find a subject | Brainstorm | All | 25-4 |
2 | Literature study | All | 25-4 | ||
2 | 2 | Literature study | Finish literature | Emma, Laura | 29-4 |
3 | Conceptual design | Sketch app | Emma, Sijt | 2-5 | |
3 | Conceptual design | Sketch physical design | Kashan, Laura | 2-5 | |
3 | Conceptual design | High level interaction (USE diagram) | Damaris | 2-5 | |
3 | 4 | Functional description | All (tbd) | 6-5 | |
5 | Final design concept | All (tbd) | 9-5 | ||
4 | 6 | Detailing | All (tbd) | 13-5 | |
8 | Software | Emma, Sijt | 16-5 | ||
Order parts | Tbd | 16-5 | |||
5 | 7 | Mock-up | Kashan, Laura, Damaris | 23-5 | |
8 | Software | Emma, Sijt | 23-5 | ||
10 | Testing | Testplan, perform tests | All | 23-5 | |
6 | 9 | Realization | Perfect product | Kashan, Laura, Damaris | 30-5 |
7 | 11 | Results and evaluation | All | 6-6 | |
12 | Presentation and discussion | All | 6-6 | ||
8 | Overtime | All | 13-6 |
Logbook
Week 1
Name | Student ID | Time spent | Tasks |
---|---|---|---|
Kashan Alidjan | 1224924 | 7.5h | Intro (1h), Meeting (3h), Research (1.5h), Reading old projects (1h), Deliverables (0.5h), SoTA (0.5h) |
Sijt Hooghwinkel | 1228761 | 7h | Intro (1h), Meeting (3h), Reading old projects (1h), Users (2h) |
Damaris Jongbloed | 1241057 | 7.5h | Intro (1h), Meeting (3h), Research (1.5h), Problem statement (2h) |
Emma van Oppen | 0963999 | 8.5h | Intro (1h), Meeting (3h), Research (3h), Objectives(1h), Wiki(0.5h) |
Laura Verbeek | 1428063 | 9h | Intro (1h), Meeting (3h), Approach+milestones (2.5h), SotA (2.5h) |
Week 2
Name | Student ID | Time spent | Tasks |
---|---|---|---|
Kashan Alidjan | 1224924 | 1.5h | Meeting (1h), Wiki (0.5h) |
Sijt Hooghwinkel | 1228761 | 1h | Meeting (1h) |
Damaris Jongbloed | 1241057 | 1h | Meeting (1h) |
Emma van Oppen | 0963999 | 1h | Meeting (1h) |
Laura Verbeek | 1428063 | 1h | Meeting (1h) |
Week 3
Name | Student ID | Time spent | Tasks |
---|---|---|---|
Kashan Alidjan | 1224924 | ||
Sijt Hooghwinkel | 1228761 | ||
Damaris Jongbloed | 1241057 | ||
Emma van Oppen | 0963999 | ||
Laura Verbeek | 1428063 |
Week 4
Name | Student ID | Time spent | Tasks |
---|---|---|---|
Kashan Alidjan | 1224924 | ||
Sijt Hooghwinkel | 1228761 | ||
Damaris Jongbloed | 1241057 | ||
Emma van Oppen | 0963999 | ||
Laura Verbeek | 1428063 |
Week 5
Name | Student ID | Time spent | Tasks |
---|---|---|---|
Kashan Alidjan | 1224924 | ||
Sijt Hooghwinkel | 1228761 | ||
Damaris Jongbloed | 1241057 | ||
Emma van Oppen | 0963999 | ||
Laura Verbeek | 1428063 |
Week 6
Name | Student ID | Time spent | Tasks |
---|---|---|---|
Kashan Alidjan | 1224924 | ||
Sijt Hooghwinkel | 1228761 | ||
Damaris Jongbloed | 1241057 | ||
Emma van Oppen | 0963999 | ||
Laura Verbeek | 1428063 |
Week 7
Name | Student ID | Time spent | Tasks |
---|---|---|---|
Kashan Alidjan | 1224924 | ||
Sijt Hooghwinkel | 1228761 | ||
Damaris Jongbloed | 1241057 | ||
Emma van Oppen | 0963999 | ||
Laura Verbeek | 1428063 |
Week 8
Name | Student ID | Time spent | Tasks |
---|---|---|---|
Kashan Alidjan | 1224924 | ||
Sijt Hooghwinkel | 1228761 | ||
Damaris Jongbloed | 1241057 | ||
Emma van Oppen | 0963999 | ||
Laura Verbeek | 1428063 |
Appendix
TODO