Team-Wide Blogs

General

Starting off this new school year, our team focused heavily on recruitment and onboarding during the first few weeks of school because we want to ensure that everyone who has an interest in marine robotics has an opportunity to participate. We especially focused on developing useful training materials for each sub team, as experience level varies greatly from person to person. From participating in the Activities Midway to giving tours at the MIT Sea Grant lab, we successfully wrapped up recruiting with lots of new faces at our general meeting. The onboarding trainings for each sub team were also carefully divided to first develop some basic knowledge/skills before moving on to more Arcturus related topics. Now, each subteam is starting to dive into smaller projects to create our new flagship for the 2025 competition season.

MechE

The MechE team began thinking about designs for the new competition boat. We started by considering our design parameters, and set the general dimensions of the boat that we want to make. Next, we designed the hulls using these dimensions, and thought of our general design parameters on the boat. The MechE team then split into groups working on different aspects of the boat, including groups for:

• Deck, who worked on the dimensions of the deck, its mounting methods to the boat, and placement of handles
• Thrusters, who figured out methods of mounting the thrusters to the hulls and made cages so that the boat can be set down without interference from the thrusters
• Command Module, who designed the housing for some of the electronics as well as a method to get the LIDAR as high as possible for maximum vision capabilities
• Battery Box, who worked on the way that the batteries are set into and accessed from the hulls

In the coming weeks, we plan to continue with these designs and do both internal and external design reviews to refine them and ensure that it will work the way that we want it to.

EE/EGGS

The EE team approached the new semester with a new vision of the standards we want to adhere to and the abilities we want our electronic systems to have. So firstly we have undergone a rebranding - we now call ourselves EGGS: Electronic Generally Good Systems. Secondly, for the term team came up with 8 subprojects EGGS will thoroughly develop:

• Thermal Management - our electronics box is already cool, but we need to make it cooler. Right now we are researching the most effective ways for thermal management and creating heat transfer simulations.
• Batteries and Battery Box - batteries must be protected at all costs, therefore we care about battery boxes.
• Power Distribution - we want our electronics box to be more organized and reliable, therefore we are developing a PCB which will take care of all power transformation and distribution to the specific elements in the box.
• BMS - our current BMS does its job, but we are looking for ways to integrate it more closely with the software stack we have and be able to read the battery charge percentages without using a 3rd party application.
• LED Signal Board - LEDs, LEDs, LEDs. EGGS want to help implement faster in-water boat tests, and a strip of LEDs visible from the outside of the box signaling about the state of subsystems would be helpful for quicker deployments.
• The Box-like container - we are working with MechE to implement the next-gen box design.
• Remote E-Stop Board - EGGS are designing a PCB to replace the E-Stop protoboard.
• Led Tower Board - EGGS are designing a PCB to replace the Led Tower protoboard.

A group of 2-5 people work on each subproject, with a great share of those involved being new members of the team. In the coming weeks, we plan to continue working on the projects and introduce new members of the team to our development process.

Autonomy

As this is the beginning of a new season and there are fresh faces in the organization, the Autonomy subteam has spent the past few weeks in the onboarding phase. The main activity at every meeting has been making sure everyone has the proper software, processes, and permissions set up on their systems such as virtual machines and dual boots capable of running linux for ROS 2 as well as git accounts with access to the organization git repositories. Besides this, the autonomy lead Jacob has been educating the new recruits about the focus of the different sub teams within the autonomy group and how they interact with each other. In addition, he has explained the basics of the ROS 2 nodes and topics system, Github collaboration, Linux, MOOS, and how we use these software to efficiently create the programs vital to running the vehicle. Along the way, new members have been placed onto their preferred subteams and given introductory tasks to simulate what the rest of the year will look like as part of that group.

MechE

During the 2023-24 season, the MechE team is going to design and build a completely new boat for future competitions. To ensure sustainability within our subsystem, we’re having one of the biggest pushes for training that the MechE team has ever done. We’ll be running trainings for almost all aspects of the mechanical design process, including Computer Aided Design and Manufacturing, using bandsaws and drill presses, and laser cutting and 3D printing.

