Project Turtle-duck

by Juan Carlos del Rio, Jayce Chow, Christina Segar, Paul Nadan, Tony Kim, Shopia Nielsen




For this project we were tasked with creating an autonomous, robotic bio-inspired,vehicle in the span of 4-5 weeks in teams of 5-6 people from various disciplines. The success or failure of any vehicle would be judged by the following metrics: It would have to be able to float fair and level without assistance, move under its own power, be able to travel in a straight line with a range of ± 1ft, turn to avoid obstacles and continue in a straight line three times, have clean wiring, and be aesthetically pleasing.  Since this was the first in a series of spirals of increasing complexity the vehicles would have to be relatively simple in order for the team to be able to concentrate on integration and assembly rather than complicated electro-mechanical systems. Additionally, in order to foment learning,  every member of the team would have to take part in some way in the design, fabrication, and testing of each system.

ENGR 3390_ Spiral 1 Report.png



The overarching theme for this design spiral was simplicity. A simpler design would allow the team to focus on making a well integrated/ working final product rather than debugging complicated systems. Therefore, for our design we attempted to follow this underlying principle by using a standard boat hull shape (rather than going for a more bio-inspired design), having a single propulsion nozzle, and steering with a differential steering system that was easy to control.

ENGR 3390_ Spiral 1 Report-2.png


The propulsion system for the duck consisted of a 500 Gph bilge pump that would take in water from the front of the boat. A high flex 1 in PVC tube  would then run the water from the exit nozzle of the pump to a rudder in the rear to provide some thrust vectoring. We ran the pump at 8 V rather than its full 12V to decrease the output so that it would propel the Turtle-duck at slow speeds decreasing the power consumption and minimize the effect of hydrodynamic instabilities in the system.

ENGR 3390_ Spiral 1 Report-3.png


The steering system for this robot was comprised of two main systems: the vector thrust and the flipper differential. As we previously mentioned the thrust provided by the pump can be directed to aid turning. The maximum angle the rudder could achieve was 10° either direction from center. Therefore to ensure a tight turning circle we added the wings as steering. Figure 4 shows how a single wing can be lowered in order to create drag in the desired turning direction. By doing so the center point of the wing becomes the center of the turning circle and thus the turning circle is significantly decreased. This also has the effect of significantly lowering the speed of the duck thus reducing the possibility of hydrodynamic instability hampering our ability to continue in a straight line after the turn.

ENGR 3390_ Spiral 1 Report-4.png


The hull was designed in two sections and the overall shape was meant to be streamlined while providing ample buoyancy. The top of the hull features small pockets for the servos and flippers and a large pocket for the tupperware to nestle into. A single large bore in the center accommodates the bilge pump and a small protrusion allows for the pump’s cables to be routed to the electronics box. On the bottom side a channel was cut out to route the rudder nozzle from the pump’s off center exit to the the rudder.  Six holes were also placed to aid with alignment between the two halves using dowel pins. The bottom half of the hull has a cutout at the front to serve as a water scoop to the bottom of the pump. Five pockets were included to help lower the center of gravity of the system below the center of buoyancy using stainless steel ballast plates. Before gluing the two halves together the hull was covered in a layer of fiberglass and a separate layer of epoxy to stop the foam from breaking during the assembly process. The entire hull was then spray painted yellow to give it a duck like appearance.  The hull then attaches to a wooden baseboard using countersunk  ¼ -20 screws.

ENGR 3390_ Spiral 1 Report-5.png

To ensure the boat would float fair and level the we performed some preliminary ballast calculations. The natural layout of the heaviest components such as the pump and the electronics box helped distribute the mass fairly evenly front to rear. We then added ballast plates to help compensate for any discrepancies between the center of mass and center of buoyancy along the length of the robot and lower the center of mass. We assumed that due to the symmetry of the design we would be dead center on the lateral weight distribution. However, since the weight inside the electronic box was not distributed evenly and was above our center of mass the robot toppled sideways in the water. A steel keel approximately 1.2 ft x 6 in was then added to help stabilize the hull in the water. By doing so we also added weight and lowered the center of the mass.

                                                     Center Of mass        Center of Buoyancy

Mass/Buoyancy Potential         3.13 kg                       4.44 kg (1.42 FOS)

Location (X,Y,Z) mm              (- 185.38 , - 41.19 , 0)       (-179.33, -39.51,0)

ENGR 3390_ Spiral 1 Report-6.png


Ultimately there were several issues with the implementation of our mechanical system. The propulsion of the boat worked fairly well and propelled out duck at reasonable speeds. However, as our robot picked up speed it would begin to around a center line increasing in amplitude with every turn and eventually turn away from the center. We believe that this instability was caused by the keel not being epoxied centered on the bottom the hull. It was centered enough that it kept the duck floating level on the water but as the boat picked up speed the combination of the weight offset and the hydrodynamic effects it caused it to veer left. We attempted to correct this instability by adding flaps and compensating with the nozzle vector but the complex nature of the instability thwarted us. We then attempted to lower the output of the pump to stop us from reaching the velocity at which the instability presented itself but the pump would not run at lower voltages. Hence, we were not able to achieve a relatively straight line for any reasonable period of time or distance. Another system that did not quite function as expected was the rudder. Despite the tube being relatively compliant the servo still struggled to keep it straight and had to continuously fight against the tube’s natural bend. The steering system worked well overall, we doubled the surface area of the wings before demo to compensate for the short range of our IR sensors and it helped us turn tightly enough to narrowly avoid walls when the sensors we working properly.



