Ship Happens Blog

The MechE team, despite being shorthanded, got the boat mechanically complete! We finished mounting the new deck on the Njord Vessel, making it wider to add more stability as we look to navigate the waves of Norway. Additionally, we worked with the Autonomy team to make adjustments to the sensor mast to accommodate the new, slightly larger LiDAR. Finally, we prototyped and tested a few methods of crane lifting the bolt with eyebolts, and arrived at the concept that we plan to use for deploying and retrieving the vessel during the Njord challenge. We’re really excited to pass the boat to the Autonomy team to get the boat tested and competition ready before we have to begin the shipping process for Norway in a few weeks.

The mechanical team is gearing up for the Njord Challenge! Some mechanical members switched to help the electrical team since they are going to be the most swamped getting Ship Happens ready to test before going to Norway, but there are still plenty of mechanical tasks that need to get done as well. We bought eye bolts to attach ropes to and mounted them on the structural parts of the boat, since Njord requires the boat to be deployed into the water with a crane. Additionally, we worked on getting the azipods repaired and ready to go for our first test after some damage that they sustained during Roboboat. We also worked with the electrical team to make some adjustments to Athena to prepare it for testing as we, along with the electrical team, finish up the final hardware adjustments to Ship Happens as we approach the Njord Challenge.

The mechanical team was working extremely hard to get the mechanisms on the boat ready to bring to competition. The ball launcher, designed to accurately shoot balls for the Feed the Fish challenge, was mounted to the boat, and is able to shoot very consistently. The water gun mechanism was being adjusted and tested by the autonomy team, and the aiming system seems to mechanically work really well. Jared worked on the ball collection mechanism for the Ocean Cleanup task, and got it mechanically complete in approximately a week. Between our tests of the motor that deployed the mechanism, the effectiveness of the tape flaps that pulled the balls in, and the creative way that it hands off to the ball launcher, we were relatively confident that it would be an extremely viable mechanism for Ocean Cleanup. Meanwhile, Julianne and Jessica designed, manufactured, and mounted a new rack and pinion mechanism run by a continuous servo motor to lower the hydrophone into the water for Ocean Cleanup as well. We need this mechanism because we wanted to reduce drag while we move through the water, but the hydrophone needs to be in the water for it to function properly. This rack and pinion mechanism allows the hydrophone to be strongly mounted while maintaining the ability to move it in and out of the water.

In order to efficiently transport the Roboboat and maintain level ground for a suitable workspace, the cradle was redesigned with accessibility and storage in mind. Eventually fabricated out of laser cut marine plywood, the Cradle v3 design includes a detachable bridge that holds the legs together. The detachable bridge allows for the separation of the cradle legs, optimizing storage space. In addition to that, while not incorporated in the final assembly due to time constraints, slots in the legs allow for the insertion of two parallel arms. The arms enable users to lift and transport the cradle without moving the Roboboat. In future competitions, the more robust design will allow for reliable transportation and efficient disassembly and storage.

In order to efficiently keep the electronic box cool, we have designed custom heat sinks made out of aluminum for the solid state relays. The current heat sinks are not efficient because they block the airflow of the fan that will be placed next to them. By designing heat sinks that have fins parallel to the fan outside the electronic box, air will be able to move through the heat sinks beneath the relays and cool down the entire system. The custom heat sinks will be milled in the International Design Center of MIT.

Team Updates

We have onboarded 11 new recruits onto the team. In order to make sure those with less experience have guidance, we’ve split up our existing members onto separate project teams and assigned 3 to 4 new members to help. This project format will ensure that there is enough work to go around and that each team has an expected deliverable to work on for January. By the end of the month, we had a design review to go over all their progress and give feedback on their design decisions. Let’s see what these project teams did!

Azipods: Jessica Lam, Toya Takahashi, Tamilore Fashae, Kat Jimenez

One problem we wanted to tackle this season was the lack of maneuverability of our competition boat, Ship Happens. In the previous season, our boat struggled to make small maneuvers to prevent it from drifting into obstacles since the thrusters were locked in place. Ship Happens was able to rotate by spinning one thruster in one direction and the other in the opposite direction. While this simple strategy worked for large rotations to point the robot in a general direction, it was difficult to make precise movements since it took around 2.5 seconds to rotate 90 degrees.

Another smaller issue with our previous thrusters was that they needed to be screwed on and off the 8020s they were attached to every time our robot was deployed. This made the process of deploying Ship Happens inefficient, and prompted us to develop a more modular design for placing the thrusters and efficiently deploying our robot.

To increase our maneuverability and modularity, we designed a thruster pod in OnShape to rotate our thrusters in place. In this new design, a servo is connected on one side of a 1.7” diameter, 20” length PVC pipe, and a thruster is connected on the other, allowing the servo to rotate the entire subsystem. This subsystem is mounted inside a larger 2.4” diameter PVC pipe with Delrin bushings so the thrusters can easily rotate and be lifted into the hull during transport.

Currently, we are in the process of assembling the design we have in CAD. Most of the pieces of the assembly were 3D printed using the Ultimaker we have in our lab and we’ve been testing fits and tolerance and approaching the end of assembling the azimuth thruster pods.

What ended up being more time-consuming than expected was the process of drilling out the hulls. Since the thruster pods penetrate the hulls, we needed to drill out a large 2.5” diameter though each hull of our catamaran using a large forstner bit. Initially we attempted to do still the hold outside with a hands drill. The forstner bit worked well to cut the fiberglass and foam, but it was difficult to cut straight down so we switched to the drill press.

