Team-Wide Blogs

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!