Vector 8177 Build Thread | Open Alliance 2023

Team History/Introduction

We are happy to announce that Vector 8177 will be participating in Open Alliance for the 2023 FRC season: Charged Up!

Vector 8177 is a school team based in Tomball, Texas. This will be our team’s fourth year (second full year of competition) and our second year as an Open Alliance team. Not only has our team grown tremendously over the past year, the Open Alliance has grown tremendously over the past year as well, and we hope to help it continue to expand in order to help more FRC teams around the world. Looking back on our last season, we can confidently say that the openalliance was monumental in the aid it gave to the FRC community. Thanks to teams sharing prototype data, strategy advice, cad models and code libraries to reference, and feedback on our own work, we were able to progress all the way to division playoffs at the World Championships.

This year, we hope that our OA posts during the build and competition season will help out other teams and help them grow. Whether it’s ideas about robot designs and iterations, the organization of different subteams, or our workflow, we hope that other people are able to find valuable insight from our experiences.

Team Links

Kickoff Event

This year our team will participate in a district-wide combined kickoff that included FRC teams 8177, 7312, 7691, and many of our district’s FLL teams. We hope that bringing all these teams together will create a collaborative community environment where we’ll be able to help each other out and grow robotics and STEM interests in our school district.

By having FLL teams come and see what kickoffs are like, we hope to inspire future generations of kids to be invested in FRC and come into high school passionate and knowledgeable about robotics. Bringing together everyone will form a stronger bond between the teams in our district and expand our impact on students.

Kickoff Plan

After watching the game reveal animation, we’ll have groups of around 10 members dive straight into the game manual to collect information, whether that be scoring tables, field dimensions, robot restrictions, etc. This will allow members fully grasp the 2023 game beyond just the animation which will help when developing potential strategies and robot designs. After a little while, we’ll gather all the groups together (including members from other teams) and go through our findings together to make sure everything was covered and answer any potential questions people have.

The next step is brainstorming different strategies and deciding what tasks we should be achieving with our robot. This will entail coming up with the pros/cons of different strategies, what scope we want to take, and narrowing down on what a hypothetical robot might do. We’ll likely decide on the main goals we want to accomplish and create a general timeline of when we want things completed. Having this will allow us to keep on track during the build season and give enough time for the programming team to test and for the drive team to practice.

After discussing potential strategies and narrowing them down, we’ll let students brainstorm and draw up sketches of a robot or specific robot mechanisms. This brain dump will allow for potential gems to be found in terms of design and strategy.

Overall, we have a few main goals for the kickoff that we want to accomplish. First is that we want all members to leave with a solid understanding of how the game works including all the rules, robot specifications, game elements, etc. We also want to come up with a rough idea of what the robot will look like by the end of the day

Build Season Plans

Due to a lack of experience in the 2022 season, the CAD model for our robot did not get done until late into week 4 which led to less time for iterations and programming. This year, we hope to finish designing the robot by the beginning of week 3 and have the robot built by week 5. This will allow ample time for the programming team to fix any potential bugs and create better autonomous routines for our first district competition.

Another emphasis we want to have this year is on driver practice. In order to be successful, the robot has to be driven and operated well during competition. Even if it a robot can do everything on the field, a lack of driver experience will lead to it reaching nowhere near its potential ceiling. On the flip side, driving a well-built robot that has reliable mechanisms at its peak capabilities will lead to a lot of success which is what we hope to aim for this season.

Off-Season Update

We’ll be posting another update soon for all the stuff we’ve done during the off-season including projects, community outreach, and more!

Also, Happy New Years 2023, we only have one more week until kickoff!!


Offseason Activities

After a pretty successful 2022 season, our team took a well-deserved break before jumping into the offseason at the end of the last school year. Here are some of the projects and things we’ve learned over the past few months.

Summer Camp

Over the summer, FRC Team 8177 Vector hosted its very first Vector 8177 Summer Camp (wooo!! :tada:) for incoming 6th to 8th graders. Overall, the camp went pretty smoothly but with a few notable hiccups that we are going to go over later in the post. But first, an overview:

The camp was relatively small, lasting only 5 days (July 18th - 22nd) from 9 am to 3 pm for 30 students and an admission fee of $225 per student or a sibling discount of $200 per sibling. Our goals for the camp were equally small. The camp was to cover very basic programming, engineering, and physics topics in an engaging and fun way that allowed students to get a glimpse of how STEM affects the world around them. As we learned, however, the engaging and fun part was the most challenging, as lecturing about newtonian physics certainly did not seem enticing to 6th graders, but more on that later. Our schedule for the week went:

  • 30 min Camp Intro
  • 30 min Ice Breakers
  • 30 min Robot Showcase
  • 45 min DIY Motors
  • 45 min Code Monkey
  • 30 min Lunch
  • 125 min Arduinos
  • 25 min Wrap Up
  • 10 min Camp Intro
  • 40 min Spaghetti Tower
  • 65 min CAD Rings
  • 30 min Egg Drop
  • 30 min Lunch
  • 65 min Arduinos
  • 45 min Line Followers
  • 10 min Camp Intro
  • 80 min Smoke Cannons
  • 60 min Line Follower Challenge
  • 30 min Dry Ice Experiment
  • 30 min Lunch
  • 30 min Gear Ratio Lesson
  • 240 min Vex Clawbots
  • 10 min Camp Intro
  • 30 min Vex Clawbots
  • 180 min PVC Catapults
  • 30 min Lunch
  • 30 min Vex Clawbots
  • 60 min VexVR
  • 30 min Vex Bounce Path Challenge
  • 30 min Vex Slalom Challenge
  • 10 min Camp Intro
  • 50 min Sling Shot Rocket
  • 240 min Vex Challenges
  • 50 min Lunch + RoboLeague Documentary
  • 15 min Kahoot
  • 45 min Prize Auction
  • 45 min Wrap Up + Parent Demo

So what worked and what didn’t work? Here are a few lessons we learned from running our first summer camp and insight into how activities could be improved.

Monday Introduction

Monday was the roughest because everyone was still getting comfortable with each other and opening up. We tried combating this with our ice breaker, which was a human scavenger hunt that forced the students to find other students similar to them. While the scavenger hunt did its job, it allowed some students to be left out because others capitalized on loopholes within the rules. Given our goal for the first hour was to engage all students, the scavenger hunt did not satisfy our goals and for future camps, we will look for an icebreaker that is more fun and less exploitable.

Robot Showcase Better Execution

The robot showcase was another instance of a great idea, with poor execution. Our idea was to give the students an idea of what everything they learn will contribute to, but it quickly devolved into us lecturing using these terms they don’t fully understand. Having them drive the bot also elicited an underwhelming reaction, as again, most didn’t fully grasp the complexities of the bot. While we are convinced that the robot showcase should be included in our camp, we would need to reevaluate our approach to it. Maybe shorten the initial showcase and, within each activity, focus on connecting it to a specific part or function of the bot?

Programming Activities Rushed

Our programming progression was very confusing. We went from Code Monkey, which was block coding and too easy for the students, to Arduino code which required more extensive knowledge of programming, and back to block code in VexVR. While a brief introduction to programming was taught, the students had little to do that engaged them. In the future, rather than separating the programming lesson and Arduino, it may be better to have multiple programming lessons that targeted a specific Arduino function, for example, flashing lights or sirens. To further streamline the programming progression, VexVR should come before Arduinos and probably replace Code Monkey. This would open up more time for Arduinos, which should give the veterans leading the lesson more time to flesh out topics and help the students.

CAD Activity Too Complicated

The introduction to CAD was interesting to put it nicely. Quickly, it became apparent that many students became lost in the various menus and terminology. Simply put, 65 minutes is nowhere near enough time to introduce CAD, explain why it’s used and its benefits, walk them through the various menus and options and also do an activity. In the future, CAD needs to be given more time and most likely separated into small, digestible parts so that everyone can keep up.

Gear Ratio Lesson Not Engaging

The last major hiccup was our gear ratio lesson. The issue with it boiled down to the activity being weak. Essentially, the entire activity was for them to figure out the best combinations of gears that allowed the last gear to spin the fastest. Mix the weak activity with a lecture on torque and its inverse relationship with speed and you can see how the students quickly lost interest. An idea that was tossed around to improve the activity was to essentially create top launchers and have the students experiment with which ratio is better suited for tops of different sizes, weights, etc.

Other Minor Issues

The remaining issues were all minor. For the DIY motor, make sure to have a powerful enough magnet to actually spin the wire. The spaghetti tower and egg drop need around 5 minutes more and the air cannon needed 80-90 minutes. Additionally, having a fog machine greatly improves the air cannon activity as students have fun shooting smoke rings at each other. The Vex Clawbots and PVC catapults could’ve had better instructions, perhaps custom-made ones that better illustrate our specific use case for those activities.

All in all, the summer camp was a massive success for our team and one that we hope to be able to continue on a larger scale. Starting small allowed us to get a taste of what to expect and taught us what needed to be changed in the future.

TRI: Texas Robotics Invitational

Oh boy. This was definitely a competition. TRI, hosted by FRC Team 3847 Spectrum in Houston, TX was a tournament of lows and even lower lows for us. The primary goal for the tournament was to get all rookies hands-on experience with the bot, from driving and climbing to scouting, strategy, and repairs. Unfortunately, that goal never came to fruition as a mechanical failure after mechanical failure had our bot barely functioning on the field. A majority of our issues could have been avoided but poor manufacturing processes and general oversight over the smaller details finally came back to bite us. Here are some of the more notable issues with our bot during the competition. You can find the post that documents our fix here.

