Team 3467 2023 Build Blog


Team 3467 is a robotics team from Windham High School in Windham, NH. Our program is also incorporated as part of 4-H allowing us to recruit students in 7th & 8th grade from our middle school giving us a unique hybrid organization. The team has come far in the past few years and has access to a solid suite of machining resources, including a CNC Router (ShopSabre), a Prototrak lathe, and a HAAS VF2 CNC Mill. As such, much of our design philosophy involves utilizing these tools and getting students hands-on experience designing and making parts for CNC, combined with off-the-shelf parts when appropriate.

Team website



We had a successful 2022 season, finishing as finalists at all three of our district events, and making the quarterfinals in our division at the world championship. The goal of this thread is to let people see how Windham Windup works, what we do, and how that impacts our students, our community, and our competitive successes and failures.

Learning from 2022

Our 2022 robot had a lot of success, so we wanted to talk a little bit about lessons learned from our 2022 robot, Tailgate.


COTS Products

We went Full Falcon this past season, with 2 falcons on each swerve module, two on the shooter, 1 for each side of the climber, and 1-2 on the intake. We had a myriad of falcon issues, that have been discussed here, here, here, and here. We’ve already invested heavily in Falcons, and we feel we’ve experienced most of their possible failure modes across our ~160 matches or so played this season/off-season, and here are our takeaways:

  1. Check the loctite on the falcon screws, and possibly replace with stronger screws that don’t shear as easily. We have been using these screws for our last three off-seasons with no issues since installing them.
  2. Support the other end of your falcon shafts, and possibly switch to ThriftyBot Keyed Output Shafts they are a single piece of machined stainless steel rather than the standard 2-piece shafts from Vex. These shafts can be used with regular NEO/CIM pinions as they are 8mm with a 2mm keyway and are tapped on the end for a 10-32 for pinion/pulley retention rather than the annoying press on retaining rings that everyone complains about. This also allows you to use a Falcon500 on a MaxPlanetary gearbox.
  3. The support for cantilevered shafts also applies in the SDS Mk4 modules. We had several Falcon failures in our swerve modules. If we switch to the Mk4i’s next year, they have the ability to support the Falcon output shaft in a bearing in the top plate (not by default in the base kit), but we are undecided as to whether we’ll be switching to Mk4i’s next year or sticking with Mk4’s (or running a tank drive - pending game announcement). We’ll likely be switching to the ThriftyBot output shafts regardless of which swerve kit we use.
  4. Falcons mounted to a planetary gearbox are supported, and we had zero issues all season with the climber falcons, which were mounted on Falcon Sports from AndyMark
  5. Anyone know how to help us with our budget?

The age of swerve has come, and the Swerve Drive Specialties modules and associated code examples are the biggest reason why. Our drivetrain this year was the SDS Mk4 from Swerve Drive Specialties in the L2 ratio. After a few initial issues setting up the robot in field-centric vs robot-centric, as well as some mid-season issues setting up the robot in the correct orientation when we switched to Pathplanner for auto, we had very few issues all season. The issues we did have were either Falcon-related, or module protection related. After our first district event we added guards to our swerve modules and had essentially no swerve issues until our second-to-last off-season, where a CAN wire got nicked by a robot hit from not being well-protected enough.

Our climber this year was modified from a set of 2 Stage Climber in a Box’s from AndyMark. We had no issues with these all year, and even helped other teams install and use the Climber in a Box. Incredible product, no complaints.

Not enough praise can be given to the Limelight team for the vision revolution. Our Limelight 2+ was easy to get running in the time between our last district event and worlds. This is made possible by its excellent performance which minimizes latency and allows the camera & processor to be used directly as a sensor, rather than using it to drive setpoint updates to our IMU, greatly simplifying the targeting logic. We hope the Limelight development team comes up with an easy way to use AprilTags for future seasons, because working vision has allowed our students to do some fun math, develop some impressive autonomous modes, and see the full potential of this robot. At the moment, due to the premature state of AprilTag support/performance for 2023 we will likely be using retro-reflective tape based targeting again next year.

