Frequently Asked Questions 

1. How detailed should our CAD models be? Does it need to show every single screw or belt?

• Your CAD doesn't need to be super detailed, as a rookie team getting different assemblies cadded to flesh them out more can be super helpful even if they aren't super detailed. It is helpful to have a full model (includes all robot parts even if they are not detailed parts) to make sure they will still fit together if you need to make a change later in the season.  

2. Which CNC services are good for rookies to use, and about how much do they cost?

• We get our side panels CNC'd although most of our custom parts are 3-D printed out of PLA. We only make a part out of metal if it needs to be super strong. The printer we use is here. If you do need CNC machining, try contacting local universities that may have facilities and will be willing to support a STEM project.

3. From the previous seasons, what were the biggest challenges your team faced when designing or developing your robot?

 CAD

We spent lots of time in our CAD software (Onshape) modeling our robot and simulating the geometry of each subsystem. Because we needed to have our clipper, intake, and depositor working together seamlessly we used our full robot assembly to iterate on our geometries until they worked.

ESD

Like many other teams, we face significant challenges with ESD, currently we cover our robot side panels with polycarbonate sheets and use 3d printed parts to fill the smaller gaps to minimize the amount of metal exposed on our robot that it could contact with field elements and ESD to. 

4. What are some advantages and disadvantages of parallel plate drivetrains?

• Our drivetrain uses parallel plates because it lets us use spacers and bearings to keep our wheels in place and we can sandwich them in between the plates. The space between the wheels in the plates can be valuable as protected space for other elements like our batteries.

5. What's the difference between normal screws and thread-locking screws, and when do you use either of them?

• We don't use thread locking screws a lot, instead we use blue loctite to keep our threads sealed. We use brass heat set inserts inside of our plastic parts and we Loctite our screws into the inserts.

6. How can we fasten/stabilize our pulleys' effectiveness?

• We usually use a tensioner on our belt systems in order to keep them tight. 

7. How much tolerance is given if the robot slightly exceeds the 18 x 18 size limit? Is one screw sticking out of the size limit enough to disqualify a robot?

• Don't exceed the 18x18 limit, even a screw sticking out will need to be fixed. They will measure your robot before every competition during the "robot inspection". Our team likes to have a little wiggle room so that we can fit easily.
  This year it’s even more important to be an inch or two less than 18 inches in at least one dimension - as many end game double parks will require fitting between the extensions of another robot.

8. What was the auto-clipping automation process like? Did you use a state machine?

• For the process of our auto clipper, we knew early on that we wanted to do something ambitious and we thought about how we could reduce our cycle times and have the most efficient robot possible. Most years we only have a state machine for our drive, intake, and depositor, but because the clipper was its own complex mechanism, we also used state machines for the clip clamp, clipper slide, and clipping mechanism.

9. Would it be better to do the CAD or prototype a lot of things first?

• For our team, we start off by prototyping a lot of ideas that “could work” with some CAD for 3-D printing parts for prototypes. We then categorize them with pros and cons and narrow down the best ideas for each of our subsystems. Document all the things you consider - judges want to see what didn’t work as much as they want to see what worked - they want to know why you picked one idea over the others. After that, we CAD out the final ideas we have and test them for feasibility and accuracy. So to answer your question, we recommend prototyping first, then cadding the designs that appeal to your team.

10. How does the mechanism design process work for you?:

• We list the design criteria and what the mechanism needs to do, then brainstorm ideas, narrow them down with pros and cons, and then look into how to prototype them. Creating a design criteria is helpful because it gives you an overview of what each mechanism needs to do and you can base your brainstorming on.

11.  Can you describe your ‘Into the Deep’ robot’s main design and what made it unique?

• For last year's game (Into the Deep) we decided to make a clip bot that was very different from a lot of teams. The main innovative feature of that design was the auto clipper, which stood out because it automated the specimen scoring process. Other teams had to take each specimen (game piece) back to their human player who had to add a clip to the sample making it a specimen, then their robot had to pick that back up to go and score it. The rules allowed for the possibility that the robot could attach the clip to the sample instead of the human player, which was very complicated, but it saved a lot of time. We spent the whole season making that work and it was a major advantage that greatly improved our overall performance. 

