Goal this week:To find a suitable and strong base for the aquarium that can support the weight of the complete setup.

What we did

-We visited several furniture shops to look for a suitable base. Initially, we had the idea of finding a base with wheels attached, which we later realised was not practical. Since the setup in the reel used an aluminium frame, we contacted and visited several aluminium shops to see if they could make a similar frame for us. Unfortunately, the shops we contacted did not agree to make the frame. We then decided to look for a ready-made option from local shops. We went to LuLu Mall and bought a 3-level shoe rack, thinking it would be strong enough to hold the aquarium. After checking the setup, we realised that the shoe rack would not safely support the required weight. We tried to improve its support while also reducing the overall weight of the setup. We eventually realised that this approach would not be reliable. We then explored other options and came up with the idea of using a wooden or plywood base for better support. Finally, we got one plywood base and one wooden base to test for the aquarium setup

Problems and blockers

-Finding a base that could safely support the aquarium weight was difficult. We could not find a suitable aluminium frame locally. The shoe rack we initially purchased was not strong enough for the expected load. Adding more support to the rack while reducing the overall weight did not seem like a reliable solution.

Decisions

-We decided not to use the shoe rack as the main aquarium base. We decided to test plywood and wooden bases because they provide better and stronger support for the aquarium.

Next week

Test the wooden and plywood bases with the aquarium. Decide which base is more suitable for the final setup. Start planning how to mount the rover and other components onto the base.

• Photos / CAD

Goal this week:To find suitable wheels, connect the wheels to the motors and base, and complete the initial motor-control circuit.

What we did

-We contacted Thomson Electronics to get the wheels we needed. We decided to use 60 mm mecanum wheels and purchased them. We then faced a new challenge: connecting the motors to the wheels and the base. We needed a suitable shaft to connect the motor and wheel, so we decided to 3D print one. We first tried mounting the motors and wheels onto the shoe rack. We then had doubts about whether the shoe rack could handle the weight, so we moved towards using the wooden base. We 3D printed several shafts, with each version differing by a few millimetres. None of the first versions fitted correctly, so we spent a lot of time doing trial and error. Finally, we got a shaft with the correct fit for the motor and wheel. After solving the mechanical connection, we prepared the electronics using: ESP32 2 motor drivers 4 motors 1 breadboard 3 batteries, each 3.75 V We completed the initial connections between these components. However, we accidentally connected the batteries directly without using a buck converter, which caused the ESP32 to crash due to the excessive voltage supplied to it.

Problems and blockers

Finding the correct wheels took some searching. The motor and mecanum wheel needed a custom shaft to connect them properly. Several 3D-printed shaft designs failed because they were slightly different in size. We had doubts about the strength of the shoe rack and moved towards the wooden base. The ESP32 was damaged/crashed after we connected the battery supply incorrectly without a buck converter.

Decisions

We decided to use 60 mm mecanum wheels. We decided to use 3D-printed shafts to connect the motors and wheels. After several attempts, we finalised the shaft with the correct fit. We decided to replace the damaged ESP32 and redo the connections properly with the correct power supply.

Next week

Get a new ESP32. Redo the motor-driver and motor connections. Use a buck converter to provide the correct voltage to the ESP32. Test the motors and wheels safely.

Links

Goal this week:To find the right-sized aquarium and get the fish ready for the final setup without making the rover too heavy

What we did

-After getting the rover base working, our next challenge was finding an aquarium that was not too big or too small and whose weight could be handled by our rover. We first approached Back Water Aquatics, but they did not have the type and size of aquarium we were looking for. They mainly had round aquariums. So, we decided to get an aquarium built according to our own dimensions. We found a shop near Tinkerspace called Glass Word and gave them the required dimensions: [add dimensions]. We received the aquarium two days later. The aquarium weighed around [add weight] kg, so we checked whether our rover base could support it. Next, we started looking for a fish. We chose a fighter fish (Betta) because it requires less water compared to many other fish. We bought a red-coloured fighter fish from LuLu Mall. We cleaned the aquarium and filled it with water. To help the fish adjust to the new water temperature, we kept the fish inside its bottle in the aquarium for some time before releasing it. After the fish adjusted to the temperature, we placed it in the aquarium. With this, the aquarium and fish part of our setup was ready.

Problems and blockers