Mechanically, we’ll start our first build by making adjustments to our test boat, Athena, giving it an X drive configuration and a new sensor mast that will match our plans for the new competition boat. This should be a reasonably fast adjustment which will allow us to transition quickly to working on the design of the new boat.

The process of building a new boat will begin with designing the hulls and deck in CAD. Once we have a preliminary design completed, we will do design reviews within our team with the Electrical and Autonomy subteams. We also plan to work with some of the professors of mechanical engineering at MIT who specialize in working on boat designs. When we have a design that we’re happy with, we will begin the manufacturing and layup process, assemble the hulls and deck, and hand the boat off to Electrical and Autonomy for integration and testing.

Overall, the mechanical team’s goal is to make a new boat that properly caters to the needs of Electrical and Autonomy, and gives the team a good foundation to perform well in future competitions.

EE

For the 2023-2024 season, the EE team is planning on doing a whole revamp of our electronic system. Our general circuit will likely remain quite similar, but individual parts will be designed more robustly. We also plan to work on expanding our team since many members are seniors, and so we want to create documentation of what we have accomplished and learned thus far.

To create a more robust electronics box, we plan to convert our protoboards into PCBs. This task will help teach the entire team, new and old members, the process for creating small PCBs. We hope that this will give our team a chance to get comfortable with Altium so this design process becomes less of a barrier for creating PCBs in the future. We also hope to find stronger connectors for jumper wires inside the box, since these become loose over time and tend to break if they are moved around too often. Next, we are planning to improve our cable management inside the box, and we hope that by introducing rails along the sides of our box, and also by using PCBs, we will create a box that is more organized and easier to debug. This will also include replacing our pass through connectors from inside to outside the box with actual connectors that plug in so that the box is independent from other parts on the boat, and so that water can not get in from the pass through connectors. Finally, we hope to work with the Mechanical team about where best to place the batteries and our electronics box on the boat.

On the communications side, we are hoping to buy updated tech for the GPS and Wifi systems. We are also planning on using the LED tower to communicate more than just RC modes and thruster power. We hope that we can find ways for the LEDs to show if the computer is powered, if the thrusters are powered, and various communication connections.

Overall, the EE team would like to create a very generic system that utilizes modules that can be added and removed depending on what sensor payloads the boat is carrying, and which tasks we plan to do at the next RoboBoat competition.

Finance

Business Team this year decided to change our organization structure in order to better coordinate different sponsorships. Before, only Business Team was in charge of talking to sponsors. However, when sponsors want to talk to specific subteams (Autonomy, EE, or MechE) about technical questions, subteams are able to offer more detailed and accurate explanations than Business Team. So this year, Business Team will not only keep track of all sponsorships as we’ve done before, we will also build a system where we assign sponsorships to specific subteams as points of contact.

While we are working on recruiting new members for Business Team now, we are also getting ready for meeting our sponsors before and after MIT’s Fall Career Fair, which will take place on Sept. 22. We are currently scheduling info sessions or recruiting events that our sponsors can host at Arcturus, either on-site or remotely.

We were just told by RoboBoat that the competition will be held in February this year. This poses challenges for the following reasons:

1. February dramatically tightens our timeline, and we are still working on getting Ship Happens sent back from Norway, where we did the Njord Challenge. In reality, we are looking at a maximum of five months’ time for us to get everything working and integrated, which is very tight.
2. RoboBoat is currently set to start on our first day of Spring classes. Many professors have mandatory attendance during the first lecture to validate your registration or risk losing your spot to someone on the waitlist, so it’s unclear how many students would be willing and able to attend the competition.

After some serious consideration, Arcturus has decided we will not compete in RoboBoat 2024. Instead, we will focus on building a whole new boat. There is simply too much on each subteam’s plate. In summary:

• MechE is building a new vehicle altogether which:
• Uses 4 45-degree thrusters to enable stationkeeping
• Will be able to be placed flat on the ground between runs in the water
• Will be generally smaller (and perhaps modular) and thus easier to deploy
• EE is building a more robust safety system:
• Finalizing our remote e-stop
• Converting our electronics to PCBs
• Improving waterproofing by minimizing passthroughs
• Navigations is going through a full refactor into ROS2 and will focus on:
• Adapting to our new steering
• Implementing path-planning
• Improving comms
• Segmenting duties into 4 smaller subteams within navigations

