Coconut Pi: Individual components Development for an AUV

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.

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).

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.

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.

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.

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.

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!