Once the holes were cut, we did a layup process on the newly exposed foam. For this, we added a few layers of fiberglass and epoxy to reinforce the foam and water proof everything. The first layer of fiberglass saturated in epoxy did not attach well to the foam so we used push pins to hold it in place.

We are very excited to integrate our thruster pod into Ship Happens and test out the new design as soon as the last aspects of assembling are completed!

Ball Launcher: Jared, Julianne, Haris, Ruth, Bella, Josh

One of the roboboat challenges, called Feed the Fish, is like a game of skeeball played from the boat. Our vehicle must be able to launch rubber balls (~2” diameter) at a skeeball-like target. To accomplish this task, we decided to make a ball launcher that could aim without rotating the entire boat.

Our launcher consists of a circular platform that stores the balls. This platform has holes that are sized to the rubber balls. As the platform rotated on a servo, the balls fall through another hole and land in the shooter. The shooter is mounted to a large gear, which we can rotate with a servo. This allows us to precisely control the aim of the shooter, as the whole shooter can rotate on its own.

Finally, the ball lands in the shooter which consists of a high-speed motor that spins flywheels. When spun at the right speed, the wheels can launch the ball to the target.

Most of the first iteration of the launcher is finished, and we learned a lot about the design through the fabrication of the shooter. First, we learned that the current method for connecting the shooter to the turret is not the most stable. These two mechanisms are currently connected by acrylic laser cut tabs that attach to the shooter’s side panels and hang from the gear. However, when we assembled this we discovered that the brackets did not provide a lot of stability for the shooter. We plan to stabilize this connection by using an L-bracket or axle to minimize movement between the shooter and turret.

Remaking Boat Deck: Ansel, Erin, Makar

The goal of this sub-project is to redo the deck of our autonomous surface vehicle, Ship Happens. The deck of the boat provides a flat and strong working surface for other sub teams to attach their modules to, and provides a barrier between the water splashing up between the hulls to the mechanical and electrical components that sit on the deck.

Because the boat is estimated to be very close to our max weight for the RoboBoat competition in March, we wanted to decrease the weight of the deck while we planned out what parts we needed to buy. We decided to replace our aluminum 8020 beams with carbon fiber beams, which we found in our lab, MIT Sea Grant. We also decided that since we were able to cut a lot of weight by using carbon fiber instead of aluminum, we wanted to add an additional beam along the length of the boat that will provide support below the wood planks that sit on top. This is important since the wood slightly warped last year, and we wanted to ensure that this deck would survive both the RoboBoat competition in March and the Njord Challenge which we plan to compete in in the Fall. We used strips of aluminum that were vertically oriented to support the wood, and bent the ends so that we could connect them to the carbon fiber tubes that run horizontally along the boat.

Currently, we are working on preparing the marine plywood for the top of the deck. This wood will need to be cut to size, holes that fit the new azipods will need to be measured and drilled, and screw holes will need to be drilled to attach to our support beams underneath. We also need to attach our support beams, and then finally assemble the deck and test it with weights.

We have mostly finished CADding the boat! This includes designs for our ball scooper, ball launcher, and thruster azipods (rotating thrusters that will make our turning radius smaller in the water). Manufacturing has started for the ball launcher and will continue when we come back in January.

Subteam 1: Task-Ponce de Leon / Fountain of Youth

No mechanical changes have been made to this mechanism. Last season, we simply did not get to this task in competition, but from our testing we believe that the mechanism we set out to spray water last season should work again.

Subteam 2: Task- Feed the fish

We finished the finalized the first version of the ball launcher. The system is divided into three main subsections: the revolver, the turret, the shooter. The revolver holds all the balls and controls when they are deposited into the shooter. The turret allows the shooter to rotate so we can aim independent of the boat's positions and the shooter is the flywheel system that launches the balls.

The revolver/ball deposit system is modeled after the ball drop arcade game. There are slots for the balls to sit in and a servo rotates a plate to move the balls until one eventually falls through the hole to the shooter. We went with this system because it utilizes only one moving part and we can reliably ensure that only one ball goes into the shooter at a time. All the balls are also stored horizontally which is an additional benefit because we want to minimize obstruction to the lidar. We also included a 3D printed dome to prevent balls deposited from the ball collection system from staying in the center of the plate or falling and damaging the servo.

The turret is controlled by a 180 degree servo. A small gear attached to the servo controls a larger ring gear that is connected to the rest of the system. The gears are laser cut out of ⅛” aluminum and stacked for a final height of ¼”. Originally we planned for the pieces to be made of acrylic because they could easily be cut for exact sizes, but after meeting with Chandler Griffin of iSensys recommended we go with metal because acrylic tends to crack easily. The turret is attached to the underside of the revolver so that the pivot point of the turret is concentric to where the balls drop.

The shooter is powered by a 6,000 rpm goBilda yellow jacket series motor. We haven’t found the ideal speed the flywheels should rotate at, but we decided to go with the fastest motor in the GoBilda series because the flywheel speed is more of a concern than the amount of torque. The motor is belted to the flywheel with the ability to easily change the gearing ratio. We also went with a belted drive so the motor could be placed such that the center of mass is as symmetrical as possible. The flywheel has a rubber tread which provides grip and compression to help launch the racquetballs. Once the ball drops into through the hole in the revolver the ball makes contact with the flywheel and is compressed between the flywheel and the ramp to gain rotational speed before being launched out. The shooter connects to the turret through two tabs that go into the ring gear. The shooter also has a delrin plastic bottom to support the weight of the shooter instead of the tabs and to increase the friction between the shooter and the deck.

