Individual Components testing and development

Our project is current into our the development phase for the individual aspects of the project and this blog will be dedicated to updating on the progress we have covered so far!

If you haven’t seen our introduction blog and want to find out more about us you can read about us here.

Mechanical Design
Our mechanical design is currently into the hull fabrication phase after rounds and rounds of intense discussion with control systems considerations taken into account, electronics interfacing problems and also computer vision dilemmas and sorted out before we finalised on the current design as shown here below in the CAD render.

Front view of the 3D Render of our AUV Mechanical Design

The AUV will have a total of four thrusters with two at the side and forward facing in the middle of the AUV and another two thrusters one at the bow and the other at the stern of the vessel facing upwards(seen in the cylinders through the AUV). The bow of the AUV has a hemisphere with a transparent acrylic dome which will house our camera system. The two sonars will be placed in a sonar mount at the bottom of the dome. The AUV will have four degrees of freedom. Forward/reverse and yaw will be controlled by the side thrusters. Heave/dive and pitch will be controlled by the two bow and stern thrusters.

Control Systems
The control system of the AUV will be utilising Proportional Integral Derivative Feedback Control (PID) which is commonly used in various autonomous vehicle applications (our Electronic Speed Controllers use it too which is encapsulated from us and even your home air-conditioner uses it!). Whilst the PID algorithm was made for linear applications, it has proven to be quite responsive to various types of non-linear situations and hopefully it would prove the same underwater where the dynamics are more non-linear in nature due to the drag force being proportional to the squared of the velocity given the drag force will also be the only non-linear term in the dynamics equation for underwater vessels. Anyway this is all in theory, so once the AUV is up and ready, with the four thrusters in place we will be running test runs to tune the Kp, Ki and Kd parameters pertaining to control system stability for the various Degrees of Freedoms we are operating in.

Experimenting with the Ardupilot Mega hardware which will perform the autonomous control with its onboard IMU and servo/ESC control outputs
Here the APM 2.0 is hooked up to a portable Digital Signal Oscilloscope Nano 2 from Seed Studio in the debugging of PWM at the output pins

For our AUV, yaw and pitch is corrected based on angle by applying feedback control on the various angle of tilt and calculating the error terms from the accelerometer and gyroscope sensor readings from our Ardupilot Mega(above) which has an onboard Inertial Measurement Unit. The IMU of the Ardupilot Mega contains a three axis gyroscope, a three axis accelerometer and a magnetometer. The more problematic control system to implement would be on the other two degrees of freedom. Forward/Reverse autonomous control will be implemented by feedback control on the displacement of the vessel with its own calculated position since start, based on a dead reckoning algorithm. Lastly, Heave/Dive autonomous control will be implemented by calculating the error terms from the depth sonar sensor in combination with dead reckoning to account for the depths the sensor is unable to detect.

Electronics and Actuation
Selection of thrusters was another difficult issue that we faced. In our first iteration of tests we tested the suitability of Electric Ducted Fan(used in RC park jets) units for underwater applications but they were mostly made for high speed running at above 3000kV (that is 3000 RPM per  volt) and either drew too much current or did not have enough torque to pull the water at that high speed. We also played with different configurations of Electronic Speed Controllers which are made to control brushless DC Motors. If anyone noticed our actuation is actually largely based on RC Electronics and it was inspired by the success of Diydrones (here) and also our supervising professor who does research in artificial intelligence on embedded systems and used RC planes for his work.  Additionally a lot of autonomous vehicles research work have also been based off RC electronics. Apart from that brushless DC motors ran more efficiently and required low maintenance but speed control is generally more complicated than brushed DC motors. But given the benefits of a BLDC motor, coupled with a linear ESC with a variety of configurable functionalities(such as adjusting the timing to “soften” the power of the motor), the use of RC Electronics was a premiere choice.  As a side bonus, the brushless motors were surprisingly (at least to us) waterproof and ran perfectly fine in water after discoverin people who had run their motors underwater for days and testing out on our own (not without fear of short circuiting ourselves).


Testing the current draw on the high torque and low speed outrunner motors we purchased

