FRC 1466 Webb Robotics – 2023 Build Thread

Welcome to Webb Robotics - Team 1466’s build thread for the 2023 FRC Season! After a great competition season last year, we are excited to bring you student-written team updates throughout the build and competition seasons. As part of Open Alliance again this year, we will share all of these updates and collaborate on the official Open Alliance Discord server.

About Us:

Based out of the Webb School of Knoxville, we are the oldest active FRC team in East Tennessee. Webb is a PreK - 12 independent day school. We’re part of a collaboration & cooperation network within a relatively large local density of teams.

We’ve got ~30 students and ~5 mentors this season. We also have 3 FLL teams and 1 FTC team working with us in a large, shared build space.

Season Planning and Goals:

Team leadership spans 11th-12th grade. We have 2 team captains and 4 subteam leaders. They’ll be sharing the responsibilities of posting regular updates here. The leadership team identified a few overarching goals for the competition season:

  • Better communication within and between subteams
  • Visible schedule and task planning in the lab
  • Improved and consistent organization of our lab space
  • Keeping team members engaged and staying on schedule for build season
  • All team members participate in at least one team-sponsored service project
  • Developing our non-technical sub-teams and documentation
  • All team members can pass a game rules test by end of week 1
  • Creating a stronger team bond and building team relations
  • Reliable autonomous routines (to be defined after game reveal)
  • Basic robot CAD by end of week 2 (drivetrain in week 1)
  • Easily accessible and labeled robot wiring

Build Season Plan

Our team meets after school on Mondays and Thursdays around 3:30-5:30pm. On Saturdays and some Sundays, we run extended build sessions. We schedule around 10-12 hours of robotics workshop time per week. Some FRC work happens outside of those times or via remote collaboration or in other supervised lab times.

We are scheduled for regional events in Week 5 (Smoky Mountain) and Week 6 (Rocket City). Our goal is to have a finished robot by early February, giving drivers plenty of time to practice. We expect to build two robots - prototype bot and a polished bot done in time for events.

We are excited to bring you regular updates throughout the build and competition season, along with an off-season recap beforehand. For now, you can check out our website, social media pages and GitHub repository. Thanks for stoping by!

Website -
YouTube -
Instagram -
Facebook -
GitHub -


Off-Season Recap :rewind:

We made lots of progress in our 2022 off-season. We participated in the Tennessee Valley Fair’s RoboRodeo event, and won 1st place in an alliance with 4020 and 2614! This was with our 2022 competition bot, coded in Java instead of LabView (code is on our GitHub). In this event, multiple new drivers had the chance to drive the robot around. Now, a drive team has been identified for this season.

Top-down view of the field at the 2022 RobotRodeo

Mock Kickoff :hatching_chick:

We hosted a mock kickoff in November to read the rules and analyze the strategy of the 2019 FRC game, Deep Scape. Team leadership split up into groups of 4-5 students and discussed strategy (doing our best to suppress conversations about robot mechanisms). We explained our drive team expectations to new and veteran team members. We plan on having 2 drive teams this year, a primary team (members must attend both regional events) and a backup team (preparing members for future seasons). Membership to our team Discord server was checked, ensuring team members were able to stay up to date with ongoing projects.

Off-Season Build Projects :toolbox:

We prepared two robots for our drive team to practice with during the build season: our ‘Spooky Swerve’ (which is a 21” swerve drive frame) and a KOP chassis drive (with a pneumatic test board for prototypes). As part of the process of building these robots and taking apart the 2022 competition robot, our new mechanical team members were given safety and power tool training.

Here’s ‘Reindeer Swerve,’ Spooky Swerve modified to spread holiday cheer during exam season

We hosted other training sessions for CAD, electronics, business, and code. Several experienced CAD members participated in an InspireNC CADathon in August. We’re participating in the F4 CADathon from December 16-23, so hopefully more members will have experience CADing with a strenuous time limit before the build season starts.

We have a new electrical mentor coming to our team, and there are many rookies and older team members alike that have become comfortable with doing electrical work for the build season. We do not have any of the new REV control system pieces, but we will order some with our REV vouchers as soon as they come back in stock. Other than that, we are standardizing the use of the Anderson powerpole connectors for use on our robot, and we are also implementing ferrules and new CAN wire connectors.

Business :briefcase:

This year marks the first year in a while where we have multiple students interested in business. Currently, we have applied for a Casey’s grant, as well as sent emails to local companies asking for both mentors and sponsorships. The sponsorships will be eventually integrated into the team’s new website (which is currently in progress, but there are people working on it.)

Outreach :speaking_head:

We are continuing to organize outreach events for our community and other local FIRST teams. In November, we hosted an FLL Innovation Expo where local FLL teams were invited to share their Innovation Projects to FLL Alumni, as well as to teach other FRC members about the FLL game so they would be more prepared to volunteer at future FLL events. We hosted an FTC Scrimmage December 17th in partnership with our FTC team. Materials and plans are being finalized for a Boys and Girls Club partnership, which is slated to start as weekly after school STEM activities in January.

Top-down view of the FTC Scrimmage hosted in the Innovation Center Library on campus

Media Team :art:

A lot of things are happening with the media this offseason, including an entire rebrand. With our rebrand, one of our key goals was to keep the school color, but to look more like a team as opposed to a club (which our school presents us as). Additionally, we wanted to not be overly tacky, and have branding that is gender-neutral (our school mascot is a Spartan, but we want something different). This rebrand will be finished before school lets out for winter break, so the media team can focus on working on the Impact Award video starting January.

One of the many logo brainstorming whiteboards created during the off season

Miscellaneous :paperclip:

We have organized our Google Drive, and are in the process of working on some new training materials (such as for CNC and laser cutting or a mechanical training timeline). These materials (and other training materials the team has made) will be shared via our website.


Click here to watch: Houston was organized chaos | FIRST Worlds 2022

It’s months late, but you can enjoy it as a reminder (or a sample) of the energy that only exists at Worlds. Constructive criticism is highly appreciated; comment here on or YouTube.

Teams explicitly mentioned or shown:

FRC: 51, 148, 302, 1293, 1339, 1678, 1902, 1939, 2046, 2056, 3824, 4020, 4265, 4481, 4907, 6919

FTC: 15993, 16461, 21062


Hey there, Chief Delphi! With kickoff under 24 hours away, it seemed like a good time to add another openalliance update to share how we’ve prepared for the 2023 season and what our kickoff weekend is going to look like. I’ll share some info from 1466 subteams as well.

A few important links:
Off-season Swerve and TankDrive Code can be found here:
Our 2023 robot CAD will be located here: 1466 Charged Up Robot - Onshape

Mechanical Team

Though the team has not had any meetings since winter break started, team leadership spent some time on lab organization this week. One major pre-kickoff project was standardizing our fasteners. We’ve had a mix of lots of different bolt sizes and threading in the lab - some things may have been on the shelf for more than a decade. We cleared out all 10-24 bolts, and will use primarily 10-32 from now on. Fasteners were reorganized to be centrally located in our machine shop instead of spread out in a few different storage locations.

One of our freshman CAD members designed tube plug design to be 3D printed; allows for more efficient prototyping of box tubing mechanisms as opposed to arduous process of putting in gussets and riveting. Link to Onshape doc. This was inspired by tube plugs from WCP. Though this 3d printed version may not end up on a competition robot, it may help mechanical team to prototype and build with box tubing.

Media Team

Media team spent November and December focused on an imagery overhaul, as noted in a previous post. We’ve now finalized a new team logo, color palate, and fonts. We even got it all completed in time to order new team t-shirts to hand out at kickoff tomorrow! If you want to read about out imagery inventory and what changed we’ve made so far, you can look over our 1466 Image Redesign Project Summary

New Logo:

2023 Season Goals

Team leadership (consisting of 2 co-captains, 4 subteam leads, and 6 mentors) worked together to come up with a list of goals for the 2023 season. We worked on making sure each goal was specific, measurable, attainable, realistic, and time-based. We’ve shared the goals with the full team and have them on a one-page flyer posted in our build space. We thought it might be worth sharing those goals here, too:

Student Impact Goals:

  • Daily after school meeting attendance above 80%, and 100% of team travels to regionals
  • Host monthly collaborations with other Webb clubs to expand team’s in-school network
  • Place all interested team members in summer STEM internships, camps, or service work
  • Achieve 100% student participation in team community outreach events before SMR
  • Sub-teams post Discord progress updates at the end of each meeting, including (1) accomplishments (2) details of the next step and (3) a photo or video

Community Impact Goals:

  • Weekly B&GC visits include 33% of team members as volunteers this spring
  • Open Alliance posts on CD or Discord are authored by at least 50% of team members
  • Reach 100% completion of FIRST’s ED&I online training before SMR
  • Host two FIRST community events for local teams at Webb before SMR
  • Promote 1466 in the upper school with weekly update videos in chapel and on social media

Robot Goals:

  • Drivable chassis available throughout all of build season for prototyping and practice
  • Implement a basic form of vision processing in autonomous using AprilTags
  • Reliable autonomous routines score in at least 90% of qualifying matches
  • Efficient and reliable wiring allows robot to maintain comms in 100% of matches
  • Build a robot intended to achieve the team’s strategic design goals established at kickoff
  • Robot v1 mechanically and electrically complete by Monday, February 6th
  • Publish a robot reveal video on YouTube by Friday, March 24th

Results-based Goals:

  • Play on a playoff alliance at both regional events
  • Top half of teams in terms of OPR at both events
  • Qualify for the FIRST World Championships
  • Be an alliance captain at one or more events