-Finding an aquarium with the right size and weight was difficult. The first shop we approached did not have a suitable aquarium. We also had to make sure the aquarium's weight would be balanced by our rover base.

Decisions

-We decided to have the aquarium custom-built according to our required dimensions. We chose a fighter fish because it needs comparatively less water. We decided to properly acclimatise the fish to the aquarium water before releasing it.

Next week

Mount the aquarium securely on the rover. Continue testing the rover with the aquarium and fish. Start working on the camera and fish/object tracking.

Links

Goal this week:To build a stronger rover base, make the wheels work, and test whether the vehicle could carry the aquarium.

What we did

We realised that the 60 mm mecanum wheels could not handle the weight of the setup properly. We thought of using two mecanum wheels along with a caster wheel to provide better support. We searched several shops for a suitable caster wheel, but could not find one. During a random conversation with Jayasurya and Shan, we discussed how an aluminium frame would give the rover better support and grip. Jayasurya helped us by giving us an aluminium frame/base that he had made for a college event two years ago. We connected the motors and wheels to the aluminium frame. Since the earlier 60 mm mecanum wheels were not suitable for the weight, we got another set of four wheels and connected them to the motors. We connected the ESP32, two motor drivers, four motors and battery and tested the setup. The motors and wheels worked successfully. We uploaded code to control the rover to move forward, backward, left, right, U-turn and stop. All the basic movements worked. We then created a local-host control website to control the rover wirelessly. The website worked and we were able to control the vehicle from it. Finally, we placed the aquarium on the rover base to check whether it could carry the weight and still move. The rover successfully carried the aquarium and moved.

Problems and blockers

The 60 mm mecanum wheels were not able to properly support the weight. We could not find a suitable caster wheel despite searching several shops. We needed a stronger frame to support the aquarium and the components.

Decisions

We decided to move away from the original 60 mm mecanum-wheel setup. We used the aluminium frame provided by Jayasurya. We replaced the earlier wheels with another set of four wheels. We decided to control the rover using an ESP32 and a local-host website.

Next week

Improve the rover's mechanical setup. Work on the Raspberry Pi and camera. Start testing object/fish detection and tracking. Plan how the rover can respond automatically to the detected movement.

Links

What we did

Our next step was to bring the Raspberry Pi into the project because it would handle the camera and fish-tracking system. We connected to the Raspberry Pi remotely using SSH through PowerShell. This allowed us to access and work on the Pi from our laptop. Before starting fish tracking, we first needed to make sure that the Raspberry Pi camera was working properly. We tested the camera using different camera commands and test programs, including rpicam-hello, and checked whether it could capture images and video correctly. After testing and fixing the initial camera-related issues, we confirmed that the camera was working properly.

Starting the fish tracking Once the camera was ready, we started working on the main part of the project — detecting and tracking the fish. Our first approach was to use YOLO (You Only Look Once) for object detection. Before training our own model, we tested the camera and detection with the available setup. We noticed an unexpected problem: even though our fish was red, the camera/detection output was showing the fish as dark blue. The system also detected people as blue, which made it difficult to clearly distinguish the fish from other objects in the camera view. This became one of our main challenges because simply relying on colour was not giving us reliable fish detection. We therefore decided that we needed to train the model specifically for our fish and our aquarium setup.

We started collecting images of our fish from different positions and conditions. We manually labelled more than 1000 images, marking the fish in each image so that YOLO could learn what our fish looked like. The labelling process took a lot of time because every image had to be checked carefully and the fish had to be marked correctly. We included images where the fish was in different positions and parts of the aquarium so that the model would not only recognise it in one particular location. After preparing the dataset, we trained the YOLO model using our labelled images. We then tested the trained model with new images and camera footage. We repeatedly checked the results and improved the training wherever the detection was not accurate enough. After several rounds of testing and training, the model became much better at recognising our fish specifically. This gave us a reliable starting point for the next stage, where we would use the fish's position to understand its movement and control the rover.

Problems and blockers

Setting up SSH access to the Raspberry Pi was one of the first steps we had to get working. We had to test the camera before beginning the tracking work. The camera/detection system did not represent the fish's actual red colour correctly and showed the fish as dark blue. It also detected people as blue, making simple colour-based detection unreliable. We therefore had to move towards a trained object-detection model. Creating a good dataset required manually labelling 1000+ images, which was time-consuming. The first model was not perfect, so we had to test and improve it repeatedly.