Final CAD of all three systems:

Next steps: Over IAP (January) we should begin the prototyping, fabricating, and assembly process.

Subteam 3: Task-Ocean Clean up

At the last team time, we learned that the boat cannot drive into the enclosure with the balls so we moved forwards with the arm and elevator system. A spring loaded PVC arm with a sliding L piece is spring loaded and released when the boat approaches the task. The boat drives around the perimeter of the enclosure collecting balls. Once all the balls have been collected the L arm is reeled in with a winch to collect all the balls into one location. An elevator mechanism on the side of the boat will then pick up all the balls and deposit them into the revolver on the ball launcher.

Next Steps: At the moment, we are unsure if we have the manpower to implement this design so it is currently on hold for further development.

Subteam 4: Azimuth Thrusters

In our azimuth thruster design, a servo is connected on one side of a 1.7” diameter, PVC pipe, and a thruster is connected on the other, allowing the servo to rotate the entire subsystem. This subsystem is mounted inside a larger 2.4” diameter PVC pipe with Delrin bushings so the thrusters can easily rotate and be lifted into the hull during transport.

A 2.5” in hole will be drilled 6” inches from the top for the larger pvc to be mounted to and a 5” inch hole will be drilled 5” inches from the bottom to create a channel for the thruster to rest when the system is retracted.

From the tasks, it looks like we need to be able to collect balls from the water after detecting their location from a pinger, shoot balls into a skeeball board, and shoot water into a target. The last two tasks are the same as last year, so we plan to use the experience we gain through building and testing to make necessary improvements.

Subteam 1: Task-Ponce de Leon / Fountain of Youth

This task is very similar to the water gun task from last year with the main difference being the location of the target point. We decided to use the same mechanism from last year to complete this task. For this, we have a pump that continuously draws in water from the lake so we have a virtually infinite supply of water and two servos to control aiming. The pump we purchased last year has the specs to shoot water at the height required for the aiming system (figure below) which is compact, light, and works fairly well.

Next steps: Hand Mechanism to navigation to begin programming and testing.

Subteam 2: Task- Feed the fish

This task is almost exactly the same as the skeeball task. Last year we used a linear slide mechanism to deposit the balls into the buckets. After building and testing we realized that the bulkiness and weight of having an arm extend out two feet was not worth the additional accuracy provided. The racquetballs are relatively small compared to the bucket with a fair amount of room for error. Thus this year we decided to move forward with a flywheel ball launching mechanism. A flywheel will rotate quickly compressing the racquetball against a 3D printed ramp and launch the ball. A turret will be implemented to give control of the x,y position of the ball and the speed of the flywheel can be adjusted to control the height the ball is launched. We will begin a CAD design of this soon.

Subteam 3: Task-Ocean Clean up

Ocean Clean up is a completely new task introduced this year so we immediately went into brainstorming to find potential mechanisms. We were initially deciding between a net that would mount inside the area between the hulls to collect delivery balls and an arm that extends outwards to collect the balls.

The net is mounted between the hulls; one side is free to pivot and the other side is attached to a winch to control the height. The net will be lowered and the boat will drive through the area with the balls and once the balls are collected the net will be raised. The net would be well-supported by both hulls and any actuators required to move the balls can be mounted to top of the boat. The downside to the water well mechanism is we are unsure if we will be able to go inside the region where the balls are located.

The alternative method we discussed was an arm that reaches into the enclosure to collect the balls. A PVC arm is spring loaded to the side of the boat and will be released when we approach the region with the balls. The boat will drive around the perimeter collecting balls.A sliding L PVC piece is attached to the arm and can be pulled in with a winch system. The L PVC piece will ensure all the balls end up in a corner near the side of the hull. There will be a separate elevator on the side of the hull that takes the collected balls to the ball launcher. Because the pvc extends beyond the boat we are going to add pool noodles on the L slides so that it's supported by the buoyancy force. We also wanted to test how well the pvc would work at herding the balls so we did a couple of tests (video and photo shown below). The downside to this mechanism is that there are significantly more moving parts and therefore a higher risk for failure.

Subteam 4: Azimuth Thrusters

One problem we wanted to tackle this season was the lack of maneuverability of our competition boat, Ship Happens. In the previous season, our boat struggled to make small maneuvers to prevent it from drifting into obstacles since the thrusters were locked in place. Ship Happens was able to rotate by powering one thruster in one direction and the other in the opposite direction. While this simple strategy worked for large rotations to point the robot in a general direction, it was difficult to make precise movements since it took around 2.5 seconds to rotate 90 degrees and since our thruster layout did not allow any form of strafing.

Another smaller issue with our previous thrusters was that they needed to be screwed on and off the 8020s they were attached to every time our robot was deployed. This made the process of deploying Ship Happens inefficient, and prompted us to develop a more modular design for placing the thrusters and efficiently deploying our robot.

This year we are planning to implement a retractable azimuth thruster to provide additional maneuverability for alignment tasks. Retracting the thruster into the hull of the boat for transport would help protect the thrusters and simplify the deploying and retrieval process. A servo controls a pvc strut attached to a thruster, thus rotating it in place and changing the angle of thrust force relative to the boat.