Awards-based Goals:

  • Win Impact Award and/or Engineering Inspiration Award at the regional level
  • Impact Award documentation is complete in time for 3 full rehearsals in front of judges
  • High quality Impact Award video shared on YouTube by Friday, March 10th
  • Prepare a well-structured business plan and judging handouts for regional events
Kickoff Plan

We’ll be meeting for kickoff in our build space on our school’s campus this year. We have access to a large meeting room and library in addition to our robotics lab, so plenty of room for students, parents, teachers, alumni, etc. to watch the broadcast together.

Our kickoff plan will involve Kickoff Bingo and prizes (usually trophies made from old game pieces)!

After we watch the broadcast, we’ll be splitting up into smaller groups to read and discuss the rules. We want to focus just on understanding the game, and will avoid talking mechanisms or robot design until day two or three. We’ll be filling in this game analysis document.

We cannot take credit for that game analysis form. We definitely picked it up several years ago from either a CD post or The Compass Alliance. The document linked above is the one we’ll fill in on Saturday, so our game discussion notes will show up there. We use this same form when we run our mock kickoffs.

After some initial time reading the rules, we’ll be running a ‘World Cafe’ style discussion for the hour or so to help facilitate discussions. Each student team lead will focus on understanding a specific section of the game: tournament structure, robot rules, match play, autonomous, endgame, arena, and scoring/penalties. Every other team member with rotate through discussion groups to ask questions and make observations about the topic. At the end of our world cafe discussion, we’ll discuss our conclusions as a full group.

Build Season Organization

Keeping the team on track during build season is a critical goal for us, so we’ve spent some time practicing our organizational methods in the fall and looking for project management resources.

We’ve implemented out own adaption of Scrum for project management. By Monday, team leadership will build out our season backlog, and plan the tasks for our first 2-week sprint. We keep our Scrum board large and visible in the workshop.

We also have been looking into the recent addition of ‘Timelines’ to Google Sheets. You can now pretty easily generate a Gantt-style chart from a sheet. We’re going to try to use this to organize our build season. You can see our Timeline here. By Monday or so, once we have a better idea of expected robot build, we’ll be filling the Timeline out with more details. No matter what we decide in terms of robot strategy, a top priority goal for our team is to have a v1 robot completed by early February.

1 Like

Hey, Chief Delphi! This is our #openalliance update for Week 1 of build season. Kickoff weekend will be organized in chronological order (as all the team was focused on strategy throughout the weekend), and then the rest of Week 1 will be organized based on subteam activities.

Saturday (Kickoff Day) - Game Rules

In the morning of kickoff, The 6 team leaders collectively presented a basic presentation about FIRST robotics, followed by sharing our 2023 Season Goals. After that, one of our mentors gave a 5 minute presentation on data analytics, setting the tone for mass multivariate data collection and analysis that would prepare us for better scouting and prototype testing this build season.

Once the kickoff live stream concluded, the rest of the day could be summarized in three words: reading the rules. First, the team split into groups of 5-6 people to begin the rules-reading process for about 40 minutes. Then, the full team reconvened and had a group discussion about the rules, pointing out specific important rules, answering questions, talking about mechanisms solely in the context of strategic advantage, and generally getting every team member on the same page in our limited understanding of the rules at this point.

To expand our understanding of the rules, we moved onto a World-Cafe discussion. Team leads stayed at their table to moderate the discussion; everyone else rotated through each group every 10 minutes. All discussion notes were recorded on paper to be shared with the team at the next full group discussion. Team leads briefly recapped findings so far for each new group they meet with. Our groups were Autonomous & Endgame, Tournament Structure, Robot Rules, Arena, and Match Scoring & Penalties. Each team lead did a quick presentation of their station once the team reconvened.

We wrapped up kickoff by identifying some robot archetypes and strategies. As people were leaving, we gave everyone who ordered our new team T-shirt with a new logo developed in the fall. Like last year, we encouraged everyone to take Citrus Circuits’ Rules Test until they reached 80% correct. At the moment of this post, however, 9 students out of ~30 have passed. This is not an ideal number, and we hope to increase it this week.

Sunday (Kickoff Weekend) - Game Strategies

Sunday is when the team went more in-depth on strategy discussions, figuring out our priorities as well as further studying game rules. From the field walkthrough videos and discussions online, we discussed some notable insights, such as:

  • Using limelights to score in the grids would blind drivers
  • Field visibility from driver station is not great
  • Max point total (discluding penalties) in this game is 193
  • Penalty points are much higher this game then in Rapid React, massively discouraging any robot interaction in opponent protected zones

Cycle times for scoring game pieces became an important point of discussion, especially when talking about how hard it would be to achieve the maximum point total. To try and get a better sense of what cycle times would look like in this game, we watched some 2017 match video from Smoky Mountain Regional. We noted that cycle times were ~15 seconds at best and many were longer. We also watched 2011 and 2012 games to get a sense of inflatables, 3 levels of stacking, balancing bridges, and platforms.

After watching past years’ games, we discussed all the potential robot archetypes this season, as seen in the picture below.

We made a list of robot priorities, including our demands, “prefers”, wishes, and no’s. The link to our strategy doc (including the justifications for each reason) is linked [here](Charged Up Strategy Ideas - Google Docs), but here is our list of demands, that must be included on our first iteration robot, set to be completed by February 6th:


  • Drive
  • Drive for Mobility bonus
  • Score cone/cube low
  • Drive over Charging Station
  • Dock on Charging Station


  • Drive
  • Drive over Charging station
  • Dock on Charging station
  • Engage on Charging station
  • Actively balance w/one other robot on charging station
  • Score cones low/mid
  • Score cube low
  • Receive cone from human player
  • Can take a hit

Our “prefers” are still pretty important, but a lot of these are “prefers” so we can complete our first iteration robot by February 6th and achieve our bare minimum demands. If all goes well, most if not all of the “prefers” will appear in later iterations (I might be jinxing it, but I think some of these will show up on our first iteration robot too!).

The last thing we did on Sunday was to start discussing our drivetrain, with our main two options being swerve drive and kit drive. A picture that summarizes the discussion of the swerve drive is included here.

Rest of Week 1


CAD and mechanical teams were quite overlapped this weekend, but CAD in particular has been occupied with testing different lifter designs in CAD, different grippers, as well as setting the (tight) deadlines for the team so the February 6th deadline for robot completion can be met. The 1st iteration CAD review day (which will include CAD, mechanical, electrical, and code teams) for our robot is set for Thursday, January 19th, so that is when 1st iteration CAD will be mostly finished. Once CAD has been reviewed and changed to different subteam wants, then the V1 CAD release will be announced on the Open Alliance Discord server as well as in this build thread.

One of the highest priorities for CAD was to decide the size for our SDS MK4 swerve drivetrain. The two main mechanisms we wanted to make prototypes of were lifters and grippers, with lifters being the most important to determine drivetrain size. Like many other teams, CAD has been working on the one DOF dream, but with our robot only having mid-scoring, we have found 4 different ways that a 1-DOF lifter is attainable! These are a 2-stage constant angle elevator, 2-stage constant angle telescoping arm, a virtual 4-bar, and an “energy chain” lift. All this is possible with our target drivetrain size of 26” x 26” or smaller.

There haven’t been too many gripper designs translated into CAD, but with the four lifter designs and the three-four gripper designs we have in mind, we have made two whiteboards to compare each mechanism set so decisions can be made quicker. The pictures shown here are only the start of these comparisons, with pros and cons listed and ranked criteria being used to classify certain mechanisms so we can use some Pugh analysis to decide what mechanism concepts we end up going for on Monday, January 16 (I know this gives CAD very little time to finish by January 19th, but trust. Some mechanisms will be designed before then too, just to visualize them in CAD, and some mechanisms + the drivetrain have been mostly designed already). You can find our comparison sheet [here](1466 Prototype Inventory - Google Docs).


While the CAD team was conceptualizing prototypes, the Mechanical team was building and testing prototypes as well as providing input to the CAD team about design for lifters, grippers, and drivetrain. Throughout this week, the team has been proof-of-concept prototyping four lifters and three grippers. Details about each are found below. We are still ironing out the prototypes, so pros and cons are not finalized yet. On Monday, we decided that we would go for a swerve drivetrain this season, due to the multiple maneuverability advantages + it being possible to go over the charging station with the swerve drive.

With the help of team parents, we started field element construction, with the goal of building at least one grid and ½ charging station. As of today, the two columns with two cone nodes + hybrid nodes have been built.

Lifter: Two-Stage Elevator

The plan with this lifter is to have a constant angle elevator that maintains 1 DOF to score for the mid node but with a wrist that can be added to the elevator so it can support scoring high. When we built a proof-of-concept two-stage elevator out of old box tubing and some Andymark elevator bearing kits, we truly realized just how heavy (on the top too) and how wide a two-stage elevator would be, which would make it harder to balance on the charge station during teleop. It would still work at a constant angle for sure, and would be suitable for most if not any gripper design the team comes up with, but it’s not the team’s definite best choice.

Lifter: Two-Stage Telescoping

This lifter would function the exact same way as the two-stage elevator, but would be lighter and narrower, making it easier to balance in the charging station. Luckily, we had telescoping arms from last year so we could see the mechanism in a real state as well as in CAD. In the first iteration of the robot, the telescoping arm would be put at a constant angle, but the stages can be made to easily integrate high scoring through adding rotation to the base of the telescoping arm. However, due to only using the one telescoping arm, this would only work with light and narrow grippers, so the versatility of a telescoping arm for grippers is slightly less than an elevator.

