PRE2018 3 Group5: Difference between revisions
Line 100: | Line 100: | ||
==Deliverables== | ==Deliverables== | ||
*Requirements document | *Requirements document | ||
* | *Implementation document | ||
*Use analysis | *Use analysis | ||
*Cost analysis | *Cost analysis | ||
* | *Conclusion | ||
==Who's doing what== | ==Who's doing what== |
Revision as of 13:25, 17 February 2019
General info
Group members
Name | Student ID |
---|---|
Ruben Haakman | 0993994 |
Stan Latten | 1257196 |
Tom Mulders | 1008890 |
Jasper Stam | 1006240 |
Mathijs Vastenhouw | 1269496 |
Problem
To keep residential areas clean and neat, lots of tools are used. Most of the tools are operated by humans, but some new tools can do some tasks autonomous. Can't this be done by one autonomous robot? We think the most common tasks can be performed by an autonomous robot.
When farmers grow crops, the have to deal with weeds growing on their fields inbetween their crops. To remove these weeds, pesticides are used. These pesticides can be harmful to insects, animals and humans and might even contaminate (ground)water. Clearly an alternative is needed.
Problem statement
How can tasks of maintaining residential areas be combined into one (modular) robot?
What are the possibilities for automated removal of weeds in farm fields without the use of pesticides?
Objectives
- The system must have the ability to do tasks, like lawn mowing and trash picking
- The system must be able to go autonomous to the place, where the task has to be performed
- The system has to give a warning to the owner in case of technical disorder
- The system has to ask for help of human if needed
- The system must have the ability to collect trash
- The system should have the ability to reach narrow places
- The system could have the ability to drop the trash on some location without the help of human
- The system could have the ability to attend the owner on many trash (full trash can)
RPCs
Requirements
- The system collects trash (litter, leafs, snow, ice) from the streets
- The system has to be modular, e.g. be able to do different tasks
- The system recharges autonomously
Preferences
- The system can reach narrow places
- The system can navigate around most obstacles
- The system can operate for a long time before having to recharge
Constraints
- The system has to be more cost-efficient than human workers
- The system has to be intelligent, has to know what to do.
- The system does never run out of power
Users and other stakeholders
- Municipalities: responsible to maintain the residential area
- Citizens: clean and safe neighborhood
- People that are maintaining the neighborhood: can focus on other tasks, that currently would not be done
- Society as a whole
- Enterprises that specialize in maintenance of public grounds
- City cleaning service (user): easier cleaning of the city center and better for human, because they have to stoop less to pick up trash under obstacles, like benches
- Shop owners: cleaner and more attractive city center. More customers leads to more sales.
- Shoppers: cleaner and less inconvenience of people that are trying to get the ground under your bench clean.
- Farmers
- Consumers
- Governments
- Society
Project setup
Approach
After reviewing the literature, we will determine the requirements for the system. Based on these requirements we will investigate implementations for these requirements and analyse their suitability. We will analyse the costs associated with a solution and compare this to the current costs of using pesticides, the effects on the stakeholders and on the future of farming. Finally we will conclude with a recommendation for or against the automated removal of weeds on farm fields without the use of pesticides and recommend future research topics.
Milestones
- State-of-the-art analysis
- Requirements Document
- Use analysis
- Implementation propositions
- Implementation analysis
- Cost analysis
- Conclusion
Deliverables
- Requirements document
- Implementation document
- Use analysis
- Cost analysis
- Conclusion
Who's doing what
- Ruben: Design(electronics), cost analysis, prototype.
- Stan: Design(general), Requirements, Use analysis, prototype.
- Tom: Design(general), Requirements, Use analysis, prototype.
- Jasper: Design(software), STOA analysis, Requirements, Use analysis.
- Mathijs: Design(general), STOA analysis, cost analysis, prototype.
State of the art
The literature study can be found on the page State of the art
Planning
For each week, there are points what we plan to do in that week. Planning can change over the weeks, dependent on the progress in the project. Final versions of the documents will be delivered at the end of the quartile, but concept versions will be delivered earlier.
Week 1
- Introduction to course
- Brainstorming about problem
- Make problem statement
- First idea on plan for project
- Literature study on problem
Week 2
- Updated problem description
- Concrete planning for project
- Make plan more clear with introduction
- Analysis of literature found in week 1
- First idea on requirements
- Start on USE stakeholder analysis
Week 3
- Concrete decisions on prototype
- USE stakeholder analysis
- Make requirements ready to start on design
Week 4-6
- Work on prototype
- Analysis of requirements based on prototype and update if needed
- Analysis of decisions made for prototype and update if needed
- Update other documents if needed
Week 7
- Finalize prototype
- Prepare presentation
Week 8
- Presentation