2024-2025 Robo Yetis Team 5196 Engineering Portfolio

Background

The Robo Yetis founded in 2011 at Aspen High School has been the primary Aspen High School robotics team for the past few years. Our oldest members are juniors with three years of experience. This was the first year since the pandemic that our club had more than one team. While they are not at this competition, the Robo Yetis are excited to announce their sister team the revived Black Forest Robotics team. This season we have been working separately but our designs have become closer and closer. The Black Forest team was not ready to compete at this qualifier so we invited some of their members to come work with us. One thing the Robo Yetis would like to highlight this year is that the majority of our team is in 8th grade. All of our eighth graders have had experience in FLL. We met them last year while we were doing outreach at our middle school To get them adjusted to FTC the first thing we did was build a GoBilda kit robot. That way our new members could learn how to use tools such as hex keys and become more familiar with the size of the robot and its strategy goals. \

Gender Make UP

Club

Team Makeup

Grade Level Make Up

Club

Team

Team goals

Gracious Professionalism

Gracious professionalism is one of the main values of FTC. That is why we decided to bring more attention to it by making it one of our goals. Another reason we wanted to highlight it this year is because of our club split. We are now sharing our space and resources with another team. We thought this might be a challenge since we would be roommates and competitors, so we did not want any conflict. To practice gracious professionalism we first put in place a few strategies such as reorganizing our room and making rules on when the teams can talk, so that no one feels like the other team is holding them back or wasting their time. We also all started as a club at the beginning of the year. When we first all met as a group we were not split into two teams. We took/gave tours of our space and began to brainstorm ideas for this year’s challenge. We were successful in maintaining gracious professionalism with the Black Forest Robotics team which can be seen in our collaboration with them at this competition.

Collaborative Google image with BFR explaining our organization

Building interest

Like many other teams, the Robo Yetis were hit hard by the pandemic. We did not have anyone competing for a while and then when our juniors joined three years ago there was only one senior. A lot of the mentorship has been left to our juniors who didn’t receive much themselves. One of our goals has been to start appearing in our community again and building more interest in the younger groups. When we learned we could have 8th graders on our team we invited them to join us as a way to maintain and grow the program. This just about doubled the size of our team.

Time Management

Last year we had to cram before every competition and it was very stressful and did not give us enough time to make improvements to our robot or practice driving. As a result, time management was one of our biggest goals. We used strategies such as a Gantt chart, Millanote, and a rule that we could not stay past 6. Last year we had a few meetings go well into the morning. This year we have only broken our rule twice where we stayed until 9:30. We are going to continue to work on this but our improvement from last year has been drastic.

Gantt Chart

Millanote

Building strategies

Pre-Building

At the beginning of the season we had hoped to do more Computer Aided Design this year, but with our team being mostly new members we did not have enough time to thoroughly teach our new members how to use CAD to the level of detail we needed. As a result, we used our whiteboards and paper to draw out our designs. We also acted out a lot of the necessary pieces with our arms or pieces we already had to communicate what we needed to make.

Prototyping

We used paper and tissue boxes to prototype many of our nonkit parts. We made our bucket out of paper and our claw out of cardboard the first time.

Building

When building we tried to split up into pairs and every pair had an assignment for the week on what they had to build. That way if one person couldn’t come one day their partner would work on the assignment. We made the assignments based on the level of commitment of the pairs. If we had a pair that could only come one day each we would give them something like an actuator or a slide which is part of a kit and has instructions.

Test as we go

Something new this year is we are testing all of our moving parts as we build. Last year we ran into the problem of putting together our entire robot and then having some parts not turn on or move like they were supposed to. It was then a big time expenditure to take those parts off fix them and then reattach them. One of our outreach experts recommended that we run our actuators and slides before putting them on the robot. We have employed this strategy and it has saved us a lot of time and given us confidence in our robot’s ability to turn on and move.

Game Constraints

When designing anything it is first important to identify your constraints. That way you do not build something that doesn’t follow the rules or waste time designing something that you can’t use.

Constraints:

Size

FTC has a size constraint of 18inx18inx18in for before the game starts. Once the game starts, we can extend 1 foot outside of our frame and 4 feet above our frame.

To stay within the size constraints we built a chassis that was 17inX17in and tried not to build outside of the chassis frame.

Number of Motors

Our original design had 9 motors, but the limit is 8 so we had to redesign and ended up only using 7.

Time

Everyone on our team has other extracurriculars outside of robotics. This means the time constraint for building is a huge limit for us. Our time constraint mainly plays into our game strategy. We knew we would have to use a lot of past knowledge and skills since we did not have much time to test new ideas. That is why we are going for a mid-level hang. We know how to hang, but we have never had to pull our robot up and our robot is too big to be above the bottom bar, so as a result of time we are going for a mid-level hang.