The plan is to use one telescoping arm for the lifter, but we had a set of two in the lab already so we could just experiment with that.

Lifter: Virtual Four-Bar

The lifter would function by having two rotating joints that are both controlled by one motor, in effect making it 1 DOF. Chains would be run through the system, making the VFB somewhat top heavy due to the sprocket that needs to be put on the top, making it harder to balance the robot on the charging station. However, the simplicity of the build is enticing, so we’re not counting it out (yet).

Lifter: Energy Chain (Gary)

The last and most interesting lifter we are prototyping is the energy chain. Inspired by 1477’s 2020/2021 robot, as well as it being something the team did in 2011, we want to use an energy chain with a custom-made gear to spool/unspool the chain, which is something we are currently working on. The main concerns with the chain are 1) how heavy can we make the gripper we put on the chain and 2) how can we prevent the energy chain coiling upward when we don’t want it to or controlling the coiling of the energy chain so it can coil back and straighten out when we need to. More prototyping will definitely provide more information on the legitimacy and/or severity of these concerns.

Gripper: Succ

From the pretty self-explanatory title, this gripper uses suction to hold on to game pieces, for both cubes and cones. From preliminary testing, we have already figured out what region of the cone and cube the suction cups need to attach to grab either piece. However, when testing this gripper, the holder of the gripper would need to push onto the game piece to actually establish working suction, so the next steps with this gripper would be to figure out how to get a spring, string, or motor to provide the push force that establishes the suction. If the gripper works, it has the potential to be the lightest gripper that we use. However, wiring the air compressions would be difficult, and it has potential to use the most motors (2) out of any gripper we prototyped.

Gripper: Top Roller

Again, the title is fairly self explanatory: it’s a top roller gripper that can intake both cubes and cones (with the same length roller, those cubes are durable!). Although it works, there was some difficulty to pick up the cubes (which isn’t too important; picking up cones is the top priority). The gripper would as well be wide and relatively heavy, which would prevent some lifter designs from coming to fruition.

Gripper: Chopstix

Chopstix is the last gripper we are prototyping, with it being the most conventional gripper that we are designing. Like the name suggests, it uses a pincer system to grip both cubes and cones, with the in-and-out motion controlled by a string + spring system with the string being spooled up and down by the motor. The gripper would be (relatively) wide, but it wouldn’t be too heavy as the motor could be moved to the bottom (unless it is the energy chain gripper, then the motor would have to be near the gripper, making it heavier).


The code team has mainly been focused on setting up a reliable swerve drivetrain that includes absolute positioning and feels natural to the drive team. We also did a lot of experimentation with Shuffleboard and have been reading the docs of PathPlanner and PhotonVision, two of our new libraries, to learn how to utilize them. A full list of what we did and the specifics is included below:

  • Before CANcoders were wired, we were only using the TalonFX integrated encoders to control module angle. We had problems with the positions of the wheels, since when driving translationally, directions were completely fine, but when driving with rotation, two of the wheels were driving the opposite directions they should have been. We tried reversing the motors (drive and position) and resetting encoders in almost every permutation, with constants eventually being easily updated via Shuffleboard and a toggleable module switcher was made with the drive controller to center and reset encoders. The solution turned out to be two of the SwerveDriveKinematics constants being reversed, which promptly fixed the issue.

  • We have written experimental autonomous code using the PPSwerveControllerCommand from the PathPlanner Library. The autonomous code has not been tested yet.

  • We experimented with network tables and the Shuffleboard layout. Two tabs were added, “Telemetry”, for simple read-only telemetry data, and “Tuning,” for modifiable constants, like PID constants and motor direction booleans. Some issues have popped up with Shuffleboard, mainly that the values do not update consistently and sometimes tables don’t show up. When trying to add a box via the side menu, values show up and are changed in the menu, but do not show up on the interface. This could do with a stale client interface that needs restarting, but further debugging is needed.

  • After CANcoders were wired, we switched to a WPIlib PID control loop using CANcoders as feedback and the normal SwerveModuleState rotation as a setpoint into a percent output motor. This ended up causing a fair amount of trouble, as there were issues with the wheels not being lined up exactly and PID not going to setpoints as well as it could (took a while and seems to be inconsistent across modules). This results in translational drift with turning (e.g. when going with only vx, no vy, it would have a slightly off heading and end up in a curved trajectory, instead of straight).

  • Because of the quick refresh rate of integrated falcon encoders and its greater ease of use (although sad lack of continuous pid), we decided to switch to that as our control loop. The cancoder’s absolute position with an offset will be used to reset the rotation motor’s position to ensure constant direction on boot.

  • The cancoder offset is planned to be derived from lining up wheels with something like a plank of wood, having cancoders initialize to 0 upon boot, then calculating the offset by looking at the difference between normal position and absolute position.

  • To prevent drift throughout the match, we plan to either keep an offset that’s applied to the position throughout the match (either derived experimentally and multiplied with current signed rotation count or updated periodically with cancoders) or simply reset the position motor encoders with cancoder data. This does rely on cancoders, so it’ll depend on if cancoder drift is significant or not.

  • Our Orange Pis arrived, which we plan to use as a coprocessor for vision with AprilTags using PhotonVision. We plan to power them with the 5V/1.5A VRM but if there is too little amperage, we will use a buck-boost converter supplied with 12V and create greater amperage. The Orange Pi hasn’t been set up yet, but we plan to use the base Debian with Orange Pi OS.

  • Some problems that we believe could be potentially harmful are odometry updates while going over the charge station (wheel slip and the fact that it’s at an angle translating pose further than it should be). This could be minimized by creating a custom update function that takes into account IMU data (needs to be accurate or have a deadband likely) or using AprilTags to reset pose. There also seems to be a decent amount of swerve skew when rotating, which seems to either be minimized with either doing a Twist2d ahead one command loop or implementing second order kinematics. Further experimental testing is needed to see how much each one actually affects the skew, as they haven’t been implemented yet.

Post written by Dmitri, Noah, Nicholas, Emily, and Dr. Lawrie

4 Likes 1466 Webb Robotics showcases their different intake prototypes including claw, suction and even a Gary the snail intake and provides a look into their swerve drive and CAD for the 2023 Charged Up season on The Open Alliance Show



Summary of Recent Events

  • We made a decision on overall robot design and strategy on 1/16, as scheduled
  • The team had 4 main intake and lift systems that were developed and compared
  • We decided on a virtual 4-bar to focus on low and mid levels and a claw that could intake both cones and cubes
  • We appeared on FUN’s Open Alliance show this week!
  • Code team has field-oriented drive functional and some basic autonomous drive happening. Worked with drive team this week to make sure that the controls are intuitive and responsive
  • Robot is structurally complete in CAD, and parts for swerve chassis are being cut
  • We’re still deciding on whether our MK4’s will mount on top or bottom of box tubing. We want the flexibility to be the 3rd robot up on the charging station and are worried about breakover angle. We will be testing this week.
  • Media & art made progress on pit banners, team buttons, and team avatar

This week, code was focused on finalizing setting up swerve and making it have a good feel to the drive team. We also tested autonomous using PathPlanner in auto and have written code for autonomous routines in TeleOp. We set up our OrangePi 5 with photonvision and calibrated the camera. For a full list of what we did, see below:

  • We initially tried to set up cancoders to control integrated encoder position on boot, but after continually lining it up, and after a lot of wheel turns, there seemed to be a heavy amount of cancoder drift to the point of unusability. We switched to integrated encoders that boot to zero (so the robot always has to be aligned perfectly before the robot turns on). In the future, we hope to diagnose the problem and set up absolute cancoders since aligning the wheels isn’t optimal, but this is enough for now.

  • We encountered a problem that, when there’s suddenly a new direction for the angle motors, they don’t go to the setpoint immediately, so there’s a bit of translational movement in a direction other than intended motion. The position PID for the angle motors was tuned to minimize this.

  • A Joystick instead of an Xbox controller was tested, which seems to be a lot more driver friendly with swerve, and likely what we’re going to switch to for controlling the drive. Everything is controlled with the one joystick with the forward, sideways, and turning functions of the joystick. Certain buttons (which are conveniently numbered) control some of the other things on the robot, like resetting the gyro, field oriented toggle, and going to a specific pose.

  • Auto routines were tested, both a straight forward test, a turn test, and a turn in place while turning test using PathPlanner. With initial measurements with meter sticks it appears to be pretty on point in terms of how it moves, but we plan to further tune both encoder measurements and add photonvision for vision pose updates.

  • We tested the theoretical swerve skew when going one direction and turning, but it doesn’t seem to be significant. We still have attempted to calculate a pose ahead one controller loop (which didn’t work, likely because the loop time was wrong). We also have added a modified version of the SwerveDriveKinematics class to take into account the math for 2nd order kinematics found in this paper: Whitepaper: Swerve Drive Skew and Second Order Kinematics (big thanks to 3181 for the implementation) and also implemented it wrong in our code, so further testing needs to be done.

  • We took inventory of the coprocessor equipment for setup of an Orange Pi with camera equipment, everything has arrived and is there. Some initial temperature control includes heat sinks over the cpu and ram, but there likely needs to be a fan to ensure longevity. The fan that we have, the Noctua NF-A4x10 5V, does need to be mounted, so a case will probably need to be 3D printed to fit the geometries. We set up an interface for connecting to the pi with peripherals and a monitor. We then installed photonvision using the default Debian installation instructions ( and uncommenting the AllowCPUs line). We also had to install openjdk-11-jdk via the apt package manager to get the systemd service to start. Photonvision works with the web interface and we also calibrated the camera we have (Global Shutter AR0144) for all three resolutions.

  • We tested the 21” square swerve on the charge station (it works!) and tried different configurations. It has to be at a decent speed to get onto the charge station when it’s at 35°, but can pretty easily balance when on it. Future plans for balancing include a gyro pid in auto, but the code hasn’t been written yet.

  • We have written a collection of classes to create scoring zones on the field (the areas in front of the scoring). When the robot is within these areas and a button is pressed on the Joystick (out of three options) and the robot goes to the specific scoring position. Unfortunately, because of some initial problems with the code and later not having a testable robot, the code hasn’t been tested. Future expansion would include the rows of scoring in addition to columns (for intake commands or small modifications of pose), which hasn’t been written and can be tested after the scoring mechanism is built. We’re considering buying new driver controllers for the team this season, so this could be controlled by a 3x3 keyboard, or will be controlled with buttons on the joystick.

  • We also created some code from scratch as a training exercise for our KOP defense bot (which we plan to put Gary, one of our scoring designs, on), and successfully got that working with differential drive kinematics. We also tested a simple auto that goes forward and turns.