Decisions

We decided to use the Raspberry Pi for the camera and computer-vision part. We chose YOLO as our first approach for fish detection. Because the initial detection and colour representation were unreliable, we decided to train our own model. We manually labelled 1000+ images to make the model more familiar with our specific fish and setup.

Next week

Track the position of the fish using the trained model. Determine whether the fish is moving left, right, forward or backward. Convert the detected movement into rover movement commands. Start connecting the Raspberry Pi tracking system with the ESP32 motor-control system.

Links

• Code: # Check whether the Raspberry Pi camera is detected rpicam-hello

Display the camera preview for 5 seconds

rpicam-hello -t 5000

Capture an image

rpicam-still -o test.jpg

Capture an image after a 2-second delay

rpicam-still -t 2000 -o test.jpg

Record a 10-second video

rpicam-vid -t 10000 -o test.h264

from ultralytics import YOLO

Load the YOLO model

model = YOLO("yolo11n.pt")

Train the model using our fish dataset

model.train( data="data.yaml", epochs=50, imgsz=640, batch=16, name="fish_tracking" )

Test the trained model

results = model.predict( source="test.jpg", conf=0.5 ) path: /home/pi/fish_dataset

train: images/train val: images/val

0: fish

• Photos / CAD: fish tracking demo videos

https://github.com/user-attachments/assets/0fe73372-cad0-411d-8595-1c96e9e69063

https://github.com/user-attachments/assets/ec2f21c9-5562-4859-bf95-afc372da9829

Goal this week:To move from controlling the rover through the ESP32's own Wi-Fi website to controlling it through the Raspberry Pi, so that the control system would be smoother and less laggy.

What we did

In the previous weeks, we had already connected the vehicle, placed the aquarium on it, and successfully tested its movement. At that stage, the rover was being controlled using an ESP32, which created its own Wi-Fi network and hosted a local website for controlling the vehicle. Although the vehicle was working, the local website was lagging and the controls were not responding as smoothly as we wanted. We discussed how we could improve this, and Shan suggested moving the control system to the Raspberry Pi. Our plan was to keep the Raspberry Pi and ESP on the same Wi-Fi network and use the Raspberry Pi as the main control point. Before making this change, we had to make sure the ESP side was working properly. We faced an issue where, when the ESP32 was disconnected from the laptop, its Wi-Fi connection/local website would also stop working properly. We also had trouble uploading the required code to our previous ESP32. To continue testing, we got a NodeMCU and made the required motor-driver and power connections. We uploaded the motor-control code to the NodeMCU and successfully enabled its Wi-Fi. After that, we tested the vehicle again and confirmed that the wheels and motors were working. We then continued troubleshooting the original ESP32 because we still needed to understand why its Wi-Fi and programming setup was not working as expected. During this troubleshooting, another problem appeared: the USB port of the ESP32 was damaged. The ESP32 itself could still power on and work, but the USB port could no longer be used to upload new code. Because of this, we could not continue programming that ESP32 normally. So, this week became less about the final Pi control and more about getting the ESP side stable enough to make the transition.

Problems and blockers

The ESP32's local control website had noticeable lag. The ESP32's Wi-Fi/local website did not behave as expected when disconnected from the laptop. We were unable to upload new code to the previous ESP32. During troubleshooting, the ESP32's USB port was damaged, preventing further code uploads. We therefore had to use a NodeMCU to continue the motor and Wi-Fi testing.

Decisions

The ESP32's local control website had noticeable lag. The ESP32's Wi-Fi/local website did not behave as expected when disconnected from the laptop. We were unable to upload new code to the previous ESP32. During troubleshooting, the ESP32's USB port was damaged, preventing further code uploads. We therefore had to use a NodeMCU to continue the motor and Wi-Fi testing.

Next week

Connect the Raspberry Pi and ESP/NodeMCU to the same Wi-Fi network. Create a control system on the Raspberry Pi. Send movement commands from the Pi to the ESP. Test forward, backward, left, right, U-turn and stop commands. Work towards replacing the laggy ESP-hosted website with the Raspberry Pi-based control system.