Until we consistently can accomplish several tasks, we don’t think it’s worth the significant practical and financial hurdles to go to RoboBoat. Furthermore, because this is our third year, we no longer get registration for free, so we would have to pay to enter again.

We believe that there are many benefits of competitions including team bonding and condensed testing, but we also think that competing isn’t the only method which would do this. Many other Edgerton Center teams go on “field trips” where they bring their vehicles to tracks or scrimmages to test or compete informally. We are considering doing something similar either within Massachusetts or in a nearby state. We are reaching out to UMichigan to see if they would be interested in setting up a course together for practice.

Deciding to take a year off poses a great opportunity for MIT Arcturus to focus on our technology and development as a team. This is especially relevant as many of our ‘24s are graduating out, so we would like to dedicate much of our energy towards recruiting and training underclassmen during this time. In the long run, we believe this move will better prepare the team for success when we begin competing again.

What went well

After a long week of hard work, we’re proud to say Arcturus placed first in design documentation, team video, and website in RoboBoat 2023! This Sunday we ran a debrief discussing what went right and wrong at RoboBoat, where we want to be going as a team, some potential new leadership structures as we prepare for long term continuity, and interest and logistics for the Njord Challenge.

What we need to improve

• Connecting different subteams - have EE/mechE and nav work more closely so that there isn’t a weird divide and everyone is on the same page for system integration.
• Testing earlier and more frequently!
• We should be in the water by the end of the fall semester at the latest so we know what needs to be fixed.
• We need to have a hardware freeze by the end of the first semester so nav can work on programming the boat and debug.
• We should breeze through safety checks in the first day to maximize the number of slots we get on the water during competition.

Takeaways and recommendations for next season

• We need to put a hard deadline to stop building earlier so that we don’t spend time building things that don’t have time to get integrated and give nav more time to integrate.
• More tests! We need to get in the water more frequently - but in order to test, we need to have programming done earlier in the season.
• Testing more also means we have more data to share!
• To this end, Njord Challenge will be super helpful actually because it’ll encourage us to focus on programming in the coming months since there are no mechanical tasks.
• But we don’t want our EE and mechE’s to get bored so after we finish a vehicle and hand it off to nav, we should do another new project and cycle on/off season for hardware vs software for a given vehicle.
• Now until Njord Challenge:
• Nav programs the boat.
• EE and mechE build the sub.
• Next Fall:
• EE and mechE wrap up the sub and design RoboBoat modules.
• Nav begins programming for modules and refines navigation tasks.
• Next Spring:
• Integration of modules and testing of our boat!!!
• If time: begin thinking about RoboSub or other submarine competitions and begin implementing approaches to those tasks.
• Programming first: instead of having our mechE’s ask “can you program it to do x” have nav tell mechE “here’s what is easiest for us to implement, create a mechanical system which can do this.”
• In many ways this is a more interesting task for mechE’s.
• Enables nav and mechE to work in parallel.
• We still want to work hard to give people training when we get back since we have many freshmen on the team.
• Connect new members to shop staff so that you can get to know them better and feel comfortable asking them questions.
• In order to speed up efficiency of manufacturing, we’re creating a part tracking system so that anyone can go to the IDC (a machine shop we use), look at the doc, and start prints or cut parts for others.
• Part numbering:
• Use parametric part numbering featurescript (Jared can do a quick featurescript tutorial).
• ARC-Project-Year-Assembly-Subassembly-Material-Part
• Each project (Ship Happens - SH), assembly (Ball Launcher - BL), subassembly (Turret - TU), and material (1/16” Aluminum - 1/16AL) get an identifier.
• Have the files w the dxf or gcode in the drive with descriptive names of thickness, material, version etc.
• Early season space allocation:
• We need to know where things will go on the boat a lot earlier.
• We can get a reasonable weight/CG estimate earlier.
• Can just use rectangular prisms with approximate weights assigned in Onshape.
• Work on getting us space in N51 (a building at MIT):
• Would enable us to more easily use tools in N51 and interact more with the other Edgerton Center teams working there.
• The Milk Drop shop is clearing out - Audrey can ask about getting space there.
• Next year RoboBoat logistics:
• Having a travel manager is good! Someone needs to manage who’s going where and when AND they should be there at the competition to see it through!
• We should ask Milwaukee Tool for more packout boxes to hold stuff since the cardboard ones aren’t enough.
• Should also get our own set of tools (pliers, calipers, etc) if possible.
• Also would be nice to have smaller boxes with subdividers for electronics and fasteners.
• Someone should be the designated testing director who makes sure batteries are charged, tools are in hand, etc. every time we are going out to test to take advantage of the time given.
• We should have designated divers for the first shift so we don’t pull another all nighter situation.