Mechanical team was quite busy with building the V1 Robot this week.

  • Decided on Virtual 4-bar lifter and Chopstix-style gripper (Gary is too slow :frowning: )
  • Finished building grid and charging station
  • Assembled V1 Robot Drivetrain (26” square, MK4)
  • Cut some pieces for virtual four-bar

Field Construction

As of this post, we have one full grid section and a ½ charging station complete. We are still waiting on the official hinges we ordered from AndyMark to ship, but the 1” box tubing solution in the Team Field Elements is working well.

We’re less sure of what specific polycarbonate sheeting to use on the surface. If anyone has suggestions, we’re open to them! Otherwise, we’re going with some thin (0.02”) polycarb sheets from McMaster-Carr.

The grid structure really helped us with testing lift system geometry, in addition to the work in CAD. Overall, we had a fixed angle elevator and a fixed angle telescope both mocked up in CAD and built by mechanical team. For the energy chain lift and virtual 4-bar, we put together more developed prototypes, but had less detail in CAD.

Intakes Goals:

  • Light
  • One or two moving parts
  • Active capture and release of cone/cube
  • Room for development/iteration over the next 8 weeks

Top rollers - prototyping teams looked at using compression to trap cube and cone between two rollers. One fixed, one powered roller did not hold a cone or cube, but two spinning rollers did a great job of capturing both cone and cube. The roller system worked best with 2” green compliant wheels spaced about 2”-3” apart on the axles. Ultimately, the team working on this prototype felt the design was too heavy to make it onto the robot. To be fair though, code team and drive team have both requested some additional testing in this area, as this seems like an actual “touch it, own it” intake possibility.

Suction - #teamsucc had a lot of momentum at the beginning of the weekend and developed some prototypes using a vacuum pump kit from Sparkfun. It did not have an FRC-legal motor, but we were confident we could swap in a 775pro. Some pneumatic tubing and basic small suction cups from McMaster-Carr worked great to pick up cones and cubes. Mechanical team built some angled arms to hold suction cups in place to wrap around the cone or cube. Surprisingly, the team found it was easier to pick up a cone with the suction left versus the cube. One challenge was getting good suction cup placement on the cube. It could help to have the cone or cube funneled into the robot in a repeatable way so suction could grab the same way every time.

The Claw - mechanical team decided to continue developing the side pincher claw. It will likely be actuated by motor. We tested pneumatics, but don’t want to add that system for one piston. In order to study this mechanism, we designed and then laser cut some mockups to check the geometry. The team favored this design over the other options and will continue to develop it on our v1 of the robot which we plan to complete by the beginning of February.

Lifter Goals

  • Mid-row and hybrid node capable scoring
  • Quick and reliable robot
  • Minimize the number of moving parts
  • Simpler, well-tested
  • Mechanically complete for >6 weeks of development time.

We explored:

  • Fixed Angle/Slanted Elevator which we explored in off-season
  • Thriftybot Telescope which we assembled for 2022
  • The Snail (Gary)
  • Virtual 4-bar

We mentioned the elevator and telescope in a previous post, so we’ll add a bit more detail about our late-week developments: the energy chain “snail” and the virtual 4-bar prototypes.

Some notes on the inspiration for The Snail… we had the “Unofficial FRC Mechanisms Encyclopedia” open for kickoff day and the “Unique Mechanisms” playlist running. We saw the FUN interview with 1477 showing their hefty Igus energy chain climbing hooks. It deployed from a large spool. We had rookie CAD team members design the gear to turn it, which was a great learning experience. We cut the gear on our Glowforge and were able to drive the energy chain for mid and high scoring.

And of course, here’s a video of Gary the cone delivery snail in action. Unfortunately, Gary’s not as fast as we’d like. He’s likely going to be moved from alpha robot concept to defense bot entertainment.

Virtual 4 bar was suggested based on this video. It’s geometry, man! Our team has built 4-bar designs in 2015 and 2016, but the virtual 4-bar would be new to us. The advantage of carrying the cone or cube inside the robot seems nice, while still being able to pick up and score from outside the frame. We usually try to find over-the-bumper solutions before frame cutouts, and this fits that criteria.

Here’s a video of us testing the range of motion with a quickly mocked up virtual 4-bar.

We had a team meeting to review the pros and cons of each on Monday. While we could probably run any of these and learn a lot from them, the floor pickup possibility with the Virtual 4-bar was the deciding factor. Code team wants to floor pickup in auto, providing alternative routines. They want floor pickup on our v1 of the robot, so there’s plenty of development time. Our team was successful with a gear floor pickup in 2017, and it seems appealing here. We know there will be other robots specializing in the top level, but we don’t think it needs to be us right now.


This week in CAD was all about decisions being made. With all our prototypes being adequately tested to where decisions could be made (deciding on a virtual four-bar for a lifter and chopstix-style gripper) on Monday 1/16, it was up to CAD team to have enough of a robot so mechanical team could start cutting parts by our meeting on Thursday 1/19. While most of the measurements are done, to build our virtual four-bar mechanism properly, we need to test some things with our drivetrain (such as seeing if it will meet breakover angle) before finalizing some four-bar dimensions.

  • CAD team has been able to fit the virtual 4-bar architecture into a 26”x26” swerve chassis design. This should enable our team to be a good alliance partner for charge station balancing.

  • Dimensions for box tubing for the drivetrain and some for the four-bar were already finalized at that point, so the mechanical team got to work constructing the drivetrain for testing and as many lifter pieces as we can early.

  • We are keeping an eye on some clearance issues in the robot design. For example, the sprockets on the 4-bar arm come pretty close to the Falcon motors. We don’t want to hit those. We’ve talked about switching to the MK4i setup, but our conversion kits aren’t expected until some time in February. Swapping to inverted configuration could also impact our ground clearance - we’re not sure the MK4i configuration makes sense if we want to bolt our box tubing frame to the top plate of the motors.

There’s been a lot of CAD work over the last several days, and we’ll likely have a dedicated post to that topic soon. For now, our CAD is public and can be found here.

Drive Team

With only one swerve chassis to work with, we are scheduling separate meetings for drive team and code team to be able to work with the robot. On Friday, we had an extended drive practice to help drive team learn to maneuver with the field-oriented swerve drive. We’ve not run swerve in an event before, so we want some time to switch from the tank drive mindset to swerve. Main driver and backup drivers got a chance to drive on the charge station and run drills with the 21”x21” swerve chassis.

Driving drills setup in this video! We think the L1 MK4 gearing seems plenty fast, but want to order L2 gears when they are in stock.

One big issue we ran into was with bolts rattling loose from the MK4 swerve modules. Use loctite on everything! Out mechanical team was in the process of checking connections and reapplying loctite, but two of the MK4 modules hadn’t been checked yet. The result was a 10-32 bolt holding the Falcon 500 pinion in place backing out and dropping into the turning gears! We’ve chipped a tooth on the 15t hex bore gear, but the chassis still seems to drive just fine. This was a lesson to drive and mechanical both to inspect regularly and lock down connections. We don’t have spare swerve parts yet, so we don’t want to see anything get damaged!

1 Like

Hey Chief Delphi! Week 3 has just wrapped up, and here’s some detail of the recent developments in our lab.

Summary of Recent Events

  • CAD for lifter and drivetrain for V1 is finalized for assembly. Minor changes could (and most likely will) still be made after initial mechanism testing.
  • Swerve chassis 26”x26” is completed with CTRE control system and code team has been debugging and working on auto paths
  • Virtual 4-bar parts have been cut and assembly started
  • Work continues on end effector development, with machining of claw parts done this week and horizontal 3-roller intake prototype tested

The CAD team has been working hard over the last 3 weeks, and here is our progress on our V1 robot designs! The drivetrain and lifter designs have been finalized for V1 (but will probably change after mechanism testing), and the team has consolidated to working on two types of grippers: roller and claw.


