They’re these 3D printed quick build blocks. @Billfred linked them above already, but I figured I’d clarify too 
1 Like
There’s a lot of really great advice in this thread, so instead of echoing it I’ll just point to this one thing: 9 hours a week is a very small amount of time, well below the norm I’ve seen in FRC. Across many teams (not just CD teams), 20-30 hours per week seems to be pretty typical, for average teams up through world champions. Adding more time to a broken system won’t help, you’ll need to find a way to also implement other advice in this thread, but it doesn’t surprise me at all that your team moves slowly when you’re meeting so little.
One thing I’ve noticed both with my own team and by talking with better teams is the value in long meetings. My team seems to be more productive per hour when we meet for 6-7hr on a Saturday than 3hr on a Wednesday. Your mileage may vary.
Today seems like they day I repost links that have already been posted, but I’ll do it again! I’m having my (fairly new to FRC) captain participate in a little book club with me where we go through the JVN 2018 season blog. We’re going from “The Pact” through to “2018 Championship: recap”. I find the structuring and timeline, while maybe not 100% realistic for a young team like we have, very very helpful to contextualize targets for students.
While on the note of giving students JVN blog posts as homework assignments, all mechanical students read The Weak Robot Cart and write a (very short) reflection that we then sit down and discuss as a group. We also read JVN’s Priority List 2019 as a reference frame for “hey maybe we shouldn’t try and make a crazy complex robot”.
@JVN, thank you for writing your blog! It remains hugely influential to how we run 7525
4 Likes
OP, my team found ourselves in a somewhat similar position after the 2019 season. We systematically failed prototyping for that game, and it showed in our robot performance that year.
What worked for us is leaning far in the other direction. We prototyped a lot during the 2020 season and it definitely paid off. Here’s some tips:
- If you can, encourage prototyping as a team wide activity.
- Nail down goals for what you want to accomplish with your prototyping.
- Recognize that not everything needs to be prototyped, things like shooters, intakes, and conveyors are good to prototype, but arms and elevators are less important (possibly too complicated to effectively prototype)
- Document! Document! Document! I cannot stress enough how important documenting your prototyping is. Our kids are trained to take pictures and videos of everything they test, and record the results.
- Use prototyping systems such as Spectrum Prototype or Thrifty Blocks as mentioned early in this thread.
With all of that being said, a common theme I noticed in your post is that your team may not have the resources in terms of time, manpower, or money to prototype effectively during the build season. While a healthy long term goal would be to reshape the team to address those resource gaps, in the short term I have some suggestions that may benefit a team in your particular situation.
My favorite innovation in FRC the past few years has been #openalliance. This is a collective of FRC teams who document their build season and share their findings and CAD. For prototyping in particular, this a highly beneficial resource because a lot of FRC prototyping is figuring out the “magic numbers” which allow certain designs to work regardless of how they are specifically constructed. Some examples would be:
- What compression does an intake/conveyor/shooter need
- What arrangements of wheels works for an intake
- How does any given game piece handle
The best Open Alliance teams are testing this stuff and posting extensively about it, which can allow you to skip prototyping by borrowing their “magic numbers” and instead focus on design knowing you have a solid foundation to build off. I would recommend you check out Open Alliance posts generally, however here’s some specific teams to check out:
In addition to Open Alliance alliance, your team might benefit from looking at the EveryBot program. Everybot is a bot built by mentors from 118, where the goal is to design a cheap, easy to build robot what would be a benefit to any alliance. They realease a full CAD model, Bill of Materials, and build instructions every year. Many teams have found success copying the EveryBot initially, and iterating on it to suit their specific needs and goals.
8 Likes
I’m the OP I just wanted to say something quick. I’ve presented resources like the Open Alliance before and before even looking at it they ask me what kind of teams they are. They just claim that all the online resources consist of teams that are out of our reach and refuse to use them. I don’t know how to convince them. I’ve tried to say that these teams break down their design process and thought process for teams not as good as them, but they don’t really listen. I’m the only person on the team who uses any online resources, everyone else is in an isolated bubble. Their first time seeing other designs are at our first competition. This also leads to the problem of thinking the original design is good because they’re so isolated.
What we have here is a failure to communicate.
The teeny bit of advice I give my students: Communication is much less about saying the things that are true, and much more about implanting true ideas in the listener’s head.
How to do this? Start with listening. Understand them - what their motivations are. What they like, what they’re afraid of, what brings them joy. Then form your message around it. Show how they benefit from changing their minds.
This is all way easier said than done, especially when there is frustration. And you’ll wanna take what I say with a grain of salt - other than what’s been shared in this thread I know nothing of the details of the situation. Still, from what I can see, it does seem like the roadblock isn’t the availability of resources or time or effort… it’s the individuals who are struggling to see the optimal path in front of them. Assuming that is an accurate assessment - work it from that angle. Address that root cause, and see where it gets ya.
Best of luck!
5 Likes
I appreciate the additional information.
What you have here is a classic difference in program goals/outcomes:
- Your goals might be something like, in order to do well, in order to improve, I need to build on the knowledge of others. After all, there’s no need to reinvent the wheel.
- Their goals might be something like in order to have pride in the robot, students need to figure things out themselves, looking at other teams is cheating and detrimental to learning.
Here’s the the thing, nobody here is inherently wrong or right, you just disagree. I’ve been in a similar situation. I had someone on my team tell me verbatim, “I don’t care what other teams are doing”, which to me is almost alien speak.
To solve this conundrum my advice would be to sit down as a team and really hash out what your program goals/outcomes are, which can and should involve compromise from both sides. Only then can you expect to move forward, together.
As an aside, Gerthworm’s advice is also sound, often times the delivery is almost if not more important than the content when presenting a new idea.
3 Likes
If you have a minute to waste, click to display (I like everyone else’s posts better than this one):
TLDR
I’m reminded that at one of my jobs I happened to sit next to the group that tore apart every little detail - wire, screws, sheet metal, motors, everything - for all the competitors’ products.
This also sounds like my wife’s father whose motto, that he always stayed true to, was “Don’t bother me with the facts; my mind is made up.”
I’ve talked with several nearby good teams and one of the best in the world isn’t too far from our location. I can assure you they all started modestly - not as good teams - and built on each year’s mistaken designs and good designs of theirs and others.
I had the pleasure of having a student team member recently who wanted to learn and he learned from every source he could. He took every scrap of information and synthesized his own conclusion and plan of action. For example, there are a plethora of excellent free OpenCV tutorials on the Internet. The student bought with his hard earned money (he was willing to work food service and that included taking out the garbage) an OpenCV tutorial just in case the purchased lesson had some tidbit that he hadn’t found elsewhere.
Other students being the opposite of his quest for all knowledge wanted to discover stuff on their own (a variation of reinvent the wheel). If I suggested something, you could rest assured they would not do that idea. I had to be sly and I’d suggest a bunch of options but omit the one I thought best but maybe allude to it very, very gently. With the possibilities greatly reduced they could discover that better option (I thought) on their own and use it.
There are some “team” resources on the Internet such as:
The 4 Things Resilient Teams Do
https://www.monster.com/career-advice/article/5-ways-to-be-a-good-team-player-hot-jobs
2 Likes
I just recently finished my fourth and senior year on 696, and during my previous three (really, two years because of COVID), I can say we definitely had similar iterating and performance problems.
I will say in terms of specifically getting prototyping and testing cycle times down (design + build + review = 1 cycle), you must change the root of your team’s culture.
My Experience In The Matter
On our team, 2021/22 was a complete sh**-show of what we had done before (and what I was used to). We had two new lead mentors after recently losing our previous one, had almost ALL rookies as covid set us back a year, etc. Although this seemed daunting to us at first, my mindset leaned more towards “This is a great opportunity to change how this team operates from it’s core”, rather than “how can we restore the previous 696?” There were things that I had seen in prior years’ leadership that I did not like and wanted to change.
Taking this opportunity, it was as simple as deciding from a leadership point that the team needed to iterate more quickly. We changed policies like:
- Weekend field setup and testing (we have a gym shared with school), to Field set up any day we needed testing. We’ll stay the extra hours to set up and clean up in one day.
- Failure is GOOD. In fact, we tried to avoid referring to things as “failures”. The team adopted a mindset that each failure was actually one step closer to success, which it literally is. So, if prototype X “failed”, it was really that “prototype X needs improvements in A B and C to get us closer to goal D”.
- Extremely important: we tried to make robotics MORE than just robotics. Another one of my goals was to make the team not just a robotics team but a small family of kinds. This really boiled down to wishing good for your peers and building trust; not to mention having FUN! We did somewhat throw out this very professional, bureaucratic previous 696 with little “jokes and screw arounds”, to a still professional and bureaucratic 696 but with leeway for jokes and fun (like sliding around the gym floor on furniture dollies late at night).
- Last point: I felt like the team understood itself as “a small group of highly motivated kids who want to achieve great things and have fun”.
All of this lead us to build 696’s highest performing robot of all time this season.
Back to your case
Your team’s performance problems, in my opinion, really end up boiling down to culture and leadership problems. To change culture, you have to change how the team is led. Here’s a decision “schematic” I would use in your shoes:
Decision 1: Can I move into a leadership position to change the team’s culture?
If yes: Do it! It won’t be easy but it will be extremely rewarding to you and your teammates.
If no: Decision 2: Can I influence current leadership members to change team culture?
If yes: Do it!
If no: Make the most of your current position. Learn technical skills and push yourself to your limits with what situation you’re in. Remember, if you can’t control it, don’t stress over it and make the most of what you have.
5 Likes
Here I am again, lol! I guess my last post wasn’t my last.
I have a few new thoughts after reading through the OP.
First, the new stuff, I understand your frustrations, and I can relate to what you are going through. I have been on teams where some teammates think that “they know it all,” and then people refuse to research and try to develop concepts for future years. This is a dangerous mindset to be stuck in as it can easily lead a team to not being as successful, and then this leads to a demotivated team. Again, with the listening portion, I HIGHLY recommend going down the path of “Hey, it really wouldn’t hurt us to try other things rather than staying on one idea.” In my experience, this method is incredibly effective as at the end of the day, it is the duty of a mentor to provide an environment for students to learn. If this doesn’t work, then cite times in engineering history where multiple designs led to a more sound, refined product. I would also suggest bringing up the engineering process and linking this to the design thinking process of how it is essential for one to prototype to attain the best product.
I must also say that I have fallen victim to this as well where I think what I have done for my team is something that allows us to perform at a higher level of competition and then I refuse to iterate, but one thing that humbled me immensely is watching my team perform poorly. This kicked me in the butt and allowed me to research other ideas. I recommend you note this to your mentors on how idolizing one design essentially has proved to not work in the past, and then bring up how you could do a team rebuild as all the seniors who took all of the work left this year. I think it is a perfect time for you to consider making huge strides on your time and putting your foot down on ideas; again, be calm through this process. It may increase tension within the team in the short term, but it might be more beneficial in the long term.
The reason why I wanted to conceal my identity was that I didn’t want my mentors and teammates to know it was coming from me as I didn’t want to have the slightest chance of being a poor reflection of my team by saying anything controversial if I did.