WildStang Robotics Program: Team 111 and 112 Build Blog - 2023

Program Logo-Full-Web

WildStang and Plus One is pleased or announce our 2023 season build blog! While not an official #openalliance team, will be posting updates about our team, things we’ve learned and our build progress throughout the build season. While we greatly appreciate the efforts of the #openalliance (and have benefitted from their findings over the years), we are opting to not fully participate as we feel that the full unfiltered information on our strategies, code and build is not entirely beneficial without proper context. However, we will attempt to post as much information as we can for the broader FRC community.


111 CAD: Onshape
112 CAD: Onshape

(Software links coming soon)

Who We Are

WildStang Robotics Program consists (WSRP) of two FRC teams, Team 111 WildStang and Team 112 Plus One. We also have multiple FLL teams at our affiliate school MacArthur Middle School in Prospect Heights, IL, which is also where our FRC shop is currently located. Our 2023 FRC teams tops out at 75 students hailing from all seven Township High School District 214 high schools on Chicago’s NW suburbs. Our programs has 12 technical mentors from the defense, communications, coin-op, automation and broadcasting fields. Additionally, we two non-technical mentors from the communications and healthcare fields. One point of pride in our mentor staff; 11 of these mentors are FRC alumni. The student → mentor cycle is a big part of our success.

WSRP is a credit-bearing program at our high schools. To facilitate this, five teachers oversee most of the administrative tasks of the team as well as ensure that the program is meeting or exceeding the education requirements of our school district.

We assign students to team 111 or 112 based on their years of experience in WSRP. 112 primarily consists of underclassman while 111 is primarily upperclassman. The choice for two FRC teams was one of the big takeaways from our very successful 2021 intramural season (link). We found that our limited engagement in underclassman was mostly due to their not being enough work for 75 students on a team that was only building one robot……so the natural conclusion was two robots with dedicated work for each age bracket. 112 made it’s re-debut during the 2022 season.

Both teams will be competing week 2 at the Midwest Regional and week 5 at the Seven Rivers regional.

How We Are Organized

WSRP teams follow what I call the ‘old school’ FRC format. We attempt to mirror real world industry department structure onto our teams as best as possible. Mentors serve as the ‘senior engineers’ or department leads, while the students act as the intern/junior engineers on a project. We meet for four, three-hour sessions on weekdays and Saturdays for 6 hours. Over the years (and through several different hour requirement structures) we have found that this organizational structure helps to ensure that students can participate in the team to the level of their choosing. Lower attendance students still have a place to come 1-2 days a week and have something productive to jump in on, while high-attendance students can treat this with the time commitment of a varsity sport and own larger portions of the robot design. Mentors are in charge of overseeing that all work is being done in a timely manner, and is productive towards completing the robots.

Fall Classes

WSRP is a year round program, however, we scale back meeting hours during the fall semester, meeting only on Mondays for class and optional Wednesdays for things like driver practice, FLL mentoring and shop organization.

During these Monday classes, 112 students attend two, six week mentor taught courses in two of the WSRP sub teams. These are intended to expose students to as much of the FRC knowledge base as possible outside of the build season. Having them attend two sub-teams classes also empowers them make more informed decisions about the sub team that they will participate on in the spring build season. One other (slightly intentional) effect of this formula is students tend to be more aware of how their sub-team will interact with other sub-teams during build. Things like the reason for creation of our motor ID sheet and pre-assigning CAN ID’s become more obvious when you see for yourself how that information can expedite robot bring up for the software team. The mechanical team getting to see what parts of the control system are required and best practices for wiring and layout can help them make more informed decision during the robot design process.

While not strictly ready/documented for third parties to teach from, I’ll release our fall mechanical class slides here: Link

Students in our fall mechanical class will get exposed to everything from strategic design, fasteners, materials, COTS vendors, as well we several hands on activities in the shop. We also have them setup OnShape accounts and work their way up to designing a full WCD chassis by the end of the six weeks.

111 students spend the fall classes working on what we call ‘thesis projects’. These are projects of the students choosing that must be in some way beneficial to the team. This year we had projects that involved developing new robot sub-system designs(more on that later) to investigating things about our team such as equitability in our enrollment process and alumni outcome research. We’ve also had multiple service projects created and executed through our fall these project program.