Jammed Elevator

  • Due to a lack of time and knowledge, we were not able to get our cnc up and running for cutting tubing during the season. All of our tubing holes were hand drilled, leading to out-of-tolerance parts. We thought that they would be “good enough.” Spoiler alert, they were not. At TRI, our cargo elevator motor finally burned out after having issues at worlds. A mentor of 3481 Bronc Bot was kind enough to give us a replacement 775pro to use (thanks again). We ended up fixing the issue by oversizing the belts and under-sizing the pulleys(insert pic of elevator for context) for our second off-season competition.

Jammed Climbers

  • Our climber used two climbers-in-a-box, which we have had repeated issues with. Whether we implemented the system incorrectly or there was some issue with our climbers, throughout the season we ran into intermittent issues that prevented us from traversing. At TRI, the frequency of our climber’s failures peaked at an all-time high. We could climb to the mid-bar every match, but there was a >50% chance that we couldn’t make it too high or traversal. Because our technical leads were stuck in the pits after every match trying to fix the climber, we were not able to properly give our rookies as much focus as we should have.

Robot Remix

For our second off-season event during the 2022 summer, we went to Robo Remix hosted by FRC Team 1477 Texas Torque in the Woodlands, TX. Our main goal for this competition was to train rookie members and get them used to the competition environment and how everything works. This included things like unloading the cargo van, pit setup, inspection, practice matches, scouting, drive team, strategy, and more.

Overall, I think we were pretty successful in teaching new members as we had a good mix of veterans who attended multiple competitions the previous year which meant they were able to show them around. Because we were only able to bring 20-25 people, we roughly split it in half between veterans and completely new rookies so that each rookie could be paired with someone with competition experience. If you’re able to attend an off-season event after recruiting new members, this is a great way to get them super invested as going to competition is one of the most exciting things about the FRC season.

In terms of how we did at Robo Remix, it went pretty well compared to TRI. Since it was only a one day event, there were only a total of 5 qualification matches, so we had to make each one count. This time, the robot performed pretty well as we were able to get a record of 4-1 heading into the playoffs where we partnered up with 2881 Lady Cans, 8576 Golden Warriors, and 8769 G.O.R.T.s. Although we were knocked out in the quarterfinals after two close games, I think it was still an overall success as our robot was fully functional throughout the entire competition. We managed a traversal climb every match with the new ratchet strap climber modification we made (Link) which made the system way more reliable and durable. The shooting was also well-tuned and we didn’t experience much trouble with that either.

All in all, Robo Remix was a great learning experience for all our team members, both veterans and rookies, and it was an awesome event to kickstart the beginning of the new school year.

Bomb Squad Robot Repair

The Houston police bomb squad had an USAF autonomous RC-30 robot used for moving explosive ordinances or deactivating them remotely. The machine had a series of repairs that were needed for it to be fully operational, including several mechanical fixes (antennae electronics, battery changes) and software issues (lack of a connection between computer and robot, goal of streamlining the setup process for quick deployment in the field)

The bomb squad and our team got in contact with each other, and we went over to help them out. Working over the course of 2 days, we eventually achieved our goal of establishing a connection between the robot and computer, gaining teleoperated control! This was a very interesting project for us as the team got to learn about the real-world applications of robotics, and it was fun to draw a parallel between the professional systems on the EOD robots and our own FRC bots.

As they were impressed with our quality of work, the HPD bomb squad showed us several other projects they’re working on to open the door for future collaboration. This was one of our favorite outreach experiences, and we’re looking forward to working with HPD Bomb Squad in the future!


This offseason, we purchased SDS mk4i modules for the 2023 season. While creating our test base, we learned a few key lessons, so here are a few of our do’s and don’ts with more detailed explanations of our insight in each dropdown.

Mechanical Related

DO: Design your test chassis like you're designing a competition bot.

Design your test chassis like you’re designing a competition bot. What I’ve seen from some teams is a test chassis that looks like it’s held together by hopes and dreams, which can work great for the off-season. However, I found that by planning our chassis as if it was in-season and we needed to mount game-piece manipulators to it, we could better prepare for the season. As a team new to swerve, understanding where to add support, how to keep the COG low and centered, and how to manage the extra electronics was vital. Before deciding on the final layout of our chassis, a 2022 bot and a 2019 bot were mocked up in cad on top of the chassis. While they were (very) rough CADs, they proved that the general design could be feasible on a competition robot.

DON'T: Decide that electronics can get planned out later.

Don’t decide electronics can get planned out later. We decided on a fairly small chassis size(26”x26”), which as it turns out, does not leave a lot of room for electronics management. The battery is sandwiched between two support 2”x1” tubes that run down the entire chassis, which forced us to space the electronics out to the edge of the chassis. (insert pic) Proper planning would have led to the foresight of “hey let’s not separate the two major electronics that are linked.” What I would recommend teams do on all of their bots(and especially swerve with the added complexity) is spend time drawing out various electronics and wire paths on a 1:1 scale. This is where charts such as 3161’s wiring diagram become particularly useful.