In a most recent test run we managed to fit our 600kV motor onto the EDF unit that we bought after a bit of hacking and modification and fitted it onto our Coconut Pi Mk I, a makeshift floating container solely to test the thrusters out. The motor and ESC combination this time performed way better with better thrust output and powerful speed. Our design requirement for the motor of an underwater AUV were low speed and thus low kV and high torque output on the motor. Similarly for the propeller we aimed for less number of of blades and less amount of torque generated (though the 5 blades still generated quite a bit of torque). We selected these based on the low speed requirement of the AUV to perform the various tasks and power conservation for the AUV to last longer with lesser current draw.


Testing the thrusters on the Coconut Pi Mk I in a pool

Depth and Obstacle Detection
The AUV will require Depth and Obstacle Detection too and to achieve that we decided to deploy Sonars. However, sourcing for the right sonar that could function well underwater was another difficult task by itself given the high price range of the deep sea ones(we do not have much a hefty budget for the project) and ineffectiveness of its functionality in swimming pools of depths of 1m – 3m given the common operating depth being in the range of a minimum of 2 metres at least. We came up with other range detection options like laser rangefinders but the high end ones were costly to implement or had bad range underwater. Also the attenuation of lasers underwater was another issue that we would have to handle if we deployed those.

title Our MB7078 in a waterproof housing interfaced with a TTL-RS232 Convertor and connected to an Arduino Uno

So we bought a set of sonars from Maxbotix and calibrated the MB7078 sonar, selected primarily for its IP67 rating (waterproof up to 1m) but tested only in outdoor scenario and not for underwater purposes. We brought the sonar out in a local swimming pool and derived some really interesting results!


For starters this was our Proof of Concept that you could use these “cheap” sonars underwater(at least for swimming pool context depth ranging). Next, the plot of data points that we got was a near linear plot of the actual ground distance vs the readings from the sonar, which are already calculated for us using the speed of air but placed underwater. Second by using linear regression, and deriving a line of best fit, the gradient was found to be 4.169 which was close to the theoretical gradient of 4.31 (by dividing speed of sound in water by speed of sound in air both at 30 degrees celsius). Lastly we had an interesting y-intercept of 50 cm which meant that we did not have a direct proportional constant in the transformation. As mentioned above the graph was plotted based on just 4 data points, which may not be accurate enough for our application but as our Arduino got affected by the water after we accidentally dipped it into the water, we discontinued with our experiments for another time. Additionally the sonars were placed close to the surface and there may be surface reflections causing inaccuracies in our readings. Another issue we discovered was the minimum range of these Sonars. The one we tested in the swimming pool had a minimum range of 150cm and that was physically sound given, the minimum range in air being 30cm and since these devices work by measuring the time taken for sound pulses to reflect off obstacles and the hardware limitation is most likely on this measurement. Based on that, the faster speed of sound in water would result in a longer minimum range. So that multipled by 4.3 would give us a theoretical minimum range of 130cm which corresponds closely with our collected range of 150cm.

Computer Vision
The Computer Vision aspect would be the hardest portion and the greatest in determining the successful competition of the various tasks that we have to complete. Currently, our vision system will consist of a USB Webcam (Yes a USB webcam) with 640 x 480 pixels of resolution. Our Computer vision algorithm will be based on the OpenCV libraries from Willow Garage. We are currently still experimenting with a variety of techniques such as Edge detection, Hough Transforms and image segmentation.


Our USB Webcam interfaced with a Raspberry Pi