What We’ve Been Working On

One of our top priorities each year is to choose our drivers for the coming season. We do this as early as possible to maximize the amount of stick time our drive teams have before competition. Waiting for a complete robot often means that they will only have 1-2 weeks at best on a robot before hitting a real match. Of important note, our 2021-22 111 driver also graduated last year, meaning we are in need of replacing the 100’s of hours he had driving swerve. Drivers are selected through evaluation against criteria that isn’t entirely skilled based. We have created this document to outline what we look for in a driver. (It’s largely based on an old 254 document, but has been updated to better correspond to our team’s requirements.)

Driveteam selection document: Link

On the mentor side, most of our work has been pre-buying many of the COTS components we expect to use for the 2023 season. Stocking up on things like Spark Maxes, NEOs, PDH’s has been the entire game this fall. Supply chain has still been rough, so being on your toes to click buy when things go up for sale is half the battle. Right now we are running an inventory of electronics that will let us build two entire PDH’s worth of robots with full sized NEO’s. Some level of this inventory was harvested from our 2022 robots, converting those to demo or display-only robots.

We are also fully stocked on our most of the extrusion, sheet and axle stock will anticipate needing for 2023. We can usually go 2-3 seasons between restocks, but 2022 was our year to buy. We usually hold about 100ft of 2x1x1/16, 100ft of 2x1/8 and 50ft of 1x1x1/8 in stock at max capacity.

111 is anticipating going with swerve for this next season and has purchased five Rev MaxSwerve modules. We ran SDS MK3 modules during 2021 and 2022 and had no issues with them, but given the uncertain supply with the MK4i’s for 2023, we opted to go to the REV modules. Had we received them before the fall classes ended, we would have built up an entire development base with them for our software team to migrate our swerve framework with and begin auto-pathing, but now that work will have to happen during week 1 of build season. The goal is to have the dev base entirely built and wired by the Tuesday after kickoff for delivery to the software sub-team. One of our students has created a full scalable swerve chassis that will let us create the shop prints for this drive base within a matter of minutes letting us get that build team off and running on the Monday after kickoff.

Configurable MaxSwerve Base CAD: Link

112 is anticipating going with with a WCD style drivetrain. We have spent much of our time learning about the new Rev gearboxes and how they would best integrate into our design language.

Much of our fall these project involve creating ‘template’ designs for things like intakes, lifts, drivebases, etc. We are betting on 2023 being a lift game, so this year we tasked a fall thesis project group to design a multi-stage lift system. We were pretty unsatisfied with the rigidity of our 2019 lift system, but now lacked the sponsor resources that we used to construct our much more sturdy 2018 lift. This team’s project involved adapting this design to better match our 2023 construction capabilities. Expect a write up on this design in the coming days from one of our junior students.


Bro! So excited for this!


What are the spectrum corners in the swerve module?

Pictured here

1 Like

I believe they are referring to something like this. We used 3D printed corners that pushed our frame perimeter out about 1/4 of an inch, this lets us mount plates on the sides of our traditional frame rails and keeps everything in a legal frame perimeter.


That particular design is a prototype for the Rev Swerve. But the longe answer is it’s a feature to exploit the 1/4” tolerance on bumper zone backing. Expanding the corners 1/4” outwards on all side means you can bolt brackets directly onto the outside of your frame without having to worry about frame perimeter variations.

We saw that design feature in Spectrums 2022 blog and immediately thought, “we’re stealing that!”. They didn’t have a name at the time….so Spectrum corners it is.


And as long as you mount the plates around the robot so they don’t ever have greater than 8" gap between them, the 1/4" rule doesn’t even need to come into play since that’s just your new frame perimeter.


Correct, yes. We may or may not use this depending on the robot architecture. For example, our 2022 robot didn’t need these as we had no brackets at all on the outside of the robot. The one plate on that outer frame rail last year was our intake, but we just printed a mount for it on the top side of the rail to get around that.