12.  What was the biggest technical challenge your team faced, and how did you solve it?

• We encountered many issues last season (Into the Deep). The transfer mechanism proved to be very challenging because it was the place where all three of our subsystems (transfer, intake, depositor) met. We modeled our geometry in CAD and were able to iterate on it throughout our season - having a good CAD model is very valuable as the season progresses because it allows for making adjustments and verifying they will work/fit before touching the hardware. Additionally we focused on increasing the reliability of our robot. Because our entire robot was centered around our clipping mechanism we had to make sure that it could score every time it picked something up without missing clips or transfers. Solving that involves taking into account every failure mode you encounter - allowing you to avoid problems or recover from failures you can’t avoid. We dedicated significant time to refining both the hardware and software, carefully testing and fixing every potential issue to make sure the clipper could score reliably.

13.  How did you test and refine your robot throughout the season?

• During (Into the Deep) last year, the clipping mechanism of our robot had a high potential for failure, so we focused heavily on testing and refinement. We created realistic field scenarios to observe both when and how our robot could fail, allowing us to identify weak points early. We also used a go-pro camera mounted on our robot recording how the mechanism was working so we could see in slow motion what happened during failures. We also incorporated lessons learned from previous competitions to make the robot as reliable and robust as possible, which included

14.  If you could redesign one part of your robot or process, what would it be and why?

• One process we would redesign is our project planning at the start of the season. We sometimes fall into the trap of assuming we have plenty of time, but that’s never the case. Recognizing this early on would help us plan and pace our work more evenly throughout the season and avoid the last-minute rushes that usually happen one to two months before competition.

15. How do you keep your robot stable when pushing with other robots?

In order to improve our stability in previous seasons we have added weights to our robot - this can come at a cost if there is an endgame lift/hang element because it will take longer to hang and we may need to dedicate more motors in order to get the force we need. This also affects speed, as the more mass you add, the longer it takes to reach top speed - limiting your speed across the field. We also may adjust our gearboxes on our drive motors to increase torque in order to account for this in exchange for our top speed being lower. This trade off depends on the various goals of the game and on each Team’s strategy.

16. How does your team conduct testing and design iteration before the final build? Do you follow a specific evaluation process or method?

When we test our robot we try running whatever we are testing a bunch of times and recording what the results are, we set a goal and a percentage of the time that we want to consistently achieve that goal and we iterate on the system until we get to that point. Lots of our testing results from driving our robot in practice matches and observing when things go wrong or could be improved. 

1. Is the Logitech webcam that comes with the control kit reliable for computer vision?

• Yes, but it depends on the use case. Some deciding points may be the field of view, resolution, or how well it fits on your robot.

2. Are the touch and color sensors useful for anything?

• Yes, touch and color sensors can be very valuable. Touch sensors can be used to detect a successful intake, or for re-zeroing a slide. Color sensors can be used to sort game elements, avoid collecting the wrong colored game elements, or finding field features.

3. How does your code structure work? Does it follow any methodology or something specific?

• We generally have it split into what manages our robot and what our robot is actually doing. We use state machines and a robot class, as well as inheritance and velocity control loops.

4. What type of library do you use for code organization? Would it be SolverLib or NextFTC?

• We don’t use any specific code library, most of our code is organized with github. We don’t have experience with SolverLib or Next FTC so we can’t say anything about those.

5. Do you use any type of calculation to calculate the power of the shooter based on distance?

• We have just started prototyping so we are still developing a definitive calculation, but the physics for a flywheel would start with the Kinetic energy generated (if the ball is not slipping) Ef=½(Iw^2), then use a ballistic trajectory formula for the distance: y = h + xtan(α) - gx²/2V₀²cos²(α). Google those terms to get details on what the variables are. 

6. If you use Limelight, how do you use it and configure it in the code?

• We do not use Limelight because we find the camera FOV to be too narrow and we prefer making our own color sensing algorithms. For our vision code, we use openCV because it is compatible with our camera of choice and allows deeper control via the openCV library. We haven’t used the Limelight sensor so we don’t have insight into how to configure it.

7.  What sensors or programming techniques are you using, and why did you choose them?

