Entry 2

One of the agenda for today is to address the importance of the engineering notebook and meeting etiquettes.

Hardware team members build a robot based off of the chassis design.

• • Members who do not have the kit of parts (KOP) do the self-paced courses on OnShape.

Programming team members have a new programming challenge to practice what they learned on Android Studio.

Hooryah and Murtaza talk about the Engineering Notebook, and show us the importance of every Entry.

• • As heads of the engineering notebook, they explain how every person would contribute and provide their own input.

  • Alongside that, they discuss the importance of the engineering notebook in FTC competitions. They expand on how the engineering notebook makes our FTC team eligible for various awards, such as the Think Award and the Inspire Award.

The hardware team was split into two parts based on if they could access the Kit of Parts (KOP) or not.

• • That way, while one group focuses on virtually constructing the design of our robot, the other team focuses on becoming familiar with various parts of the robot, such as different channels.

    • • The OnShape group focuses its attention into designing their own chassis projects – possible designs that we could edit and revise for the robot we will build for this FTC season.

As for the new members in the programming team, they are assigned the coding challenge of the week.

• • The goals for today are to practice writing engineering notebook entries, using your critical thinking skills to tackle the coding challenge, and understanding the meeting etiquettes.

  • Meeting etiquettes include how during Zoom meetings, we should have our cameras on and our microphones not on mute in order to maximize communication.

Today the hardware team works on the main base of the design.

• • We determine what specific channels we needed for the base of the robot.

  • We insert those channels into the workspace and are successful in assembling most of the channels together. We assemble the two halves of the chassis holding the mecanum wheels.

Our plan is to finish the robot by the end of this week (Friday afternoon).

• • We will meet again twice throughout the week at the team meetings.

As head of hardware, Amanpreet and others plan to connect the two halves of the chassis and complete it during the next meeting.

However, the blueprint that we are following as a sample lacked any sort of screws, nuts, or bolts keeping the channels together – making the process a bit more difficult as we need to improve the design's feasibility.

• • After the chassis is finished, we need to retroactively add screws, nuts, and bolts. On Wednesday we will exchange ways to be more efficient in our building and navigating the system. If we do not finish the chassis next meeting, we will plan more meetings if they are needed.

We find that it didn’t work to all try to work on a different part of the design because most of it was symmetrical. We could simply build one side of the robot and copy it to make the work easier. When we all try to do a different part, we find one person's work can be easily replicated eliminating the need to have two people working on identical parts.

• • Our communication is lacking both because we are on different experience levels and aren't yet acquainted to each other's styles. We find this causes a rift between those who are working on the document and those who are not. In future meetings we plan to speak out more about what contributions we can bring and split up our workload fairly.

    • • We are successful inserting the channels for our base design. After having all of the materials in the workspace, my team is also successful in assembling most of the channels together so that next time they are ready to be attached.

      • However, since it is the first time working with a team, Sometimes it isn’t really clear who is doing what, which causes problems in making the design. Later we discuss this problem and plan on collaborating better the next time we meet.

The objective of the programming team is to learn basic programming principles through trial and error.

• • This week in particular is to demonstrate the importance of having distance based programs versus time based programs.

They have to create a successful program where the robot would make a 90-degree turn and travel in a square.

When the new programmers test their programs on the virtual robot, none of them are able to have the robot make a 90-degree turn since it is our first try. As a result, none of the programmers are able to have the robot travel in the route of a square.

• • However, the initial flaws in their programming codes are blessings in disguise as they are able to learn from their mistakes, and correct what they have done wrong.

    • • As a result, new members are able to figure out that the time (milliseconds) they input is too short, and because of that, their robot distance is inaccurately portrayed on the virtual robot simulator on Android Studio.

Due to COVID-19 social distancing guidelines, we do not have the opportunity to test programs on a real robot. Instead, we test our programs on a virtual robot simulator that is conveniently seen in Android Studio.

• • We eventually learn that virtual robots will never be able to fit the criteria of a real robot. Its experience never feels like it will have if we had the opportunity to test our programs on the real robot. However, it does provide us with a decent visual of the programs.

  • After looking at the way the virtual robot travels, we decide to make the necessary changes in our programs before trying again during the next team meeting. We also ask some of the team’s seniors for advice on our programs.

    • • Ahmed Mahmud, the head of the programming team, explains how the virtual robot simulator will not portray the current situation of our robot's performance correctly all the time.

      • He and Manyata discuss that the virtual simulator should be taken into consideration for advice, but it should be taken with a grain of salt as well.