“Take this one. It’s better.”
The pharmacist was recommending a dotted one.
“No, I need that one.”
I pointed at the plain one again.
He tried again to convince me. I was already embarrassed enough buying a “balloon” from the pharmacy with people around, but I had done my research. For what I needed, I was fairly sure the plain one was better.
The people who had come with me were not helping either. None of them wanted to enter the pharmacy, so I had been nominated to make the purchase alone.
The pharmacist had no idea why I was being so specific about a certain type of balloon.
To explain that, I have to go back a little.
In 2017, I was bored and wanted to build something for fun.
I only wanted an RC boat
What I actually wanted was a quadcopter. I loved aerial photographs, and building something that could fly sounded much more interesting. The problem was money. A decent quadcopter was expensive for me, and building one properly was not much cheaper.
Then I started watching RC boat videos on YouTube. The nice ones on AliExpress looked fast, clean, and ridiculously fun. I thought I could build a simpler version myself with PVC sheet, a brushless motor, a propeller, and whatever electronics I already had at home. Sakib and Arko joined me on that experiment from the beginning. We were just trying to build an RC boat because it sounded fun. Maybe we could take it to Hatirjheel, which was close to Mohakhali, and drive it around for no serious reason at all.
I ordered a few parts from AliExpress, including a brushless motor. I already had an RC controller at home. I rarely bought every component for a personal experiment from scratch. For some of the projects I did for other people, part of the arrangement was that I would keep the components afterward. Over time that left me with a useful pile of motors, controllers, sensors, and random electronics. An RC controller could cost around 3,000 BDT then, which was a lot of money for me, so having one already made the boat possible.
On the table, the brushless motor was exciting. It started with a few little ti-ti-ti beeps, then the propeller spun up into a high eeeeee that got louder as I increased the throttle. It sounded as if the boat would try to escape the moment it touched water. I finished the hull, attached everything, put it in water, and prepared for the dramatic splash I had seen in the videos.
The boat moved.
Very slowly.
I do not remember the actual speed, but watching it felt as if it needed several minutes to travel a metre. The motor was not the problem. My hull was simply bad. It pushed water instead of cutting through it, and the result looked much closer to an ordinary slow boat in Hatirjheel than the RC boats I had been watching online.
Still, I had built an RC boat. Making the same boat faster suddenly sounded less interesting than making the problem harder.
What if I made a submarine instead?
The submarine became something else
My first mental picture was a normal long submarine. It would move forward and turn gradually. That immediately created another problem. Where would I find enough clear water around Dhaka to let something like that make wide turns? Hatirjheel was not going to work. The water was too unclear for what I was imagining.
So I started wondering whether the vehicle needed to behave like a submarine at all. What if I added more motors around it so it could move more directly instead of depending on long turns? I was watching videos, searching Google, looking at whatever designs I could find, and trying to understand what people actually built underwater.
This was not completely my first encounter with underwater robotics. Back in 2016, Hirok and my batchmate Shakil had pulled me into a more serious project after I had proved myself enough for them to trust me. Part of that work touched underwater robotics, but we eventually ran into the same practical wall: even basic underwater components such as proper thrusters were difficult for us to source in Bangladesh. That attempt stopped there.
This new idea was different. It had started as a bad RC boat, and now I was deliberately making the problem harder.
I was searching Google, watching YouTube, reading papers and forums, and talking to whoever might know something useful. I also wanted someone else researching the problem independently.
That person was Tridiv. I told him I had this idea for an underwater robot and asked what he thought. He wanted to be part of it, so we split the research. He would find everything he could about how people were building underwater vehicles, I would do the same from my side, and after a couple of days we would compare what we had learned.
While doing that research, another question came to me: was there a competition for this?
I found RoboSub in the United States and another underwater robotics competition in Singapore called the Singapore AUV Challenge, or SAUVC. It was a competition for autonomous underwater vehicles. The United States felt very far away, and the visa process felt harder for a Bangladeshi student. Singapore felt possible. More importantly, I had not heard of people around us going there for this kind of competition.
The motivation in my head was not complicated: what if we could build this strange underwater thing and use it as an excuse to go to Singapore?
That was enough.
First we had to convince someone
Wanting to go to the competition was the easy part. We still did not really know what we were supposed to build. Tridiv and I kept working on the underwater research and the plan, while Sakib and Arko were already part of the build from the RC boat stage. At that point even the terminology confused us. Was this a rover? An ROV? An AUV? We kept calling it different things while learning what the words actually meant.
The distinction eventually became important. An ROV is remotely operated and commonly connected to the operator through a tether, essentially a cable. An AUV, an autonomous underwater vehicle, has to make decisions and operate without someone standing beside the water steering it. For SAUVC, we needed the second kind.
Somewhere around this stage, the project also got a name: Duburi, the Bangla word for diver.
We prepared a plan and took it to Dr. Khalilur Rahman, the faculty member supervising our robotics work. His approval mattered because we needed university support, access to labs, and eventually funding to make the project possible. He was skeptical, and reasonably so. Nobody around us had built this kind of competition AUV before. We had no proper underwater thrusters, no test facility, no established component supply, and very little experience in the domain. From his perspective, there were a lot of reasons this project might not work, so he initially suggested that we focus on something closer to what the university already knew how to support.
We were stubborn enough to keep returning.
We put the plan and 3D design on a pen drive, went back, and showed him again. Looking back, I think two things eventually worked in our favour. He knew we were not going to stop asking, and he also knew the limitations were so severe that reality might stop us on its own. We had already built enough strange things around the university that letting us try was not completely unreasonable.
He finally said yes.
Among the three of us doing most of the hands-on building, we each had an area we naturally leaned toward. I spent more time on software, Arko leaned toward mechanical work and electronics, and Sakib was strongest in electronics. But those were preferences, not boundaries. All three of us could work across the robot.
Arko also had a background none of us shared: he had been in the Army before joining BRAC University. His stamina was on another level. He was the strongest swimmer I had ever seen, not just within the team, and he could dive much deeper than the rest of us while carrying a weight. Sakib could swim normally. I, ironically, was building an underwater robot without knowing how to swim at all, so nobody was letting me anywhere near deep water.
I remember delegating the Arduino firmware to Arko. I asked him if he could write the firmware that would drive the motors and the lower-level controls. He looked at me and asked, “What is firmware?” I told him it was simply the code running directly on the controller. That was enough. He took it and worked on it.
That was fairly normal for us. We learned whatever the next problem required and crossed into each other's areas constantly. Sakib handled much of the electronics, while Arko's firmware became the layer that interfaced with those electronics and controlled the motors. The person who had initially asked me what firmware meant was soon writing the code that actually made the vehicle move.
After this many years, I cannot honestly remember who first suggested every solution. Most problems ended with the three of us sitting together, throwing ideas around, trying something, discovering why it was wrong, and trying again. Sakib was strongest in electronics. Arko increasingly handled the firmware, motors, and a lot of the physical work around the vehicle. I spent more of my time on programming and often ended up connecting the different pieces of the project. The boundaries were never clean.
Rahatul Amin Ananto also became part of the wider team. He had previously worked on an underwater ROV as a thesis project under Dr. Amitabha Chakrabarty. That project had different goals and constraints from ours. It could remain tethered and was built as an academic research prototype around water-quality work. Duburi had to survive repeated testing, travel to a competition, operate autonomously, and complete predefined tasks. Ananto had graduated by then and would sometimes join us after office. His contribution became more visible later, particularly around writing, documentation, and media communication.
For now, we had a much more basic question.
What should an AUV even look like?
Our AUV started with plumbing pipe
The AUVs we saw online looked beautiful. Metal frames, sealed electronics tubes, expensive thrusters, clean machining. They looked like machines that belonged in proper research institutes.
Ours started with PVC pipe.
Dr. Khalilur Rahman was mechanically minded himself, and Munir Bhai was the person in the mechanical lab who could turn student sketches into actual hardware. Munir Bhai had originally been found through a local fabrication workshop and later joined BRAC University. He had already worked on most of the other major robots built at BRAC University. Students could design strange things on paper, but when those things needed cutting, drilling, welding, fitting, or simply the practical judgment of someone who had made physical objects for years, Munir Bhai was often the person who made them real.
He and Dr. Khalilur Rahman put together a first structure using PVC pipes, screws, and a large PVC fitting in the centre for the electronics. It looked nothing like the polished AUVs we had been watching online, but suddenly our idea had a body.
Then we needed thrusters.
The commercial underwater thrusters we saw were beautiful in the way only someone already obsessed with mechanical things would understand. They were also completely outside our budget. Depending on what we looked at, one could cost hundreds of dollars. At that point our effective project budget was almost nothing. Later we had a formal budget around 50,000 to 60,000 BDT, but even then buying several proper thrusters would have consumed far more than we had.
So we asked a much cheaper question: what if we used ordinary geared DC motors underwater?
That kind of problem suited Arko particularly well. He loved exploring scrap yards and seemed to know where to look when we needed some strange mechanical part or material that was difficult to buy normally. For a project where we were constantly improvising with whatever we could find, that knowledge mattered more than it sounds.
The motors were not waterproof. They would degrade quickly. We did not know how they would behave under load in water. We also needed propellers that matched their relatively slow, high-torque movement. Quadcopter propellers were designed for a completely different operating speed.
We eventually tried blades from PC cooling fans. Munir Bhai fabricated small housings and helped us modify the fan blades so they could connect to the motor shafts. We put one of the improvised thrusters in a bucket, held it by hand, and switched it on. The water churned immediately, and the thruster pulled against my hand harder than I expected.
It felt surprisingly strong.
For a few minutes I genuinely wondered why anybody would pay hundreds of dollars for a thruster when we had apparently made one for less than ten.
Reality would correct that confidence soon enough.
Our first test tank was an elevator shaft
We initially arranged eight of those improvised thrusters around the frame: four vertical thrusters for up-and-down movement, and four thrusters at the corners for forward, backward, right, and left movement. For the first test we only needed an Arduino, the motors, and enough wiring to see whether this thing could go down and come back up.
The next problem was finding water deep enough to test it.
BRAC University's Mohakhali campus did not have a swimming pool. Pools were not particularly accessible to us elsewhere either. My apartment building, however, had an unfinished elevator shaft. The lift had not been installed, and rainwater had collected at the bottom.
Calling it a test tank would be extremely generous. The water was black, dirty, and smelled terrible. But it was deep enough, and at that point that was all we cared about.
Our landlord already knew that the students in his building spent a suspicious amount of time building robots, and he was unusually supportive. He let us use the space without making a problem out of it. We lowered the wired prototype into the water and switched on the motors.
At first it barely wanted to go down.
The PVC structure contained a lot of air, which gave it strong buoyancy. The motors that had felt so powerful in a bucket were now spending most of their effort fighting a machine that desperately wanted to float.
So we added a brick.
That brought the vehicle closer to neutral buoyancy. In simple terms, we wanted it to almost stay at the same depth by itself, so the motors would only have to move it instead of continuously fighting its tendency to float. Once the balance was closer, the improvised thrusters could push it down and bring it back up.
We recorded a video and took it to Dr. Khalilur Rahman.
See? It works. Now give us the next problem.
The first “balloon” I bought from a pharmacy was an engineering component
The next problem was much harder. Going down and up under remote control was not enough. Dr. Khalilur Rahman wanted the vehicle to hold a depth on its own, roughly the underwater equivalent of a quadcopter hovering at a fixed altitude.
Our first idea was to control depth through motor speed. If a certain motor command produced a certain amount of thrust, perhaps we could learn that value and use it repeatedly.
That idea failed almost immediately. The motors degraded after repeated exposure to water. Battery voltage changed as the batteries discharged. Water conditions changed. Small differences in load changed the result. A motor value that held the vehicle approximately still at one moment could send it slowly upward or downward a little later.
We needed feedback. The robot had to know how deep it actually was and adjust itself continuously.
We first tried several ways of measuring distance underwater. Arko and Sakib experimented with waterproofing sonar and Sharp infrared distance sensors. Sonar sends out sound and listens for what comes back, while the Sharp sensor uses infrared light and interprets the reflection. Sound and light behave differently underwater than they do in air, and the particular sensors we had were designed to work in air. Neither gave us the reliable depth measurement we needed.
We needed another way to measure depth, so we started thinking about pressure instead.
Air-pressure sensors were familiar from flying robots. Atmospheric pressure changes with altitude, so a pressure reading can help estimate height. The sensor itself, however, was not something we could simply expose to water.
Then we started thinking about the problem differently. What if the sensor stayed dry inside a tiny sealed air chamber, but one side of that chamber used a flexible membrane? As the vehicle went deeper, water pressure would push the membrane inward. The pressure inside the chamber would rise, and the ordinary air-pressure sensor could measure that change.
We imagined using a small plastic jar, something like the little Meril lip-gel containers we had around us. The remaining question was what to use as the flexible membrane.
A normal birthday balloon seemed obvious. For reasons that made perfect sense to us at the time, we decided a balloon from the pharmacy would probably be better. The advertising had spent years telling us how strong and protective the material was. Our engineering conclusion was that it must be better rubber.
So I went to a pharmacy to buy one.
The others were too embarrassed to come inside with me. I had already decided I wanted a plain one. The pharmacist kept recommending a dotted one and telling me it was better. I kept insisting that I knew exactly which one I needed.
From his perspective, I probably looked unusually confident for someone who was visibly uncomfortable buying a balloon from a pharmacy. From mine, I had already done the engineering research.
We stretched it over the little chamber, put the pressure sensor inside, and tested it in water.
It worked.
Not only as a funny experiment. It actually gave us pressure readings that changed with depth. We connected the sensor to the vehicle, wrote the control logic around it, and for the first time the robot could go down and approximately hold a depth by itself.
We were delighted until a day or two later, when the readings stopped behaving properly. The pharmacy balloon material had lost much of the elasticity we needed. It had proved the idea, but it was not a reliable long-term membrane.
We went back to birthday balloons. They turned out to stay flexible for longer, so the pharmacy balloon was removed from the final design.
By the time we showed the sensor properly to Dr. Khalilur Rahman, the visible membrane was a birthday balloon. I do not remember us explaining the earlier version.
He gave us the next challenge: now make it move forward and backward while keeping itself under control.
We needed a swimming pool, so we built one
At some point Dr. Khalilur Rahman stopped being satisfied with our videos and said he wanted to see the testing himself. He came to my apartment and saw the elevator-shaft water, the smell, the dirt, and the fact that none of us seemed particularly bothered anymore.
He decided we needed a proper place to test.
Finding a swimming pool in Dhaka turned into its own project. We contacted restaurants, hotels, and other places with pools. Almost everyone refused to let us put an experimental robot in their water. Their concern was understandable. They imagined oil leaking, equipment contaminating the water, or guests becoming uncomfortable about swimming afterward. Even offering to pay usually did not solve it.
We did get access to a proper swimming pool once, at the Bangladesh Biman Authority office, but occasional access was not enough for repeated testing.
Dr. Khalilur Rahman tried the university side too. We even looked around the construction site of BRAC University's future campus in Badda to see whether some space there could work. It was still a construction site and clearly not practical.
Eventually Dr. Khalilur Rahman made a harder decision. If we wanted to test repeatedly, we needed a place of our own, so we would build the smallest useful version of a swimming pool.
Through BRAC and BRAC University, he managed to get permission for a small unused space at the BRAC Driving School in Niketon. Behind the driving school, near a nursery, there was an area that had mostly been used for dumping rubbish. It was not glamorous, which made it perfect for us.
A small concrete tank was built there. I do not remember the exact dimensions, but it was only a few metres across, enough for Duburi to descend, move forward, and turn a little. It was not a swimming pool by any normal definition.
We called it our swimming pool anyway.
The driving school helped with the practical details too. There was a water line used for washing cars, and with a long hose we could fill the tank. A drain at the bottom let us empty it. The first evening taught us that we also needed lighting if we planned to stay after dark, so lighting appeared too.
The water was not blue swimming-pool water. It could look a little green, but compared with the elevator shaft it was wonderful. We could see through it, and getting into it did not feel hazardous.
On the first day we tested Duburi there, we ended up getting into the tank ourselves. From then on it really was our pool.
The team was becoming bigger than the people building the robot
The project had also started attracting younger students around us. Elham, Shemonto, Anik, Adil, Fahim, Kingshuk, and others were still juniors. They were curious enough that whenever there was a screw to fix, a part to carry, or some small job nobody had assigned, somebody would usually do it.
As the project became more serious, that enthusiasm grew, but they were already doing the work that never appears in a robot specification.
Kingshuk also had one advantage that became surprisingly useful: he had a bike. Our Niketon testing ground was roughly three kilometres from the university, and arranging university transport every time was not practical. For quick trips between the university and the test tank, Kingshuk and his bike became one of the team's unofficial transport systems. It was also the bike on which I learned to ride.
The tank was outside and not chlorinated. Algae grew on the walls. Sometimes we arrived and found a dead frog in the water. Once there was a dead crow. There was a building on the other side of the wall, and rubbish occasionally ended up around the tank too.
Very often, before the main team was even ready to test, some of the juniors had already gone ahead. One or two would get into the empty tank, scrub the walls with brushes and washing powder, clean whatever had accumulated there, disinfect it when needed, and start filling it with the long hose. By the time we arrived with Duburi, the place was ready.
Nobody had to promise them Singapore for that. At that stage we did not even know exactly who would travel. They were part of the wider Duburi team, but the travel team was still uncertain. They simply wanted the robot to work.
That winter we usually started testing around 5 p.m. and could stay until one or two in the morning. On some of those winter nights, by that hour the temperature could be around 15°C. The first few seconds after getting into the tank were always the worst. The water felt painfully cold around the legs. At home, winter was cold enough that I sometimes wanted heated water before taking a shower. At the test tank, somehow none of us cared.
Our landlord and apartment guard got used to our strange schedule and never made our returns at one or two in the morning a problem. Police checkpoints stopped us during some of the first late-night trips too. After seeing the same students carrying the same strange equipment often enough, some of them started recognizing the robotics team.
Batteries, bottles, and a robot that wanted to spin
As the mechanical system became more permanent, we stopped thinking about the brick as the final answer to buoyancy. We needed batteries anyway. High-power LiPo batteries were common in quadcopters, but we did not like the idea of sealing them inside an underwater housing where heat or damage could become dangerous. They were also more power than our slow geared motors really needed.
Lead-acid batteries were cheaper and much heavier. Normally that weight would be a disadvantage. For us, weight was something we needed. We placed multiple lead-acid batteries around the frame and used them as part of the ballast.
Sometimes we went too far and Duburi became too heavy to float properly. The answer was empty plastic bottles. Add batteries when it floated too aggressively. Add sealed empty bottles when it sank too easily. Back and forth we went until the vehicle sat close enough to neutral buoyancy that a small amount of thrust could move it up or down.
The larger tank revealed another problem the elevator shaft had hidden. When we tried to move forward, the vehicle did not simply travel straight. It wanted to rotate.
All of our propellers were effectively spinning the same way, which made the body want to twist in the opposite direction. In engineering terms, that is reaction torque. Quadcopter builders solve the same problem by pairing clockwise and counterclockwise propellers so the opposing torques cancel each other.
Our improvised thrusters were built from computer cooling fans, and nobody sold us a convenient mirrored set. After we realized what was happening, and Sourabh Bhai confirmed the same principle from his drone experience, we physically reversed two diagonal thruster assemblies and ran those motors in the opposite direction.
That removed most of the obvious rotation, but the vehicle still did not hold a perfectly straight line. The frame was crude, the improvised blades were not matched, and small differences between motors were enough to push it gradually off course. We needed heading hold.
We congratulated ourselves like Boston Dynamics
Our next thought was to add an IMU, a small sensor unit that included a gyroscope and helped Duburi estimate which direction it was facing. The sensor gave us yaw, pitch, and roll. Yaw is turning left and right, pitch is tilting the nose up and down, and roll is leaning sideways. For moving straight through the pool, yaw was the part we cared about most.
Again, the first version of the idea sounded easier than the real one. Cheap gyroscopes drift over time. A magnetometer can provide a reference for direction, but magnetic interference changes its readings. Duburi had eight motors around the frame, and motors contain magnets. We had effectively surrounded our direction sensor with things designed to disturb it.
A lot of testing became an exercise in finding a position where the sensor was disturbed as little as possible, isolating it, tuning the control, running the vehicle, watching it drift, changing something, and trying again.
This was also where Sakib became our closest thing to ChatGPT for electronics, years before we had anything like that to ask. A circuit that behaved perfectly well on an ordinary robot could become much harder to debug on Duburi. Motors, power, sensors, and the surrounding electronics introduced interference and other variables that were difficult to isolate. When an electrical problem stopped making sense, Sakib was usually the person we expected to figure it out.
The problem with Sakib was that once you gave him a difficult problem, he did not know when to stop. I eventually made a strict rule for everyone, including Arko: never give Sakib a serious debugging problem after 10 p.m.
If we ignored that rule, there was a good chance he would spend the whole night chasing it. The next day he would turn up with the solution, explain what had been wrong, and then his body would effectively shut down. He would fall asleep and sometimes miss the testing session that needed the fix. So the 10 p.m. rule was partly project management and partly an attempt to make Sakib sleep.
We never achieved a laboratory-perfect heading system. But eventually the vehicle could move forward while holding approximately the same direction instead of slowly turning itself around.
I remember one of those tests when the robot finally moved through the water, kept its depth, and kept its nose roughly where we wanted it. Everyone around the tank started clapping.
We joked that we had just created Boston Dynamics.
From the outside, it was a PVC frame carrying improvised motors, lead-acid batteries, plastic bottles, and cheap sensors. From where we were standing, it had just learned how to hold itself underwater and move in the direction we asked.
That felt enormous.
I wanted the ugly PVC pipe gone
There was one part of the first structure I never liked: the central PVC fitting that held the electronics. It worked, but to me it looked too much like a large bathroom pipe connector. We were already building almost everything from whatever we could find. If we were really going to carry this machine to Singapore, I wanted at least one part of it to look intentional.
I suggested making a transparent cylindrical electronics housing from acrylic. Dr. Khalilur Rahman told me not to waste time on it. His point was reasonable. We still had major technical problems, and bending flat acrylic sheet into a sealed cylinder was not one of the problems the competition required us to solve.
So Sakib, Arko, and I bought the acrylic and tried it at home anyway.
We had a heat gun, essentially a much hotter and more dangerous cousin of a hair dryer used around electronics and fabrication. We had occasionally even used it to dry hair.
With the acrylic, we spent roughly five hours heating and bending the sheet little by little until it became something close to a cylinder. It was not perfectly round, but it was transparent, which already looked dramatically better than the PVC fitting.
Sealing it was harder. We experimented with acrylic solvent, silicone, shoe adhesive, epoxy, and different combinations of them. The smells became part of the experiment too: some shoe adhesive could leave us feeling a little dizzy, epoxy had a pungent smell of its own, and silicone was not exactly pleasant either. Eventually epoxy resin became one of the more reliable answers because once it cured it formed a hard seal around the joint.
A lot of Duburi was developed in this slightly backwards order. We would spend our own money trying something, discover that it failed, try another version, and take the working result back to Dr. Khalilur Rahman. If the successful acrylic housing cost around 3,000 BDT, the real experiment might have cost us closer to 4,000 because another attempt had already gone into the bin.
When I finally carried the acrylic housing back and admitted that we had built it anyway, he looked at it and liked it. There was no ego about having told us not to spend time on it. His concern had been whether it was worth the risk. Now that it existed and worked, he was happy to use it and cover the cost.
That became part of our relationship through the project. He had the responsibility to think about safety, time, university resources, and whether an experiment made sense. We were students with considerably worse risk assessment. Sometimes we deliberately took Duburi home, tried things without asking first, and returned only after we could prove that the idea worked.
Somehow, that combination kept moving the project forward.
Getting accepted changed everything
By early February 2018, Duburi could move forward and backward, hold its depth, and hold its heading well enough for us to show that we had built a functioning vehicle. SAUVC required teams to submit a qualification video before coming to Singapore.
I remember the night as February 8, 2018. Before midnight, we recorded the video and sent it.
Tawfiq Taher, a Bangladeshi living in Singapore and part of the SAUVC team, was the person communicating with us from their side.
When the response came back telling us that we had qualified, Singapore suddenly stopped being an idea.
We were going.
We could barely believe it. Every AUV we had seen in old competition videos looked more polished than ours. We had tried hard, but part of us still expected someone to look at the PVC frame and improvised thrusters and say no.
That changed the energy around the entire project. The juniors who had already been helping became even more involved. If Duburi needed carrying, somebody wanted to carry it. If something needed fixing, someone was already reaching for the tool. They were part of the team whether or not their names would eventually appear on the first travel list.
By then, we had started describing Duburi as Bangladesh's first AUV. We had searched for earlier projects and spoken to people in the robotics community, but could not find another autonomous underwater vehicle built in Bangladesh before ours. If someone can show me an earlier one, I am happy to correct the claim.
Now Duburi had to see
Qualification did not mean the autonomous part was finished. Until then, most of our work had been mechanical and electronic control. Duburi could hold depth and heading, but now we had to give it machine vision, essentially the ability to make decisions from what its cameras could see.
That became mostly my problem. A laptop obviously could not sit beside the pool processing everything. We needed something small enough to sit inside Duburi, so we used a Raspberry Pi. We also needed cameras. Even a Xiaomi action camera felt expensive, so we experimented with cheaper Chinese action cameras and whatever could realistically fit inside our budget.
For connectors around the housing, some of our ideas came from the satellite ground-station work I had seen before. Antenna-style connectors looked mechanically strong and less likely to become useless immediately around water, so we borrowed the idea for Duburi.
I started working with Python and OpenCV for the machine vision. Our approach was direct: isolate colors, identify simple shapes, and turn what the camera saw into rules the vehicle could act on.
The first SAUVC challenge we focused on was a gate. It was physically simple: two colored vertical sides with a dark bar across the top. Duburi needed to find the two sides, aim for the space between them, and go through.
Detecting a known object in a clean image was one thing. Detecting a very simple colored structure from a moving camera underwater was another. A face contains a lot of features and texture. Our gate was basically a few bars. Worse, underwater light distorts color, and the cheap camera we could afford did not produce anything like the footage from expensive underwater systems.
Dr. Khalilur Rahman asked for proof instead of accepting my claim that the idea should work. First I wrote a program at home that could detect and track colors through my webcam.
Then he pushed it further: make a small ground robot see a gate and drive through it.
So we built the small demonstration in the robotics lab using a compact ground robot with mecanum wheels. A Raspberry Pi processed the camera feed and sent movement commands to an Arduino controlling the wheels. The robot detected the simple gate, lined itself up, and drove through it. It worked.
That proved the logic in air. Underwater was still another story.
We made a gate for our Niketon tank and tried the same idea. The greenish water, algae, lighting, and cheap camera changed the colors enough that the controlled demonstration stopped being reliable. We had managed to use a proper swimming pool once earlier, but that was before this machine-vision work started. We no longer had reliable access to a chlorinated competition-style pool where we could reproduce the visual conditions from Singapore.
Our only references were old SAUVC videos and whatever test objects we could build ourselves.
So I built myself a fake swimming pool.
When the real pool did not exist, I made one in Unity
I had never really worked in game development, but I knew Unity existed. I did not need to make a game or publish anything. I only needed a crude environment on my computer that looked enough like the competition course to become a playground for the vision code.
I spent a couple of days following tutorials and learning only what I needed. I made a pool, gave it water and a blue tint, added the gate, and roughly recreated the objects from the SAUVC course.
The competition had more than the gate. Farther along the course were colored target mats where the robot could drop a ball. There was also a task involving an underwater acoustic pinger, a small beacon that repeatedly sends sound through the water so a vehicle can locate where the sound is coming from. Ships and underwater systems use similar ideas for locating things acoustically.
We researched the pinger task seriously and eventually ruled it out. Building our first AUV was already stretching every limitation we had. Adding underwater acoustic localization on top of it was too expensive and too far outside what we could reasonably finish in time.
The vision plan used two cameras. A forward-facing camera would look for the gate and other objects ahead. A downward-facing camera would look at the floor of the pool.
That second camera gave us another useful idea. Swimming pools have straight dark lines on the floor. GPS was unavailable underwater and our IMU readings could drift, but the pool itself contained a reference. If we could detect and count those lines, we could use them as a crude indication of where Duburi was and whether it was slowly rotating away from the direction we wanted.
It was an ambitious plan built on a lot of assumptions. We knew that.
But the Unity environment gave me somewhere to keep testing while Sakib and Arko worked on the physical vehicle. Without reliable access to the kind of pool we needed for vision testing, simulation became the best playground I had.
I still have that old Unity project on GitHub. I also remember how little Unity I actually learned. I learned exactly enough to make the environment I needed, which was more or less how the rest of Duburi had been built too.
A proper PCB, and approximately sixty solder joints of enthusiasm
By then the experimental electronics already worked. While I was increasingly buried in vision and autonomy software, Sakib was cleaning up the hardware side and turning our temporary circuit setup into something firmer that we could actually carry to Singapore. He designed a proper custom PCB, sent the layout to a shop for fabrication, and then the components still had to be placed and soldered onto the printed board.
I loved soldering. I had spent years making circuits on breadboards and Vero boards, and I was the kind of person who would see someone else soldering a Vero board and volunteer to do it for them. The hot-flux fumes rise almost straight toward your face, and I liked the smell in the same way some people like the smell of petrol.
Duburi's PCB was large and had a lot of components and solder points. When the fabricated board arrived, I enthusiastically told Sakib I would handle the soldering.
Somewhere around fifty or sixty joints later, my enthusiasm became much more theoretical.
I handed the rest back to Sakib and returned to the software.
That small episode probably describes the team better than neat job titles do. We each had areas we were stronger in, but all three of us crossed between software, electronics, and mechanical work whenever Duburi needed it.
The chronology was messier than this makes it sound. Even before the first complete structure existed, we were already building small proofs for individual problems because Dr. Khalilur Rahman wanted us to show that the ideas were actually possible. We had already experimented with basic machine vision, made a small ground robot detect and pass through a gate, and tried several ways of estimating depth before settling on the air-pressure sensor.
We left Bangladesh without a full autonomous underwater test
This is the part I am not going to rewrite into a cleaner engineering story than it actually was.
We never properly tested the complete machine-vision system on Duburi underwater before leaving for Singapore.
The physical vehicle worked. Depth hold worked. Heading hold worked well enough. The vision software worked in controlled proofs of concept and in the simulator. But we never had a suitable environment where we could confidently connect all of those pieces, put Duburi underwater, and run the full autonomous mission from beginning to end.
Our plan was to go to Singapore, finally get access to the real competition pool, see what the water and lighting actually looked like, and finish the integration there.
It was not a comfortable plan. It was the only plan we had.
Behind the scenes, the three of us were realistic about what we wanted from the competition. We wanted to compete seriously, but winning was not the reason we had started. We wanted to prove that students in Bangladesh could build something like this at all. We wanted other teams to see that we could make things, and we wanted BRAC University to see what became possible when students were given room and resources to attempt difficult projects.
Dr. Khalilur Rahman never treated that as an excuse to aim low. He kept pushing us toward the actual tasks, asking for proofs, and making us research things even when we eventually had to admit that something like the pinger was beyond what we could finish.
Looking back, one part is easy to say clearly. If either Sakib or Arko had been missing, I do not think Duburi would have been built. Without Dr. Khalilur Rahman, I do not think we would ever have reached an international competition. I often found myself bridging the software, hardware, and people around the project, but Duburi depended on all of them.
Once SAUVC had invited us, the travel side moved surprisingly smoothly. Dr. Khalilur Rahman had been through international competitions before and knew people who could help with the practical process. We got the invitation, visas were processed, flights were booked, and suddenly the thing that had started with me watching RC boat videos was packed for another country.
On the morning of the flight, we did not look like the polished international competition team I might have imagined months earlier. We had barely slept. Our clothes were fine, but our bags looked like workshop bags because that was what they had been. Some were worn and torn from carrying robot parts around.
Dr. Khalilur Rahman looked at the three of us and laughed that he seemed to be taking three labourers to Singapore.
He was not entirely wrong.
We had a vehicle that could hold its depth, mostly hold a heading, and run software that we hoped could understand enough of the competition course to give us a chance.
What we still had not done was prove all of it together underwater.
That part would have to happen in Singapore.
We took Duburi and got on the plane.