2026: ?????; Captain: ?? (co26), Programming Cap: me, finally (co26)
… [fill in the blank] …
It all comes down to execution. Especially in FRC, when you really don’t have time to waste.
Let’s look at the mistakes from the last part:
2023:
- code issues (really, not enough testing time)
- the autos were not very reliable (also, we had localization issues)
- electrical issues (somehow no other team has as many electrical issues as we do)
- mechanical issues with the elevator
- the h-drive mechanism didn’t work
2024:
- the intake was badly-designed, so it was horrible to actually use and/or code
- the handoff was somewhat cooked because of the intake
- there were localization issues so we couldn’t shoot reliably
- no autos, and when we added autos, they weren’t really reliable either
- would’ve been nice to get more testing time
2025:
- weld broke
- intake was kinda bad
- fixing stuff on the telescopes was a pain
- we were a few inches short from consistent L4 scoring
- autos
- autos, again
- oh, and i forgot, driver practice. this applies to past years too
These can be roughly classifed into:
- programming team skill issuing
- localization
- programming team not getting enough time
- autos
- design team skill issuing
- electrical stuff breaking
- no driver practice
Two of these points can be directly attributed to our team being slow.
Design team skill issuing comes from a bit of lack of experience.
Electrical, idk, honestly.
Programming team skill issuing is kind of our fault. It feels like the solutions that work for everyone else don’t work for us… but really, that kind of stuff can be fixed by trying harder, especially on programming team. I’m gonna have to fix some of this during the pre-season.
But why is our team slow? and why is design team skill issuing all the time? I’m not going to blame design team here. Instead, I’m going to claim that we try to overcomplicate it all.
Other teams build swerves by bolting the modules to box tube with pre-cut holes. We CNC everything nicely with mounting holes.
Other teams zip tie the wires to random holes on their box tubes. We run wires through telescoping tubes.
Other teams copy, part-by-part, the sample robot they put online.
And they do better than us.
* * *
If we know we can’t execute like this, why do we keep on continuing to go like this? Supposing we have two options, continue doing as is, or build a kitbot, isn’t the obviously rational choice to build a kitbot? We we certainly have that option (and many more options). Why do the same thing, and expect different results?
Perhaps we believe, that we are better than last year. To be honest, we are not. I hope that is clear enough based on history.
The only real solution that I see (that is actually feasible) is to make a design that is actually executable (by our team), and execute it. in the simplest way possible.
* * *
Our team has a tradition of mechanical elegance. We like to CNC all of our parts perfectly, and whine whenver someone mentions manaul machining, or a drill. We go for the most elegant ways to do everything. Almost every box tube we try to perfectly design, weight reduce, machine, etc. Almost everything touches the CNC. And almost nothing gets built until we have a good 80% of our design set.
Sure, it’s pretty. But you know what the cost is? time. I don’t think mechanical realizes the full impact of all of this. But whenever they delay, programmming team suffers. Every hour at the CNC is one less hour programming the robot. And one week is simply not enough for programming the robot, let alone autos, driver practice, tuning, testing, etc.
41 has a tradition of captain being a mechie. Something about mechanical elegance and having to know mech stuff etc. No one wants to take programming seriously, ever.
* * *
It’s been said that 41 is better at shooter games. After all we went to worlds in 2016 (shooting balls) and 2021 (again shooting balls). I used to wonder why, but after writing this, it’s become more apparent. It’s because shooters are simple. Just an intake and a shooter. Usually one or two DOFs maximum, and simple DOFs at that. And our team can really only execute simple things.
Looking at it from an economic perspective, we have a comparative advantage in shooters. Why don’t we use it? In each of the past years, shooting has been viable (shooting cubes in 2023; shooting balls in 2025). Perhaps we would have done better if we did. Actually, IMO the best thing that happened to team 1923 in 2023 was that their arm broke, so they were left with a cube shooter. They never fixed their arm, because they never needed to.
Maybe 2026 will be another shooter game. But maybe it would be better if it weren’t a shooter game, but something like 2023 where shooting was still viable. Then we’d have an actual comparative advantage.
Looking at this through comparative advantage is actually pretty insightful, I should do this more.
re: recruiting. The long-term solution to this problem isn’t exactly the same as the short-term solution. In the long term, we really need more human capital. This (plus the simple design) is what got us to worlds in 2022. And having one or two designers, and one programmer, and half an electrical member just isn’t going to cut it. Especially when your only designer is a sophomore.
We tend to scare away a ton of new members, especially in the first few weeks of build season. The main reason is the time commitment needed to actually be a productive member of the team. If you’re not here for like 2 hours * 3 days / week, you don’t even know what’s happening, and to actually contribute you need to be here for more time and have more expertise. (Note: each subteam also has less busy / more busy times, so it tends to be less time for most of the season and a burst of a few busy weeks. Although newcomers really don’t know this.)
A lot of people end up standing around with no real contribution, and really it’s hard for them to contribute (especially when you don’t teach them enougn in the preseason, cough cough programming). And we know it, and they know it. So they prefer to just leave.
* * *
To be honest, I’ve thought about leaving several times. I was advised by multiple (highly respected) people to quit robotics (according to one: “why are you still in robotics? it’s basically a part-time job”), and to be honest, it is not exactly a very high-EV activity (especially for college applications). I really stuck to it because of some combination of liking it, sunk-cost fallacy, responsiblity (what would programming team be without me?), and probably some other reasons I can’t immediately recall.
Actually, a rough rundown for me, personally:
Reasons to leave:
- i literally have to be there like average 6 hours a day for 5 days a week, that’s 30 hours
- my job as a programming lead is not that interesting, to be honest. Most of the fun stuff is done for you in a library. (for this reason, there is actually an ioi gold medalist who does mechanical work on his FRC team; sometimes I wish I did that too)
- our team sucks. and honestly, I went into seasons half expecting the same thing to happen. and it did
- being on programming team sucks when you have a week to code everything and everyone expects you to make it work
- There are other things I could do with the time. Like grinding olympiads
- it kinda sucks not to be captain too, especially when you are doing more than said captain
Reasons to stay:
- i like robotics.
- sunk-cost fallacy about value (for college apps and in general)
- i learn stuff (sometimes, and not frequently enough to justify staying IMO)
- if i left, the rest of programming team would be left to do everything without me. (perhaps they should learn the lesson the hard way…)
- Mr. Hadzic is there. And MK and LXM. <3
- I somehow delude myself into thinking i can multitask (i can’t)
- other reasons I can’t remember right now
Anyway the team is pretty damn lucky that I didn’t leave.
For most people, the cost of robotics outweighs the benefits. And a significant portion (\approx 5) of the people who still do robotics do it outside of our school. These kids tend to be pretty strong, too.
* * *
Programming used to have a recruiting problem when it became clear to the new members that the veteran members would write all the code, and like 10x faster than them too. At least, during this preseason, it’s getting better (the solution: I tell people to code stuff while I play tetris). Even then, it looks like it’ll be rough after I leave.
Design and electrical don’t really get members in the first place since CAD / wires are kinda boring.
Mechanical gets a lot of members. And there’s almost always a good amount of people who know what they’re doing.
We definitely need more programming and design members. More electrical members is nice but not as critical.
It’d be nice, from a recruiting standpoint, for our team to reduce the amount of time we spend on robotics. Giving the new members something to do helps, too. Also, it’s nicer when you win.
Well, I hope this was a pretty good glimpse of our team, and what’s been holding it back. Hopefully, some of these issues will be resolved in the near future.
If not, failure is certainly not a bad thing. After all, high school is a time to make mistakes, and I certainly wouldn’t have learned that much (or written this blog) if our team was 118. But hopefully, 41 will learn from its mistakes.
One more thing: I (again) apologize if anything is inaccurate, or just skewed by salt. Also, I’m not trying to blame anyone here, I’m just trying to point out our team’s problems, so I apologize if it looks like I’m blaming anyone. Except when I’m blaming myself.
I’ll probably take a small break from blogging after writing this (wow this is a lot). See you after uc apps, probably.
