A Split Team

I am a co-captain of my high schools FRC team. On day 4 the team collectively decided (voted) to build a robot that had an elevator on the front to deliver hatches, and a different undecided mechanism on the other half to score cargo into the cargo ship and the lowest rocket bay. However after seeing a couple of RI3D teams members realized that it wasn’t as hard as previously thought to build a mechanism that manipulates both cargo and hatch panels. Their idea was to put a manipulator onto the elevator that we planned to use for the hatches.

When they brought to their idea to some of the mentors the mentors said basically said “we have already decided on our general design”. However the students believe that this could be a beneficial change to our robot.

I however don’t really know what to do. My co captain has a parent that is a mentor, and lets the parent push them around, so they are on the mentors side of not changing the design. I am personally on the side of the students, but i don’t want to appear to biased. Any Ideas on how the students and I should handle the situation.

You essentially have three options:

  1. Re-vote with new information. I suspect that that won’t go over well at this point.
  2. Persuade/executive decision to change the design. I’m not sure you CAN do that cleanly at this point without making it worse.
  3. Continue with the current design, knowing that it could be better.

Take Option 3 right now. HOWEVER… If you have any of the students who have ideas about that mechanism who happen to not be doing anything else productive at the moment, have them start working a prototype. The emphasis is that you’re trying something that might improve the design, and can be implemented relatively quickly. If you do get a prototype that works decently, then the mentors can either change their opinion or not–if they don’t I predict that you’ll want to have a conversation after your first district event if things don’t go very well.

And the reason I’m saying to go with Option 3 is this: In engineering, once you have started down a path of building a particular design, you really don’t want to change unless you absolutely have to (for performance reasons, or other issues coming up). But you can always make changes later, iterate after deadlines pass, and call it a new revision/generation.

5 Likes

Unless there is a set design with parts already ordered, etc. then it doesn’t really hurt to change overall designs this early in the season. Most teams are just now finishing initial prototyping anyway, so a lot of teams don’t really have things to “change” yet. So from a season benchmark, things are fine there.

Our team initially decided something on kickoff day that we’ve since re-thought and now have a completely different design. We’re a week in and feel that we have a better understanding of the game and of what our team is capable of, so everybody feels it was the right decision to make (or at least, nobody has publicly said otherwise).

As someone who used to be co-captain of his team, I don’t think it’s wrong to stick up for the students on this. Be prepared to make compromises though, since the last thing you want in the heat of build season is to create a rift between your students and mentors and ultimately ending up worse off than if you went one way or the other in the first place.

This same basic thing happened to my team last year. We had a divided team 80% of the team wanted to go for the scale and the 20% wanted to be more and go switch/vault. This took 3 week (yes 3) of arguing and conversation until we decided that it was smart to go low. It happened to then be our best season with basically 3 weeks to build a robot.

This is a bigger question around team dynamics. Every team is different so I don’t want to push something that isn’t possible or can’t work for your team. And if this doesn’t exist right now, it’s going to be a very bad time of year to make a similar change on your team, but read on and keep it in mind for next year… It doesn’t exactly fix your issue this season, but your situation could be a catalyst for this kind of a discussion.

A number of years ago (6-7 maybe), our team switched from being a primarily mentor-driven team to being a fully student-led, student-run team. Mentors are still around for safety, general guidance, bounce ideas off of, and the like, but we (try) not to get in the way of what students plan for or design or build. Mentors are still responsible for a number of things relating to keeping the team running and whatnot, but the students ultimately do the majority of fundraising, team recruitment, robot design/strategy, Chairman’s design/prep, match scouting, etc. We even have only students on the drive team, no mentor coach anywhere. (We sometimes help strategize in the pit, but the field is all for the students.)

It was a big culture change on the team, but ultimately I think it has been a positive change. Students learn more and are more engaged than when just doing what the mentors used to tell them to do. It’s also a point of pride for the students when they look at the robot that they designed, CAD’ed, build, and competed with (and even sometimes win with).

