HARDWARE
FROM PAPER TO REALITY
For primarily biological science and computer science students, hands-on engineering is definitely not intuitive, let alone simple.
1. Planning
Planning it alone was already a challenge — from design to science, we had too many questions and too few answers. But as Dr Ho and Tony mentioned at the start; we all start somewhere, not necessarily the right place — in fact, who defined where right is? And so begins us going with the flow, and then realising how impractical a design is, and then back to the drawing board, to and fro, until we came up with something.
We had 3 main considerations:
firstly, how it will look.
Initially, we wanted a spherical buoyant object, wouldn’t that be cute? A floating ball that contained a camera!
There was, of course, a major problem with this, and the very reason why boats are not designed like that to begin with — a sphere is too symmetrical. In fact it has infinite lines of symmetry, and that makes it very difficult to break symmetry to move. There is a reason why fishes are not round, and it didn’t occur to us until we proposed our idea and saw Dr Ho’s and Tony’s bewildered expressions. Under their advice to see what other people have done, we eventually settled with a PVC raft based on this image:
The second issue on our list was how to ensure it will float.
And the CY1308 course we took a semester ago came in handy:
where the upthrust, or buoyant force, is essentially the negative of the downward gravitational force x density of fluid (ie. water, which is taken to be 1) x volume of the object that displaces the fluid, or simply said, submerged volume of the object.
Which sounded simple enough, until we realised that is a lot more math than we were expecting…
<insert calculations>
and the final, but very important factor, is how it will move.
This portion required a lot of strategic thinking. We wanted a boat with many degrees of freedom, hence the ball, but the issue with that was that although high degree of freedom should mean high mobility, it was very hard to control something like that. It might move left when we wanted it to move forward, and that was an engineering problem more than a coding issue. So judging by our standards, we did what we thought was realistic and pragmatic: forward only. Direction changes could come easily if we just re-orientated ourselves to face the “new front”.
Like Tony loves to iterate: “Work smart not work hard.” This would be conveniently settled through pump controls: if we could just turn on the left side pumps, we could turn the boat around!
2. Building
3D prints and Aluminum profiles
As the old adage goes: Measure twice, cut once. Unfortunately, that was not the most intuitive thinking. A lot of times, we went ahead with a rough measurement, or a 3D print design that looks flawless, only to realise that there were a lot of things paper work doesn’t translate perfectly into… Which also explains why we have 3 versions of pipe holder brackets that we had to also find new names to call each file. From ‘pipe holder’ to ‘final bracket’ to ‘mickey mouse’, at least in that sense our creativity was limitless.
In the beginning we had no idea how to go about printing anything. And in the beginning we also didn’t think we would ever need to 3D print anything. But look how far we’ve come!
There were test print to test the diameter and sizing…
…2D prints and scaling…
…And staring at our final product with a sense of pride and fulfillment…
and many other projects:
example file: Inner fastener
3. Circuitry
Towards the “end” of our project — we realised the need for a buck-booster so that the battery is compatible with our components.
It was a difficult time to learn Arduino as school was starting, but Anita took the challenge.
example of Anita’s notes:
trust me it gets more chaotic…
Initially, Anita had to do the circuits just for the router, however, after testing the entire circuit (router with cameras, rpi, arduino, etc) there was insufficient power for the cameras to function. The cameras were connected directly to the Rpi, however since the connection was most likely in series, there was insuficient current for the cameras. (circled in blue was the added component: Cameras had to be directly connected to the power supply, with a buck (5v))
Anita also had to reconfigure the arduino code and account for the buffer zone. The previous only had a fixed value which was not ideal since the voltage would jump when it is connected to the load. This causes the switch (Relay module) to oscillate between turning on and off.
As for the batteries, we decided to make use of the car battery since it has a larger capacity than the motorbike battery. It was also safer than a lipo battery, which is extremely volatile.