B.R.U.C.E. (Bio-inspired Robotic Underwater Creature Experiment)

INTRODUCTION

For this project we were tasked with creating an autonomous, robotic bio-inspired,submersible 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, autonomously locate and "hunt" three underwater beacons , and be aesthetically pleasing.  This part of the project was intended to be the second of three design spirals but due to the increased complexity afforded by the submersible and vision components of the project this would be its final incarnation. 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.

                           Figure 1: Demo day grading criteria diagram

                         Figure 1: Demo day grading criteria diagram

MECHANICAL SUB-SYSTEM

SYSTEM OVERVIEW

For this project we decided to create a robotic shark which we have internally named B.R.U.C.E. (Bio-inspired Robotic Underwater Creature Experiment). With this design we really wanted to make it look and move like a real shark. Hence, the shape was inspired by that of several sharks in nature such are the great white and mako sharks. The prototype that was built measured just over two feet in length from nose to tail and 8 inches tall at the widest point of the body without the fin. Due to the submersible aspect most of the electronics are housed in a watertight hull located just below the center-line of the body for weight distribution/buoyancy purposes.

                                                                   Figure 2: Mechanical system cross-sectional view

PROPULSION

In order to obtain the desired motion from our robot we used  attempted to construct an abstracted version of a shark tail. A spring steel skeleton is sandwiched between four independent articulated sections. The movement is then actuated by a servo located in between the second and third sections (as seen in Figure 3) sweeping between positions in a sinusoidal pattern. The fin in the rear then serves as a sort of paddle to move water and propel the shark forward. The spring steel backbone allows the tail to articulate freely while providing a solid mechanical connection between section. It also adds realism to the motion as it flexes the non actuated area between sections 3 and 4 as the tail moves through the water.

                                                           Figure 3: Isolated propulsion system rendering

STEERING

The steering system for this robot was comprised of two main systems: the tail articulation and the pectoral fin differential. As we can see in Figure 3, the tail also contains a steering servo in addition to the propulsion unit. This servo allows the robot to turn while maintaining the same propelling motion downstream of sections 1 and 2. In case the shark needs to turn faster than the tail would allow it can deploy its pectoral fins independently. By tuning one of the fins it can use it as a brake and the body will begin to pivot around it. These fins were originally designed as dive planes for the next phase of the project but the can also be used for steering in situations where the robot needs to avoid obstacles.

  Figure 4: Top down section view shows both steering systems: tail articulation in the rear, and pectoral differential steering.

Figure 4: Top down section view shows both steering systems: tail articulation in the rear, and pectoral differential steering.

BODY

In the interest of authenticity we first determined a profile, seen in Figure 5,  that approximated that of a shark and tried to define it using simple splines. The overall length of the shark was determined by space needed to house the pressure hull and batteries in the main shell. Cross sections at the head and tail ends were also created to ensure that the body would follow one smooth curve from nose to tail. From the inception of this design we paid attention to the weight distribution and placed the center of the pressure hull (one of the heaviest components in our system) 2 inches below the center-line of the shark to ensure the center of mass was well below than the center of buoyancy created by the curved underbelly.

                                                                    Figure 5: Original layout sketch used to determine proportions based on required pressure hull size and desired body proportions

Due to the complex curves and convoluted geometry resulting from the bio-inspired profile the design was primed for 3D printing. Due to the limitations of the build plate size the head and main shell were split into two components. The components were 3D printed in ABS. Figure 6 shows the details in each of the components of the body. The head was simply cosmetic so it is a shell of the profile with teeth and a channel in the mouth with a vision cone to allow the PixyCam housed at the end of the pressure hull pressed against the base of the head to see with minimal obstruction. The main shell is features a curved cradle where the pressure hull tube rests, the holes in the support allow cable ties to pass through to secure the hull to the body and the batteries to the side of the supports. A small door at the bottom serves as a quick water drain point and as a hatch to replace the battery powering the servo motors without having to remove the top section of the shell. The top section of the body shell closes the system and holds the main fin which serves as an E-stop that cuts power to the motors.  The fin can be pulled out breaking the contact of the magnet on the fin and the magnet inside the pressure hull.

             Figure 6: Shark body is comprised of the cosmetic head, and the top and bottom shells. The bottom shell                                 connects the tail and head of the robot and is the mounting point of the pressure hull

           Figure 6: Shark body is comprised of the cosmetic head, and the top and bottom shells. The bottom shell                                 connects the tail and head of the robot and is the mounting point of the pressure hull

To ensure the boat would float fair and level the we performed some preliminary ballast calculations. Our initial analysis revealed that the robot would be able to float without any additional flotation placed in the cavity in the top shell. Since the head has a wider profile than the tail it created more lift and so a bag of sand of approximately 300 g was placed in the ballast pocket of the head. This weight was sufficient to make the shark float level without the assistance of the lead screw weight system at the bottom of the main shell.

PRESSURE HULL

The pressure hull was constructed out of 4 in diameter acrylic tube, two nylon caps with two retaining rings each created a watertight seal for the non-water resistant electronics. The tube was cut to its length of 9 inches using a fine tooth band saw and sanded to precision. An acrylic  laser cut baseboard allowed for mounting of all the components within the board without having to fix them to the inside of the tube. Figure 7 shows the machined end caps that served as pass through conduits for the power wires and servo wires from the Arduino control central to the outboard systems. These tapered fittings were then sealed using a strong silicone based sealant. A small porthole was cut on one of the end caps and covered with a clear acrylic piece to allow the Pixy camera to see out of the pressure hull. A valve on the tail end cap allowed us to pressurize the hull to avoid water trickling in and ensure water tightness at the pool depth.

                                Figure 7: Pressure hull end caps  and sealed hull inside the shark body

                              Figure 7: Pressure hull end caps  and sealed hull inside the shark body