One alternative design we have is to integrate the spectrum corners into a ‘dust cover’ for the MaxSwerve modules that will seal up the geartrain. Our hope is to reduce the amount of carpet schmoo that ends up in those gears.


Is this 111’s (&112’s) first build blog? Super excited for this.


Here’s the direction for the ‘Spectrum corners’ we’re much more likely to use. Integrated into the dust cover we want while at the same time expanding the frame perimeter.

If we don’t end up using the expanded corners, we’ll just shrink the wall thickness down in that area to still keep debris out. The extra encoder pass through will just get electrical tape/plugged.

Onshape Link


Lift Project Write Up:

This year my thesis group was tasked with developing a lift so that we won’t go into the anticipated lift game without any experience designing them. Our goals were to create a lightweight three stage continuous lift with passthrough capabilities and address the previously mentioned issues with the 2019 lift.


  • 3 Stages
  • Continuous Rigging
  • Passthrough
  • <25 Lbs
  • ~40’’ Range of Motion


Custom Bearing Blocks:

  • Mounts both the bearings and pulleys
  • Room for CF spring integration
  • Minimizes distance between stage tubes
  • Maximizes stage overlap
  • Acts as a hardstop


  • ~2 Lbs without mechanism
  • Tube and plate structure
  • Easy to attach mechanism


  • Small footprint
  • 2 Neos
  • Easy to maintenance

Onshape Document: Link

Overall we’re pretty happy with how it turned out and learned a lot about lift design in the process. If we end up needing a lift in season, we will probably use a similar design optimized for whatever tasks are needed.


111/112 2022 Competition Season Code Release

111 2022 Robot Code
112 2022 Robot Code

Documentation of the 111 code is below. Feel free to ask any questions for anything I didn’t clarify below.

Driver Controls

Swerve Drive controls:

Translation + thrust: The translation joystick moved the robot (field-centric) for up to 60% of the available power. The “thrust” on the trigger unlocked the final 40%. This gave the driver the ability to drive fast without being unstable by driving without thrust, but also the thrust to unlock full speed while crossing the field and traveling in mostly straight lines.

Rotation joystick: The rotation joystick rotates the swerve drive, with the input scaled exponentially to give the driver fine rotation control when the stick isn’t moved much, but still allow a fast rotation when needed to push away from defense.

Heading locks: The heading lock buttons take over the rotation joystick and automatically rotate the robot to a certain gyro value. 4 buttons rotate to a cardinal direction (NESW), or press two buttons at the same time to turn to the hub angle between those two directions (for shots while directly up against the hub).

Snake mode: Snake mode is a button that controls the rotation to automatically point the robot’s intake in the direction the robot moves. This was mostly used for grabbing cargo while crossing the field, as sort of a “rotation auto-aim” to give the driver one less thing to worry about.

Robot Centric: We had a camera for picking up cargo behind the hub (in the blind spot), but that’s rather hard to use while using field-centric controls. So holding this turned the translation stick into robot-centric (as well as slowed the rotation to make the robot less “jittery” while turning in this mode).

Autonomous Driving

We used a custom path follower to control the drivebase during autonomous, with paths generated by BobTrajectory from teams 319 and 2363. We used the direction of the path to control the translational direction of the robot, manually found feedforward to control the translational magnitude, and a control loop to keep the robot oriented in the correct direction.

The feedforward found to control the translational magnitude was found with some custom tests. Specifically, we used 2 of them - one to determine how much power from the motors would overcome kinetic friction, and one to determine the power-velocity conversion. We had feedback based on the drivetrain encoders, but left it unimplemented due to the accuracy of running open loop (in favor of giving the drive team more time to practice with the robot).

The rotational controller controls the rotational magnitude to keep the robot at a certain heading, which can be changed in the code with an autonomous step.

Autonomous Programs

All of our programs got the robot coordinates from sketches in Onshape (seen above). Our 5 Ball Auto was pretty similar to the standard 5 ball, though we parked slightly farther away from the human player station so that the ramp up to it wouldn’t interfere with our intake.

