Overview
Our group, group 4, comprises of one mechanical engineer, one electrical engineer, and three computer engineers. Three of our members are international students, and this project marks the first time we’ve collaborated. Despite our diverse backgrounds, we are all enthusiastic about this semester ahead and committed to working closely across our respective disciplines.
The mechanical engineer will be responsible for developing the physical design and contributing feasible design proposals aligned with the project’s goals. The computer engineers will focus on navigation control and all AI-related components. The electrical engineer will ensure seamless integration between mechanical systems and software functionality.
Project Criteria
During the first week, we brainstormed multiple ideas and evaluated them against a set of criteria to identify the most suitable project. The questions helped guide our decision while deciding on a project:
Is the project viable?
Can this project be realistically completed within the timeframe provided in this course?
Is it budget-friendly?
Do we have access to the necessary materials and resources to implement the desired functionality?
Is it complex yet achievable?
We assessed whether each idea offered sufficient scope for all disciplines—programming, mechanical, and electrical. If a concept lacked depth for one or more members, we considered expanding its requirements to ensure a balanced workload: challenging but attainable. However, we remained mindful not to deviate from the core objective.
Is it testable?
A key requirement of this course is to demonstrate a working prototype. If a concept lacked a practical or physical application, it was deemed unsuitable.
Is it engaging?
We recognized that genuine interest in the project would foster motivation and sustained effort throughout the semester.
Summary of Criteria
Feasible within the timeframe
Budget conscious
Technically challenging yet manageable
Practically testable
Engaging and enjoyable
Methodology
While enthusiasm is essential in any project, we also established clear expectations, boundaries, and a structured workflow to ensure we remain on the right path, with the most effective progress each week. Therefore, for this project we adopted an agile methodology, holding weekly meetings with 15-minute sprint reviews at the start of each session. These sessions will act like reviews, allowing members to share updates, assess progress, and ask for support if needed.
For communication we selected Microsoft Teams as our primary platform to maintain efficiency and organization.
Group Members
Darkio Eleno Schneider Luft Santos: Computer Engineering
Bram van den Nieuwendijk: Mechanical Engineering
Åsmund Wigen Thygesen: Computer Engineering
Sulaf Bozomqita: Computer Engineering
Rick Embregts: Electrical Engineering
Landing on a Project
Using the criteria above, we explored several creative and technically viable ideas. After thorough discussion, we narrowed our options to the following five concepts:
Drawing Machine
Sorting Machine
Autonomous Submarine
Robotic Facial Mimicker
Weed Exterminator
Each idea was evaluated against our criteria. We considered ways to increase complexity while brainstorming, and possible issues we might meet along the way.
Drawing Machine: Initially promising, but ultimately too simplistic. Even with added features like color and shading, it lacked sufficient scope for three computer engineers and failed the “complex yet doable” criteria.
Sorting Machine: Had diverse applications, such as a robotic trash sorter using mechanical arms to pick up trash from the wrong bin and sort it into the correct bin itself, or flappers on a conveyor belt to sort flasks. However, it lacked excitement and engagement, leading us to deprioritize it.
Autonomous Submarine: The autonomous submarine had a relatively fair share of votes. We were rather excited with the concept of an autonomous submarine, and thought of different application possibilities for it, such as exploring marine biology, or collecting plastic. However, after speaking with the supervisor, we figured it did not pass the testing criteria, seeing it was not possible to have an aquarium in Dronesonen.
Weed Exterminator: This concept stood out as the most promising. It was engaging, adaptable, budget-friendly, testable, and offered sufficient complexity for all disciplines. It received the highest number of votes as well.
We officially selected the Autonomous Robotic Weed Killer, named AROWEEK.
AROWEEK – Requirements
We categorized our requirements using an ABC priority system:
A – Must-Have Requirements
The robot shall operate autonomously.
It shall navigate in the X, Y, and Z directions.
It shall locate all weeds within the terrain.
It shall distinguish between weeds and other botanical elements.
It shall apply weed control to identified weeds.
It shall be capable of recharging.
B – Should-Have Requirements
The robot should detect obstacles.
It should map the terrain.
It should recognize when the spray tank is empty.
C – Could-Have (Optional) Requirements
The robot could include an autonomous charging station.
It could feature a dashboard website to display performance statistics and efficiency metrics.
Conclusion
By successfully implementing these requirements, we aim to develop a fully functional autonomous robot that meets these objectives in this course.