OUTCOME

The mechanical system worked fairly well given the expedited timeline we set out for ourselves to ensure there would be ample time for electrical, software and integrated system testing. There were some issues with hard to reach hardware that would have been removed with mechanically interlocking mechanisms but without too much information about the print tolerances and no time for test prints we decided to play it safe with the use of hardware. The spring steel in the tail served its purpose well but we did see fatigue cracks in between sections 1 and 2 due to the repeated and aggressive steering angles causing the steel to sharply bend at a point for multiple cycles. The fully built system looks like a shark and floated as expected. A larger tail fin would have helped propelling the robot at higher speeds than the ones we achieved in testing but beyond that the propulsion was adequate and fairly natural looking. Due to complications during testing we were not able to allow the two day downtime required to paint the body to match the color scheme depicted in the renderings. The result is an eye catching combination of colors which were a function of the filaments available to our printers and the multiple build plates required to print the entire system.

                                                                                                                                                                Figure 8: Fully assembled prototype

                                                                                                                                                              Figure 8: Fully assembled prototype

ELECTRICAL SUB-SYSTEM

SYSTEM OVERVIEW

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

                                                                                                      Figure 9: Electrical system data flow diagram

                                                                                                    Figure 9: Electrical system data flow diagram

The diagram above shows the flow of data between the sensors, motors, and Arduinos with their respective shields. The computational load of the system is divided among three Arduinos, one for each of the sections of our code. Depending on their function the Arduinos were fitted with shields that would facilitate connection to their sub components.

SENSE

The sense Arduino is responsible for the pixy cam data, water level sensor, E-stop, temperature sensor, and ballast tank sensor. The pixy cam can detect colors it has been “trained” on and sends the size of the squares of said color on the image in its field of view. The E-stop is a switch operated by magnets, if the magnets are in contact then power is allowed to flow to the motors. The water level sensor is placed at the bottom of the pressure hull and senses if there has been a breach in the enclosure. The data from these sensors comes into the Arduino IMU shield and is transferred from the Sense Arduino to the think Arduino. The ballast tank sensor was not used in this spiral but the infrastructure was laid out for its use when the robot would also submerge in the third spiral.

THINK

The think Arduino takes in data from the sense Arduino and the XBEE radio module. The think Arduino is able to send and receive data to the XCTU monitor in an outboard laptop and use the commands sent by the operator to send instructions to the Act Arduino based on its current mission and the information incoming from the sensing module.

ACT

The act Arduino mainly communicates to the four servos in the system. It uses a standard motor shield to plug in all the servo motors. Two LEDs plugged into this Arduino indicate whether the Think Arduino has cut power to the motors and if the code is running through the loops as expected.

POWER

In order to understand the power requirements of our system we created a power table (Figure 11) 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.

                                                                                                                                             Figure 10: Power flow system diagram

                                                                                                                                           Figure 10: Power flow system diagram

                                                                                                                                                                        Figure 11: System power table

                                                                                                                                                                      Figure 11: System power table

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 25 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. The power flow diagram shows how power is transferred from the batteries to the DC/DC converter which then provides the appropriate 5V to the Arduinos.

OUTCOME

Packaging the electronics in the pressure hull was a challenge with all the wires but we managed to do so. However, we failed to seal the pressure hull adequately where the LED light cables ran out of the cap and so the electronics were exposed to the highly chlorinated pool water. There was also another incident where a o-ring out of its groove allowed water to flow into the hull again during testing. Both of these times we submerged the components in a deionized water bath for three hours and allowed them to dry before use. Despite our precautions corrosion set in as we continued to run power throw the system and we began to have faulty connections with the Pixy cam, the steering servo, the E-stop, and the XBEE; as well as a small puff of smoke from the act Arduino.

SOFTWARE SUB-SYSTEM

SYSTEM OVERVIEW

The software was broken down into three key sections: sense, think, and act. The processing load was divided between three Arduinos to allow space for all the shields and minimize the processing load on each part of the system. Figure 12 demonstrates the basic structure the code used by robot to execute its mission. The colors of each section have been highlighted to show which processes are run on each of the Arduinos.

ExZ3rzM.png

OUTCOME

There were issues communicating the pixy cam data from the sense Arduino to the think Arduino, and it was hard to diagnose whether this was due to an error in the code structure or the result of a corroded pin from the water. Because no pixy cam data was being received the system would be stuck in hunting mode. We developed a remote control code to be able to move the shark in the direction of the beacons remotely. However, we then lost XBEE communication we hard coded a triangle sequence to the shark where it will swim forward for an amount of time then turn left for a few seconds and swim forward again, it would do this in an infinite loop.  

AREAS FOR IMPROVEMENT

It is hard to identify areas for improvement as we were stymied by the water damage in the electronics. Testing before the sudden loss of data and communication was encouraging and indicated that our system would be able to perform on the demo course. With a little more consideration during the mechanical design phase we could’ve made munting components easier with interlocking mechanisms which would have allowed us to be able to inspect the pressure hull better to avoid water coming in. A larger tail fin would have also helped propel us faster in the water making the turning in the hard coded demo a little more efficient.