Next Steps: Begin CAD model

First draft of the RoboBoat 2023 tasks is out. We are working on brainstorming new ideas or adapting our old modules to accomplish these new tasks.

The electronics team has been working on implementing our circuit redesign for the Njord boat. Members on our team implemented an LED tower that provides visual cues for onlookers to know what is happening on the boat. The LED tower features three lights: the green light indicates that the boat is in Guided (autonomous) mode, the yellow light indicates that the boat is in Manual (remote control) mode, and the red light indicates that the thrusters have been E-stopped. To send voltage to the LED tower in all three cases, two protoboards were designed and soldered, one to control the yellow and green lights, and one for the red light. Other members worked on designing and protoboarding a circuit that allows us to have an E-stop on the remote controller for the thrusters. The circuit interprets a PWM signal from the RC receiver in the electronics box and transforms it into a DC signal that regulates a relay. This circuit is at the core of our safety system as it ensures that the high current contactors that control power going to our thrusters default to an open circuit when we decide to estop remotely or when communication with the emergency transmitter is lost.

The electrical team has been focused on making sure that Ship Happens meets the electronic safety requirements for the Njord Challenge. We started out by prototyping the safety equipment, and have all hands on deck working on getting our battery management system, LED tower, and remote emergency stop system working and ready to pass the Njord Challenge’s safety inspections. We also wired up the test boat, Athena, with a new electrical box, to allow the autonomy team to do testing for Njord while the electronics and mechanical teams make their final adjustments to the Ship Happens.

The electrical team worked tirelessly to get the electronics on Ship Happens ready for the boat to compete. New for this year, we are putting all the electronics in one box, and so the team spent a lot of time working on getting everything in that box properly placed and wired up. We also ensured that Mission Planner was properly interacting with the thrusters so that the boat can autonomously perform the navigation tasks that it needs to on the water. We also worked with the mechanical team to get all of the modules for Ocean Cleanup and Feed the Fish integrated and mounted.

The process of installing electronics into the box is taking longer than we initially expected. Our team has mostly finished connecting the internal components of the box to each other, but there are a lot of cables from the outside that have to come into the box. We want to allow the box to be able to be removed from the boat, and the inside base plate to come out of the box too. This means that the connectors cannot be pass-throughs, but instead should be plug-in connectors, so that cables can be unplugged from the outside and inside of the box. Next steps will be to decide where connectors will be placed on the box for the thruster cables, battery cable, water gun servos and pump power cable, ball shooter motors, ball collector motors, and all the cables for the sensor mast.

The process of installing electronics into the box is taking longer than we initially expected. Our team has mostly finished connecting the internal components of the box to each other, but there are a lot of cables from the outside that have to come into the box. We want to allow the box to be able to be removed from the boat, and the inside base plate to come out of the box too. This means that the connectors cannot be pass-throughs, but instead should be plug-in connectors, so that cables can be unplugged from the outside and inside of the box. Next steps will be to decide where connectors will be placed on the box for the thruster cables, battery cable, water gun servos and pump power cable, ball shooter motors, ball collector motors, and all the cables for the sensor mast.

Team Updates

We have onboarded 11 new recruits onto the team. In order to make sure those with less experience have guidance, we’ve split up our existing members onto separate project teams and assigned 3 to 4 new members to help. This project format will ensure that there is enough work to go around and that each team has an expected deliverable to work on for January. By the end of the month, we had a design review to go over all their progress and give feedback on their design decisions. Let’s see what these project teams did!

Electronics Box: Ansel Garcia-Langley, Ivy Liu, Erin Menezes, Maaya Prasad, Shruti Garg, Makar Kuznietsov, Dylan Gaillard, Sera Hamilton

Last semester, our electronics team redesigned our circuit to include many new components such as optoisolators and overcurrent protection that will prevent important and expensive components from being damaged. Because we have a lot of new parts to include in our electronics box, the team also spent time last semester creating a CAD layout of the new electronics box, making sure that everything fit in one watertight box.

This IAP, we started ordering the components that we needed, and fitting them into the box. During this process we realized that the base of the box, which has holes for easy part adjustments, did not have large enough holes for our parts. This meant that we had to CAD and laser cut a new base with large enough holes and slots so that all parts could be adjusted slightly to fit into the base. Because of the large amount of components that will be in the box, we also created a second layer in the shape of an L that fits around our computer and is mounted above the first layer with nylon spacers. We plan to replace the entire second level of the box with a large PCB so that we can avoid having messy wires and breadboards that may shift and unplug on the water.

Another member of our team focused on making sure all the motors and motor drivers worked by creating Arduino code that ran all the motors at the same time using an Arduino Mega and an Adafruit Motor Shield V2. This code also confirmed that the Arduino Mega and motor shield could power all three types of motors at the same time. We discovered that when running the servos on digital I/O pins, they only want to respond to angles between 10 and 174, and do not move when given commands beyond that range.

We have also started thinking about the types of connectors we need to route the external wires for the sensor mast and motors to the inside of the box. Because the box needs to be waterproof, good quality connectors and air tight holes are very important. We also want to limit the number of holes on the side of the box to avoid mistakes that need to be taped over, so planning is necessary. Another design choice that we decided to make this year is to make the box removable from the boat. This means that the box connectors will not be passthroughs, and will all be plug in connectors. This will enable us to unplug everything on the exterior of the box, so that we can pick up the box and move it away from the boat to debug the inside, rather than having to work on the boat.