Embedded Software Design
Now comes the really exciting part (okay maybe that’s because I am a Computer Engineer), the embedded software architecture of our AUV. Our main controller board will be based on the Raspberry Pi as we mentioned in our previous blog post which will be running on the stock Raspbian Operating System for now for full compatibility with the hardware. It will be interfaced with another Arduino Mega custom board, the Ardupilot Mega via the serial interface. So one question which may pop up in everyone’s mind would be the decision behind our selection of not one but two controller boards for our application. There is an article here which explains the difference between the two but we decided to incorporate both for more critical reasons than just processing power and power savings. For our AUV, the Raspberry Pi will be responsible for Computer Vision and the more algorithmic and computational tasks whilst our Arduino will handle the actuation and control systems for the AUV. Whilst the Raspberry Pi definitely has the computational power to handle everything, it however does not have the precise timing that a baremetal microcontroller has. The various timing critical processes (like ESC/Servo control) may get preempted due to Linux being a Multi-tasking Operating System and not to mention the Interrupt overheads that may further cause complications for these real-time systems. And this is exactly why we need the Arduino, to handle the low level precise control for our system using a Timer-driven multi-tasking kernel. At the same time we needed the Raspberry Pi for its greater computational power and the benefits of a full fledged multi-tasking operating system with all the goodies of multithreading and also the many libraries for opencv being available to us. The added memory was a limitation also faced by the Arduino which only has 8KB of SRAM which was pretty pathetic for Computer Vision applications.

titleThe Embedded System Architecture of the AUV

The software and hardware architecture is still under development as we test more of our various components and we will leave the details of it out first until our next blog update!

Introducing Coconut Pi

We are a team of Undergraduate Engineers embarking on an exciting journey into the embedded realm of Autonomous Underwater Vehicle Development. The Singapore Autonomous Underwater Vehicle Competition 2013(link) is an Autonomous Systems Competition organised under the IEEE OES Singapore Chapter and we are participating in this International Competition with participants coming from all over the world, much like the AUVSI scene in the US but this is the first time Singapore is doing it. The Singapore AUV Challenge 2013 Taken straight from the website: “The competition is a forum to showcase system-engineering skills in underwater environment for budding engineering students. The competition also aims to create more interests within students in autonomous underwater robots technologies. Each team must have a fully functional autonomous underwater vehicle (AUV). The AUV may follow a marked line on the bottom of pool. There are three major tasks for AUV. The first task is to cross a gate by swimming under it. The second task is to bump a flare mounted ball. And third task is AUV coming out of water at a designated area. The successful completion all the tasks in the shortest possible time decides the winner. Achieving each task will gain points associated to it. Also extra points will be given based on time taken to complete the tasks.”

The Who

Goh Eng Wei
A student in Computer Engineering specializing in Control Systems and Artificial Intelligence. He will be handling the control systems and dead reckoning algorithms.

Doan Viet Tiep

Viet Tiep is a student from Computer Engineering with specialisation in Embedded Systems. He will be handling the Sonar and obstacle detection.

Kenny Tan

Kenny is a student in Computer Engineering with background in embedded systems design and high level programming design. He will be handling the Computer Vision aspect, path recognition and and flare detection algorithms.

Shanmugam Muruga Palaniappan

A student in Electrical Engineering with specialisations in embedded systems. He will be handling the actuator system and electronics interfacing.

Devansh Sharma

A student in Mechanical Engineering with specialization in Automobile Engineering. He will be working on the mechanical design and kinematics of the AUV.

The What

Our team has been kindly sponsored by RS Components in the design, assembly and programming of the fully autonomous system. Given the requirement of the competition we need to create a highly intelligent system that is completely autonomous and this means that there can be no human intervention  able to navigate waters by itself and that is defined as to be line tracking, obstacle detection and object identification.

Our AUV has been “christened” Coconut Pi, after the Raspberrry Pi as our platform will be based on the Raspberry Pi as the central controller. And here is the logo that we designed for it with a bit of geekiness added it 🙂


The Why

This competition for all five of us is one of complete voluntary nature and we have taken it up on top of our own final year academics coupled with our Final Year Projects (this is not our FYP if anyone was wondering) which is usually the last mile for any Engineering student at the National University of Singapore(NUS). To us the project is one of hobbyist nature and we are but a group of undergraduates who are passionate in our respective fields and this multi-disciplinary (and so very cool!) project satiates our thirst to do something with our newly acquired skills in our studies at Engineering!

So follow us on our facebook fanpage at or stay up to date as we post our fortnightly blog updates to Designspark! Our team is also open to suggestions and opinions from the Designspark Engineering community. You can either comment on our blog posts or just scroll through our daily pictures and updates on our facebook page and leave a helpful comment or suggestion for us to consider in our development process!