We designed a swerve drivetrain using SDS MK4 modules with a 26” square frame, so it would give robots on our alliance room to fit on the charging station. We did some testing this past week with the charge station, which led us to the conclusion that we want the 3” of ground clearance afforded by mounting the swerve modules on the bottom of the chassis box tubing. Calculating our breakover angle led us in this direction, and testing the chassis while holding the charge station fixed at level (as if there are already 2 robots on it, making it hard to shift) confirmed our calculations. The robot could get high-centered with the low ground clearance configuration, but easily makes it onto the charge station with the elevated chassis. A video of one of our tests is included below, including a test to see if we could hang off the edge of the charging station.


With this game seeming to end up being pretty violent this year, and with the possibility of the swerve modules being put on the bottom of the robot, trying to find an effective way to mount the battery as low as possible is paramount for drivetrain design this year. Our offseason swerve using the horizontal battery box, mounting it 1” higher than the rest of the bottom of the drivetrain frame. However, having a horizontally mounted battery that is parallel to the bottom of the drivetrain frame would make our CG lower while not reducing the ground clearance. Although nothing final has been decided for the battery mount, the current solution is to have two pieces of 1/8th inch thick 1x1 box tubing bracketed to both sides of the battery with ¼ inch clearance, with the battery being strapped on the top.


The lifter is a virtual four bar (V4B) mechanism designed to reach the mid level and the floor while being able to effectively stow all the weight in the robot and not make the robot too top-heavy. We decided on a V4B between three other lifters: an elevator, a telescoping arm, and an energy chain (Gary), which could all reach the middle level with one DOF (although Gary is not going on our competition robot, Gary will be on our defense bot, which we might bring to offseason events), as the V4B is a simple, reliable build that can also integrate floor pickup with appropriate dimensions that, with composite materials for the tubing (that one of our mentors can help with), can be made very light as well, helping prevent the robot from being too top heavy.

The V4B only uses one motor, a Falcon with a 16:1 gear reduction, to both rotate the mechanism around and to control the gripper orientation. In this version 1 CAD, the gripper orientation remains constant throughout the rotation, but this might change in future iterations. The entire assembly is connected with #25 chain, so the 60T sprockets on the rotating box tubing could be made smaller. The Falcon is chained up to an intermediate shaft, which has sprockets that belt up to the top base shaft with the 60T sprocket chains. Because of our experience with chain last year, we wanted to make sure that the chain running from the intermediate shaft to the top shaft had a tensioner, so we have the intermediate shaft and motor as low to the ground as possible.

The 16:1 57 Sport Gearbox we have in stock may not be able to handle the arm rotation. Currently, we don’t have solid numbers for arm weight and length. With the virtual 4-bar design, the effective length changes as the arm is deployed, with the end effector facing out. Currently, the “bar” in the 4-bar has an extension of 27”, but a claw or roller on the end could add significant weight and reach. We may need to move to a 36:1 or even 48:1 HD 57Sport. We don’t have those in stock, and will probably need to order for testing.

JVN calculator is great for identifying the right gear reductions, so that’s where we’ve started. The goal is motion that is fast enough but keeps our current draw under ~40amps per motors. In addition to increasing the gear reduction, we can also add a second Falcon to drive the arm to make sure we don’t blow any breakers.

Another problem that we might come across with the V1 V4B is giving enough horizontal room to attach the gripper. The space between the two rotating VFB arms is about 13” (subtracting space that chains take up from distance between the box tubing of the arms), and the space given by the base box tubing is 12”, which is not ideal for storing a gripper into the robot. Of course, there are multiple options we have to circumvent this, such as angling the gripper upward, but for later versions of our robot, something we are highly considering is trying to move the box tubing to the outside of the swerve modules so they attach onto the outer frame. However, there is complexities that arise there with extending frame perimeter, making sure that the motor can be put low enough for enough chain to run between the intermediate and top shafts with a tensioners, etc., which is something that CAD team is in the progress of figuring out how to deal with in these upcoming weeks.


Both intake mechanisms currently under development would be powered with Neo 550’s. We haven’t used NEO’s before, but are trying to work a little more within the REV ecosystem. We had a team this week working to add pinions to the 550’s we got with our FIRST Choice order and get gearboxes assembled. The intake rollers will use a 5:1 reduction, and the claw a 60:1 reduction. The REV instructional videos were great for getting the gearboxes assembled and tested without needing a full control system set up, just connecting via Spark Max to a computer. More about our work on grippers is coming up in a post next week.



Mechanical was pretty busy this week with testing intakes (see CAD) and assembling the drivetrain and lifter. Version 1 drivetrain is completely assembled, however the battery mount we wanted to use is not too effective (see CAD), and we are considering how to upgrade it to make it more stable.

Lifter assembly has started, with all the parts cut and assembly underway. The base of the lifter has mostly been completed, with the box tubing there and most of the shafts attached to the assembly. Hopefully, by early next week, mechanical can finish the lifter assembly so we can attach it to the drivetrain for code to use.



This week, code was mostly focused on writing code as swerve was being worked on by mechanical for quite a bit. Some of our highlights are a custom odometry updater, a swerve balance class, and auto routines. Near the end of the week, we focused on testing, debugging, and tuning.

  • Finally correctly implemented FRC 3181 Pittsford Robotics’s BetterKinematics and BetterSwerveModuleState to account for swerve skew. No video as of now, but works well when the swerve spinning is constant, less well when swerve spinning is sudden. How we implemented it is to do the desired module state angle minus the omegaRadPerSecond in the BetterSwerveModuleState times the loop time (in our case 0.02s). This simply updates the desired module state of the module to be slightly different, so we don’t have to change anything else.
  • Create a custom pose updater for going up the charge station. Has been tested but still has some drift, open to feedback on any errors in the implementation. Uses a rotation matrix to transform the delta distance vector on the plane z=0 for the module to be on a newly tilted plane. The vector’s projection onto the plane z=0 is then the true delta distance traveled for the module. Also updated the angles of the vectors, since they change too, by just using atan2 with the y and x of the resulting vector. The calculations are being done robot relative (yaw=0), so there could be an error with this module angle, but I haven’t had a chance to look at it.

  • Created a custom swerve balance class. Hasn’t been tested unfortunately due to an error in how the commands were implemented. This class just calculates the slope at y=0 and x=0 from the rotation matrix of the tilted plane of points to find what’s essentially the partial derivative for x and y. This is scaled with a constant and directly piped into a new ChassisSpeeds, where we then do the normal things of ModuleStates and updating the motors. The reason we use pitch and roll is so we can auto balance the robot even if the robot is not aligned straight; it can be at an angle and the balance should still work. Feel free to contact us here or on the Open Alliance Discord if you need more info.

  • Created a module heading control for direct translational motion in TeleOp. Uses the rate of the gyro scaled to radians, then applies PID with a setpoint of 0 to output a new rotational velocity for the ChassisSpeeds. Only turns on when there is only translational motion. Tuned it and it works pretty well.
  • Tuned our autonomous PID constants for Pathplanner Trajectories to minimize the final error of the pose. Minimized it to less than 0.1 degrees heading and 0.01-0.001m in position. In actuality it’s around a few inches off when going to the field pickup area and going back to a node, likely due to module angle error since it’s spinning 180º while it’s doing the routine. We haven’t implemented vision yet though, so we’re hoping that our Orange Pi 5 with photonvision will be enough to compensate for the error.
  • We also added a lot of auto routines, including 3 score autos (which we’re not sure if we’ll be fast enough to execute yet), 2 score + charge, 1 score + charge, and a few 1 score + field and just field to get out of the way of other teammates and go close to the loading zone for faster cycle times. For the last one, we plan to also have a customizable second-based wait time to coordinate with other alliance members how to not run into them. We’ve designed most of these options for three starting spots, middle, right, and left. Below is a single score (that waits a custom amount at the beginning) before driving off near the loading station to decrease cycle #1.

  • One major error we encountered in the week was Swerve working fine for a bit, then suddenly breaking, with the console being filled with Command loop overruns, a million CAN frame timeouts, high rio CPU usage, and packet loss. This ended up being a CAN wiring issue with insecure wires and also the VRM randomly shorting due to insecure wires. If you encounter similar issues, check the CAN connections and look at Phoenix Tuner (if you have falcons) or the equivalent to see if CAN connections are actually showing up on the robot.
1 Like

Team 1466 is proud to officially announce its new brand identity! You may have seen our new logos, color scheme or t-shirts on our social media platforms (or the Open Alliance Show).

Check out the process that went into this redesign below. An explanation of our Google Drive is included, exemplifying our commitment to organization and the continued use of these design elements.


With 2022 being the first time the overwhelming majority of our team attended an FRC event, new team members were exposed to teams with strong branding. This sparked ideas of adopting an entirely new theme, including spiders (Web robotics), gears, villains, and scientists with black lab coats. Other ideas included leaning into an elemental theme (periodic table element Wb) or Webers, the SI unit of magnetic flux.

Our brainstorming process became strategic at the beginning of November of 2022. While attempting to sketch out some logos and create merch designs, our lead mentor urged us to to use a strategic design approach towards establishing our new brand. Similar to how we approached robot design, we began to look at the function of our branding and the values we wanted to display through it. These included:

  • Representing us as a team, not a club
  • Keeping the name “Webb Robotics”
  • Keeping our school’s green color
  • Not being tacky

While our ideas of an entirely new team brand were exciting, they were dropped as we saw the value of maintaining our ties to the school that supports our program. Soon the NO’s of not using overly masculine branding, not using gear branding and not using any symbolism that directly represents our hometown of Knoxville (Sunsphere, mountains, etc.) became requirements. We chose our circuit theme since it is not common among FRC teams and maintains a good balance between Nerdy and Pablo (artsy). We kept the Nerdy-Pablo scale in mind throughout the design process.