Materials

Shipping where we are is pretty difficult, so if you order something online it is not going to be there within a week. As a result, we try to use materials that we already have. That means we are partially constrained to what is in our parts closet. We design with those materials in mind.

Robot Design

Special Design

Wood

Last year we used many 3D-printed parts. We found that while they were light and relatively easy to make, they broke a lot. This year with our fear of things breaking and our lack of experience with CAD, we decided to go with wood for our special pieces. Wood is light and strong. It is also easy to make multiple drafts or changes later. We used wood for our claw and to attach our slides to our robot.

Claw

Our wood claw also uses veterinarian pet injury wrap as a way to grip the samples.

Basket

When testing how the basket would work we picked up the red container and used it as a prototype. We then realized it was a perfect size and decided just to use it instead of spending time cutting or printing something. It is lightweight and easy to attach.

Next Design

Before our next competition, we want to add another servo to our claw so that it is more stable and we would like to alter our design so that we can get the high hang.

Game Strategy

What we are going to do-Marley

• Hang
• Species
• Specimens
• Reasoning for our decisions
• Includes pictures of what we are talking about (a lot of judges are not involved with FTC and just volunteer so they may not know really what the field looks like and what parts are called)

After watching the video, we first identified that with such a young and experienced team we should try to go for quality over quantity. We decided our robot must be able to place the samples in the top bin and be able to do a mid-level hang. These both seemed attainable because the samples only required a longer slide and we know how to hang from last year. We decided not to attempt the specimens (hanging pieces) since they were not worth the extra points and would take more time. We plan to go back and forth from the submersible to the baskets. We will extend our slide as we are moving to save time. If for some reason we can not get our sample from our claw to our basket, we plan to put a sample in the net zone (space taped off under the baskets) to score 2 points. Ideally, we will put our sample in the top basket for 8 points. Then during the end period, we plan to do a mid-level hang earning 15 points. We are estimating at our first competition we will be able to back and forth from the submersible to the basket 5-6 times. That means we will be scoring 55-72 of our alliance’s points.

Introduction

Programming a robot requires a significant amount of coordination between functions - distance-aware movement functions must be able to interpret the location of the robot, which must be corrected for overflow when sending data over wires, and the robot and controller must constantly be isolated from static that can interfere with sent signals. We elected to synchronize the base of our robot in the Robot class, which contains references to all of its parts: a Chassis, a set of Encoder localization wheels, a Launcher, and others. The encoders are stored in the main robot model, and not the chassis, because they are the basis of the robot’s action methods.

Localization