Offseason Activities

Auto Development

Prior to the World Championship, we focused attention on developing a better suite of autonomous modes. We had implemented PathPlanner but struggled with some of the details of transitioning between parts of a path, as well as tower serialization during paths. Our best auto for the Championship was intended to be a 4-ball auto, but our best actual match performance was a 4-ball attempt that scored 2 balls. After the Championship we identified this as a major point where improvement was needed for us to get to the next level of performance.

We worked to understand a bit more of the nuances of our PathPlanner implementation, and fix some of the edge cases in our serialization logic. In addition, we wanted to make sure our autos were ready-to-go when they hit the field for the first time, so we re-measured our ⅔ size practice field and did a ton of testing. For BattleCry, this resulted in us having a 5-ball auto that was extremely consistent on the field, scoring 19 of 20 attempted shots over our first 4 qualification matches, and ending quals tied for the third highest Average Taxi + Auto Cargo score.

The five ball autonomous utilizes PathPlanner to pick up the 3 balls on the right side of the field, as well as the one in the human player station. We also designed it to start at the edge of the right side tarmac, allowing a partner to start against the hub and score their preload, freeing the left tarmac for a partner to run a 2-ball if needed. We do not use vision targeting at any point in the path, primarily to save a bit of time, which is a testament to the accuracy of PathPlanner’s excellent holonomic controller. Shoutout to our friends on Team 4909 for their TrajectoryFollow class which wraps the PathPlanner swerve controller and makes the auto commands a lot cleaner.

Here’s a video of our BattleCry 5-ball autonomous.

Since BattleCry, we’ve worked to shorten the amount of time used by our 5-ball, to allow for a wider time window for our human player to roll the 5th ball out to the robot. Developing our NERD 6-ball was a great exercise for achieving this. A rule change was implemented allowing robots to preload 2 cargo instead of 1, which meant we could have a 6-ball auto if we could shave some time elsewhere and modify parts 1 & 2 of the path. In order to achieve this, we modified the existing 5-ball to shoot cargo #1 & 2 directly in front of the cargo #3 pickup location, but before picking up cargo #3. We were close there, but we needed to gain more time, so we modified the tower control to load all cargo into the shooter faster, which required improvements to our shooting velocity PID loop. We also found a few tenths by increasing the path velocity in between points, so the longer sprints are a bit quicker.

We hit our 6-ball auto twice at NERD, and in our 6 playoff matches we scored at least 5 balls in every match. It’s a significant iteration from our 5-ball at BattleCry, and was a game of finding 1-2 tenths of time savings in several places throughout the autonomous routine. We’re very satisfied with the PathPlanner platform, and will certainly continue to use it next year, assuming the game is accommodating of swerve drive.

Here’s a video of our NERD 6-ball autonomous. You’ll notice in the video we actually just brush 5962 who are sitting against the hub, but it doesn’t affect our ability to score. Cool!

Shooting Improvements

At our district events, our cargo strategy was focused around scoring from against the hub (the “fender”). While this was successful, the geometry of the fender shot means it’s harder to be accurate, more likely for shots to bounce out, easier to be defended, and harder to get to in cycles due to on-field traffic. For the world championship, we improved our shooting abilities by developing a shot from just outside the tarmac that used vision to both rotate to the goal and drive us to the correct distance to make the shot. This allowed us to shoot from 1 distance from the goal, with the limelight data fed into a simple proportional controller using the same flywheel RPM for every shot. The chosen shot was tuned for just outside the tarmac, which meant we would hit the field border in the tarmac positions near the center of the field. This saved significant cycling time, but there were still improvements to be had.