• We code in Kotlin, which is essentially Java with additional features, because it handles concurrency well (which is also known as multi-threading / running multiple decision loops at the same time). Kotlin offers useful tools for development, and is easy to understand if you understand object-oriented programming. For our vision, we use OpenCV as our library. We don’t use a Limelight camera because using a flexible wide-angle webcam better aligns with our vision goals and we’ve already developed many tools for OpenCV over the last 3 years. Last year, we experimented with a SparkFun odometry sensor, which works like a computer mouse, and found it to be a great choice due to its lightweight design and precise tracking over short distances (half the field). Encoders are also a crucial part of our system, as they allow us to achieve highly accurate and automated movements of our mechanisms. Finally we use software states to manage our mechanism behaviors.

1. What exactly do judges expect to see in our presentation and portfolio?

• For the portfolio, the awards rubric is posted in the game manual in section 6.3. Try satisfying all of the requirements for the award(s) you would like to win. For the interview, the judges like to see how enthusiastic you are, that everyone is involved, and how you spread first/gracious professionalism.

2. In how much detail do we have to explain our code in our presentation/portfolio?

• Judges will want a general understanding of your code. Using visuals like flowcharts are a great way to convey how your code works. You want to show the judges that you know your code well. Be ready to verbally explain your code.

3. Is there some sort of rubric we can use to structure our presentation and portfolio? So far, we haven't been able to find one.

• The awards rubric is posted in the game manual in section 6.3. We recommend trying to satisfy all of the requirements for the award(s) you would like to win.

4. Which award would be the "easiest" for a rookie team to get?

• After the Inspire Award, all the other awards are worth the same amount of advancement points so try for the one that best fits your team. You might shoot for awards like Innovate, Connect, or Design because they may be easier to get for newer teams. For the Innovate Award, if you are able to make your robot have a new creative feature, even as a rookie team, it's feasible to win. For the Connect Award, judges are looking to see how you work with your local STEM community and spread FIRST. Finally, for the Design Award, it can be awarded to a simple robot that is optimized for the challenge.

5. How is your portfolio divided?

• Our portfolio changes over the course of the season, but we categorize it by having 3-4 pages about our team, sponsors, and goals. We have 3-4 pages on outreach which we try to make as concise as possible. Finally we share the remaining pages among hardware and software. Make sure to expand on the design process and how you spread first in these sections. For our portfolio, we try to abide by the rubric that's posted in the game manual (section 6.3) to maximize our award winning potential. 

1. Is reaching out to local businesses rather than large corporations an effective way of securing sponsors/grants?

• We would recommend trying to do both as it is a good idea to have as much support as possible. Large businesses are harder to get, but contribute more money, while local businesses are easier, but will likely not give a high amount of money. Some ways to secure these grants are through parent employers or foundations that are interested in supporting First.

2. What are some ways a rookie FTC team can do outreach?

• Some good ways to get started with outreach are presenting in local events, technology fairs, holiday events, or even farmers markets where you can show off your robot. Also, if you have connections with schools, presentations/demonstrations are a great way to raise awareness. You can also ask for tours of local foundations/businesses. Stem focused events are preferable, but doing other charitable actions in your community can spread your team name and First values.

3.  How do you share FIRST and STEM in your community?

• We spread FIRST in our community by attending local events and showcasing our robot and the FIRST organization. We visit local businesses and give presentations to encourage new students to join FIRST. For STEM outreach, we participate in events that aren’t specifically STEM-focused, like Farmers Markets, or City Festivals where we can have a booth, which gives us the chance to teach and inspire students who might not otherwise be exposed to STEM. Additionally, we mentor some community teams, sharing ideas and strategies that have been successful for us to help them grow.

4.  Have you mentored or collaborated with other teams? If so, how?

• We have met with many teams, primarily over Zoom. Typically, a team reaches out to us seeking insights or guidance, and we shortlist the most interesting opportunities for collaboration. From there, we share possible meeting dates and eventually connect to exchange ideas and experiences. So far this year, we’ve met with teams from Indonesia, India, Brazil, and now Greece! These interactions help us share our STEM knowledge while expanding our global impact through outreach and collaboration.

