(Disclaimer: I know this topic has probably been beaten to death in the past, so I searched the forum for similar threads to try and model mine to be something a little different. Additionally, I use the word “competence” to describe my team’s robots in my post. The use of the word competence is not to highlight a difference in intelligence, but more to highlight the gains in success that is natural to every team as their experience increases. For all intents and purposes within the thread, “competence” is the generalized measure of a team’s ability to compete either for awards or with robots).
It’s been a while since my last post, and even though I’ve gone and graduated, as my college experience begins to ramp up, I’ve noticed how some of the takeaways from FRC have scaled up to my future aspirations of starting my own company by developing practical technologies for the future (whatever that may come to mean for me when I graduate).
That aside, I feel as though one of the major takeaways from FRC that is often left unimplemented by many teams is the idea of integrating principle to the design process. What does this mean? In short, to me, it means taking real engineering practices and combining them with FRC experience to maintain consistency in both growth and success.
Saying that principle is unimplemented by many teams does not mean that teams don’t implement design principles (one good example is to think of how many teams use the K.I.S.S. method to build their robots). In fact, most implement principle of some sort, but to say that any one team is entirely principled would be a poor assertion.
Example of the trade-off made between principles.
One example of how my old team would be both principled and unprincipled would be that we often strive to have simple mechanisms on the principle that fewer movements means fewer breakages. At the same time, we are unprincipled on the fact that we don’t use as much data to drive those decisions, simply: if it has fewer movements, it’ll suit us better than being a faster mechanism.
Bringing this around to the point of discussion, what, if any, principles can/would/is your team implementing for the 2020 season and beyond to maintain success without a bag day?
Furthermore, this question relies on the assumption that the lack of 2020 bag day has the possibility to significantly change FRC.
My own thoughts on the question.
Between my circle of friends, we have all agreed that mastering the transition to 2020 for team 234 would be an important one. Having seen some success into becoming a more competent and successful team with our design process (transition from 2016 to 2019, in which we went from using fewer principles to develop a coherent design to 2019 in which our implementation of consistency principles allowed us to win 72% of our matches).
One way we felt that it was important for us to be successful was to maintain consistency while making greater leaps in progress between events. This need for versatility would be a major technical draw, seeing how FTC compares from it’s first events to the world championship, where robot designs converge in many ways.
Additionally, for smaller districts like Indiana, Georgia, North Carolina: Teams at a similar competitive level to ours (best described as, “not a powerhouse but consistent”) it would be very easy to lose any gains made in competence by making too bold of changes and inevitably having a calamitous contraption that breaks down too often or is too hard to control to be competitive, meanwhile formerly unsuccessful teams make great strides because they had more time to flesh out a simpler design.
(TL;DR: We had a good past few years, so how do you make a good robot without getting a big head while also making big changes between events without the robot being destroyed?)
One idea we converged on was to make a more modular design while also meeting more often between events so that way we could do stuff like replace an elevator going from week 3 to week 4, or add a climbing mechanism going into the state championship.
Needless to say, that is one idea among many… what would your team do, if anything?