Localization, or knowing the location of the robot relative to its starting position, is the basis of our coding system. We built three custom encoder pods that allow the wheels to always connect to the ground, even when parts of the robot are raised, and attached three REV Robotics encoders to the main control unit, feeding our code a constant stream of location data. Originally, our localization relied upon the RoadRunner library, created by ACME Robotics (FTC Team #8367). However, despite RoadRunner being a powerful library with many useful features, we determined that it would be best for the functionality of our robot to use our own Encoder implementations. Our Encoder class relies on a RoadRunner implementation to a certain degree, taken from the RoadRunner quickstart. We use this implementation to fix overflow in the transmission of data from the encoders to the control unit - while these data may be relatively accurate, the encoders have (ideally) incredible precision. This precision is essential because the encoders are the basis for so much of our code design, and is the logic behind our decision to use RoadRunner’s Encoder implementation. However, we do not use any other parts of RoadRunner - we specialized the Encoder implementation to use inches instead of ticks, and all of our movement methods take in an argument of distance in inches.

Robot Movement

Our robot’s autonomous mode relies on precise distance measurements provided by our encoders. If an encoder makes an error of 0.01 inches/inch, it may not be immediately noticeable (overflow can result in errors even larger than these, as entire bytes of velocity information can be lost). However, if the robot moves 100 feet throughout the autonomous mode, then its encoder positioning would be a foot off. If the robot were to try to pick up a pixel at that point, it would be unable to do so. It is therefore essential for our encoders to be as accurate as possible. We have garnered specifications for the wheels and encoder pods that we installed on our robot, and have tested movement continuously in the real world. Our autonomous mode has a certain amount of error correction built in (though, at the time of this writing, the autonomous mode is quite sparse), but focuses on specific movements only allowed through knowledge of location, rather than a sort of detection method (ex. TensorFlow Object Detection). Our manual control modes also rely on distance measurement but in an incremental way. Our current forward movement methods rely on setting motor power, but we decided to create a new recursive function while the robot runs to move forward. While the robot is running (while (opModeIsActive())), we call the driveStraight method and other functions based on the current percentage of tilt in the controller joysticks. These methods call the underlying Chassis.driveStraight with a distance parameter of one inch - an amount small enough to allow finite movement, but large enough to prevent high overhead. The function calls itself when the driveStraight method finishes, and checks if the gamepad is still tilted - if so, it drives the robot again.

Currently, the driveStraight method pauses the robot at the end of its movement, using the stop function (which sets all motor powers to 0). However, we have had to refactor this function so that it only stops when the robot is truly done moving, rather than every inch, preventing “jerky” motion. We have accomplished this by passing in a should stop parameter to the driveStraight function, which will only be true if the robot has traveled enough.

Project Organization

Abstraction, or moving lower-level code to specific handlers, is a major feature of our project structure. Our OpMode calls functions on our Robot model, which in turn calls its proper subpart. This abstraction is to avoid having the OpMode contain references to any parts of the robot itself. This also means that, when we have to change the actual behavior of a function (for example, changing the distance parameter of movement functions from inches to feet), we can just change the lowest-level function and then alter a slightly higher one to still take inches and then convert. We also abstracted telemetry functionality to the Utils.OutputUtils.print function. This function avoids possible errors of forgetting to use telemetry.update(), though it does increase overhead.

Pixel Detection

When we began to code our robot, we considered using a TensorFlow Neural Network for object (pixel) recognition. However, we decided against using an AI to detect pixels for several reasons. Cameras on robots are not only expensive, but also incur significant overhead, and an RGB camera would require a large amount of power. The camera can also be destroyed or knocked off-kilter easily, which would result in improper location detection for the pixels. The nature of Centerstage does not require a robot to detect the vast majority of pixels in random locations -  instead, the robot can find them in predetermined spots around the field. An object detection Neural Network might also struggle with the estimation of proper bounding boxes for objects, especially with novel backgrounds encountered at competitions.

Outreach

Instagram

With the loss of all of our older members, this year came the loss of our social media passwords. This led us to create a new Instagram account. If you would like to take a look our username is @ahsroboyetis. We have used our social media to get our team out there. We first put all of our bios on it, so followers could get to know us. We also update our Instagram page regularly by posting pictures of our work and humorous captions. We followed other FTC teams and they followed us back. Through DMs, we have made connections with other teams. We asked the teams who followed us where they were and what competitions they were going to.

George Helfenstine

Our middle school FLL coach made an announcement at the middle school describing what we did and encouraging middle school students to join our team.

Will Gilmore

While meeting with our local FLL teams we met one of the coaches, William Gilmore, who is a mechanical engineer. After our presentation, he sent us an email asking if he could come in and talk to us about our design and see if he could improve it. After meeting with him we decided that we could have a static claw. He also brought us a McMaster-Carr physical catalog. In there, we can find any materials. While looking at it, we learned that we should be using screws specifically for plastic. Gilmore was also able to help us with our static issues, even though it is not his specialty. He taught us how to mount our grounding wire properly. It was very beneficial for us to be able to hash out our design with someone who knows enough about design that they can help us critique our plans. He has also offered to let us use his 3-D printer which is a huge win.

FLL

Some of our members went to our middle school to help our Worlds Qualifying FLL team design their project, which is a robot that looks like a turtle and swims through reefs to monitor reef health.

Betty Book-Sloane/Marley

One of our past teams wrote a book called Betty the Yeti. This year we are working on writing a sequel that we can then read at our local library.

Clubs Fair

The main way our team attracts new members is at our school’s club fair. The fair happens every mid-October. During our study hall period, clubs set up tables in the gym. Every year we sign up for a table, make sure we have a robot for demonstrations and print out the sign-up sheets. This is a good opportunity to remind our community about the robotics club and to get new students or freshmen involved. Leading up to the club's fair we also post flyers around the school. We got four members this fall after the club's fair.

Cover page

Background/make up

Team goals

Design process/build strategy

Game strategy

Design

• Chassis
• Slides
• Hanging
• Moving claw out
• Claw-Aurelia
• Basket (with chute)

Outreach

Non-technical

• Instagram
• Spotify
• Showing of robot
• Betty the yeti
• Clubs fair
• George helfenstines
• Logo competition-Aurelia

Technical

• Fll teams
• Will gilmore
• Tyson weighs

State goal

State constraints

Describe design

Research

What went wrong

Goals for next one

What went wrong

Goals for next one

Final description of how it works