DO: Triple check everything.

Triple check everything. While this may seem obvious, even the smallest thing can slip your mind. One of the major roadblocks for us was an error that caused a cancoder to lose its position every time we restarted the robot. The strange thing was that it was a different cancoder each time, and it didn’t seem to be caused by software or hardware. After over a day of head scratching, we finally identified the issue to be a bad super glue job on all of the cancoder’s magnets. After re-gluing the magnets in place, the error went away completely.

Programming Related

DO: Spend time studying the components of the swerve robot and how they function before coding.

Spend time analyzing the components of the swerve robot and how they function before touching the code. Learn everything you possibly can about them, the gear ratio of the drive motors/angle motors, the wheel diameter, how the gyro is oriented, and any information you might need, you should figure out ahead of time. This becomes incredibly important when you have to fill in your constants, and also when you’re implementing different systems or using code from another team. For example, when programming the mk4i modules it was valuable to know that the angle motors needed to be inverted to work with 3512 Sparkatroniks’ offseason swerve library. There is no such thing as too much information, be a question goblin and I promise it will lead to fewer errors throughout the process. Don’t be afraid to ask questions, there are lots of amazing people out there willing to help whether through Open Alliance or the (Unofficial) FRC Discord.

DON'T: Mindlessly copy and past code and expect it to work.

Mindlessly copy and paste code and expect it to work. There’s nothing wrong with using other teams’ code as a base point, but make sure you aren’t simply filling in data and clicking deploy. Not understanding what is going into your code is not only a living hell if you want to debug anything, but also is a major roadblock when you want to add something else to the code. For example, I spent hours just reading over 3512’s library, which allowed us to implement path planner relatively painlessly, a welcome change from last year’s struggles with incorporating it.

Here’s a video of getting path planner/an autonomous routine working. Credit to Murad for getting everything up and running!

Outreach Activities

Toys for Tots

Our team hosted a toy drive at our school for the nonprofit USMC Toys for Tots. We focused on acquiring STEM toys, as our members collectively vouched for the impact that similar toys had on ourselves growing up. In the end, we collected dozens of toys and are proud of the impact our contribution will have on future STEM enjoyers!


FLL Mentoring

Now that our team has become more established and organized, we’ve started to reach out and mentor local FLL teams. Our members rotate through mentoring two local FLL teams every week. By sharing our knowledge with a younger generation of roboticists, we hope to foster STEM growth in our local community and inspire the children to work toward their passions, so they can benefit not only FIRST but the entire world. This has been a really valuable experience for our members, and it’s immensely gratifying to hear that they’re doing much better with successful mentorship! Check out our Instagram for more updates!


TISD Combined Kickoff Event

Vector 8177 hosted a combined kickoff with TSA Allstars 7691 and T3 7312! Along with the FRC teams being there, we also invited middle and elementary school robotics teams to join us so that they can see what their future in robotics would look like.

Our goal for the kickoff was simply to understand the game. To do so, we broke up into smaller groups, each one composed of students from each team to thoroughly look over the game manual and write down any specific rules that might affect robot design and strategy. In addition, we reenacted the game with humans to determine how communication impacts the success of alliances.

picture kickoffpackage grouppicture picturework

Day 3: Setting Priorities, Subsystem Ideas, and Strategies


  1. Basics: Drive effectively, meet all robot and bumper specifications
  2. Maximize mobility and efficiency
    a. The loading zone is a natural chokehold point that is formed by the barrier and the field wall.
    b. This means that defending bots can more easily hinder bots trying to get in and out.
    c. Having the advantage in mobility can allow us to weave past defending bots.
    d. In general, the goal is the minimize the amount of time spent in the loading zone.
  3. Be able to defend chokehold points
  4. “Touch It Own It”
    a. This goes in line with the idea of minimizing the time spent collecting game elements, speeds up cycles
    b. Idea is to be able to collect any game element at almost all orientations and speeds
  5. Score on L1, L2, and L3
  6. Secure game elements from dropping
  7. Modular autonomous routines
    a. There are too many possible auton routes to make each one a dedicated route
  8. Pick up game elements from the floor or shelf
  9. Dock on CHARGE STATION during autonomous
  10. 2+ game element autonomous
  11. Auto-balance on charge station
  12. Automate as many processes as possible
    a. Automated processes allow us to worry less about driving and operating perfectly the entire time


  1. Buy Parts
    a. Field Materials
    b. Robot Parts
  2. Work on Chairmans
    a. Nasa Requirements (June 1st)
    b. Compile events
  3. Write Woodie Flowers nomination
  4. Focus on Team Sustainability Award
  5. Continue fundraising money
  6. Figure out the logistics of traveling to and from competitions


  1. Release Kick-Off Updates
    a. Instagram: @vector_8177
    b. Twitter: @tmhsrobotics
    c. Youtube: Vector 8177
  2. Begin Chairman’s Video
    a. Compile pictures and videos
    b. In style of documentaries
    c. Interviews with coaches, mentors, and members
    d. Research other teams
  3. Finalize Merch Designs
  4. Finalize Pit Banners
  5. Begin Weekly Updates on Instagram
  6. Plan Robot Reveal Videos