We wanted to make some small iterations to that shot for our spring offseasons (BattleCry and Summer Heat), and as such we moved the shooting location closer to the goal so we could make shots anywhere on a circle around the goal. This was accomplished by modifying the ratio between our hood wheels and main wheels, giving us a taller arc, and allowing us to shoot closer to the goal. The underlying software targeting architecture, however, remained the same - we just changed the desired target distance.

For the Championship, we had a rudimentary launchpad shot developed that used a simple turning-only vision loop and a constant RPM. This took a bit of time and relied on the driver going to the same distance each time, and only using the close launchpad. After Summer Heat, we identified that shooting from any distance between the far launchpad and tarmac’s edge would be of significant strategic advantage.

In order to achieve this, we collected and tuned shots from several random on-field points between the tarmac and far launchpad, and entered them into a sheet. The goal of this data collection was to build a mapping between a given distance (represented by the limelight’s reported ty value) and flywheel RPM. We used a cubic function to fit the points, and had great results. An interesting finding was that shots from further away start to have a greater increase in RPM for a smaller distance. This is likely due to the ratio between our main and hood wheels causing the shot arcs to get steeper as we move further from the target.

We deployed this new shooting-from-anywhere algorithm first at Mayhem in Merrimack, which partially was a beta-testing event for our new intake & serialization system, and a lot of our software testing at the event was hindered by issues with our REV I2C Color Sensor on the onboard I2C port. That being said, the testing we were able to conduct showed great promise, and we began to learn little ways to improve our curve tuning. By the next event, Governor’s Cup, the intake was dialed in and we were able to maximize the robot’s targeting/scoring performance, and we ran it with great results at every offseason following. You can see the development of the curve over the course of the season - old was a snapshot from NERD, and new was deployed midday at River Rage and was used until the end of our season at Battle of the Bay. You can see the targeting in action here.



We attended Battlecry@WPI and Summer Heat this summer. The five ball auto and improved shooting led us to the finals at both events.

  • At Battlecry we played with 131, 2423, and 6324 and came up short in a close three-match set against 2168, 7407, 2265, and 3182.
  • At Summer Heat we played again with 131, and this time also joined 6153 and 8046 to win the event in another close 3-match finals series against 6329, 6328, 6329B and 2648.

In the fall we attended four offseason events (we are blessed to have so many opportunities to play here in New England)

  • At Mayhem in Merrimack we struggled through some CAN issues and problems with the new intake’s Color Sensor and ended up losing in the round robin on the 5th seeded alliance with 166, 501, and 1729. At this event we also fielded 9993 our swerve test platform with a Climber In a Box. This let us rotate more drivers and have twice the fun. It finished in the round robin with 5813, 319, & 1922.
  • At the Governor’s Cup, we went undefeated! We did a full iteration of the new intake, removed the color sensor, and it performed exceptionally well. We were able to seed first and select our friends on 131, as well as 4546, and cruised to a victory! We also fielded 9993 a second time to round out the event finishing as the third robot on the finalist alliance with a reunion with 5813 and 319.
  • At N.E.R.D. we captained the 8th seeded alliance to a win alongside teams 4909, 1768, and 5962! This included a triple climb of two traversals and one high bar climb to just barely eke out a win over the #1 seed in the quarterfinals by 1 point. Our second robot 9993 made the semifinals as the third robot alongside 1153b, 88, and 4473.
  • At River Rage, we seeded first, then played with 172, 4909, and 6324 in eliminations. In the end, we lost a close fought finals set to 131, 2262, 509, and 1474. The first round selections at River Rage are randomized, which often results in some team getting a very lucky first round pick, but this year the alliances were pretty balanced, and 131’s alliance pulled off an incredible triple traversal in Finals 3 to take us down.
  • We played our last matches of Rapid React at Battle of the Bay, in Alton, NH. We seeded first, picked our friends on 131 yet again, as well as 1307, and fought through a fun elimination bracket, including three close finals matches to win the event. This marked the third offseason event we won with 131.

