(There may be some exaggerations or incorrect bits of memory… But I never intend to do that.)
I’m a co-captain with 3 other co-captains in my team (2502). This is our third year.
Our first year, it was just maybe 10 students. No real mentorship, and no real direction. We just built whatever we could and felt like was good. All our reasoning behind supporting or discouraging a certain mechanism (drive train, end effector, etc) was based off what we “thought.” Some of them were true, some of them were false. We had the kit chassis running maybe by end of week three, and final robot running days before. Our end effector that year was 20 lb. overweight. All in all, we really lacked foresight, hindsight, and clarity in decision making. Everyone just went with the flow. Even though there were 10 people involved, effectively it was 2 people who knew what was going on and 1 person who programmed it. He’s now at MIT.
Our second year, it was maybe 20 students. No TRUE mentorship (but a LOT more mentorship than first year, a lot more knowledgeable mentors, a lot more time volunteered by the mentors, etc), but what we did have was the horrible experiences from first year that we wished not to repeat again. We got 4 captains (yes for 20 people :P). Our framework was that the team discusses and comes to conclusions as best as it could, but ultimately, the decision was made by the captains. (Note, not by the mentors). The 4 captains had many issues regarding pretension (I was the worst by far), personal goals/wants, miscommunication (I was also was the worst by far), but still, we talked things out, compromised and got a design out that won GM Industrial Design Award. So far we didn’t use 99%-Objective method that JVN has amazingly written out for FIRST Teams to use (and apply to every day life). We really could’ve. We should’ve. But we didn’t know about it. We learned a very important lesson: have some[one/people] in charge. Inexperienced team members and mentors make false assumptions and logical reasonings that are nothing but fallacies. (A LOT of the times though, they are correct, and even if they aren’t, they’re close or they have good intentions, or they err on the side of safety and rule-abiding). The 4 co-captains deciding what to do I think quiet a lot of the storms in terms of all the logical arguments and pro/con discussions about everything. No system will ever be perfect. It’s about building what feels the best to the team’s gut. If something simpler appeals to people’s guts, then build it! However, we didn’t have a clear idea of our final design by end of Week 3. Quiet a huge improvement from the Kit Bot running at end of Week 3 to having a clear idea about the robot by the end of Week 3. Moral of this year that I learned was sometimes you just gotta move on with critical decisions (of course, having weighed every option and every situation that the team could think of).
This year, it’s almost the end of Week 1. We have a clear idea about what our design’s going to be (decided just today!). That’s not because our team was able to transcend arguing (haha… not even close) but because we had more experienced members, more experienced members pointing out to new members that some things aren’t true and than their assumptions are just completely off the mark. Sometimes, it’s a jerk move, but if everyone’s nice all the time, nothing would really get accomplished. Leaders aren’t here to be marshmallows but rather we’re here to be the fire that allows marshmallows to be deliciously soft and warm. Sometimes, yes, your hands get burns, but it heals, and it’s not because of malicious intent. I have no idea about your team structure or team leadership or mentorship, but you really need your experienced members to step forward and share all that they know in response to false arguments (even if they don’t intend it to be false).
Last year, team 2502 was led by 1 senior and 3 sophomores. This year the captains are 3 same sophomores (juniors now) and a newly “picked*” senior. Us four, today during our meeting stepped up and questioned every proposal seriously with serious and questions meant to stumble them (not maliciously, but in the curious sense, as if we would build it; we need to have certain questions answered before we commit to it.)
For instance, someone brought up “Let’s do Tank Treads!” and we asked “So, how fast can that turn?”. Then we asked the whole team “Actually, is maneuverability something our team should rank high on our priority list?” Everyone basically said unanimously that it was important. If the person had good ideas on modifying the tank treads so it could turn easily, then probably would’ve went on further questioning).
Another person presented that our team should use crab drives. This makes me reflect the last year. As a sophomore captain, having only participated in 1 year of FIRST, I had no idea about pros/cons of crab drive. I was all crazy pushing for it and I thought it was the holy grail. But now, I know better. I was able to ask the person “Do we want to go over the ramp?” and the whole team also almost unanimously said “Yes we want to go over the ramp.” and then the person had ideas about having a high clearance on those crab modules. Then I asked him “Do we have the ability to machine those parts out?” (We don’t have a CNC or a CNC sponsor locally… And the WildStang Modules have pretty low clearance.) and basically the idea went down.
It seems that you support going under the tunnels. If this was in my team’s discussion, the following are some things that I would’ve asked
- How many other teams will rely on this tunnel?
- Can we design a robot that fits under this tunnel? (And still have it do other things?)
- Will there be tunnel-blocking robots we need to deal with?
- Why is it not worth going over the bumps?
- (I’m sure there are way better questions to consider than these)
Another argument seems to be about the end effectors (mechanisms that move the soccer ball). You seem to like a motor controlled ram. However, rest of the team (except programming) seems to like pneumatics. Your reason is that programming has never learned about pneumatics and would see this more fit as a summer-offseason-project. That is very valid. But also you have to ask them, did the building team ever use pneumatics? Do we have any mentors that can hook up a whole pneumatics circuit? Do we know how to turn on the compressor and use a regulator? This is where the whole team comes in to decide. Does your team want to commit the time that it takes to learn pneumatics? (We tested today and it’s really fast. It could break someone’s bones if we aren’t careful.)
If majority of the team’s willing, then it’s really difficult not to go with it. If you don’t have any mentors knowledgeable in pneumatics, there’s always us (Team 2502) that you can rely on (PM me). There’s also the WHOLE ChiefDelphi you could rely on. However, stepping back and looking at it, it really comes down to whether or not your team wants to commit the time. These decisions seemed to have made-or-broke our team in certain aspects throughout the competition. However, I asked this question during meeting today regarding pneumatics, “How likely is that someone will overlook a loose connection in the pneumatics tubing and have the circuit just leak air, thereby disabling most of the pneumatics?” and even the mentors really didn’t have a good answer.
Last year, we were really rolling as a team and come semi-finals, under the whole bowl of stress, we overlooked to tighten our jaguar connections. It came loose and paralyzed half the robot. It’s small questions like that I think help the most. “Even if we perfect Pneumatics, how likely are we like to overlook something really stupid and essentially throw away all this work?” There’s a serious tradeoff to be considered when doing something experimental verses traditional. Of course, I’m not saying that proven & traditional technology is always the best… since being innovative is one of the coolest things that a team and an individual can have.
As for the wheel discussion, you need to calculate how easy it would be to turn. Treads has too much grip, 2 wheel design may not have enough consistency. Some teams that I know are gonig 8WD with dropped center 4 wheels. I don’t have a conclusive answer. Our team couldn’t find any benefits but perhaps we missed something; afterall we’re all humans. What I’m trying to say is you need to plot out, figure out, calculate, and imagine how the robot would be able to move.
I went off on tangents a LOT, but in short, what worked for my team was more structure (but not crazy hierarchy…) and more power entrusted in to the captains to make decisions, especially if the whole team’s going to just rip on at each other for a couple weeks. Also during design sessions, our team listed every possible idea by number. The captains just read off the idea, described it briefly, and people started to list pros and cons. If there were any disagreements, people raised their hands. Have more organization and innate “protocol” and hold people accountable for the ideas they develop. Afterall, all it matters is that they get inspired and that they have tried their best.
- The captains pick new captains for graduating seniors because if it was open voting, it’d be way too politicized. Captains based the picking with merit, participation, leadership ability, and how much common sense does that person have ;). This was a very civilized process, at least for our team (We all “knew” who it should be…)
Oh man. It’s late here and I’m pretty sure I messed up something or said something in the completely wrong tone. If there’s anything inherently evil or bad about this post, let me know…