Mechanical Discussions:

The main two scoring mechanism options that we will be prototyping are pneumatic grabbers (Mr. Grabbs) that were shown on Ri3D and use gravity and free-spinning wheels to orient the pieces and a V shaped claw that can grab both pieces.

unnamedunnamed (3)

We also decided on having an intake to pick up pieces from the ground. Shown below are two concepts from FTC 16460 (left) and Ri3D (right).

unnamed (2) unnamed (1)

Programming Discussions:

For our team’s autonomous programming we began with the philosophy that we should optimally work around other team’s routines. That’s a tough issue on its own considering the amount of variability in this year’s game. We decided that the most effective results would be a modular system composed of different “phases” the robot runs through which would just be mini-autonomous routines. This would allow for on-the-fly generation using ShuffleBoard and Path Planner Lib.

We’re also experimenting very heavily with using pose estimation from encoder values and the new April Tags to line up the robot accurately to the poles and steps for the game pieces. We have no testing done to see if there’s enough accuracy but theoretically the drivers would be able to just use a single button to line up automatically.

Business and Outreach Discussions:

Our business team discussed our goals for the build season such as starting on Chairmans for the first time on the team :cold_sweat:. We feel that it is important for us to start now and get more experience for the years to come. The main highlights of our outreach events include our summer camp for incoming 6th-8th graders, FLL mentorship of 2 Tomball teams, and working with the HPD Bomb Squad with the theme being “fueling passion for STEM within Tomball ISD”. We will be also aiming for the Team Sustainability award, not only teaching our members how to properly present to judges but also working on a business plan to present.

We will be less focused on fundraising as we believe we have done an excellent job during the off-season to raise $40k in funds which is the most our team has raised over an entire season. We will still obviously be looking out for grants and potential sponsors within our local community. As well as working with the Booster club to feed our hangry students and reduce costs for students going to competitions.

Media Discussions:

Our media team discussed our vision for upcoming projects like a Robot Reveal video and our Chairman’s submission. We wanted to prioritize more of our team’s overall personality instead of our general achievements by doing personal interviews and starting to film whenever possible. Graphic design also finalized t-shirt designs for competition season and decided on adding our team number so that our logo is more recognizable to other teams and companies. Because our current social media presence is mainly photos, we also discussed the idea of uploading to Instagram Reels and Youtube Shorts more frequently with clips that show our team dynamic. Overall, we have many things to tackle this season and are very excited to start.

Day 4: Tuesday

Engineering Team Discussions:

To start off the meeting, we recapped yesterday’s options and created a document to document various mechanism grippers and intakes which can be found here. After deciding to further explore the V claw designed by one of our members and the pneumatic gripper developed by RI3D Redux, we moved on to a discussion of scoring mechanisms.

After sending our students home with the task of researching possible scoring strategies, we came back and created a document to list the pros and cons of various mechanisms, which can be found here. The mechanisms we considered as a team consisted of a fixed angle elevator, a pivoting elevator, a pink arm, and a fixed angle elevator with a long arm attached to the end. The pink was eliminated due to its complexity, and the fixed angle 4 stage elevator was eliminated due to the added downsides of being 4 stages(weight, mechanical slack, added cost, etc). While the pivoting elevator was considered, it was ultimately decided that a fixed angle single stage elevator with a pivoting arm(possibly telescoping) would provide the most support and control.

unnamed (7) unnamed (6) unnamed (5) unnamed (4)

As of right now, the plan is to have a through the bumper intake with a claw/grabber attached to the elevator act as the passthrough mechanism. We will be running mk4i modules in the standard low tube configuration, with a chassis somewhere between 26”x26” and 28”x28”. Various play-doh cads can be found on our onshape found here.

Programming Team Discussions:

While waiting for the engineers to finalize designs, Tuesday was mostly spent compiling a list of to-dos for our team during the season. With the start of the season comes a plethora of new software to download which we had to install on each of our laptops. We also have to get Photonvision installed and updated on our Limelights to begin testing out April Tag pose estimations.

Business Team Discussions:

The business team worked towards making a buylist for materials to create the field. We will also be working on contacting Home Depot to potentially get raw materials such as wood donated to the team.


Are you leaning towards any size in particular to fit the charge station or are you just choosing a size that will fit your mechanism?

We’re mainly choosing the size based on what will fit our intake/grabbing mechanism. I think even if we shave off 2" (or more) from our frame and go with something around 26"x26", it will still be a pretty tight fit on the charge station so we decided it’s better off to use that space to create a more reliable/robust mechanism.