**Goal this week:**To control the rover using the Raspberry Pi instead of the ESP's Wi-Fi, create the control website on the Pi, and test the wheels, ultrasonic sensor, and fish tracking together.

What we did

After last week's testing, our main goal was to make the Raspberry Pi the main control system for the rover. We first tried to connect the ESP and Raspberry Pi to the same Wi-Fi network so that they could communicate wirelessly. However, this did not work as expected. The ESP was only working properly when it was connected to the laptop. After trying different ways to make the Wi-Fi connection work, we decided not to spend more time on that approach. Instead, we decided to connect the NodeMCU/ESP to the Raspberry Pi using USB. We then uploaded the required code to both the ESP and Raspberry Pi so that the Pi could send commands to control the rover's wheels. We also decided to create the local control website on the Raspberry Pi itself, instead of hosting it through the ESP. This was expected to make the control system more usable and reduce the lag we faced earlier. Once the connection was ready, we first tested the wheels and motor movements from the Raspberry Pi. After confirming that the wheels were responding correctly, we connected the ultrasonic sensor and tested it separately. We then tested our fish-tracking system using the Raspberry Pi camera and the trained model. The wheel control, ultrasonic sensor, and fish tracking were all working successfully when tested separately. This was an important step because all the individual parts of the project were now working. The next challenge was to bring everything together into one complete system.

Problems and blockers

The ESP and Raspberry Pi could not communicate properly through the same Wi-Fi network. We found that the ESP worked only when connected to the laptop, so we dropped the wireless approach for now. We switched to a USB connection between the Pi and ESP. Another major problem appeared with the power supply. Earlier, we were using three batteries of 3.75 V each, giving us around 11.25 V nominally. After changing the wheels and motors, the new setup required much more power. The batteries were getting drained in around 5 minutes of operation. We tried different batteries, but they were also getting drained quickly. Our measured requirement was around 14 V, 2 A, so we realised that we needed a proper power source capable of supplying enough current for the new motors. Because of the power problem, we could not continuously test the complete system using the batteries.

Decisions

We decided to use USB communication between the Raspberry Pi and ESP/NodeMCU instead of relying on Wi-Fi communication for now. We moved the local control website to the Raspberry Pi to make the control system more usable. We decided that the wheels, ultrasonic sensor, and fish tracking would first be tested separately before integrating them. For testing, we temporarily used an external power supply instead of the batteries so that we could continue testing the wheels and tracking system. We also decided to find a suitable battery/power source that can handle the rover's higher power requirement.

Next week

Find a suitable battery that can provide enough voltage and current for the new motors. Integrate the wheel control, ultrasonic sensor, camera, and fish tracking into one system. Make the rover respond automatically to the fish's movement. Test the complete system with the aquarium and fish.

Goal this week:To improve the fish tracking and start connecting it with the rover's wheel movement.

What we did

We temporarily borrowed a battery from someone so that we could continue testing the rover while working on the power-supply issue. Using the temporary battery, we tested the rover with the aquarium and checked the wheel movement. We tested the fish tracking again and tried to connect the tracking system with the wheel movement. Initially, we were using YOLO for fish tracking, but after trying it several times and facing different issues, we decided to try OpenCV instead. With OpenCV, the fish tracking gave us better results, so we continued with this approach. If the fish is stationary, the wheels should remain stopped. If the fish is moving, the wheels should start moving. We tried connecting this basic fish-movement detection with the wheel-control system. During testing, the Raspberry Pi kept powering off because the available power supply was not sufficient.

Problems and blockers

We had several difficulties with the YOLO-based fish tracking, so we changed our approach to OpenCV. Connecting the fish tracking directly to the wheel movement was more difficult than testing each part separately. The Raspberry Pi was repeatedly shutting down during testing because of insufficient power. The temporary battery helped us continue testing, but it was not a permanent solution. Decisions

Decisions

We decided to continue with OpenCV for fish tracking because it was giving better results in our tests. We started with a simple moving/stationary logic before implementing directional movement. We used a borrowed battery temporarily so that testing could continue while we worked on a proper power solution.

Next week

We decided to continue with OpenCV for fish tracking because it was giving better results in our tests. We started with a simple moving/stationary logic before implementing directional movement. We used a borrowed battery temporarily so that testing could continue while we worked on a proper power solution.