Logo brainstorming whiteboard with our list of values and designs of Stuart, a mascot idea

Developed designs that include loops around our team number (not translated into our final logo)

Photos were taken of these board and then digitized using a stylus and the Sketchbook app on iPad

More digitized logos

Brand board brainstorming created collaboratively in Canva

We sent out a branding questionnaire to the team, asking for opinions on 8 logos, 3 fonts, 3 mascots, and the color palette below. 19 responses showed conclusive results, including positive feedback towards the sketch that would become our primary logo and distaste towards a fuchsia pink as our accent color. The final branding you see takes into account many of these suggestions, while making choices that weren’t loved by everyone. Overall, team feedback towards the new branding has been positive since the brainstorming sessions were highly collaborative and the ideas of many team members are represented in the redesign.

Palette voted on in our branding questionnaire (the fuchsia pink was ultimately replaced with a more subdued purple-pink)

All of our brainstorming and final design work was created in Canva or the Sketchbook app, with touch-ups made in Preview on Mac.

Primary Logo

Our primary logo includes a “W” made of circuits, our team number, and our purple-pink accent color. Variations of the primary logo, including transparent background files, are stored in Google Drive. These are used when the primary logo doesn’t seem appropriate aesthetically, like on business cards, print documentation, or social media. Our YouTube video watermark is our white transparent primary logo.

Primary logo variations

Large Logo

Our large logo is seen on our digital banner and includes our full team name.


We hadn’t made a season t-shirt since 2020, and we decided a t-shirt for all members to wear would solidify our new brand and help build community within the team.

2022 hoodie designs in Custom Ink

Our 2022 hoodies were immensely popular with the team, especially since they could be worn over our school uniforms during the school day. With updates to the 2022-2023 dress code, students are no longer allowed to wear hoodies during classes. Students are allowed to wear season t-shirts on competition-week Wednesdays, so we had a larger incentive to create a new shirt.

The 1466 on the back of our hoodies was the highlight of the design, making the team number extremely visible. This was the starting point for the back of the season t-shirt, which evolved into a CPU-esque housing for the number that sticks to our circuit theme. Here’s the source for the blue circuit inspiration picture.

T-shirts were ordered through Custom ink on December 20th and they arrived on the 30th. Here they are in their full glory:

The purple-pink accent color made it onto the t-shirts

We’re celebrating 20 years in FIRST™ this season


  • Titles - Lexend
  • 1466 (On logos) - Lemon Milk
  • Subtitles - Exo
  • (Sub)headers - Open Sans
  • Primary Read - Jost
  • Alternate Primary Read - Lato

This document includes the exact specifications and use cases of our new fonts. The organization of this document is heavily inspired by the FRC team 2976, the Spartabots, and their Year 15 Special Branding Reveal. Our team has never had formal standardization of our fonts; these guidelines have greatly improved the uniformity of the content we publish.

FMS Avatar

An attempt was made to use a pixelation feature in Canva to create the logo, but this did not yield a design with a sharp contrast between the green and black of the design.

Created to resemble our primary logo, our 40 x 40 pixel avatar was completed in Piskelapp. The pink in our logo didn’t make the cut since it was not likely to be seen on scoreboards and FIRST™ has a rule against using fuchsia in team avatars.

The circle design isn’t commonly used among FIRST™ teams, and the black contrasts nicely against the standard alliance colors

Color Palette

Our color palette includes our school’s official dark green, a light green (an elevated version of our previous lime green), a purple-pink accent color, and gray.

Digital Banner

Our digital banner incorporates the circuit design in our t-shirt, edited to include less circuit breaks where the large logo sits. We used the Coolors gradient maker for the green to black gradient. The gradient is strategically spaced so that it does not appear in the banner in the YouTube mobile app, while being visible on the YouTube website.

Original t-shirt design elements rearranged

Simplified circuit background

Banner on YouTube website

Google Drive Organization

At the beginning of 2022, the Media Team completed its overhaul of the team’s digital storage in Google Drive. Home to documents and content for all 20 years of the team’s existence, an organized digital space allows for the storage of current knowledge and memories.

Our school provides Google Workspace accounts for all students, so choosing to use Google Drive came naturally. Google’s collaboration features prove great for editing collaboratively and sharing content from events with other teams.

The Drive is divided into 12 folders as seen in the image above:

  • Team Basics: team timeline, training records, schedules
  • Awards: Impact and Woodie Flowers Award submission documentation
  • Branding: logos, font .otf files, t-shirt designs, and branding redesign documentation
  • Build Season: Chief Delphi / Open Alliance weekly updates and prototype inventory
  • Business: grant applications, sponsorship letters, team budget
  • Content: lab and event videos and photos, social media posts
  • Off-season: CADathon, mock kickoff, and leadership meeting notes
  • Outreach: event brainstorming, gingerbread house build blitz files, Boys & Girls Club mentoring resources
  • Strategy: Charged Up game manuals, strategy breakdown, event scouting spreadsheets
  • Team Handbooks: CAD, CNC, Laser Cutting, Mechanical, Media, Robot Design, Scouting, Talking to Judges and General handbooks
  • Training Modules: Team structure, CAD, code, electrical, fabrication, outreach, safety, strategy, and general conduct presentations
  • Ze Archive™: former season documentation, award-winning essays, completed media projects, and Discord emoji files

Ze Archive™

Folder template for future seasons

Important logos easily accessible in the Branding folder; variations stored in folders

All folders contain the current season’s files. When competition season ends, all files are moved into Ze Archive™ and replaced with new folders. The Media Team kept the number of clicks needed to open a document in mind. Most current season documents can be reached in 2-3 clicks, while archived files take 3-5 clicks to access.

Google Drive shortcuts are used if content needs to be stored in two locations, such as videos in Completed Media Projects and in their respective season folder

Note that our team number is added to our “Team Basics” folder so that, when sorted alphabetically, it always appears first. We wanted our team archive folder to be the last folder in the Drive, hence the name Ze Archive™.

Google has recently announced a 100 GB cap on Shared Drives. Our Drive currently houses 99.52 GB of storage, so we plan on creating a separate Shared Drive exclusively for Ze Archive™ files from the past 19 seasons.

Ze Archive™ could stand to have a few files reshuffled to remove folders, our Team Handbooks are unfinished and out of date, our file naming system depends on our mood, and our training presentations include old branding, but the Google Drive serves its purpose. With our folder template, future members can maintain a well-established legacy of organization.


Summary of Recent Events - Week 4

  • We’re approaching our scheduled alpha robot completion deadline: Monday 2/6
  • Mounted the virtual 4-bar arm superstructure onto the 26” square swerve chassis
  • Continued development on both the claw and the rollers intakes. Claw parts were cut by a sponsor, Everybot 2023 plates were ordered to test out roller configurations. Ended up attaching the claw to the robot, but not wiring the motor yet.
  • Lot of fine tuning with autonomous charge station balancing and AprilTag detection
  • Code team added 4-bar arm control with PID using a REV through bore encoder
  • We received word about a grant award at the beginning of the week, allowing us to purchase the REV control system! We weren’t expecting to make the change this year, but that award (plus out FIRSTChoice stuff) means we can make the switch
  • Our assistant coach and his wife had a baby (their first) this week - Congrats, Mr. Witt!

Mechanical team was really busy this week with putting everything together for our V1 robot. Throughout the week, the team was working on the virtual four bar assembly and the grippers.

NEO 550’s on End Effector

We’re using NEO 550’s for the first time this year after picking them up via FIRSTChoice. So far, we’re really happy with the Ultraplanetary gearbox system and being able to power and test the 550 motors via usb connection. We’re sold! Even better is that our FTC team uses the Ultraplanetary system, so there will be some hardware consistency from one team to the other.

We had a group assemble a 5:1 gearbox for a roller intake and a 80:1 gearbox for the claw intake. We ran into one problem: they accidentally used socket head screws in the motor to gearbox plate assembly when it should have been button head. It damaged a gear slice in the plates. Took us a little time to troubleshoot, but we tracked down the issue. Mechanical team was able to confirm, replace, and then test the parts individually and get the gearbox assemblies running again. The damaged gear slices seem to still work, but they’re a little noisy so we’re setting them aside as backups.

Virtual Four Bar

On our virtual 4-bar assembly, we managed to find an AM Sport 4:1 add-on slice to combine with our 16:1 gearbox. This gave us a much more reasonable 64:1 reduction on our Falcon-powered arm, followed by a 50:16 reduction achieved with #25 sprockets and chain. We used the JVN calculator to run the numbers on our arm, and it looks like we can get some reasonable arm speed with this. This was confirmed when we tested the lifter speed on Saturday.

Note we are probably overestimating the weight and length of the arm in the calculation above, but it gives us a margin of error to work with. The pivoting arm is 24 inches, and the gripper mechanism will stick outward only in the scoring/pickup orientation. The claw weighs in under 4 lbs and the roller assembly is 5-6 lbs (still working on that assembly).


Most tests with the roller gripper were for finalizing the design to be mounted on the robot (which will be machined Monday), so the only thing that was assembled for version 1 this week was the claw gripper, which was then attached to the virtual four bar to complete the robot. More details about how the claw gripper works is in the CAD section.

Roller Gripper

Claw Gripper