to add on to what roland said, our main constraint is our intake. With mk4i modules taking up a decent sized footprint, if we go too small we can’t properly add supports for the front modules, since we’re planning on doing a thru bumper intake


We finished the single substation on Friday and began doing some initial testing. A couple of important things to remember are to make sure that the surface is HDPE and that it is sanded completely smooth. Whatever orientation you release the cone in should maintain that same orientation as it slides down.

Our goal is to be able to intake cones from the ground tip first as well as with the standing up, so we tested a bunch of different angles to see if we could get a consistent drop. Here is a diagram of the field and what we’re aiming for with the cone drops:

Dropping Cones Upright

After some drops, we found that letting go of the cone base first actually results in the cone consistently standing up. We tested it about 30 times and it stood up about 90% of the time. The key is to not let the cone gain too fast as when it hits the ground, it’ll bounce back and have a greater chance of tipping over. This could be useful for teams who can pick up ground cones in the upright orientation as they wouldn’t have to travel to the farther double substation and raise their mechanism to the platform.

If other teams could test this and see if it works on their setup, that would be great to know!

Cone Tip Facing Driver Station

We also found that releasing the cone at a 30° angle with the base facing the right side of the substation would result in it facing the driver station and perpendicular to the substation. One thing to note, the base of the cones are not perfectly square as we measured ours to be around 8.25” by ~8.6”. We found that dropping it with the shorter side versus the longer side would actually drastically change the results.

With the longer side facing down, it consistently landed with the tip facing the driver station and it being perpendicular to the wall. By marking the correct side, we tested this 50 times with 42 attempts being almost perfectly 90° to the substation and 8 attempts being at a 30-45° offset (but still with the tip facing the driver station). There were zero failures (pointing wrong direction) with using the long side.

In this video, it shows 3 drops with the long side, and the last drop with the shorter side.

However, with the shorter side, it would consistently flip toward the other side. We think it could have to do with the center of gravity changing, but we’re not completely sure. We only have one cone right now, but once we get our order of more we’ll test them as well to see if the drop angle can stay consistent.

If any teams out there want to measure their cones and respond with their dimensions that would be awesome. This might be a fluke with our cone or it just being warped from testing, so we want to make sure we’re gathering accurate info, thanks! Also, if teams have built their own substation, it would be great to see what your tests have looked like.



This is really neat!

Reminder that the real field has a second angled ramp that extends from the bottom of the chute over the guardrail. I’m not sure if it would affect your results, since it’s much steeper than the chute ramp, but it might.

Photo from WPI field photo album:


Thanks for pointing that out! We’ll see if we can replicate that secondary ramp in our next meeting and see how it affects the cone drop test.


Combined Kickoff Event Recap Video!

Kickoff Video Link


Week 2: CADing, Building, Testing

Field Building

The room we work out of isn’t big enough to host a full field or even half the field. This meant before we could start building, we needed to prioritize what should be built and where it should be built. The goals we have for our bot influenced these decisions and are

Dock on Charging Station

The necessity of being able to dock doesn’t need to be explained. Therefore, the Charging Station is a top priority item since it would allow us to practice manually and auto-docking. We ended up going for a half-sized port because we don’t intend to implement a buddy climb system.

Score on L1, L2, and L3

This year’s game emphasizes not only how you score but also where you score. This means that if we want to create a bot that can score at any level and assist our alliance with scoring links, then our drivers need to be comfortable scoring at any angle (especially if they’re going to have limelights pointing at them the entire time). Therefore, we had to build the entire grid system.

Efficient Cycle Times

We believe teams will win this year based on their cycle time efficiency. With this in mind, our goal would be to minimize time within the Loading Zone and the Community. This, in turn, would allow us to fit more cycle times within a match. We decided on making the single substation because it was the closest entry point for new game pieces to the Community and therefore would allow us to minimize the time in the Loading Zone.

buildingfield kylebuilding


End of Day 1 of Field Building

Robot Design

The past week has seen our design for the bot have undergone a tremendous amount of iteration and overhaul. Our initial ideas revolved around the concept of having the intake and the elevator separate. Teams like FTC 16460 served largely as a basis for our discussion where a spring-loaded ground intake would take in a game piece in any orientation, a “cradle” would hold the game piece within the robot, and a claw on a tilted elevator would grab the game piece from within the cradle and score it. However, as we developed the idea further, we quickly realized that the scope of our bot was expanding beyond what we believed was necessary and could handle.

This intake presented a couple of challenges that we needed to solve. First, the intake was limited to being an opening in our frame. We didn’t like this idea because it would require precision from the drivers to intake game pieces, something that is hard to do during a match. Our intake couldn’t be deployable because then we would run into the complexities of packaging all the components to just be legal. We figured the over-bumper front rollers would help solve this problem, but then that’s another piece of complexity we need to account for. Finally, this intake would have taken up 4 motors (2 for each side roller, 1 for the top roller, and 1 for the ramp) out of the 20* available slots, making this style too expensive and complicated to do what we needed it to do.