The project guidelines dictated that apart from powering our propulsion and steering systems the electrical system should aso include a number of safety measures such as a fuse for the battery and an E-stop switch that would cut power to all moving components. Additionally a blinking light would indicate that the control program was running and another solid light would indicate the electrical system was operational.



In order to understand the power requirements of our system we created a power table (Figure 8) where we listed the most power consuming components of our system and ensured our battery would be able to power all of them simultaneously. Additionally using this table we calculated the estimated battery life of our system.


The power table indicated that we would be able to power all of our electronics would be able to run with our battery for around 15 minutes. Battery life was a key feature as it would enable us to test for longer without having to open the electronics enclosure to swap out the battery. We used an expansion shield to connect the IR sensors, servos and the motor shield connected to our pump. In order to obtain our desired voltage to the arduino and the pump we used a DC/DC converter.


In order to keep the wiring inside the electronics box we laser cut a thin piece of MDF to which we screwed down the arduino, DC/DC converter and strpped in the battery.  We opted for a relatively shallow tupperware which meant that we had little clearance for the connectors so we had to allow the top of the tupperware to bulge up using a heat gun. Small slits in the corners of the box allowed connectors to run outside the enclosure for the servos, switches, pumps, and indicator lights. These slits were waterproofed after the fact to ensure the integrity of our sensitive electronics in the case of a rollover. The wires ran in between the baseboard and the hull where possible to minimize their visual impact on the final design.



Due to the tight packaging of the electronics it was hard to cleanly route all the wires cleanly, especially since were were testing and debugging up to demo day. The main issue in our system was the left IR sensor was faulty causing us to to turn into walls on our left side. Smaller issues also arose which we were not able to completely debug. The solid run light we installed would not turn on and so we had to to use the one on the arduino which was not very visible. The on/off switch worked well but the killswitch failed to cut power to all the systems it needed to causing handlers to get whacked by the wings sometimes. There were some issues powering the pump which would then cause the system to go haywire when the battery was low.



The software was broken down into three key sections: sense, think, and act. Using these three principles an Arduino uno would then control the electrical and by extent the mechanical systems to avoid the walls and travel across the pool efficiently. Figure 10 demonstrates the basic structure the code used by the turtle-duck to perform these actions effectively.



The sensing section of the code is relatively simple. In this section the arduino stores the values of the left and right IR range finders and both bump limit switched located in the bow ow the boat. The IR sensors return a range of values while the limit switches have high and low states. A debugging stage averages the five last values coming from the range finders to ensure the robot reacts to the walls/obstacles only and not to a random anomaly.

Screen Shot 2017-10-17 at 1.27.55 AM.png


With the inputs received from the sensors the code then proceeds to its thinking stage. The first thing it will check for is if it has crashed. If either of the limit switches have been activated it will shut off the bilge pump. If it did not E-stop then it will proceed to go straight if it was not within a turn timmer. The code then proceeds to determine if its got a wall coming up on either side. If it detects a wall consistently it will then inform the act loop which direction it should turn to (logically the opposite direction of the wall its detection).

Screen Shot 2017-10-17 at 1.36.25 AM.png
Screen Shot 2017-10-17 at 1.36.40 AM.png


When the think section detects a wall the act code proceeds to turn by lowering the wing located on the side of the turn and turning the rudder servo in the same direction to vector the thrust in the appropriate direction. It does so for a set amount of time which we determined during testing. The act portion also ensures that within this loop the LED is blinked to indicate that the system is running. If the E-stop is triggered then the LED is set to high and will no longer blink.

Screen Shot 2017-10-17 at 1.37.36 AM.png
Screen Shot 2017-10-17 at 1.38.26 AM.png


The software worked fairly well but it was hampered by the faulty measurements it obtained from the left IR range finder. It was also thrown for a loop when the voltage of the pump varied causing the flips to alternate. We attempted to correct some of the instability with a piece of code that would dip the right wing periodically to counteract and leftward motion caused by the keel but it was not useful. We had issues setting the center for the rudder as the value the servo believed to be center did not appear to be so.


The immediate area where we could make a massive improvement on this design is in the keel. Had we given this a little more forethought we could have routed a slot of the correct thickness at the center of the hull. Also had we placed the keel closer to the trailing edge it could have helped it center the boat along its path. We would also do well to switch the range finders to those used by other teams to allow for wall detection further out and more reliably. Spending some more time laying out the wire could have helped us debug our electrical issues such as the E-stop and the malfunctioning LED.  Given a camera we could’ve actively corrected for deviation using a variation of the dip code we mentioned and the duck could go in a straight line by dipping its wings until it finds the center of a target.