Again, this isn’t the kind of thing you necessarily have the bandwidth to bring up at this point in the season, but consider it for later. If you have any questions about how our team works, just send me a DM and I’d be happy to discuss it. I could even put you in touch with our student leadership if you want to hear their side of it.

1 Like

Well, Thanks to all of your feedback to my questions so far I will most likely dm you @nicfouts, and i will try to get the students that want the design change to start prototyping. Once again Thanks.

1 Like

There’s a quote from JVN that I’ve referenced before:

“Voting is not an engineering process. We will never vote on a design.”

Every team is run differently. I don’t know what exactly what goes into your vote, but I urge you to think about better ways to handle this in the future. Our team uses a combination of things. I would look into the Engineering Design Process. Our full team goes through the process, and ultimately our design team (experienced team members and mentors) decide what best fulfills our requirements based on all the data presented from the full team. Here are the first few steps we use: Define the Problem, Generate Requirements, Rank the Requirements of importance, Brainstorm Design Concepts, Prototype Design Concepts, Choose Concept. As we learn more throughout the process our rankings may change. There are a lot of tools that can help you as well. We have had decent success using a Pugh matrix.

5 Likes

I cannot agree with this enough. Data and facts do not care about anyone’s feelings or “hunch”. Empirically prove if it will work with prototypes and pictures/videos of previous robots that use similar systems.

In my opinion (so take with a grain of salt), mentors are present to educate, guide, supervise, and serve the students. They are not there to make the decisions, but to mediate the decision making process. If something was the leading idea, but a better more valuable idea was discovered, it would be a disservice to the team to not adapt to the new, more valuable idea.

The only caveat is when there is no longer enough time to pivot from the previous idea to the better idea. Only attempt what is within your team’s capabilities if you actually wish to succeed. Which involves knowing your team’s limits.

2 Likes

I would also recommend trying to have private conversations with mentors on why this is bothering you. If they feel less confronted about it, it’s more likely they will consider an alternative.
Also +1 on having students prototype. Having two (or more) different ideas developed and then deciding on a final path has actually been a really great way for our team to allow all ideas a full chance.

2 Likes

our team votes and the mentors have the same voting weight as the students.

There have been times when I think we’ve built the ‘wrong robot’ but I also have a slide that says "who in this room knows what sort of robot will win this year? " None of us.

I never know what the robot we might’ve built would’ve done, but I can know that the team picked the robot after building the best proof-of-concept models we can and watching them, timing them, and observing them trying to do the actual tasks.

So to me (an engineer) saying ‘engineering decides’ implies that engineering knows more than it does.

Have you asked the mentors why they don’t want to create all these additional mechanisms?

Just to play their perspective as someone who has been a student on a team and now a lead mentor:

Designs do need to be “locked” but they can also be sorted by prioritization. Basically we create a “need” and a “want” categorization for all mechanisms and tasks. If a task if further down on the needs list, it is prototyped later in the season, or saved for unbag.

Have your mentors and your team had a realistic discussion around your team’s skills, knowledge base, capabilities, funds, and time that can be put into the season? Many times, mentors have more realistic views of a team’s limitations (many times they don’t) but don’t want to say “no” to a kid with a good idea.

Maybe they learned to do less from your previous seasons?

Not to pick on your accomplishments, but just going off of The Blue Alliance information, your team did not make eliminations at either of your events last season, nor the season prior. Now, does this mean your robot was necessarily bad? No, there’s plenty of factors that play into this. But more than likely, your mentors saw that you should probably bite off a little less this season and focus on specific goals and tasks instead of going for too much. This is something that takes teams seasons to realize, and most teams in FRC still do more than they should.

But, approach this problem this the following in mind:

  1. Focus on our “need” category tasks first
  2. Build on top of your mechanisms once the “needs” in #1 are accomplished (in example: “We MUST be able to score a human loaded hatch panel on the lower goal”) vs “Score on low and middle goals”)
    In this situation, make sure your solution for the first goal is met before moving onto the second goal.
4 Likes

Having been a lead student on a team, and now a mentor, here is my advice.