We initially liked this concept because it passively orientated the cone with the free-spinning rollers. However, the clunkiness of the general design made it hard to implement onto the robot. Its ability to hold the cone was also something that we were not too impressed with. Including the fact that its weight is more than we desired and the need to run tubes through the entire length of the elevator, this style of grabber just didn’t live up to what we hoped it could be.

In the end, we scrapped the entire concept and restarted from square one. We still liked our tilted elevator idea, but this time, instead of separating the intake and the grabber, combining them into one system would decrease the complexity of the overall robot design.

The 3 roller designs that were prototyped in Week 1 inspired this style of intake. We first noticed how effective it was at grabbing both cones and cubes and the potential to launch these game pieces. This cuts down on time spent aligning ourselves to score, which reduces cycle times. Its relatively simple design also ensured that it could be quickly replaced mid-competition without having to disassemble the bot. However, this style of intake also has its compromises. The tip of the cone must always be the first to enter the intake and must come from the front, not the bottom. We believe this is an appropriate compromise to make because of our ability to control a cone’s fall from the ramp. In most other cases, the cone will be upright which isn’t a problem for this design.


Intake Positions For Cube and Cone
robotcube robotcone

Yes, the elevator is half floating :slight_smile: We’ll get around to adding actual support to it… eventually…

Cone Testing

First and foremost, if you hadn’t seen our post about our initial cone testing, then you should go read it above. It’s very cool and awesome. :cowboy_hat_face::+1:

The long and short of it is that we got consistent landings of the cone in the orientation we prefer (upright or laying parallel to the single substation). Sliding the cone with its base downwards would result in a 90% chance of landing upright. Things get more interesting when we try to get it to lie parallel to the ramp. We found the base of our cone to be a rectangle with one side being less than 0.5 in. longer than the other. When sliding our cone on the “long” side at 30°, we would achieve a parallel cone. However, whenever we slide our cone at 30° on the “short” side, the cone would flip to the other side.

So then the cone drop issue is solved, right? We just have to slide it base first and at 30° depending on what we needed…

Oh, how I wish it was.

We retested our drops on a separate day and found a significant decrease in the consistency of both types of cone drops. While before, our cone would land upright 27 out of the 30 drops, now it would only land upright 20 out of the 30 tries. Dropping the cone on its “long” side at a 30° angle would result in the cone laying parallel to the single substation about half the time, with the other half seeing the cone flip to the other side. Dropping the cone on its “short” side at a 30° angle would surprisingly result in the cone laying parallel to the single substation most of the time, a direct contradiction to the results from our initial test.

So then that begs the question: what changed from the initial test to the retest?

Secondary Polycarb Ramp

It was pointed out to us in our initial test that the actual field will have a secondary ramp set at a steeper angle. After adding this secondary ramp and doing a couple of tests, here’s what we noticed:

  • When dropping the cone base first for an upright orientation, the tip of the cone would come into contact with the edge of the secondary ramp. The secondary ramp would then bounce a little.
  • The bouncing of the secondary ramp may apply an additional force to the tip of the cone, causing the cone to overrotate. More tests need to be done to see if this is true.


Repeated Warping of the Cone due to Prototyping

In our prototyping, our cone got thoroughly abused. With only one cone, this meant we had to use that cone in our tests. In our retest, our cone would give an audible dragging sound if it slide down its “long” side. This sound was absent in the initial test. After examining the cone, we found that the “long” sides were warped inwards while the “short” sides were warped outwards. This allowed us to conclude two things: that the dragging sound was created by the corners of the cone and that the warping of the cone will have a drastic effect on the result of the test. Unfortunately, the warping of cones seems like an inevitability as teams constantly manipulate them during matches. More testing will be needed to see if there is a difference between a fresh cone and a warped cone.

A silver lining in our retest revealed that we didn’t need to drop the cone at exactly 30°. Anywhere between 20° and 45° would result in an acceptable orientation. So at least we have that going for us.

Programming Update

Our programming team has been messing around with auto-balancing code and AprilTag detection and alignment. Both are still in their initial stages but have been showing promising results.



This looks super clean! Do you have any prototypes of this combined intake configuration? Specifically the cube pickup - I’d be worried about a dead spot once the cube passes under the first roller there may be a spot where it’s not in contact with either roller. Probably just a geometry problem that’s easy to solve, but curious if you’ve tested it.


I want to yell “Four” every time this robot comes to the field :slight_smile:


Thank you! We prototyped the front two rollers (cone rollers) with the few wheels we have in store and found that a surface-to-surface distance of around 1.75" to 2" worked pretty well. The bottom two rollers for the cube have yet to be prototyped, but we’ll be getting an AndyMark order this Wednesday with more parts to work with (right now we have 4 compliant wheels and a few stealth wheels to prototype with :joy:). The distance right now is an 8" gap so 1.5" of compression, but we might increase the compression to 2-2.5" if we notice the small dead spot is affecting our intaking ability.