We had 4 different 2 ball autonomous program we were ready to run. The first was a simple back up to grab our alliance’s cargo, and shoot 2 cargo. The second and third, after backing up and shooting 2 cargo, would pick up the other alliances two cargo nearby, and either hide them in the blind spot next to the hub or shoot them into our alliance’s hangar. The final auto shot two, but then picked up 1 opposing alliance cargo, used this to displace our alliance’s cargo on the other side of the field, and picked up that cargo to score a third. This was only possible on the blue alliance due to the red alliance side having our personal nemesis in the way, the cable protector.

Other Subsystems

We had different subsystems for the climber, shooting system, and ballpath. Some of the key details are highlighted below.

We used a limelight to gather distance and angle to the goal. From there, the robot would take over the rotational joystick to aim at the goal, and the distance would be fed into two piecewise quadratic regressions to find the correct hood angle and flywheel speed to make the shot. These quadratic regressions were calculated by taking a few data points from inside the tarmac all the way back to the alliance station wall.

Shoot while move: our shoot while moving ended up pretty simplistic, due to not having a turret. After experimenting with a static horizontal offset, we ended up altering the distance read from vision and the angle to the target based upon the current translational joystick’s values. So driving fully tangential to the goal would give the stationary distance but an angular offset, while driving directly towards/away from the goal would only change the distance we needed to shoot. This ended up being fairly successful, due to the large size of the goal. However, we had to limit our speed, otherwise the horizontal offset would get large enough that the target would disappear from the limelight’s FOV.

Our ballpath subsystem used 2 banner sensors that would determine where cargo was in the ballpath. Once two cargo were loaded, it automatically shut off the feed until we were ready to fire.

We had a complicated state system for automating the climber, but had issues using it due to inconsistent encoder values relative to the climber position (due to our climber cabling wrapping at different diameters depending on whether the system was under load or not). We instead gave the operator manual control of all parts of the climb, and with enough practice this was an error-free solution.

For the Future

For next season, we have a couple of main changes planned

  • A move to using PathPlanner for autonomous
  • Using the new Rev Swerve instead of the SDS MKIIs
  • A couple of smaller changes, including switching to a Pidgeon for our gyro, and some better Shuffleboard organization

I’ll have a post up before kickoff with some of these tentative changes released (but fully untested on a robot), and hopefully follow up week 1 or 2 during build season with our (hopefully) robot-tested drive code for the Rev Swerve (and hopefully some autonomous paths).


This year we will be continuing to use our Java framework developed in and continually updated since 2016. Our framework, like many others, was developed to add an additional layer of abstraction on top of WPILib. This abstraction helps us reduce the learning curve to get into robot software development and generally reduce development time. The framework, associated I/O hardware abstractions, and sample subsystems make up most of our software year-to-year. It is publicly available in its own repo. Ideally, this repo gets framework updates right away, but that doesn’t always happen in the heat of build season. One thing you will definitely find there in the coming weeks is the updated swerve code for Rev MaxSwerve Modules that Stu mentioned.

Almost everything we do on the software front ends up public at some point, on our program Github where you’ll also find 25 years (30 robots) of previous source code, multiple (sorry) scouting apps, scouting data, and various side projects. As Harrison alluded to we will not be developing our software for Charged Up in the open, however, we will be posting regular software updates -likely with snippets of source code- in this thread.

1 Like

Here are our teams kickoff notes, goals and a start on robot capabilities. We’ll spend tomorrow expanding on our robot capabilities list and generate a list for prototyping.


  • Qualifications
    • Maximize RP as possible
    • Maximize our points scored for 2 win RP‘s and tie breaker
    • Maximize Charging Station points for tie breaker and bonus RP.
  • Eliminations
    • Maximize our points scored

How To

Earn RP’s

  • At least dock, preferably engage in auto
    • Dock or Engaging allows 2 robots to earn RP
    • NOT docking or engaging requires 3 robots to engage during endgame.
  • Earn 5 links (15 game pieces), emphasizing 1 in co-op to allow ‘time cushion’ for RP if opponents score Co-Op
    • Leave remaining time to score additional links and engage charge station to maximize score.
  • 1 link feasible by solo robot in Auto.