We had our first in-the-water test of the year in the Z-center pool! (It’s currently too cold to test in the Charles River anymore.)

What went well

1. Having a car made transport easy even in bad weather
2. Ardupilot and RC control functioned flawlessly
3. Collected a lot of useful data for testing
4. MIT community members loved it: “I never get to see research happening here!”
5. Lots of members came to help out

What went badly

1. The packing list was started too late and we forgot a lot of things, we’re lucky multiple trips had to be made anyway
2. Senior members were too busy with individual tasks to direct new members who ended up standing around with little to do much of the time
3. The purpose of the test and information on the vehicles wasn’t clear to a lot of new members
4. Hardware-software integration was not ready which meant having to take the boat out of the pool a lot to fix things, wasting testing time
5. No GPS fix at all in the pool, as opposed to just a poor connection in Sea Grant

Key Takeaways

1. Tasks during the tests should be assigned ahead of time so new members know what to do and senior members can focus on technical work
2. We should do a dry run-through of testing operations (using the test tank) sometime in the week before the test
3. We should hold an open meeting where we discuss all of the logistics and technical details regarding the upcoming test
4. Hardware-software integration always takes a lot longer than expected regardless of how well each is working individually and should be considered a week-long process.
5. Our next test should be in the next 1-3 weeks and should still use Athena. Testing for Ship Happens should be led by navigation members going to competition and should occur weekly starting in mid to late February.
6. The Jetson Nano gets REALLY hot. We need a better cooling system. It’s probably better to just buy given our timeline.
7. For cooler tests, maybe with ship happens or if we’re ready for full autonomy with project Athena, we should advertise to the general MIT community

Actionables

• Poll members for the next testing date and dry run-through and once decided:
• Reserve pool
• Let Dr. Drew Bennett, our faculty advisor, know when we’ll be doing dry-run since we’ll probably take up a lot of lab
• Reserve car
• Start test page and packing list immediately
• Add missing buoys to the order list
• Email Stereolabs to figure out how to run ZED SDK on a Jetson Nano running ubuntu 20 instead of ubuntu 18
• Build an improvised dock for floating task objects in the pool
• Athena improvements
• Waterproof LiDAR box properly (just anything but gaffer tape holding a ziplock bag)
• Fix janky LiDAR ethernet cable connection, instead use the actual cable connectors
• Document best position for thrusters and cut 80/20 to length so we don’t have to guess every time we mount it
• Get a permanent SSD for the computer box

Following RoboBoat 2022, we have done a comprehensive debrief and have several goals for this season:

Rework electronic systems:

Last season, a reverse polarity power cable fried several key electronics on our boat -- including our computer, an Intel NUC. As a result, we had to scramble to reconfigure for a backup computer we had brought. We want to make sure we have redundancies in place so a similar mistake won’t happen again. In particular, we want to implement overcurrent protection by investigating the use of fuses, diodes, optoisolators, switch boards, microcontroller choice, and voltage regulation. We also would like to try designing our own PCB boards, since this is a skill which isn’t really taught in our course curriculum and we think it would be interesting to learn.

In order to make this happen, we plan on:

1. Doing a comprehensive “roadkill” (layout of all powered devices) before worrying about component placement.
2. Finding more members who are specialized or interested in learning EE.
3. Create handbooks members can reference for Ardupilot, CAD/CAM, and battery handling.