We also had the opportunity to run students in all sorts of different roles at competitions that they do not normally get to perform, including new drivers, coaches, pit crews, and scouting teams. Going to seven off-season tournaments gave us a huge opportunity to grow the team, and we’re fortunate to have the ability to attend so many here in New England.

Design Activities

A few different design projects took place throughout the offseason including a modern re-imagining of the team’s 2013 robot, some 2022 robot redesigns, a new intake for the 2022 robot, and some 2013 frisbee intakes.

2013 Redesign “Decade”

The goal was to build a modern version of the team’s award-winning 2013 robot for use at Outreach events. Due to budgetary constraints, the robot may not get built, but the intention was to make something we could actually build. CAD can be found here

  • The climber, while a marquee feature of the 2013 robot, has no use in most demo events, and was scrapped for the project.
  • The 2013 robot had a single shooting angle, as it only ever shot from the back of the pyramid. The demo robot, however, is intended to be able to shoot at many angles. This allowed the team to try out designing a rack-and-pinion angle adjustment system, like the kind seen on many team’s hoods in the last few games. The rack was intended to be printed on our new Markforged Onyx One printer.

Additional CAD Projects

Intake Redesign

  • The intake redesign was inspired by 2910 and 624 primarily, and was intended to both be better at bringing in balls, as well as extend out less from the robot to reduce the possibility of entering the opponent’s frame perimeter accidentally.
  • The first iteration looked like the CAD screenshot below, and used a flip-up protrusion to pull the balls inside the robot once the mecanum rollers had centered the ball. This was inspired by 2910, but with some differences to fit this robot. Overall, it worked well in the shop, but had issues in real match play with pulling balls in and the small lexan plates shattered under defense.

  • The second iteration nixed the flip-up protrusion in lieu of a “tongue”, in the style of our original intake. This intake had some issues with the falcon shafts bending, as they were not supported on the other side. Thanks to 131 for helping us with some out of stock COTS parts!

More Offseason Activities

During the offseason, we attended a few new events to extend our reach into our community. Over the summer we had the opportunities to march in our town’s Memorial Day Parade and be a feature at the Pelham Old Homes Day where we demonstrated robots, let kids drive, and promoted FIRST to the community.

The team purchased a Markforged Onyx One and has worked to understand the best ways to use the new piece of equipment to its fullest potential. So far we’ve used it to print all of the pulleys on both iterations of our new intake using pulley designs inspired by 1678 and 3847, bearing retainers, and hard stops. We attempted some structural pieces with less success noting future 3DP designs need to be thicker or larger than if the same part was made using ¼” aluminum or polycarbonate. Overall we have been very happy with this purchase and will continue to leverage it in our workflow.

Finally, this fall we are kicking off our training for 2022. Our team has never had a consistent training mechanism in our 12 seasons as a team. This has led to wavering success as passing down key knowledge each year. Inspired by 7407 The Wired Boars 2011 Tube and 2017 Gear intake projects, we are challenging our students to build basic frisbee intakes from 2013 with the goal of collecting them from the floor and depositing them in a tote bin. So far our teams have started testing what wheels work best with frisbees and consider the basics of packaging with sketches. Over the next few weeks we will be teaching students how to use Onshape with some introductory lessons with the goal that in a few weeks we will have 3-4 unique designs in CAD with each student contributing to the design. If there is time in the schedule we hope to use it as machining training. The recent string of attending four offseasons has delayed our plans, but we are excited by this introductory step into design and prototyping!


This is amazing! Can’t wait to see what you all do this season! Cheers from 1153!


This is the build thread I’ve been looking forward to the most to date. 3467 is a class act and I expect we and many others will gain a lot from their contributions. Thanks 3467 for making this step to help the community and I heavily recommend bookmarking this thread for the season, they’re gonna cook.




Tentative Plans