There is still plenty to be done for the electronics box. Now that we know the parts for the second level work (motor driver, Arduino Mega, optoisolators, etc.), we can start designing the second level PCB board that will attach to all of these parts. We also need to organize the location of the connectors, order the connectors, wire the inside and outside of the box, and install all the connectors.

Thermal Management: Amy Shi, Karen Guo, Mateo Pisinger

The goal of the Thermal Management team is to effectively cool the electronic components that are installed on our boat, Ship Happens. Last year we had issues where the electronics box would overheat due to lack of ventilation and the heat from the sun reaching the electronics. Our solution to the latter was to mount a reflective plate on the clear top of the box, however the need for an active cooling system remained.

Why Air Cooling?

We thought of a few ways to cool the electronics (liquid cooling, heat pipes, and air cooling), and decided to go with the air-cooled system for a few different reasons.

1. Simplicity.

   Liquid-cooled systems are large loops of some fluid (not necessarily water) that is used to pull heat away from electronics and dump that heat into the environment, effectively cooling a system. Although liquid-cooling provides the best cooling performance, it requires specialized components and mounting equipment that would increase the cost, difficulty of manufacturing, and possible points of failure of the entire system. A failure in a liquid-cooled system results in leaks that are difficult to clean up, and can result in permanent damage to the components.

   Heat pipes are sealed metallic tubes (usually copper) that are filled with a fluid that quickly transfers heat from the warm end of the tube to the cold end. Although they are technically a form of liquid-cooling, they do not need pumps to move the fluid around due to their design, so they are considered their own cooling technique. These would also require specialized mounting equipment for all components that needed to be cooled, as every component that needs to be cooled must come in direct contact with the heat pipes. Although, if built correctly, a heat pipe cooling system can have no moving parts.

   An air cooled system blows cool air over the components in order to pull heat away and cool them down. Most of the heat-generating components already had heatsinks attached to them that are specifically designed to work with moving air, which meant that we did not have to manufacture a lot of the important cooling hardware as that was already attached. Some important components, like the electronic speed controllers, did not come with heatsinks out of the box so we had to machine heatsinks for those. Besides the heatsinks, the only other component that is needed for an air cooled system is a fan (or two!) to bring cool air to the electronics and/or to pull hot air away from them. In this case, we would only need to design mounting hardware for two components: the fans and the heatsinks. This is the least effective cooling method, but if it’s good enough (with some room to cushion any particularly hot days out on the water) then it is one of the most reliable cooling methods.

   You can mix and match these forms of cooling, for example computers use heat pipes to move heat to a heatsink that has fans attached. But the interfaces between these systems add a lot of complexity to a design. And simpler designs are easier to fix in the case a part breaks.

2. Time.

   A more complicated system takes a long time to design and build. And we are on a serious time constraint for the cooling system as it needs to be completed by February. With a simpler design we could meet the deadline without overworking ourselves and burning out while still providing the necessary cooling to the electronics box.

3. Risk.

   In thinking about risk we have to ask ourselves one question: what would happen if our components failed at the most important moment in a competition? Ideally, you would have multiple systems that all work towards cooling the components independently. That way, if one fails your electronics are still cool and functioning. However, if you had to pick a single system then you want to pick the one that is least likely to fail, and if it does fail the least likely to cause significant amounts of damage.

   If a water cooled system fails (for example a joint between pipes was not properly sealed), components do not get cooled and the possibility exists of a leak forming that causes permanent damage to the electronics.

   If a heat pipe fails (for example a crack forms and the fluid within them evaporates), the components do not get cooled. Due to geometry, the remaining portions of the pipes and their hardware are not very effective at pulling away heat from the electronics. If an air system fails (for example a fan burns out), the components do not get forced air through them, but the heatsinks are still capable of pulling heat away from the electronics. So your cooling is reduced, but some cooling still happens.

First Prototypes

With our approach selected, we started working on a system that would fit with the rest of the boat. As of this moment, we have built and tested our first prototype of the fan mounts that we plan on using to supply and exhaust the air in the electronics box. We have also machined the heatsinks that will be attached to the electronics that need them.

Because we are using a fan we have to cut a hole into the electronics box, which means we must do everything we can to prevent water from reaching the electronics. This is the job of the fan assembly, which is composed of two different sections: the mount and the casing. The mount is made up of two acrylic mounting plates, a silicone gasket, and a 12V fan. These are attached together onto the wall of the electronics box with a set of 12 screws and some locknuts that won’t come undone with the natural vibrations of the boat. The gasket is sandwiched between the outer wall of the electronics box and the outer mounting plate, and then compressed down to create a waterproof ring surrounding the hole. This way if there are any water droplets on the outer surface of the electronics box they will not reach the hole.

The casing is a 3D printed cylinder and cover that is there to prevent any liquid water from reaching the fan and opening in the electronics box. It will be glued onto the outer surface of the electronics box, and it has a special lid where we attach some 2” PVC piping which lets us control where the air moved by the fan comes from. This piping will have 90° bends along the way in order to catch any water droplets that might have somehow fallen into the pipe. This way we cut the risk of getting water into the electronics box while still having the flow of air to keep everything cool.

First Test