Make the boat lighter:

We have done a massive recruiting push this semester, tripling the size of our team. As such, we believe we will have the manpower to approach all the tasks this year and we think that attempting all tasks will be a good learning experience for the team. In order to make programming as easy as possible, we must ensure that mechanical modules are consistent and reliable. This will require an increased focus on quantitative and qualitative testing, system integration, and careful planning and pacing to ensure we aren’t pressed for time.

On top of competing in RoboBoat 2023, we will also be building an autonomous underwater vehicle. We’re unsure if we will be able to finish our sub in time for a competition this year, though, so this will depend on manpower. We will spend the first semester building the sub and overhauling our electronics on our boat, then hand the boat off to programming mid-semester.

This is pretty ambitious, so we're doing the following structural changes within the team to make it happen:

1. Improved onboarding. We are working on creating step by step guides to help people learn (and remember!) how to use the machines (laser cutters, 3D printers, etc.), safely charge the LiPo batteries, and use Ardupilot, the autopilot software that we use. We are also hoping to hold workshops early on to help people learn CAD, electronics, and other skills they'll need to be set up for success and hit the ground running. We are hoping to hold these weekly for the next few weeks. More details on this to come!


2. Increased focus on on-the-water testing. With more testing comes more feedback for both our design and programming teams. We are planning many more tests this semester and are setting our design deadlines accordingly. We are also coordinating with the Z-center so that we can use their pool during the winter months when the Charles River freezes over.


3. Improved organization and increased emphasis on meeting deadlines. We've put together a team Notion which we will be using to organize the team as a whole. Included in the Notion are parts order requests, task list, meeting notes, linktree, team roster, team roadmap, and comprehensive wikis by subteam. We are currently working on an overall gantt chart of all the deadlines and milestones we're looking to accomplish, which will allow us to make sure all the dominoes are placed in succession.




4. Launching Arcturus Finance. As you know, we've been having some trouble recruiting for our business team, which has always seemed to take a backseat to the technical roles in the team as many of us are mechanical/software engineers. But we also understand that there is a massive community of students in Sloan who might be interested in this kind of opportunity. It's just a matter of finding them. Which is why we’re building a new team, Arcturus Finance. By separating our business team into a separate ASA club, we'd ensure that finance would get the full spotlight it deserves and hopefully garner some of the interest other finance clubs draw at MIT. It would allow everyone to focus on the parts of Arcturus they're most interested in, be it robotics, finance, or both! It'd be a very different approach to the way most engineering teams have managed their funding, but we think it has the potential to be incredibly valuable for everyone involved. In this way, we hope to create an interdisciplinary experience which combines both technical and management skills, mirroring the structure of real-world companies and startups.


5. Recruiting. Since we are a 2024 and mechE heavy team, we are looking to recruit more members of different years from different departments. We believe this will be crucial to keep our team balanced and ensure its legacy after we graduate. We see a particular need for electrical engineers and programmers experienced in autonomy, as well as freshmen and sophomores to bring new life into the team. And of course, if we are approaching two competitions this semester, we will need more hands on deck in general, so we are looking to expand as a whole. We will be running lab tours for the next two weeks for prospective members. Interest tours for technicals will be 9/10 and 9/11 at 3 PM and 9/12 and 9/15 at 5:30 PM. Interest tours for Arcturus Finance will be 9/19, 9/22, and 9/23 at 5:30 PM.


6. Feedback and leadership. In order to get feedback from the team, we’ve sent out a feedback form to get input. We want to make sure that everyone has enough hands-on work this semester and feels they’re picking up practical skills they’re interested in, so this will be important for us to know when assigning tasks. We also wanted to open up leadership to more underclassmen since almost all of our leadership are currently in the class of 2024, and we want to plan for long-term longevity. As such, we have decided to do away with a traditional “exec” and instead have a logistics team. The logistics team meets each week to plan out…well, logistics, for the team as a whole. Our first logistics meeting this Sunday (11th) at 2 PM in Sea Grant, where we will discuss overall plans for the semester, onboarding plans, and preliminary designs.

Our first general meeting including new members will be on September 18th at 2 PM. We’re excited to get started!