We’ve been making some materials and design documents in preparation for the 2023 season:

  • Planned drivetrain (if the game allows) is the SDS Mk4i modules. We plan to use Falcon motors with the modifications listed in our last post.
    • Note: We won’t be purchasing any new Falcons from VEX if we can avoid it, and we’ve been able to purchase Falcons from some other teams that are switching entirely to NEOs to bolster our supply. If you’re a local NE team and have some spare falcons you’d be willing to sell us, let us know!

GIF added per OA leadership recommendation (it was @Connor_H you can thank him)

  • We developed an elevator design for the situation where the game requires an elevator. It is based primarily on the ThriftyBot elevator design, but with some modifications to use webbing instead of Dyneema cord, and a new constant force spring arrangement using printed mounting blocks for the springs.

  • Developed some training materials discussing elevator, wrist, and potential energy mechanism (catapult/kicker/puncher) design, since these are all categories of mechanism we haven’t had to use in a while

    • If anyone has good input on these slides, good pictures/videos/examples, let us know! It was difficult to find good documentation on 2014 catapults and 2010 kickers that used springs/surgical tubing
    • Also our technical knowledge on these subjects is not complete by any means, so if something in the slides is wrong, please comment so we know, and so do teams reading the blog!

Kickoff Plans!

We had a pretty successful 2022 kickoff, and we’re trying to take lessons from that kickoff and bring them into 2023.

The main theme of kickoff in 2022 and 2023 is the W-8

What Will Windham Windup Wield to Win Week Won?

Historically, 3467 has done poorly at our first event, which has often been the Granite State District Event (or regional). We often weren’t prepared for our opening event with:

  • no driver practice
  • mechanisms or code incomplete
  • and we were throwing things together.

These events weren’t very fun.

In the fall of 2021 we mapped out our history and this exercise largely confirmed what we suspected: we struggle when the season starts.

For Rapid React we decided to change this mindset and we made being ready for our Week 1 event our top priority in 2022. After kickoff in 2022, these were our takeaways:

And these were our assumptions:

These held up pretty well, and we hit most of our priority items for Week 1, as well as a few reach goals. In the end, what our priority list did was:

  • Give us a unified purpose
  • Solidified our scope in the first week of Build Season
  • Show us where to allocate limited resources
  • Accelerated our Build Schedule
    • Most W-8 required mechanisms were assembled on the robot by Week 4
    • We had ample time to wire & code
      • Code time was important with our first year of swerve
    • Maximized drive practice time - highest ever before our opening event
  • Let us have time to upgrade our shooter to the High Goal and Mid-Bar Climbers to Traversal in time for Week 1

Now we didn’t win GSD in 2022, but we still believe W-8 was the right stuff for us. It forced us to consider where the team was and make some hard decisions to delay upgrades or essential ranking point mechanisms until we guaranteed our team could play the basic game.

Hopefully we can come out of kickoff 2023 with a priority list and a unified purpose, and a plan to Win Week Won.


2022 season recap #silversonly


#silversonly for the win (or second place, i guess)

Little do they know all of us will be #goldsonly this year :wink:


Out of curiosity why do you prefer the straps over rope? Also, are the blocks that it’s on 3d printed?

1 Like


Some of our mentors have had previous experience with strap-based elevators and found they pretty much never needed to be re-tensioned, as opposed to the dyneema rope, which does need to be tensioned sometimes as the rope stretches.

Ultimately it’s a preference item, as the ThriftyBot elevator has a very nice system to tension the rope, but we feel we can make as-good of a system without the dyneema pulley kit.

And yes, the strap blocks at the top are designed to be printed out of Onyx, ideally.




We did a little bit of prototyping at the end of Sunday and found our roller claw prototype the most promising.

The biggest takeaway from it was that it’s possible to score sideways cones if you pick them up with a roller claw, and perhaps uprighting cones isn’t necessary!

Some resources we’ve been looking at this weekend:

Priority List

As we said in our last update, the plan for kickoff was to ask:

What Will Windham Windup Wield to Win Week Won

