Bram van den Nieuwendijk (Mechanical engineer) 

In week 6 I started to look into ways to realize the rotating part of the spraying mechanism. In the 3D model I added the rotating mechanism for the nozzle, and also for the camera. The step for next week is to prepare for the mid-term presentation, and to further detail the spraying mechanism to check the feasebility.  

Sulaf

Overview
Following last week’s deep dive into the requirements and risk analysis I made, this week was about translating those plans into a structured testing strategy when the car is all assembled (after it is 3D printed). While we’re still waiting for the physical components (IMU, wheel encoders, etc.), I wanted to make sure we’re not just waiting passively, so I focused on how we’ll test each subsystem once the hardware arrives, and how we can simulate or prepare in the meantime.

The goal was to break down the robot into its core functionalities and define what success looks like for each part (ideal success), so that when we finally get the components, we can hit the ground running.

Guiding Questions

• How will we test each subsystem?
• What tools or platforms can we use in the meantime?
• What does a successful test look like?

Subsystem Testing Plan

We broke the robot down into six main subsystems and outlined how each will be tested:

Subsystem	Testing method	Success criteria
Navigation (IMU + Encoders)	Simulated path tracking using WOKWI	Robot follows its path with less than 10 cm deviation Obstacle Detection (Ultrasonic)
Obstacle Detection (Ultrasonic)	HC-SR04 sensor simulation and physical test	Robot pauses and reroutes when an object is within 10-15 cm
Weed Detection (AI Model)	Testing by running using a camera, and test it with the dataset testing and camera input	At least 90% accuracy for detecting weed
Spray Mechanism	Manual trigger test to check that it works	Spray activates only when weed is detected within range
Power System	Battery pack testing per module	Each subsystem runs independently without instability

By breaking it down like this, it helps us isolate issues and test each part before full integration of the part. It also gives us flexibility, and if one module is delayed, we can still move forward with others.

Simulation

I expanded our WOKWI simulation to include multiple sensors. While it’s still limited, it helps visualize how the robot will behave in real time. Next I will begin drafting a test script that will run through basic movement and detection logic once the physical robot is ready.

For example, I added a simulated obstacle at 25 cm and tested how the ultrasonic sensor responds. The rerouting logic is still in progress, but the detection part is working as expected.

This week felt like a shift from planning to pre-executing. We now have a clear testing roadmap, a modular strategy we can work with and a way to simulate and test even without hardware. Once the components arrive, we’ll be ready to start physical testing immediately. The project is starting to feel real now, and I’m excited to see how each part comes together.