This week, code was mostly focused on testing and refining autonomous code, especially driver assist in TeleOp (robot alignment to scoring nodes, auto balancing). We also tried refining the controls of the robot to feel better to the driver through things like a slew rate limiter and a button box as a separate control mechanism.

  • We tested autonomous swerve balancing. It initially worked well, though there was a small amount of error in the gyro measurements because the gyro wasn’t perfectly level on the robot, or at least not perfectly level relative to the charge station. This was fixed later by calibrating it through Phoenix Tuner X. We also had some problems with the balancing being not as quick as we wanted it, as it took a second to get to a level plane. We refined the tuning to take in a scalar and an exponent to output a profile that quickly approaches a level plane when there’s a large tilt but goes slower around a level plane. Our balancing works in any orientation of the swerve robot, including when it’s balancing diagonally. Unfortunately, we don’t have videos of the updated quick process, but we’ll post them soon.
  • We tested TeleOp auto routines for scoring. This is using PathPlanner’s on-the-fly trajectory builder. We initially had some issues with some of the buttons not working and the trajectory not going directly toward the end pose. The former was fixed through adding breaks to a switch statement and the latter was fixed through doing a calculation of the translation between starting and end pose, then using that as the two headings of the robot. We also plan to be able to cancel the command, but testing it doesn’t work with an until decorator, so a better method needs to be found for canceling the command. We’re also finding a problem where if the robot is flipped in holonomic rotation and very close to the end pose, it spins really fast to get to the end pose.
  • We started setting up a framework for pose estimation by writing some code with the photonvision library and actually setting up AprilTags on our field. We’re currently planning on just using paper printouts for now, but later on making a more game-accurate setup with something like matte spray on a laminated ApriTtag. One issue we found in the code that might conflict was PathPlanner and the PhotonVision AprilTags. The solution to this was setting the origin differently for blue/red alliances for AprilTag pose estimation, and keeping the field flip for PathPlanner (since pathplanner assumes a normal alliance-flipped pose when they do their own alliance flip).

  • Added GitHub CI integration with Java Spotless for making our codebase more readable. Apply with ./gradlew spotlessApply. The code also autobuilds on commit to make sure spotless is right and there are no immediate code problems.
  • We changed control methods with the drive command, adding slew limiters to smooth out swerve motion, especially when starting and going from 0-100. At low levels this makes the robot feel unresponsive but when higher there’s a balance between gradual motion while reducing lag. Our drivers report it feels a lot better.
  • We did a lot of code training with our Gary bot. Gyro pose estimation was added, along with more review of the different organizational methods used in code. This sets up Gary to soon be able to drive autonomously using PathPlanner.
  • We added an arm subsystem. Uses a TalonFX motor setVoltage to control the arm. The voltage is controlled by the output of a pid controller, which intakes a number and the current output of a duty cycle encoder. This is controlled by axis 3 on the joystick, which is scaled to be [-0.5,0.5], then an offset is added and the value is clamped. The arm works well when tested, but the PID needs to be tuned since it’s slow to get to setpoint. The endpoints will also be adjusted, since they’re not exactly to both ends of the mechanism yet. We also plan to incorporate the absolute position of the duty cycle encoder to make sure we don’t have to position the arm at startup.
  • We wrote code for our gripper mechanism. This is our first time learning how to use the REV library. Our plan is to use PID to control setpoint for two grip and release positions for the cube and code to be able to accurately grab and release.

This week, CAD was mostly occupied with finalizing details about the V1 robot so mechanical assembly could finish, with those details mainly concerning how to design the grippers we were testing so they could go on the V1 robot. The main concerns with each gripper design were having the grippers be able to fit within the lifter and to be positioned low enough above the ground when the lifter is lowered so they can effectively pick up from the floor.

The claw gripper does the best when it grabs on the low end of the cone (about 3”- 4” above the ground. It uses a NEO 550 with a 60:1 Ultraplanetary gearbox, with a hex shaft output that rotates both sides of the claw gripper via an aluminum “potato” plate that connects the shaft to the rotation of the two jaws. Both jaws are made of 0.5” thick plywood, and every other custom plate is made of metal. There is a piece of elastic on both ends of the claw to increase retention of game pieces.

The roller gripper performs the best 3”-4.5” off the ground (4” being optimal), at about a 35 degree angle, and using the Everybot gripper center-center distances for wheels. The roller gripper uses a NEO 550 with a 5:1 Ultraplanetary gearbox, with a hex shaft output belted to the two outer wheels of the gripper.

On Saturday, when everything got attached to the robot, we started thinking about upgrades we should think about making for version 2 of the robot. The upgrades we already know we want to make are:

  • Making the virtual four bar wider so the gripper has more room
  • Attach gripper directly to sprockets for torque transfer
  • Changing from VEX box tubing to REV Max tubing grid hole pattern on areas of drivetrain frame

Hopefully, with more testing of our newly assembled V1, we can add on to this list, but this is what we have for now. Design of version 2 is now underway!

  • Electrical team spent Saturday getting familiar with the REV control system and taking an inventory of all the components required by the mechanical and programming teams. We took note of the current and voltage requirements of each part and how they need to be connected.
  • Right now, the older CTRE board is powering the v1 robot. Once our REV shipment arrives on Wednesday, we’ll make the switch to the new controls. With everything planned out and the connecting wires prepped, we’re hoping to get this done on Thursday and allow the robot to be back up and running for Friday drive practice.


The team brought STEM activities to our local Boys and Girls Club for the second week in a row. Both times we set up VEX 123 robots to have kids learn the basics of coding. The palm-sized robots can drive, turn, make noises, and shine a light. The programming is done on a physical board with blocks. This system has a very gentle learning curve and kids can understand how to make their robot move within minutes. There are even “if” statements for coders who have a stronger grasp on the basics. These codes run or don’t run depending on factors like a color detected or if a button is pressed.

The team also has two student members that consistently mentor the three FLL teams affiliated with our school. Two of the FLL teams have devoted lots of time to their Innovation Projects, so high school mentor review of scripts and skits have aided in the confidence of these presentations. Robot attachments were also improved after feedback from a 1466 former FLL member. All three FLL teams are preparing for their state competition on February 11.


Lots of content has been posted on YouTube in the past week, and we’ve seen amazing results. A new 2023 Prototypes playlist on YouTube now houses build season footage. Videos of driving on the charge station have been uploaded, alongside short, vertical clips of gripper prototypes. Uploaded on a mobile device as YouTube Shorts, these clips are viewed on a scrolling feed (similar to TikTok or Instagram Reels). All three of our prototype videos have over 5,000 views, so we must be doing something right! The vertical videos have “#shorts” in the title, and are likely favored by the YouTube algorithm. Also, going in through the YouTube Studio interface allows you to set tags on videos for them to be more likely to show up when searched. All of our YouTube videos now have the tags “FRC”, “Webb Robotics” and “FRC 1466.”

We commemorated “Gary,” our Igus energy chain prototype with an In Memoriam video. FIRST asked for 20 second videos to be submitted by teams to be shown at competitions. This clip has been submitted for everyone to join us in keeping the memory of this beloved snail alive.

1 Like 1466 Webb Robotics may have retired Gary the Snail but it looks like there may be a Mr. Krabs in the future with their new cam tensioner claw. 1466 also shows off their new intake and demonstrates how they are looking to align to the nodes for optimal scoring


1 Like

Hey, Chief Delphi! Since the design of V1 was finished, the CAD team has been hard at work to make a V2 design that not only addresses the problems we had with V1 but also to expand upon the capabilities of the robot. The design for the version 2 drivetrain and virtual four bar is about finished, and we are ready to share it! Pictures of V2 as of now (Larry) are below, and both the drivetrain and the virtual four bar will be discussed in detail.


No major changes were made to the superstructure of the drivetrain. However, as we switched from VEX box tubing to REV Max tubing, the drivetrain had to be redesigned out of those materials.

One important change to note is the change from 4 25” 2x1 pieces for the frame to 2 26” pieces, which was done for connecting the drivetrain to the version 2 virtual four bar. That is also why there are no L-brackets on the top on one side of the robot (as the virtual four bar is going to be there).

The only things that could be subject to change at this point are the 1x1 pieces for the battery and the coloring of the box tubing, as we plan for V2 to be powder coated (we’re debating between having some green pieces or going all black for our robot). There are easier ways to mount a battery than this 1x1 arrangement, especially with a battery strap, but how we incorporate that strap is still up in the air.

One way we thought of incorporating a battery strap is with a new metal belly pan, something we wanted to do on V2 for multiple reasons. We could more securely mount the gyro and coprocessor case, put more mass on the bottom of the robot, and have slots made for incorporating a strap onto the robot. At the moment there is a big belly pan plate on the bottom (pictured below) and a smaller plate on top so both the gyro and the REV power module can be put in the center of the robot.

Lastly, there are multiple things that need to be added to the drivetrain before true finalization, namely adding plates to protect the swerve modules in the back from the virtual four bar sprockets and the straight bracket (which were cut L-brackets) we used to connect the front side of the drivetrain frame in the actual assembly. These will hopefully be done soon, as we have already implemented these on V1 and the assembled V2 drivetrain.

Virtual Four Bar

The virtual four bar is where most of the changes happened for version 2, as we found more problems with it for version 1. The three biggest things we wanted to change for V2 of the lifter were to increase it’s width so we can preload cubes at the start of the match, give the chain going up from the shaft on the bottom to the top shaft more length so there isn’t too much worry about chain tensioner hitting the sprockets, which requires putting the motor lower, and making it easier to adjust the tension of the chain from the motor to the bottom shaft. It was very nice when the first two problems were solved by one change in the design. To make the lifter wider, it had to go over the swerve modules. If it didn’t and still went wider, it would be right on the edge of the frame, which wouldn’t be ideal, especially if we wanted to have a bearing plus shaft collar on that side. So the lifter base turned from two vertical 2x1s with diagonal support to a box of two vertical 2x1s, two horizontal 2x1s, two vertical 1x1s, and diagonal support. 4 horizontal 1x1s had to be incorporated as a support rectangle and to also give a place for the camera mounts.

Because the lifter was an inch away widthwise from the edge on both sides, that meant a straight diagonal support was very difficult to do with this design. However, we came up with the idea of doing a smaller box attached to diagonal support on top, which makes it easier to attach to the bottom of the robot without having an open corner that could be bent in massively during match play.

To solve the third problem, the bottom shaft is designed to interface with CAM bearing blocks, with holes properly designed for the box tubing (as the rotating arm did in V1) so we can easily adjust the tensioning of the chain from the motor to the intermediate shaft. Additionally (although not shown in the CAD yet), the motor shaft will be able to go into a bearing hole on the base box tubing, eliminating a lot of bending that came from the cantilevered shaft. To accurately manufacture this bearing hole, a laser cut drill guide will be implemented.

Unlike the drivetrain, which is mostly using REV 2x1, most of the virtual four bar uses McMaster carr / leftover VEX box tubing for the 2x1 pieces, with the REV 1x1 being used much more than REV 2x1. The only piece that uses REV 2x1 Maxtube is the motor mount, because 1) it puts more weight on the bottom of the robot and 2) the motor gearbox can interface with some of those grid holes, which results in a more secure attachment than just the VEX Versaplanetary 2” mount. All other pieces are thin-walled so not too much weight gets concentrated on the top.