5. How has FTC helped your team grow interest and skills in the field of STEM, and how do you share that passion with your community? 

• FTC has had a huge impact on our team’s interest and skills in STEM. Being part of an FTC team feels like working in a real company, where each subteam such as hardware, software, outreach, and media focuses on its own goals while collaborating toward one final product. Through this process, our members have learned valuable technical and teamwork skills including coding, engineering, communication, and leadership. We share our passion for STEM by participating in community events, mentoring new teams, and demonstrating our robot to inspire others to get involved in FIRST and explore STEM fields.

6 . How has FTC helped your team grow interest and skills in the field of STEM, and how do you share that passion with your community?

• FTC has had a huge impact on our team’s interest and skills in STEM. Being part of an FTC team feels like working in a real company, where each subteam such as hardware, software, outreach, and media focuses on its own goals while collaborating toward one final product. Through this process, our members have learned valuable technical and teamwork skills including coding, engineering, communication, and leadership. We share our passion for STEM by participating in community events, mentoring new teams, and demonstrating our robot to inspire others to get involved in FIRST and explore STEM fields.

7. What is your outreach plan in this decode season? 

• Our outreach plan for the DECODE season is still developing, but we already have several key goals. We plan to host online meetings to mentor other teams, participate in community events to spread awareness of STEM, and raise funds for local nonprofits. Additionally, we aim to strengthen our global connections by organizing online events with teams from other countries to continue expanding our international impact. We also plan to host scrimmages with nearby teams and give presentations to sponsors and local businesses to showcase our work and inspire further community involvement.

1.  How often do most teams meet?

• It depends on the team's goals and the time constraints of the students, mentors, and facilities. For us - always trying to build a world-class robot, we meet around 10 hours a week, and it escalates as we get further into the season. We would recommend making goals that you want to accomplish each week, and if possible meeting for as long as it takes you to accomplish them.

2. How is the team divided into sub-team areas?

• Our team is mainly divided into a software subteam and a hardware subteam (each student is on one or the other). Then there are other sub teams like outreach, media, scouting, and notebook subteams that any members from the software and hardware subteams can be on.

3.  How is your team organized, and what are each member’s responsibilities?

• Our team is divided into two main subteams Software and Hardware with each member belonging to one or the other. We then have additional subteams, including Outreach, Media, Scouting, and Notebook/Portfolio, which members from either primary subteam can join. All students are part of the Notebook/Portfolio sub-team Each Sub-Team has a Lead who is responsible for making sure all the tasks of the sub-team are accomplished on schedule. Sub-Team leads guide their members, coordinating efforts across the group, and ensuring that all parts of the team work together effectively to achieve success. Every member sets a goal for each meeting, whether it involves collaborating with others or working independently. 

4.  How do you make decisions as a team, and what do you do when team members disagree on an idea?

• Our team holds weekly meetings to discuss future plans and share new ideas. When it comes to subteam decisions, we typically follow our mentors’ guidance, or the member with the most expertise in that area makes the final call. We rarely encounter major conflicts since our designs focus on finding the most optimal solution, which is often clear. If disagreements do arise, we revisit the idea together, listen to each member's point of view, outline the pros and cons, and use that analysis to make a fair and informed decision.

5. How does your team brainstorm to get efficient and well-thought out designs?

Brainstorming

• At the beginning of the season we have lots of ideas to work with, after kickoff we firstly discuss some strategy and look into what our ideal robot would look like. We set our design goals high because we know that we will have time to prototype different ideas. Second we split the team up into small groups and we all brainstorm ideas separately before regrouping and converging on a few ideas to prototype. From here we iterate on our prototypes and keep brainstorming across our season to improve our robot as much as possible

6. Based on your experience from the past few seasons, what is the most effective approach to finding the perfect balance between speed, accuracy, and reliability in your robot?

• In order to optimize our robots accuracy and reliability we test it and then observe it in practice. With each set of tests we try to refine it. We also try to design for the game, for example in power play we had a lighter robot that could quickly move around the field but it was able to be pushed because of this; different seasons have different requirements for these parameters. Finally we improve our accuracy with many tests, we fine tune our software in order to make our robot more consistent and automated.

1.  What are some lessons your team has learned this season?