Our first test was completed recently and we used it to get an idea on the performance of the fan assembly if we changed the size of the inlet hole on the lid of the casing. As we increased the size of the inlet, the volumetric flow rate of the air (the amount of air we moved) increased as well. With an inlet 33mm in diameter we got a flow rate of 7000 [cm^3/s]; while with an inlet 60mm in diameter we got a flow rate of 18000 [cm^3/s]. Higher flow rate of air tends to mean better cooling for electronics with heat sinks, which means that we will want to go with an inlet size that is as large as possible.

The limiting factor to the size of the inlet is actually the distance between the electronics box and the battery box. The PVC and respective fittings we decided to use for the tubes are of a standardized size, which means we cannot change their dimensions. These fittings can get fairly large, and the space we have on the deck of the boat is limited so we had to go with the largest fittings that we could while still making sure everything fit on the boat. Luckily, the flow rate we got for a 60mm diameter inlet was fairly close to the flow rate of a fan that is not constrained in any way, which was what ultimately led to our decision for the size of the inlet as it did fit within the given space.

Next Steps

For now the next steps are some small corrections to the main parts of the fan assembly, along with a single major design that needs to be made in order to attach the lid to the fan casing. We had some issues with getting the mounting plates aligned with one another, and some of the gaskets we cast were not of a uniform thickness. These are things that need to be addressed in order to have a complete system, and from there we can move on to testing and integrating the thermal management system into the rest of the boat.

A CAD layout of the electronics box has been created to make sure that everything will fit in the box. We plan to have two layers to maximize space usage, but this will also mean that the box will get very hot, especially in Sarasota, Florida. For this reason, we have recruited another member to work on thermal management in the box starting in January. We have also designed PCBs for our optoisolator components in the circuit.

We have integrated the overcurrent protection into our circuit, and have milled heat sinks for our ESCs since they melted through their plastic protectors in our test last Friday.

We had our first in-the-water test last Friday on the Charles River from Magazine Beach. We determined that our measured max speed is about 1 meter per second.

A new wiring diagram has been made to include new additions to our electronic system. These include overcurrent protection, LED monitors for visual cues on what is happening on board, optoisolator boards, and PCB integration. We are presenting our diagram to mentors next week to get feedback.

Autonomy has been working on developing multiple autonomy systems for the Njord Vessel. One is a new control system: we decided that we should develop an entirely new controller, bypassing velocity commands through Ardupilot and rather directly sending pwm signals, to allow our boat to have more flexibility. For example, this would facilitate incorporating our azimuth thruster system in the future, and have a controller that is more specific to our vessels. Secondly, we have been working on vision and mapping for navigating around buoys and detecting objects to avoid collision. Some of our members have been working on training a dataset for detecting buoys and cardinal markers, while others have been working closely with the LiDAR to overlay the ZED images on the LiDAR pointclouds. Once the buoy detection is refined, we plan on improving our buoy navigation code for visual servoing.

After debriefing on RoboBoat, the autonomy team decided to hold multiple training sessions for the whole subteam to be on the same page with our general knowledge of Ardupilot, MAVROS, and how our autonomy stack works. We also decided to develop our own controller for Ship Happens v2 (Ship Works) rather than using the built-in velocity commands. This would allow us to have more flexibility in our codebase and lead to a smoother integration of the azimuth thruster pods. While this means we have to redesign some main parts of our current architecture, we hope it would result in a more stable and robust system for the future!

The formerly navigations team, now the autonomy team (aka the autobots!) continued to program our autonomy stack which is primarily divided into vision/perception, navigation, and sensor/integration. The vision team successfully implemented their depth-masking and color segmentation to detect the targets for Feed the Fish and Ponce de Leon, while the sensor team worked on the Arduino code for the mechanical aspects of the tasks. During our integration test, we were extremely happy to see our vision and mechanical system work together to track and shoot water at the blue targets, including our team members wearing conveniently blue-colored Arcturus shirts. While our navigation stack using GPS waypoints and ZED/LiDAR data still needs more work as we had some trouble with Ardupilot, the whole navigation team learned a lot about MAVROS/MAVLink, so we would be ready to tackle our next challenges leading to Njord!

We are working on Task 6: Feed the Fish and Task 7: Fountain of Youth. Both involve detecting a blue target and aiming a ball launcher or water gun at the center of the target. We use a similar approach to solve both tasks. First we use a depth mask in our Zed camera to filter out data that is not related to the target, such as the water in the distance or the sky in the background. This removes most of the irrelevant blue data. In addition, different shades of gray are often detected as blue, since gray is equal parts blue, green, and red. To get rid of this data, we use the HSV data format and filter out pixels that are too low on saturation or value, since these represent whites and blacks. We then use a k-means algorithm to group similar colors in the color data we receive from the camera. We use the color detected that is the most similar to the color of the target and then find the median of that data with outliers removed. We call this location the center of the target. We then use servo motors controlled by an arduino to aim the water gun/ball launcher at the center of the target. We still need to test the actual water gun with the target, which we will finish in a few days.

Team Updates

We did a new recruiting push for IAP and onboarded 9 new members! It’ll take a little while to onboard them, but between Herbie and our new navigations co-lead Jacob, we think we’ll have the bandwidth to both code and teach. We will be working hybrid for IAP so that we can accommodate people who haven’t yet arrived on campus.

We will be continuing to work using our test boat Athena, while Ship Happens is under construction. Our Gazebo simulation will enable those working remotely to keep working without access to the hardware.