Priorities marked as “W8” are intended to be completed for Week 1. We expect to complete some items marked TBD as well, but which ones, we’re not sure - it depends how difficult they actually are.

Robot Concepts

  • Double Joint Arm

  • Tilted Elevator with Arm


  • “Walmart” Pink Arm (pnuematic extension, not pictured)

Robot Size

Heated debate on whether it’s more important to have the extra space to package more simple mechanisms to reach L3 Cones or whether it’s better to be smaller for bridge balancing but have a more complex mechanism as a result.

It’s going to be tight on the bridge with three “standard” width robots.



Double Jointed Arm

  • Very good at loading game pieces from Double Substation
  • Scores effectively at all levels
  • Very small, so probably good for balancing partners
  • Is it W-8 simple enough to have working for Week 1?
  • Floor intake is terrible, but it’s low priority

Walmart Pink Arm (WmPA, the “Gold Arm”)

  • Okay at loading game pieces from double substations
  • Scores effectively at all levels
  • Very small, so probably good for balancing with partners
  • Simpler than DJ
  • Floor intake is still terrible

Tilted Single Stage Elevator with Virtual 4-Bar

  • Decent at Double Substation and floor loading
  • More complex than Purple or Gold, likely difficult to get working for Week 1
  • Large by necessary, so poor at balancing



Software Update 1: Reaching Into the Cookie Jar

Cookie Monster GIF by Sesame Street - Find & Share on GIPHY
shoutout @jonahb55 for title/format inspiration

One of the primary strengths of the Double Jointed arm is its ability to quickly pick up from the Double Substation - which we’ve affectionately been calling the “Cookie Jar”. Since the arm can sit back into the frame for Cookie Jar intaking, we can slam the bumpers up against the wall for super-quick cycles without worrying that our claw would bottom out against the plexiglass behind. This seems to be a promising strategy.

While we have yet to commit to a robot archetype, one of the main concerns around the Double Jointed Arm shown above is the amount of software effort required to maximize its potential. To reduce some of the risk of building one, over the past 24 hours we’ve developed a simulator and basic controller for the DJ arm using the WPILib ArmSimulation example as a base. This simulation models gravity, inertia, current draw, and other useful metrics, includes a simple 2D visualization, and allows us to experiment with different control schemes for the arm.

GitHub: GitHub - WHS-FRC-3467/DoubleJointedArmSim: Double Jointed Arm Simulator

Some highlights:

  • Pertinent field components are modeled: double substation, mid and high rungs, grid aluminum tubing

  • Trapezoidal motion control is implemented through WPI ProfiledPIDController class

  • Multiple control modes:

    • Presets (Setpoint) Control (default): Move both joints simultaneously to the desired position. There are 6 positions, all shown in the video based on real field element dimensions and the real dimensions of the Double Jointed concept
    • Zero-Latency Software Four Bar: keeps the top arm at the same angle regardless of the bottom arm’s position. This is accomplished by setting the upper arm’s setpoint to negate the setpoint of the lower arm
    • Manual angle control (not shown): manually set each arm’s setpoint independently of one another
  • Gearbox, inertia simulation for both arms, weight simulation for lower arm

Caveats of note:

  • Gravity is not simulated for the upper arm since the WPILib SingleJointedArmSim does not inherently support a moving arm joint, but its inertia is simulated. In the grand scheme of control, this isn’t super critical, it just will affect some of our tuning.
  • The current motions for going from the floor to the node scoring positions pass through the grid elements - a simple but suboptimal workaround to this would be to program in an intermediate position that tucks the arm in before moving to those mid/high scoring positions. Watch for this in a future update.

This simulation seems to be promising in that the control for the arm is fairly simple - just two independent ProfiledPIDControllers running each of the joints. This simplicity is afforded by the assumption that we are only picking up and scoring on one side, and we’d just spin around 180 degrees in transit between the Cookie Jar / Loading Zone side of the field and the Grid / Community.

