Lessons Learned
Throughout our journey, we at HARRT have utilized a large array of resources & tools, developed new skills, wrestled with various software programs, and handled crates of hardware. Mistakes are inevitable; though we have attempted to learn from them, we wish to inform our successors and other stakeholders of these experiences with the intent of enabling them to outright avoid similar pitfalls or at least be able to mitigate their impact. Here, we will speak about the logistical lessons learned, the engineering insights we’ve made, and comment on the software and hardware we have used over the course of this project.
Advice to Future Teams
Throughout the course of the semester, the team has maintained continuous and scheduled communication, resulting in a streamlined integration of the sub-teams and our success. More specifically, Monday meetings have been dedicated to budget updates / team-level challenges and goals for the week, while Tuesday meetings have included sub-team work and Wednesday meetings have included schedule updates / Gantt Chart work. As a result of this defined structure, the team has consolidated our advice to future teams in the following list:
- It requires continual effort to maintain effective communication in a group. Beginning our project during the Fall 2021 semester, our team had varying interests ranging from a solution that provided societal-impact to out-of-the-box / innovative ideas. In order to finalize our project as a Disaster Relief Amphibious Robot, each member of the team needed to provide inputs / suggestions, and frequent & effective communication as a group needed to be fostered.
- A focus on team bonding and building in the beginning stages allowed for better conflict resolution and problem solving. The team had several challenging conversations regarding team dynamic, and conducted team-bonding activities both in and out of the classroom, which allowed for team trust to be established early in the project. In turn, when conflicts arose, team members felt more comfortable addressing them quickly.
- Lead times will always be longer than you expect. Budget updates throughout the course of the semester allowed for the team to organize our purchase orders, and recognize when orders needed to be filled out early.
- Constant prototyping can inform better design choices. Each sub-team produced 3-4 iterations of their prototypes, each of which was more effective. See the Prototyping page for more details regarding each sub-team’s prototype.
Useful Resources
Team Self-Examination – Winter
At the start of the semester, the team determined our overall goals to be: Learn New Things, Everyone is Heard / Values / Appreciated, and Be Proud of the Final Product. This semester, we have consistently looked back at these 3 goals as we’ve worked collaboratively to make decisions. Specifically, we designed a Team Contract tailored towards our team members to ensure that we are meeting these goals, including being thoughtful and respectful of each other’s ideas and encouraging everyone to speak on each decision. Through such concrete actions, we have had the opportunity to make significant progress on our product’s goals. Initially, the team’s goal was to envision / design several sub-functions of the robot at a high-level. Upon conclusion of the semester, we have been able to come up with a Minimum Viable Product, as well as have working prototypes of both the Water Movement and Land Movement sub-systems, as they fit into the MVP.
Further, with respect to the Team Roles, the team had a rotating system, by which each team member had the opportunity to practice skills, including leadership as well as organization / communication. Overall, this system had its advantages / disadvantages, but overall, was effective. Next semester, the team plans to have the above team roles, as well as roles more specific to the work that needs to be done (pertaining to Electronic System Design, Waterproofing, etc).
Finally, our plans for the end of the year are to have a fully-functional prototype of the Water Movement and Land Movement functionalities. We would also like to have the robot be able to Transition Between Environments with no human interaction; however, this is a stretch goal. Given the set-up and background work that has been completed to ensure that we are working effectively, we believe that we will be able to achieve these goals and more, if we continue to set-up our team roles / responsibilities appropriately.
Technology – The Good, The Bad, and the Ugly
Programming & Hardware Specifics
- Beware excessive reliance on and overestimation of the structural capabilities of 3D printed parts — sometimes it seems the support material is the only part capable of withstanding failure during its expected service conditions
- Make moving parts as simple as is feasible, e.g. we found bevel gears much more headache-producing than spur gears
- Never assume a purchased part or component will function just as you expect or your design requires, allow (time, patience, design adaptability, etc.) for deviation from your expectations
- Leave ample time to manage and tackle controls, electrical design and construction
Software & Hardware to Avoid
Water Movement
- The motor used needs to be waterproofed, not water-resistant
- Make sure the power supply used can supply the ample amount of voltage and current for the motor
- It is better to use an existing bilge pump motor than a non-waterproofed motor