• A few things that have come up so far this year are:

1) A single fly wheel is easier to implement than a dual-wheel launcher. Teams with two-wheel launchers are finding a lot of variation in aim because the wheels get out of sync.

2) To improve your odds of being picked for an alliance in the elimination rounds, your double park strategy should either be compatible with most other robots or be able to fully park using less than half the square.

3) Rule updates and reading the question and answer forum is critical this year as always… keep up on all interesting questions and official rule updates each week!

2. In the DECODE game, how did your team determine scoring priorities and try to balance time efficiency during both the autonomous and tele-op periods?

• To figure out how best to use our time and our scoring priorities we come up with goals such as ‘we want to shoot 3 balls in x time’, ‘we want all our balls sorted before we enter the launch zone’, ‘we need to intake this fast in teleop’, and more. These goals help us manage our expectations for scoring and time management. In Decode - a fast consistent intake, a consistent autonomous that scores the pattern, and accurate shooting are key priorities.

3. What is the award that the team is aiming for and why?

• This year, our team is aiming for the Inspire Award for several reasons. First, we believe it’s an achievable goal for a team like ours, which already has experience and a solid understanding of how the competition is structured. The Inspire Award recognizes teams that are strong candidates for multiple awards, which aligns well with our strengths. Additionally, with the new scoring system, earning the Inspire Award grants a significant number of placement points, making it an even more valuable goal to pursue.

4. What is your outreach plan in this decode season? 

• Our outreach plan for the DECODE season is still developing, but we already have several key goals. We plan to host online meetings to mentor other teams, participate in community events to spread awareness of STEM, and raise funds for local nonprofits. Additionally, we aim to strengthen our global connections by organizing online events with teams from other countries to continue expanding our international impact. We also plan to host scrimmages with nearby teams and give presentations to sponsors and local businesses to showcase our work and inspire further community involvement.

1. Based on your experience from the past few seasons, what is the most effective approach to finding the perfect balance between speed, accuracy, and reliability in your robot?

• In order to optimize our robots accuracy and reliability we test it and then observe it in practice. With each set of tests we try to refine it. We also try to design for the game, for example in power play we had a lighter robot that could quickly move around the field but it was able to be pushed because of this; different seasons have different requirements for these parameters. Finally we improve our accuracy with many tests, we fine tune our software in order to make our robot more consistent and automated.

2. How does your team apply the principles of Gracious Professionalism during competitions and interactions with other teams, both locally and internationally?

• FIRST is built on the foundation of Gracious Professionalism, and everyone on our team practices it at all times. Gracious Professionalism means showing good sportsmanship, supporting both teammates and opponents, and being kind and respectful in all situations. Our team is always willing to help others and offers assistance whenever we can. Locally, we participate in community events to spread awareness about FIRST and share our knowledge, while globally, we host Zoom calls and strengthen the connections we’ve made during championships.

3. How does your team manage pressure and consistent performance during major competitions like the World Championship, especially when certain subsystems encounter technical issues?

• During our championships we have implemented a hardware checklist and test op mode in order to assure ourselves that our robot is ready for its next match. In our checklist we write down all the elements on our robots that are critical to its operation and the elements that are prone to breaking - things like our servos and motors being plugged in, screws being tightened, and servos and motors being in working condition. Before every match our drive team will run through this checklist and make sure that everything is ready to go before our match. After we run our checklist we run our test op-mode, this moves all of our motors and servos on each mechanism to make sure that we did not miss anything on our hardware checklist and that our robot can mechanically reach its full range of motion. When we do encounter hardware problems we try to implement a quick fix or replace the broken part/system with one of our backup parts/sub systems that we have prepared before the competition. Finally we bring our 3-D printer (a Bambu Labs A1 mini) to our competitions in case we need to design or print something on the spot for ourselves or another team.

• 4. How does your team apply the principles of Gracious Professionalism during competitions and interactions with other teams, both locally and internationally?

• FIRST is built on the foundation of Gracious Professionalism, and everyone on our team practices it at all times. Gracious Professionalism means showing good sportsmanship, supporting both teammates and opponents, and being kind and respectful in all situations. Our team is always willing to help others and offers assistance whenever we can. Locally, we participate in community events to spread awareness about FIRST and share our knowledge, while globally, we host Zoom calls and strengthen the connections we’ve made during championships.