Scoring Positions

Here are a few snips of what our scoring positions might look like for all 3 levels for both cones and cubes. Since we have a wrist pivot, we’ll be able to modify some of these positions when we start testing with the actual robot to see what works best.

For cube scoring, we plan on launching it from the intake at a ~90 degree angle, so we don’t have to extend the tilted elevator as far.


Hi! The robot looks great. Is the robot throwing the cones or is there going to be another system to put the cone more vertically?


Thanks! The cone will be launched horizontally as of now. We did a test of launching the cone and it seemed to work pretty well.


Cone Drop Testing Summary

This week our order containing more cones came in, which means we were able to continue cone drop testing! (Our original cone became deformed after prototyping) After all of our previous testing, we concluded that there were only 2 viable options:

  • Dropping the cone base down and having it land straight up.
  • Dropping the cone at an angle (tip pointed away from the field), in order to have the tip pointed towards our alliance’s side once it lands on the ground.

Our first order of business was to gather a large amount of data for dropping base down to get a gauge for how consistently it will land face up. We conducted 162 trials, with 155 of the trials resulting in the cone standing straight up, for a 95.7% success rate. One other thing we noticed while conducting this experiment was that of the last 110 trials, 108 were successes, compared to only 47 successes in the first 52 attempts. Though we cannot think of any reasons as to why this could be (nothing changed about how we dropped the cones, the only idea we have is that the repeated trials somehow made it smoother), this was still statistically significant (p = .011) difference, and something worth noting.

Next up was testing when we dropped the cone at a specific angle, in the configuration shown below. We quickly found out that any angle greater than 30° would not be viable for what we wanted to do, and therefore, we decided to test at 15°, 20°, 25°, and 30°. Our goal when testing was to get the head of the cone pointed toward our Community Zone to allow for easy pickup, within the range shown below.

Our results are shown in the table below.

Here are some super long videos of the cone drop testing if you want to see the drops:

15 Degree Cone Drop Trials
20 Degree Cone Drop Trials
25 Degree Cone Drop Trials
30 Degree Cone Drop Trials
Straight Up Cone Drop Trials (beware this is 13 min long :joy:)

Some observations (from the blue alliance’s perspective):

  • For 15°, the vast majority of failures were when the tip of the cone was pointed directly away from the single substation, and the rest of the failures (~5) were when the cone pointed slightly towards the opposing alliance area. While it theoretically would be possible to pick these cones up, it would be a rather tight fit to avoid the wall separating the loading zone and the community, resulting in slower cycle times.
  • For 20°, the few failures were again when the cone was pointing directly away from the single substation. The vast majority of cones pointed at an angle that bisected the boundary lines shown in the diagram, making it the ideal angle for the bottom pathway shown in the diagram below.
  • 25° was clearly the most consistent. While some bisected the boundary lines, most were barely above the lower boundary, making them nearly parallel with the length of the field. If a robot were to come via the 25° pathway depicted below, they could spend the most time in a protected zone and intake the cones in an optimal position.
  • Even though it did not have the lowest success rate, 30° proved to be the worst angle to drop from. For the failures, the tip of the cone angled towards the wall, meaning it would be nearly impossible to intake these cones. Furthermore, unless a robot spent the time to push the cone out of the way, it would end up getting in the way of any other game pieces that would get introduced through this substation.

In-Game Application:

Our robot’s ideal way to intake cones will be on the ground with the tip of the cone facing the robot, which is a major reason why we spend a lot of time testing ways to drop cones and have them positioned this way. Of course, it is nearly impossible to accurately estimate the drop angle mid-game; however, from what I have seen in the manual (someone feel free to correct me if I am wrong), it would be completely legal and viable to 3d print a device (shown in blue) that could be placed at the edge of the single substation to indicate the angle, as shown below.

Screenshot 2023-01-29 at 9.13.30 PM

Next Steps:

The only thing that we could do is further testing (50-100 more trials) of 20° and 25°, since these seem to be the clear 2 best ways to drop cones. As of right now, we cannot do any real data testing to see if the difference in success rates for these 2 positions is statistically significant because of the lack of unsuccessful trials. That being said, these two angles both have proven to be very reliable.

Written by: Kai M.



This is fantastic work, thank you for sharing. Hopefully we can get some reports from the official week 0 event in a few weeks to see if these results transfer on to the real fields.


Did you control release height up the ramp? We found (in less extensive testing than yours), that releasing the cone flange first (90 degrees in your diagram) at a point near the end of the ramp could almost always make it roll over, so the tip points out from the wall. Releasing it about mid way up the ramp seemed to be best for upright landings, and releasing it at the highest point was less predictable. I’m curious if you get the same results.