ROS Display: Youry Moise, Herbie Turner

We’re working to develop a dashboard that displays real-time sensor data collected from ROS.

ROS stands for Robot Operating System; is a software middleware suite that allows us to receive information from a robot’s sensors and send it instructions based on that information. It has several “nodes” that are either publishers (the ones that send data), subscribers (the ones taking it in), or both. The data is transmitted in the form of discrete “topics”. Topics can include the depth registered, temperature, position, velocity, and other pieces of information.

Data can be streamed in real-time from ROS topics or stored and made accessible via a “rosbag," which periodically collects all the sensor data. This data may be published over 100 times per second for one topic. With dozens of topics all publishing at this rate for several minutes uninterrupted, rosbags typically become extremely large, amounting to 15 gigabytes of storage after just 5 minutes of operation.

Although it is possible to access the data from the command line it is not always convenient. Some of the commands aren’t very intuitive and visual data can only be displayed as numerical arrays. As a solution, ROS offers a package called RVIZ which can display standard ROS topics including 2D and 3D data. However, RVIZ lacks the capability to easily display some of our custom messages as well as the ability to easily control actuators on the vehicle.

To achieve this with our own dashboard, we are using Qt, software that expedites GUI development by providing libraries for widgets such as buttons, labels, tabs, and forms. PySide2 is what allows us to use the coding language, Python, to interact with those widgets.

The plan is to have 5 main tabs. The first will be an overview tab that gives a summary of the most important topics, including the 3D Map, 2D Map, Vehicle State, and Front Camera View. It will also contain a queue of tasks that the robot is planning to execute. The rest of the tabs will be “Sensors," “Perception," “Mapping," and “Pilot," and will display the appropriate information.

Boat Positioning: Wendy Sun

For an autonomous vehicle, object positions are relative to the boat’s current position. Therefore, we need to constantly have an accurate idea of where the boat currently is located, in order to put every other object in the correct world view.

There are four sources of positioning data: 1) ZED camera odometry; 2) Ardupilot; 3) Velodyne LiDAR odometry; 4) Reach M2 RTK receiver.

I started off with writing a positioning node that takes in only the ZED camera data. The positioning node assumes that the boat starts at point (0,0) on a Cartesian plane, and that x-axis points towards the boat’s starboard while the y-axis points towards the front.

After we successfully tested the ZED positioning node on data from last year’s competition as well as this year’s testing, I then moved on to writing a combined node that takes in both the ZED camera data and the Pixhawk data. Currently, I wrote two versions of the combined node: 1) simply taking the average of the ZED and Pixhawk data; 2) using robot_localization that can process multiple inputs from sensors.

The next step is to test the two combined nodes, decide which one works better, and then use the chosen approach to combine all four sensor inputs.

MOOS-IvP and ROS Integration: Toya Takahashi

We are currently using ROS1 for our autonomy code, but we wanted to experiment with MOOS-IvP since many marine research labs at MIT use it, the software is more specific for marine vehicles, and it has the potential to increase our parallel processing power. Similar to ROS, MOOS-IvP is a bundle of open-source C++ modules, but specifically for autonomous marine vehicles. MOOS acts as a middleware that connects many applications together including MOOSDB (the database), IvP Helm (determines the behavior of the marine vehicles), and others. New applications can be made with C++ using the MOOS-IvP libraries, be deployed together in a single mission using MOOS, and share their data via MOOSDB. To get started on MOOS-IvP, we completed lab assignments for MIT’s graduate class 2.680 Unmanned Marine Vehicle Autonomy, Sensing and Communications. In the picture below, we have a sample mission from one of the lab assignments running on an application called pMarineViewer.

Furthermore, Professor Michael DeFilippo, a research engineer at MIT Sea Grant, has been working on a ROS node and MOOS application that connects the two software. His software serves as a bridge between MOOS-IvP and ROS, allowing ROS to publish MOOS variables into MOOSDB and vice versa. We have been and will continue to work with Professor DeFilippo to experiment with how we can integrate both ROS and MOOS-IvP to increase our parallel processing power and combine the strengths of the two software.

Perception: Evelyn Zhu, Bruke Wossenseged

There are several different tasks that our Autonomous Surface Vehicle (ASV) must be able to complete as part of the RoboBoat competition. Example tasks include navigating around obstacles like buoys and poles, and locating a target to shoot water at. One necessary component of our ASV is the ability to detect the different objects that will be in the various tasks. This is the Perception system of the ASV, and it is one of the projects within the Navigations subteam. We worked on two sub-projects as part of this system: 1) creating a labeling workflow and 2) developing an object detection model.

Generally speaking, before we are able to train a model we first have to gather some data. In our case, we were looking for image data that was specific to the types of objects in the RoboBoat competition (e.g. buoys, poles, and a dock) and that included labeled bounding boxes of the objects. While we were able to find some existing datasets on the Internet, we discovered that the data contained mislabeled images, and consequently, our initial object detection model was not very accurate. As such, we wanted to generate labeled data on our own, which is where the labeling workflow comes in.

Our team had access to some videos from online and from our own boat tests that captured the objects we would see in the competition. Using those videos, what we would need to do is generate bounding boxes for each frame, and we decided to use MATLAB for this labeling process. There are other labeling softwares out there, like Label Studio which has a nice UI and is free for anyone to use. However, while MATLAB is proprietary, thankfully MIT’s license covers most of the toolboxes that MATLAB offers. Moreover, MATLAB has some very nice built-in software, like the Video Labeler app, which we used to help us automate the labeling process.