Maximize Points Scored

  • Prioritize scoring high, then mid, then low
    • Low may be scored with ‘failed’ high and mid attempts.

    • Score on ‘border’ cone nodes to maximize rate of earning link bonuses

      • Scoring ‘Middle out’ with cones gives you maximum locations to score cubes on next cycle. See diagram for number of links that each cone location enables.
    • Score cones first to minimize risk of de-scoring

  • Choose cones for autonomous starting pieces.
    • Cone start auto in known orientation, making pickup predictable
  • Score preload plus 2 additional cones in auto, then dock/engage.
    • Moving to extra cones grants mobility points.

Robot Features (List is WIP)

  • General
    • Very fast robot speed to minimize scoring cycle time.
    • Efficiency is CRITICAL to scoring potential.
    • Starting game piece is cone.
  • Auto
    • Dock, then attempt to balance charge station autonomously
    • Collect cones from floor autonomously
    • Automatic align to goal
    • Automatic scoring release
    • Auto programs are alliance specific.
    • Cross cable protector in autonomous.
  • Tele-operated
    • Collect game pieces when available from ground to minimize cycle time
    • Minimize stationary time while scoring
    • Automatic alignment and/or automatic scoring release
    • Collect and align cones from human player station
    • Collect and align cubes from human player station
  • EndGame
    • Have all 3 robots engage, must leave enough room for 3 robots
    • < 28” robot width to leave room for two partners on charge station.

Max Points


Quick sketch to help with kinematic studies of different systems. We usually try to identify all the ‘critical positions’ the game pieces will be in relative to the robot. These help us identify reach requirements for scoring and intake of game pieces.

First glance, looks like mid scoring and HP pickup directly from the slider is nearly the same reach position. Also appears that the floor pickup position and low scoring positions can be identical.

Important to note that the game pieces move two different directions relative to the robot (you can’t draw a straight line between all the positions making it a 1D problem). This implies that any robot mechanism we create will require at least 2 DOF to reach all these critical positions.

FRC mechanisms tend to be broken into two distinct categories, rotary or linear. Since both are 1DOF mechs, some combination of the two will be required. That leaves us with:

Arm on a lift? (Rotary + Linear)
Lift on an arm? (Linear + Rotary)
Core XY setup? (Linear + Linear)
Multi-axis arm? (Rotary + Rotary)

Will need to do some real prototyping to determine if this is really a 3D scoring problem requiring some sort of left/right alignment assist. Something along the lines of the sliding hatch mechs from 2019.


Could the drive base be considered a second degree of freedom? I could envision an arm like the ones seen in 2011 (FRC 179 Auto, Logo and Minibot run - YouTube) could reach all of those points, the robot would just have to be different distances away from the location (although the cone would then not be at the same angle).


On paper, yes. In practice, we prefer to have the robot base be in a predictable location relative to the goals, meaning we can rely on scripted scoring sequences. Manual driver alignment is easiest if all they have to do it just run into the bars rather than park in an exact position on the field.


Today we created a list of all of the features that we decided our robot needed to have, features which we want to have, and features that would be nice to have.

We started by generating a list of all the features we could have:

After creating the list, we sorted each of the features into various categories. Needs are all of the features we decided were necessary to meet our initial goal of winning a regional. Wants are the features that we think we should have, but don’t think are absolutely necessary. Nice to haves are features which would be cool to have, but aren’t worth designing our robot around.

We spent the second half of the day beginning to experiment with prototypes for the various game tasks. Our main focus was on passive cone intakes, which have already shown lots of potential. Our end goal is to be able to intake cones off of the ground quickly regardless of their orientation and process them such that they end up in a consistent location to hand off to other subsystems. Here is our progress so far: Link


We spent the second half of the day beginning to experiment with prototypes for the various game tasks. Our main focus was on passive cone intakes, which have already shown lots of potential. Our end goal is to be able to intake cones off of the ground quickly regardless of their orientation and process them such that they end up in a consistent location to hand off to other subsystems. Here is our progress so far: Link

It’s a traffic cone logic gate!


Did you try this on carpet at all? We were noticing the cones slide quite a bit on the carpet.

1 Like