We hope the wider FRC community finds this type of research useful, especially if your team is considering building a double jointed arm or similar mechanism. If you have questions, or want to experiment with this tool, feel free to reach out!


Hi! I’m the lead programmer from FRC 997 in the PNW district, and we’re also exploring a revolute-revolute arm for our cone/cube placement.

Just out of sheer luck, I was challenged by our main programming mentor just before winter break to develop a control system for a 2-dof arm. And now we get to do 2-dof arms.

Our system isn’t quite finished, and is in fact lingering in a development branch of our library, but it contains one big feature I think could be of great use to most teams who want to maximize the time efficiency of their multi-dof mechanisms: configuration-space planning (configuration space is a space defined by the angles of the joints, not the end effector position).

Configuration space navigation could be a general solution to the problem you have with the mid pole blocking your farthest extension.

At this time, for us, it’s more-or-less just an optimized version of Dijkstra’s graph traversal algorithm through a set of predefined nodes which we place inside a valid (collision-free) space, although we briefly explored (pun intended) RRT or RRT*. There’s also talk about doing some small changes to paths to keep the center of mass centered (which I’m pretty sure 971 2018 did).

Pretty much the worst graph you’ll ever see, representing a very simple configuration space and nodes-- this would be considerably higher-resolution for anything we’d actually use.

Anyway, we’re more than happy to share our open source code (GitHub - Team997Coders/spartanLib2 at multiDOFMech), which we will be finishing and merging soon-ish. If you have any questions about the whole thing, you know where to find me (and our design team might be wanting to ask some questions the other way!)


This is super cool stuff! I’d never considered using something like Djikstra to traverse a graph of valid states for the arm. Thanks so much for sharing. Down the road I could definitely see us port the visualizer/simulation stuff to work with 997’s control scheme & kinematics.


Design Challenges

We’ve been heavily considering the Tinybot “DJ” Double Jointed arm design, and we’re trying to find design challenges we may not have considered yet.

Absolute Encoder Mounting

The current double jointed arm model has no good place to mount an absolute encoder. We can’t easily put them on driving shafts because they’re geared 2:1 from the relevant joint, so one absolute encoder position could mean two possible states. Ideally absolute encoders can tell us where the arm joints are to start the match with a high degree of precision, and they’d be 1:1 with these two joints:

However, those are going to be either dead-axle or MAXSpline shafts to transfer the torque better than, for example, a hex shaft can.

Our ideas are currently:

  • Add a set of 3D printed gears off the lower shaft with a ratio of 1:2 and put the absolute encoder on that shaft.
  • Use an absolute encoder on the lower shaft and use software to know which of the two possible absolute encoder positions is more reasonable
  • Find a good way to attach an encoder to the MAXSpline shafts
  • Use a potentiometer of some sort?

Any ideas here would be helpful

How Low Can You Go?

We’re a bit worried about our ability to maintain our heading and odometry going over the charging station during autonomous for various autonomous modes with a minimum height Mk4i swerve drive.

Current ideas:

  • Put the 2x1 atop the modules for more ground clearance (also raises CG and makes it easier for cones to end up stuck under the robot)
  • Use 1.5x1 instead of 2x1 for drive rails
  • Use a rolly bar!

The Struggle

math GIF


For cases like this in the past we’ve used 10-turn pots with great success


Potentiometers are generally better for this application in many regards. 3 wires instead of 4+, cheap to buy and replace, easily accessible, and a wide variety of mounting and sizing options. I’d stick to Pots if you are able to.


Weird concepts we’re probably NOT going with:

Single Joint arm on a Diagonal

Double Joint Arm on a Diagonal

Art Im Weird GIF by 60 Second Docs


You have to be careful here with the special extension rules this year. You’re only allowed to extend over one side of your robot, defined by the sides of the frame perimeter. If you extend exactly over a corner, you’ll be hitting two sides, which is illegal.