Iterative Design
If you have the student resources, I would definitely work on creating a prototype. Also, see if you can create something that would work off the elevator. Then, if you have time, you can attach it to the elevator. That way, if you don’t have time to finish, you still have some cargo manipulator.

Do it great before you do it all
Often when we look at some of the top tier teams, we say, “Wow, they can do everything amazingly”. Unfortunately, we get caught up in the everything part and forget what matters. Making a robot do one thing great will out value doing everything somewhat well. It’s possible mentors are concerned about putting too much on the robot immediately. One of my fellow mentors recently reminded me that “It’s easy to get the first design down for something, say we got it, and move on, and completely put off the first design until the end of build season.” This can be very dangerous, as it undermines you original idea. Get something working well, then move to the next design.

Maintain relationships
As a student leader, one of my most important roles I had was to maintain student and mentor relationships. Breaking the relationships is the easiest way to wreck your team for the season. Make sure you bring up your concerns to the mentors, and talk it out. Mentors are not your enemy, and FIRST was build on working with your mentors, not doing everything yourself. I would hazard to guess that they want to focus on the hatch mechanism, get it assembled, and tested before even touching a cargo mechanism due to team constraints. Learning what they think is very important, and maintaining that relationship. Since your team is split, it’s your job to seal that as soon as possible, with the help of your other leads and mentors.

Feel free to reach out to team 1646 or myself if you have any questions about the above. From one Indiana team to another, good luck during build season!

1 Like

Additional to my earlier comment,

  1. We’re a week in. All brainstorming is done. All prototypes should be done. (proof of concepts–we use the word ‘prototype’ wrong in FRC)

  2. You should’ve had a chance to measure the performance of these against each other.

  3. There is a point where you gotta ‘fish or cut bait’. You need to shake hands, agree and build “The Robot” with the ideas that have been chosen (however you choose)>
    people building other things after that point (yesterday for my team) are wasting the teams resources and time. Why didn’t you build your prototype in the first week? You could’ve compared it with what’s else has been proposed.

  4. This is the best way to not make your build schedule. I’ve seen it before.

  5. Also, dissent within the team is a killer. You need to be a team. Working toward one goal. Every team has a process and hopefully it’s written down. And in every case, there’s a time when you’ve decided the robot and people need to agree.

A lesson we learned from 558 is that you should always consider nuking what you’ve built so far in any given season and go in a different direction. In 2017 and 2018 we removed and replaced huge subsystems on our robots (sometimes mid-event) and been remarkably more successful because of that willingness.

This can be a dangerous decision, depending on a team’s design/fabrication capacity.

Definitely agree, minus the word “nuking”. We got burned last year by completely disassembling a mechanism we wanted to replace, then realizing there was an easy fix a week later. Unless resources are low, keep that you have made available in case the new plan goes downhill or you have a new realization about the old mechanism.

1 Like

To give background into what has happened during our meetings during the week. We have made proof of concepts for a hatch panel manipulator, cargo manipulator, an elevator and a climbing mechanism. We have also started programming our drivetrain (mecanum). We have pretty solid proof of concepts that work, and the plan was to vote on what mechanisms we will most likely use tonight. The group of students hasn’t built the prototype that manipulates both game pieces yet, but still want their design to be shown off. However the mentors don’t want to change the design that we had already “decided” on.

Are you trying to run mecanum and an elevator?

Yes, once again a flaw in our voting system we narrowed down our drivetrain sources to tank w/ pneumatic wheels and mecanum. Mecanum was chosen for the increased mobility, we tried to explain to some of the mentors and people that wanted mecanum what browning out was, but i don’t think they fully understood.

We ran a mecanum/elevator lift in 2011, which was a very similar game to 2019 if a team chooses to focus on the Rockets. We were pleased with the results.

It is good to have healthy disagreements on what the best manipulator(s) might be. Spend the next few meetings (and time outside meetings) getting really good prototypes done, so your team can make an informed decision. Be careful not to take away key resources (materials and time) from other priorities.

I am Looking Forward to what you guys will bring to Tippy!
Good luck.

2 Likes