With this change, some minor improvement could be made to increase the reach of V2. The sprocket was moved 0.25” closer to the edge of the robot, and this allowed for the rotating arm to be made 1” bigger. Although this wouldn’t be able to reach high by itself, it would improve floor reach (a higher priority) and a gripper that can shoot cones and cubes (the claw that we have plus roller wheels on the top) would be able to get cones and cubes into high.

*The gray pole in the picture above is the representation of the high cone pole.

To attach the version 2 virtual four bar to the robot, we are using brackets that go outside of our drivetrain frame, as well as interface with some of the REV max tubing grid holes on the side. To make the brackets outside of the drivetrain frame legal, we are going to use brackets to extend our frame perimeter (similar to what Spectrum is doing on their robot). These still need to be designed, as we plan to incorporate bumper mounting with these brackets as well.

All of our brackets (ideally) will be CNC’d, but there are some brackets in the design that we are okay with not CNCing (everything but the brackets that attach the frame to the front 1x1 and the bracket that connect the front 1x1 to the horizontal 2x1 and the sprocket). The brackets in the CAD that can’t be CNC’d will most likely be manufactured out of brackets that we have in house already or we have some fun and make our own brackets out of sheet metal (very not likely, but we might).

There are some problems that still need to be worked out with this design as well. Sprocket protectors need to be added so they don’t get damaged or damage other robots during match play is something we still need to add, and we also need to plan out a better way to wire the gripper motor. A potential issue that we already see is the robot becoming too tippy due to all the additional structure placed on the top. However, all the box tubing is thin-walled, and, with the motor going lower and the bellypan potentially becoming metal, it remains to be seen how much counterweight we need to add to the robot. I’m confident that we will find other issues with the design, but that one is the one that immediately jumped out at us.


Although the claw design has not changed too much, it has now upgraded from being a plywood gripper to a carbon fiber gripper, with metal plates now being skeletonized to reduce weight as well.

One change that we want to implement in the future is to get the claw to shoot cones and cubes out so high scoring is more achievable. Multiple ways have been suggested for this, including a linear actuator that punches the cubes/cone forward when the gripper is released, or roller on the front end of the end effector that could also help with intake of pieces. A more detailed post about our gripper will come at a later date.


What changes has your team made to the YAGSL that haven’t been upstreamed into the library? Did you or another team test YAGSL falcons with CANCoders as when I look at the code I am skeptical that it will work.


Most of our code has been upstreamed (there’s a few small things that I haven’t gotten around to opening a PR for).

However, our current drivetrain doesn’t use CANCoders because of some current mechanical problems, so we’ve only tested our falcons with manual alignment at boot. Can I ask what you’re skeptical of in the code?

1 Like

So when you do synchronize encoders many teams (including mine) have found that CANCoders don’t always return valid readings. This is worse around bootup when everything is initializing and CANCoders get reduced priority. This is also especially bad when you have high CAN bus utilization (which this library doesn’t help with cause falcons don’t have status frames set, which I am going to PR soonish).

Here is an example of how democats library (we did something very similar in the past) fixed this issue.

This is just a measurement that the code MUST get right because if it reads a bad value here it ruins the match as the team will be dragging one wheel the whole match (don’t ask me how I know, you do leave a nice fingerpainting of black rubber everywhere).


I will fix that CANCoder issue right now. I haven’t seen that issue yet, and wasn’t aware of it. Can you open a github issue?

I was going to test tomorrow to see if it was a problem but the code “can’t” hurt, it is also intermittent so it could work fine for a while then pop up at the worst time. Issue opened for both.

1 Like

Thank you for letting me know. I just pushed the addition and noted where I made the changes in your issue. For redundancy sake I copied most of democat’s code and reported the error to driver station while falling back to relative motor position on errors. I also added some CAN frame optimization for angle motors on SparkMax’s. I do need to do the same for Falcon’s still.

1 Like

Just did the same for falcon’s based off of democat’s library. General status frames (exact info described in the function) is now set to a 250ms period

1 Like

Summary of Recent Events - Weeks 5/6

  • Found and mitigated multiple problems with V1 (particularly regarding chain)
  • Built our defense KOP chassis bot Gary
  • Designed V2 superstucture, Larry, and started assembly with new REV MaxTubing.
  • Upgraded claw to carbon fiber
  • Tested both V1 arm and end effector with code, but not at the same time due to encoder problems
  • Made a new crewneck sweater
Claw Design

The gripper is composed of two jaws that rotate to grab game pieces. To assist in grabbing, elastic tubing is added to provide a more compliant gripping surface, increasing the consistency in grabbing cones.

The grippers are powered by a custom-made cam, which we have dubbed the “potato.” The potato is drive by a NEO 550 connected to a 60:1 gearbox. The gear ratio is very high because the potato only has to rotate 90 degrees to fully extend the grippers. The V1 grippers are made of a carbon fiber and foam composite.


Version 1 Troubleshooting

Although we technically completed the robot mechanically by Saturday, February 4th, the chain from the motor to the bottom shaft of the arm by the 6th/7th was skipping to the point where it was unusable. We spent a week trying to fix the chain, eventually solving the issue once we got bearing blocks so we could easily adjust the tensioning.

Here you can see one of the reasons for our chain issues - the hex shaft was not level. We also noticed that the sprockets were not clocked to one another properly when going from 16-tooth to 16-tooth to a 64-tooth. We reinstalled and aligned them correctly.

Here’s the assembly with bearing blocks and cams installed to adjust the chain tension on the small loop. On the v2 robot, the cams will be installed on the 2” side of the box tubing instead of the 1” side.

Additionally, we decided to use a turnbuckle for our diagonal support, which helped with stability but caused the virtual four bar to bend inward.

Claw gripper works great, and other than being rewired, assembly went smoothly as well. Two things for v2, we need to fix some issues with the gripper’s angle, and we need longer threaded shoulder bolts. We also already have the carbon fiber grippers for V2

Version 2 Assembly Progress

With the mostly finished design for version 2 and the unexpectedly early arrival of the REV max tubing, we could start assembly of V2 to prepare it for powder coating. The drivetrain frame was finished, and part of the virtual four bar was assembled. We couldn’t continue the assembly of the virtual four bar due to the lack of McMaster Carr 2x1 box tubing, but once that arrives assembly can continue.

Defense Bot Assembly

Over these past two weeks, we assembled the chassis for Gary, our defense bot. This was primarily a project for 1st and 2nd year team members. We used the 2023 Everybot dimensions as the size for Gary, to simulate spacing for balancing robots on the charge station most similar to how it would be at competition, and the lowest gear ratio on the Toughbox Minis so it would be fast and be able to ram into our main robot. We eventually plan to put our Gary prototype on the Gary-chassis so we can use it as an offseason robot. We practiced using the REV Control system, and completed the wiring of this 2nd robot on Friday.

  • Week 5 and 6 have been busy with outreach activities. We had all three of the Webb FLL teams attend their state championship and the Webb FTC team attend their state championship.
  • We continued our weekly visits to a local Boys & Girls Club to lead an after school STEM lesson for kids in grades 3-5.
  • We completed a 1.5-minute documentary video to submit for a project by FTC team 5773 and are preparing for their remote Global Inclusivity Conference next week
  • Impact Award was submitted!


  • Media team continues to upload content onto YouTube in the form of #shorts and regular videos.
  • We’ve also made progress on a team crewneck, with inspiration from varsity jacket designs:

  • We considered creating a design that incorporates our circuit theme this year, with circuits shaped like leaf branches. We moved away from this design over a simpler more subdued design.
  • We settled on the design below and have placed orders so that team members can wear the crew neck sweatshirt daily as part of their school uniform.
  • The dots between the word “Webb” and “Robotics” help separate the words and make them easily readable.
  • Our final design consists of a mint green that isn’t part of our color palette, but may be included in future designs.