The Video Labeler app provides a straightforward way to generate rectangular bounding boxes in video data, especially with the built-in algorithms like Point Tracker and Temporal Interpolation. With the Point Tracker algorithm, all I would have to do is hand-label the object in the initial frame, and the software would be able to track the object in the following frames. Temporal Interpolation was a neat algorithm as well. By hand-labeling just a few key frames, we are able track the bounding boxes over time of an object that comes in and out of frame. Using these tools in MATLAB, we were able to generate a training dataset with new labeled data.

So far, we have been using the YOLOv5m model architecture for training. To compromise accuracy and time to train, we moved forward with this model as compared to larger versions of YOLOv5. This model contains 21.4 million parameters and has an mAP (accuracy) score of 45. To train this model, data needs to be arranged in a certain format with separate text files for each image indicating the class and locations and size of the bounding boxes. As noted, the first training of this model resulted in poor accuracy due to issues with data labels, but we hope that with our updated data this can be vastly improved. We will also further examine implementing the larger versions of this model.

For guidance on using data and training the model, see the README of this github repo.

The next steps include training our model on this dataset and seeing how well it performs. We also have some video data that hasn’t been used yet from which we can generate more labeled data, and this shouldn’t be too difficult a task since the labeling workflow is already set up. We expect to complete these within the next week.

Water Gun Target Detection: Aarush Gupta, Alexander Zhang

The main goal of the water gun task is to shoot a water gun through a target, which fills up a bucket. The target is a blue disc with two perpendicular white lines running across diameters of the disc. Where the two white lines intersect is a hole where the target attaches to a pipe that connects to a bucket. Water needs to be shot into this hole in order to fill the bucket up with water.

The ZED-2 camera which our vehicle is equipped with provides both RGB and depth data. RGB data can be used to detect the target: we apply a threshold for the blue component of each pixel value (in HSV specifically, which is a better format for distinguishing colors) — then, all pixels which meet a certain blue “threshold” can be considered to be part of the target. Before doing this, we also use the depth data as a mask: all pixel values which are detected to be beyond a certain threshold distance away are ignored in order to minimize unintended noise due to distant objects. After the pixels that correspond to the target are detected, we take the median of their locations to approximate the center of the target.

Our original idea was using an image segmentation algorithm in order to determine the pixels corresponding to the target. While this was functional to some extent, we ultimately decided to use a more simple approach in order to increase robustness and speed, as complex algorithms might not be able to run well in real-time.

After the computer vision side of this task is finished, we will integrate this with the actual water gun by sending target information through ROS — the mechanical water gun will rotate accordingly and fire at the target.

Image segmentation algorithm results:

Creating Simulations in Gazebo: Jenny Zhao

For the RoboBoat 2023 competition, there are 8 total tasks our autonomous boat must accomplish. From simple navigations between buoys to more complicated tasks such as shooting a ball through a target, these 8 tasks make up a specific course that our boat will have to complete.

Before we have our boat designed, built and assembled though, I’ll be working on creating a testing simulation in an application called Gazebo. RoboBoat has given detailed specifications regarding each task. For example, we know each buoy’s color, size and shape and any other obstacle or task details. Using this we can create a very good simulation in Gazebo.

In order to create the simulations in Gazebo, we’ll have to first create accurate meshes in Blendr to represent each obstacle or task object. Taking these object meshes, we’ll be able to put them into task worlds and recreate each task. After creating all tasks, we will combine them into a large world with all the tasks in the same order as presented in the actual competition.

By creating these task simulations first, we will be able to create a boat object and test out our navigation systems for errors earlier, even before the boat has even been completely assembled and built. That way, when the boat is completed, and we start testing in real waters, we will hopefully have less errors and problems to deal with.

We were able to fix some bugs in Docker, so now new members should be able to access our code! This proved to be an issue with the growing Navigations team, since members have many different operating systems and the code base works best on Ubuntu 20.04.

Herbie, the Navigations team lead, is also holding office hours to assist Navigation team members in their projects.

Last Friday, we finally got our boat into the Charles River to test wifi range and collect data on buoys in the water using the LiDAR and Zed camera. We found that our wifi is able to connect until the boat is about 40 meters away. The buoy data will help us program the boat to find and navigate around buoys depending on their colors as outlined in the RoboBoat guidelines, and it was a good chance for our members to practice setting up the boat and putting it in the water.

We are working on onboarding new members, which have already been divided into sub-project teams. Because the sub team has increased from about 4 members last year to about 20 active members this season, the team lead, Herbie, has implemented version control so that multiple members can work on the same project. It is important to make sure that changes in code propagate to everyone working on it, and that if mistakes are made, we can revert back to old, working versions of the code. To do this, Herbie is using Git and Github.

Goals for the semester: Create teams within the Navigations members to work on various sub-projects simultaneously.

• Simulation Environment Team: Will use Gazebo to simulate a 3D model of a boat in the water
• Object Detection, Tracking, and Mapping Team: Using ROS, Computer Vision, and other techniques to locate floating buoys for the competition tasks
• MOOS-controlled autonomy stack: Experimenting with MOOS (MIT Marine labs autonomy stack) with the hopes of one day using the stack on Ship Happens