1. What is your strategy to consistently be a world-class team?
Becoming a team that competes consistently at a world-class level takes multiple years of growing your knowledge of robotics. Always remember that in FIRST - winning is not the ultimate goal - LEARNING is the ultimate goal! If your team doesn’t make it to Worlds but students learned new skills, gained confidence, and enjoyed working on a robot - that is a very successful season. But going to Worlds is both exciting and inspiring, so how do you get there? There is no single ‘right’ way to do it, but here are some things that have worked for us:

Basics

Gracious Professionalism (GP) - a foundational part of FIRST robotics. It’s easy to like the idea of GP, so emphasize it throughout the year! Tensions and conflicts will arise on robotics teams just like they do in real world teams - using GP values and the common goal of learning is essential to team bonding and individual growth.

Read/understand all the rules in the game manual - and read all the forum questions/answers and manual updates. Understanding a rule update or clarification can be the difference between having a creative feature or strategy that scores you extra points or that ends up being a penalty.

Make your software code re-usable each year - organize each section of code with intuitive long-name variables that can be easily updated in one place. Add comments to ALL your code so it’s easy for future students to understand the code that is there. Build and grow your code more each year.

Learn CAD - CAD your base and build off of that each year. You don’t have to CAD every detail, but seeing how the major parts will fit together before you create all your parts can save you critical time in a short build season.

Learn odometry - improve it each year. When your robot knows where it is on the field, you can earn more points in the autonomous period, and can start to automate some actions in teleop.

Use a camera for vision - every game has a vision element, start simple and build on it each year. Simple object and april-tag identification lets you score more points in the autonomous period.

Use sensors - simple sensors help your robot complete tasks. Learn how to use at least one new sensor every year or over the summer if students can meet. A simple color detector, a distance sensor, even a simple contact sensor can be used to confirm an action is complete.

Advanced
(whenever students/mentors have the passion to delve into these areas, they take a lot more time, commitment and effort but are worth it)

Use 3-D printing - move from kit parts to custom parts. If you don’t have local access to a 3-D printer, see if universities or businesses in your area will support you and print parts for you. Printing custom parts greatly increases proto-typing time, allows for unique solutions to mechanical challenges, and makes it easier to have backup parts or whole assemblies ready to swap in if something breaks. 

Reliability is more important than speed - At the highest levels, everyone is fast, but if you go so fast that you only succeed 2 out of 3 tries… you won’t be seen as a reliable partner for another top team. You want each action to succeed on at least 9 out of 10 tries, better yet 19 out of 20. 

Advanced Software - learn about multi-threading, state machines, and reducing code processing time loops. A robot can process data and react faster than a human - use your code to automate key actions in both the autonomous and teleop periods.

Manual overrides for automated processes - during a match, things don’t go perfectly - ever… so always give one of the drivers the ability to manually adjust the robot/software parameters if an automated action gets off track.

Advanced Vision - learn to adjust for shadows and different lighting conditions, locate multiple objects and elements and prioritize them, learn to shorten and optimize image processing loops - then you can track objects in real-time, determine your location from images, and automate robot actions to save time.

Have some Luck - this might seem like a joke, but FIRST is deliberately set up so that there is always some luck involved. Random partners in qualification rounds can make it harder or easier to progress. One referee might interpret a rule differently than all the previous ones you’ve had. Key people on the team might get sick before a tournament. A part that has never failed before might finally fail during a match. There are things out of your control, luck will always play a role - don’t feel bad if you have some bad luck. But bounce back - the more you learn and the harder you work and prepare, the more you improve your ‘luck’.

Finally - Love robotics - to compete at Worlds, you have to put in a lot of time - both with mentors and on your own. Be excited to research and learn about new concepts and bring ideas to the team. Be willing to document all your ideas and decisions - for the Portfolio and Judges but more importantly, for next year's team! Take data and learn from it - be excited to find a subtle (or obvious) pattern in the data that indicates a loose bolt or a software bug. Win or lose - if you are proud of the work you put in throughout the year - you have succeeded.