Team Argument!
 

Hey everyone. Well, as we all know it is well into the build season with the deadline fast approaching and since I am on a rookie team we hardly have the grasp of the gravity of our situation. What makes it much worse is a big argument we have been having and can't put behind us.

Here's the issue, when we were starting brainstorming ideas for this year's robot we had a couple ideas that people felt passionately. They were "Wheel", "Auger" and "Dual Conveyor". As a team we decided to pick "Wheel". The problem is, our lead mentor was the one who created the auger idea. Now, when we decided against it her figured that we just didn't understand it. So he decides to take his son and ONE other student and develop it as a "backup".

We thought that was alright as long as this was outside of the time we worked as a team and that it would ONLY be used if our first choice didn't work. Well, he calls a meeting today declaring that once we are done with the build season we are going to have a performance test the two and pick the one that works best, which is totally hypocritical to what he said in the beginning of the meeting which is that FIRST isn't about winning or losing.

I raised my hand and voiced my opinion that if we decide to pick the Auger that everyone who didn't work on the team would feel totally alienated because they had no help in making it. I said that I would rather lose miserbly with the bot I made, then win it all with a bot I had no help on.

I didn't make this just to air out dirty laundry and for you guys to back me up. I want to know how you guys handle back up ideas, do you just pick an idea and go with it or do you make two robots and pick the best one. Another big issue with this is that they have split our total funds between these two robots. What do you guys think?

Re: Team Argument!
 

Every team I've been apart of has been all or nothing. No middle. You pick a design, then you build it. Sure, you may draft a couple of ideas, you may prototype an idea or two, but you only build one. Otherwise, your wasting both time and money. Some teams may have the luxury of building two ideas, but I've never been on one that could. Good luck on sorting it out.

Re: Team Argument!
 

That's my feeling. He has it in his head that we have enough time to do both and we barely have enough time to do one. He's telling me to start working on "Auger Code" and I said "No, I'm not sabotaging our team"

Re: Team Argument!
 

Personally I feel that this problems should have been dealt with almost four weeks ago. When your team brainstorms ideas, it's great for everyone to defend their ideas while they develop them, however, when you start to make decisions on what will actually happen on your robot, you need to get everyone to realize that it no longer is their own idea, but the teams idea and it may be turned down. For my team, we brainstorm in subgroups, then we get together and present the individual ideas to the entire team, then we make everyone do a physical motion to signify that they no longer own that idea, but more so it's a team idea from that point forward. If, however, there is an idea that we want to keep just in case, we put it on the Put-A-Side list. The Put-A-Side list is a list that stays on the main white board where all dormant ideas stay. While on the list, it doesn't mean we will do the idea, or that we won't do it, it just means that we are focusing on other ideas before looking into the ideas on the list. Let us know how this situation turns out, sorry you had to deal with this on your first year.

Re: Team Argument!
 

Oh, I love mentors for what they do, but they can certainly be overbearing. This late in build season, I would suggest doing whichever design will be finished the soonest. It is a tough decision, between what you made yourself and what may be better for the team. Do whatever you think is right, try to get a many students supporting it as possible.

Re: Team Argument!
 

We pick one idea to stick with for good about two weeks into the build season, although I do admit this year for us is a bit of an exception, but it was acceptable because the two designs are quite similar and come from the same idea that was agreed on.

I don't know about other teams, but our team votes as a team for what we want, our mentors can voice their opinions, but our students are the ones that decide, then we focus all of our resources on the idea that is chosen. This is mostly because our team is student-run for the most part. If you want the students to play a major role in building the robot, then the students should be the ones deciding, and in my opinion, the mentor should respect the decision made by students.

Re: Team Argument!
 

I can tell you that your situation is by no means uncommon. I've been around since 2005 and almost every year our team has had some sort of conflict over design but it almost always is before we make our decision.

It's important to make sure that once you settle on a design as a TEAM you stick with it. I personally do not support your team leader working on a separate design as a back up. His time could be better spent making spares for the team approved design. If you were in the prototype phase then sure, if he wants to prototype a different design then fine, but once it's time to work on the final design, you can't have people second guessing that.

I feel the same way that you do when it comes to "you'd rather lose with a bot you made then win with someone else's." In 2006, we didn't build an elite robot, but it was a solid team effort and I'm proud of it.

Don't forget that your team leader is a rookie too. It's going to take some time for him to learn how to be most affective in that capacity. He will learn a lot from the past Woodie Flowers Award winners at FLR if he takes the time to talk to them.

The best thing you can do is get a sense of how the majority of the team feels and go in that direction. I know it may create some tension between the groups but in the end you are all on the same team and it's too late in the season to still be battling over designs. You guys need to get united together cause if your team leader is really concerned about winning, then a united team behind a common effort is the only way that's going to happen.

I can't wait to play Lunacy with you guys at FLR and I know that you and your team can overcome this and have a successful season. Good luck and see ya at FLR!

-Justin

Re: Team Argument!
 

For the FTC, we had about 5 ideas swirling around, and mine was picked. Not by the team, mind you, but the logistics coach. On his own. In one day. Once I saw the new kit of parts, I didn't like my idea. We still went with it. With only two weeks left, we (myself and two or three others) realized that it wasn't working. We made this decision at lunch, and had a working phase 1 prototype by 4 in the afternoon. While the robot didn't do too hot in competition, Jake is still the robot I'm the most proud of.

I AM NOT SAYING to wait till the last minute and change everything, but I am saying stick to your design, the coaches aren't always right, so build it and prove them wrong.

Re: Team Argument!
 

up until the past few years it was here's our idea and thats what we're going for, there was no room for changing.

Now we have kinda gone to a more modular design where things can be switched at will, the point of that isnt for switching main design ideas though but rahter for if something fails DURING cmopetition. Personally I think its a team by team decision though, if you feel strongly with your view then portray that and why to your team and when it comes time to vote if you make your point strong enough hopefully the team will agree with you.

Re: Team Argument!
 

Ha! Thanks, were probably gonna get crushed by I am very excited!

The biggest thing here is the fact that 4 people are working on the auger. Two students and two mentors..that's it. The other 15ish people are working on the wheel. There is a clear cut majority, and most everyone supports me. Our student team leader is vehemently against this idea as well.

Another point he made was that you have to compare this to industry. He said that when are working you have to pick what is best and not just which one you like. I told him that, that analogy is not valid because we don't get fired for not winning at FIRST and as he said it's not about winning, about making a group effort to get the job done and to work together to create a robot that we all agreed on.

Re: Team Argument!
 

I agree with what has been said, I prefer to choose one design and make that design work, improving it along the way. Unfortunately your team seems to be beyond that point.

I suggest you bring this point up as a team group and let everyone give their opinion on the subject. At some point you will need to choose one design, and one robot. I think the sooner, the better...

Everyone likes to fall in love with their designs sometimes, but in the end this is a team effort and the team needs to collectively make a decision. If the team members decide to choose based on effectiveness or based on whether they had a hand in making the machine, it is their personal vote. Eventually a decision needs to be made, you can't compete with 2 robots. I personally would prefer a group decision over a single person's decision (even if they're a mentor) and I would prefer a decision today rather than ship day. It's not one person's robot, so as a team you need to decide on a single machine to compete with.

There are thousands of potential designs that work will work. If you spread you resources out and build 2 designs with half as much effort as you would have if your resources were combined, you'll always have 2 mediocre robots. Hopefully you guys will come together and have everyone work as a team ASAP.

Send a PM if you need any help.

Re: Team Argument!
 

The exact same thing happened my Freshman year on 100 (2005).

I was a rookie then. But our team was in its 10th year!

A mentor built one design and we, the students, built a different one. The situation you describe sounds pretty mellow compared to us. I'm talking all out war between students and adults. It was ridiculous. People even cried :( It nearly ended the team.

We shipped the mentor built robot. It failed. It could barely move :(

What little respect we had left for that mentor vanished and we unanimously booted him off the team the next year.

But strangely enough, we all learned more that year then any other year. Looking back, I'm always amazed how dedicated we became when we, the students, were working against a common enemy.

So did we really fail? I don't know.

Well, I decided to become an engineer. I got inspired. I learned how NOT to design a robot. I learned about what happens when you aren't organized and people don't cooperate. In short, the FIRST message prevailed.

Ironically, I learned a tremendous amount from that mentor, despite the fact that he drove our team into the ground.

My advice to you?

Act like engineers and pick whichever design works best. Solve the problem. No matter what happens you'll still have learned something :)

Re: Team Argument!
 

1 design to rule them all. Everyone on the team, students and mentors alike, need to understand the compromise that comes with anything that takes place on a team.

In 05 was the only year we did the 2 track thing. One was was the kids and mentors agreed with, the other was a crazy awesome lift of polycarb a mentor and a few kids made. The polycarb one was friggin awesome....but it was wayyyy overweight and overbudget. Designs might be better, but there's always other factors.

Pick one design and stick to it. Majority rules, but sometimes a compromise can be made without compromising functionality.

Re: Team Argument!
 

Ok, let's go with the business analogy:

Ok, there is a need for a new part. Team gets together and discusses ideas. They narrow it down to two. They decide to go with one idea for whatever reason. One of the employees who didn't get their idea picked, decides to go ahead with his design. He steals a couple of people from the group to move it forward. He takes money from the mainstream plan to fund his design. The two designs are finished about the same time and are put to the test. There is a possibility of two outcomes:

1. The individuals idea is indeed better. The team goes with this idea. However, when the boss goes to review the design, he notices what the individual has done. The employee has undermined the team by taking funds and distracting co-workers. That employee is on the fast track to getting fired.

2. The individuals idea is actually worse. The team goes with the mainstream idea. The boss sees what the individual has done. Wasted time and money on something that is an inferior product. This gets him fired.

Notice a link between the two outcomes? In both, regardless of which design they go with, the person who goes against the team's best interest is usually fired. Regardless of whether or not they was right. Something to consider for next year. After the stunt that mentor pulled, I'd see about getting him removed from the team. Take these scenarios to the student team leader. See what he has to say.

Re: Team Argument!
 

Yea, you're totally right. I mean, during the third week we told both students to stop working on the auger because we are trying to focus on our main idea. They said ok, but then when this meeting was called today he used the fact that "forced people" to work on the main idea as a reason to support his claim that we should have two robots. I am just really worried that we get neither finished and we can't compete this year. If that happens I will be so angry.

Re: Team Argument!
 

I have some points to bring up, and I'm not quite sure you'll like them.

1) If there is a sensitive issue on a team, we do have an "anonymous" forum. I'm not sure this doesn't belong in there, I'm not sure it does. I'm just saying. (You may need to use it eventually...)

2) Both of you are right. The mentor is right because it's not about winning. It is about a group taking a project that they all agreed on and worked on to competition and learning along the way. He's also right--to a point-- that in industry, you do things the best way.

However, you are more right. In industry, you do things the best way that is available. Friction stir welding may be the best way to do X, but most shops don't have the equipment, meaning that it's not the best way until you get the equipment (which is kind of expensive). And, after a design is approved, you don't change it unless of necessity most dire.

3) The team, not the leader, chose the design. He's miffed, and develops his own design. This is not good! Most teams, when a design is chosen by the team, lock the design. It's not open to change, unless something really needs to change. You, as a team, need to talk to this mentor and tell him that he's acting like a child. (Not in so many words, of course, but that is what he is acting like from your description.) In other words, take the blow to your personal pride and live with the group's decision.

4) Your other option is to force his hand. Get working versions of both NOW. I mean ASAP. Test them against each other on a certain day, say Saturday (Sunday at the latest), no exceptions or excuses. If one doesn't show up, the other wins by default. Winner take all. After build season is NOT the time to make a major change!

5) You ask about what other teams do with parallel designs. Here's what my old team does: We don't cut metal until we know what we're doing. If two designs serve the same function, we try to have space for both. At some reasonable time, we test all competing designs. The best one for our purposes wins out. We throw all other ideas into mental hoppers--if a design might not work, a "tiger team" figures out a backup plan.

I do know that at a couple of points, designs were tested late in the season against each other with no ill effects--one due to allowance being made already, the other due to being reasonably interchangeable on short notice.

To sum up, if you're going to revisit your decision, do it now. If not, tell him flat out. Everyone has to make sacrifices, including him. If that includes giving up his design, so be it.

Re: Team Argument!
 

[Edit] Now that I see this post, it's really long and intimidating looking. I'm really, really sorry about that- I have a tendency to spew out a lot more words than I expect.[/Edit]


These two thoughts both show a very high level of maturity and understanding. I applaud you for that, and I hope you can continue to voice your concerns reasonably to your team- you have a lot of good insight.

While I think your team probably should have addressed these concerns when it formed and at the beginning on the build season, it is definitely better to deal with them now than to let the repercussions of the disagreements manifest further and cause excess turmoil. You don't want that kind of tension to stay in your team for long. You should have a team meeting, and discuss the concern you have brought up in the first paragraph I highlighted in the above quote. Teamwork is important- you have to have your whole team in this together. If your team made a decision as a team, your team should honor that and move forward together, even if individuals think there is potential in other options. (I bolded "as a team" because that statement is very important- if the decision did not involve the whole team, then that's the step where you have to rethink things. Those who were left out of the decision-making process are going to feel the same way you do now.)

The fact that it is your lead mentor who lead the rebellion group is also important. Our mentors have much more engineering experience than us, and a lot of insight from their experiences throughout life. They might see an idea that they believe is the optimal solution, and it is understandable why they would think it is a good idea to bring the team to work on this. However, there is one flaw with this logic- this is not what FIRST is about. FRC is a program for high school students, designed to inspire and teach many lessons that will apply throughout life. The mentors are there to be that- mentors. While they can help enormously with their knowledge and insight, they should not be taking over the reigns to the extent that they are suffocating the creativity and the learning of the students. Perhaps you need to give a gentle reminder that this experience is designed to let you, the students, flourish through the knowledge you obtain through your hard work- the successes and the failures alike. While the robot design your team voted on may not be "the optimal design" in the eyes of your mentors, it is yours- yours to build as a team, yours to learn from as a team. You are absolutely right that you will get a lot more out of losing with a bot that is truly yours than winning with one that was just handed to you.

To reiterate- you should definitely hold a team meeting where you can voice your concerns and discuss these problems with the team. Make sure it is open to the whole team and you are not excluding people by, say, meeting during volleyball practice when everyone on the "auger" team is also on the volleyball team. Consider holding a special meeting outside of build time and sending everyone an e-mail explaining why it is important that they come. The high-energy, high-stress period of the build season can be really frustrating, so remember to remain calm and explain everything rationally during the meeting- your goal is to resolve conflict, not to create more of it.

Also, now that I have explained all of this, I realize I never directly answered your final questions. Ultimately, it makes sense to pick one design and go with it. Building multiple prototypes in the early stages (weeks 1&2) is a good idea to decide what to go with, but like you said, building two full robots is a waste of time and money, and will split your team in half. You should definitely decide on one idea early on and go with it, with your whole team as one. Anyway, good luck!

Re: Team Argument!
 

hmm some times true other times not so much. I always tell my students to follow their gut and speak their mind. There is a difference between a "team player" and a yes man.

As far as the situation at hand. you need to ask your self " what do you want". What is worth more this mentor, or your pride( or your mentors pride or your teams sense of self). if what you want is the best winning robot ever then by all means have the test( but please have each team test and present the others work . . don't have 1 testing team, I have never had a "fair" result come from 1 testing team). If what you want is an organization that puts the team before the robot than I suggest that you and your team leadership sit down with the mentor and his team and work something out( you will have to lose something when you do this).

what ever the decision you make you need to do it with haste in mind. Design changes( and indecisions) at this stage in the game are too costly

Re: Team Argument!
 

Hello All,

As a mentor, I would like to reach out to all the mentors reading this thread :

Remember what it meant to be a mentor to you before the season started.

If the reason that you volunteered to be a mentor is so you can build a robot, you probably joined the team for the wrong reason in my opinion. As an adult you have plenty of opportunities to see "your design" realized. Give this opportunity to the students.

A mentor is someone that guides the team, for you to be a guide you need to be an honest broker. It is like when you are a foreign country and you hire a "guide", that individual will provide you ideas of what to see and what to do, but in the end is you that make a decision. A guide shows the path, leads in the path, but doesn't drag others along.

I am aware of what my team picked for their robot design, I am also fully aware what other teams picked for their designs. I will say this, the team that will win this competition, is the team that will be able to compete next year, and the next year, and the next year, and the next year.....and ever.

I really don't care about the robot design.

It is not about who has the best design, it is about who has a team that will go on, go on even if they loose their Mentor. Or if their Coach quits because she is overwhelmed. The main sponsor drop out and you are out of $6,000.

Those are the winners.

Cheers,
Marcos.
:)

Re: Team Argument!
 

Thank you all for your input. I'm going to talk to our student team leader and try to have a meeting with them.

I know that we should have put an end to this earlier but the thing was, at first it was really small and he said that this would be totally non-intrusive to the main design, it would be worked on outside of our build time and would only be used if our initial design totally didn't work. Since some time has passed and they had a little more progress to the design, his demeanor totally changed and went to this test.

Honestly, there is no way they could get it up and running in the next few days. All they have is a frame with two wheels, and the big worm gear that will be the auger, but there is no electronic integration at all, and no program. Our programming team consist of two people, myself and another kid (who frankly has no idea how Lab View works yet). It's hard enough for me to not knowing what lab view was before the build season, but to make two fully functioning robots is just impossible for me, and I am not going to make two very weak programs just so that they both have something.

Re: Team Argument!
 

Congratulations, you just fired the inventor of Post-Its. (Not exactly, of course, but pretty close.)

It's not that easy in business, but the analogy is flawed. A robotics team is always under an artificial brutal time limit and can't make nuanced decisions. In developing new products in business, we hedge these kinds of bets all the time. There is some need to focus, but having a small team checking out the road not followed can be an effective strategy. On a robot team, this is always a bad idea.

The other part of the analogy that doesn't work is that in business the result is more important than the process. I've worked with product teams (new product development is what I do for a living) that all hated each other, and I've worked with teams that were practically mutual-appreciation societies. Some teams were more dysfunctional than a family on Jerry Springer and others practically sang Kumbaya every day. The teams that follow bad process and don't make the best of all team members sometimes make great products, and the happy cooperative teams sometimes stink. All else being equal, I'd rather work with the "nice" team, but I'd take bad process that makes good product any day over the reverse.

Having a mentor and a small team building plan B is distracting, but not fatal, if you can afford the parts and time. I have some sympathy with your mentor's position. Three times I've been on a development team that was racing towards a bad solution and being unable to stop the race were some of my worst experiences. Just because you are the majority doesn't mean you are right. Just because your mentor is in the minority doesn't mean he's right, either.

The thing that will save you (probably) is that there are usually lots of ways to make pretty good robots. There are even more than a few ways of making really good robots. It's not the approach, usually, it's how well it's executed.

It's important for students to remember that mentors go through learning just like the students. One of my most important jobs as lead mentor for my FTC and VRC teams (we have seven robots) is recruiting and training new mentors. It's much harder to bring in new mentors than new students. I have this little speech in my mind that I never deliver because it's impolite, but I'll share it with you because you are all my friends:

"I'm the lead mentor of this team. I am not a professional engineer. I have, however, been involved in writing software, designing products and running projects for 25 years. You are better at mechanical, electrical or <whatever> engineering than I am, but I know that I'm better at mentoring students through this process than you are. This is now my fifth year doing this and it's your first. If you won't follow my lead, I encourage you to leave now."

I seem to be drifting...

For what it's worth, I wouldn't have let a rookie team decide on an engineering approach. I would have walked the students through the process and then led them to the right choice. Learning the process is key, and the results don't really matter, so (as a mentor) I might as well lead our students to a workable strategy. If your lead mentor was on one side of the argument and the students were on the other, there's a pretty fair chance that the mentor is the one who is right.

Here's another bit of philosophy for you all: my job as a mentor is to get 1) a working robot, with 2) prepared students, to 3) a robotics tournament. Letting students on an FRC team violate rule #1 means I have failed as a mentor, and I am fully willing to override any sort of "vote" to lead my team into a successful year. This is NOT what I do with my experienced students. By their third year, they are clearly able to build robots with little or no input from mentors, and that's fine with me. It gives me more time to build my hobby robots while they work on competition robots. (This is a lot easier with Vex robots than in FRC. I love Vex.)

Good luck. Focus on what you can learn from this experience, and not on a sense that someone is treating you unfairly. I can tell you for sure that being treated fairly is not universal in business!

Re: Team Argument!
 

Then as Lead Programmer, I suggest that you focus on your "main" (team-designed) robot, and kindly (KINDLY) remind him why he's here, and what he has to sacrifice for the sake of the team. As stated above, he is there to guide you, and not only has he been a hypocrite, but he's going against what he's ultimately there for, which is inspiring you, the students.

Re: Team Argument!
 

Just for the sake of playing devils advocate on this whole thing, I do not know what your sponsorship position is but generally schools and sponsors want winning teams. Face it, shiny trophies make people happy (I know it makes me happy but I am amused by simple things like that). Your mentor may be under pressure from sponsors or the school. I believe that airing your dirty laundry in a public forum was not the proper move. If you feel you really need to I would use the Anonymous board here. Remember, every post you make reflects on you, your team, your school, and your sponsors. I am not saying this reflects badly merely reminding you of the implications of posting.

That being said...

Some teams are genuinely all about teaching and student involvement, some are more about winning. Having participated on teams that are about as drastically opposite as you can get (397 and 27) I can tell you that both ways have their merits and their demerits. Your team needs to decide what it wants to be, how important is winning? Is it more important than having the kids really love doing it? Can you do both? These are things that need to be decided. How does this solve your problem? If you want your students to feel involved and inspired by what THEY can do then you need to talk to your mentor and tell him that you guys feel passionate about your design, you worked very hard and feel that it should be given a fair shot instead of being crippled by dividing your efforts. If you decide winning is more important (nothing wrong with this thinking) then you do need to test both designs NOW. Not next week, not after build season, you need to test NOW. Testing doesnt mean having code, testing means manually driving the thing with a drill if you have to.

Also, if you need help feel free to PM me about the programming, Im not the best on here by any means but I am willing to try to help.

Best of Luck, I hope to hear wonderful things about your team in the future.

Re: Team Argument!
 

Another general comment -- these sorts of approach disagreements can frequently be solved within two weeks by building prototypes. When I did FRC we went through a lot of plywood, 2x4s, PVC pipe, and cordless drills (they make great temporary power sources) in prototyping. With FTC and VRC we just use the parts slobbed together to demonstrate approaches. You can usually lock in an approach after the prototyping, especially if the team members can agree in advance to accept the results of the prototype "shoot-out" and that there are agreed-upon analysis criteria.

Good luck.

Re: Team Argument!
 

There are quite a few other more significant factors that others have already spoken to, but this was something I feel very strongly should be pointed out. One of the first things I learned when I left college, and moved into the profesional engineering feild:

There is no pride in authorship.

When personal pride becomes part of the decision making process, problems arise. Most of the posts like this that are posted on this forum seem to be caused by this situation.

Its week 5, so it sounds like the ship has already sailed for your mentors design; but if you are going to do a side by side comparison, I would suggest that you work to the best of your abilities to optimize both designs, so that the best one (as decided by some quantitative measure) is shipped, not the one that got all the time and effort just because you liked it more than the other. Have your mentor's group help to perfect the wheel as rapidly as possible, and your large group the auger. I can almost guarantee that the mentor will go with the winning design, regardless of which it is. I can give you the same odds that there will be hurt feelings if his group feels that you're working to sabotage their design.

Whatever you choose to do, do not allow this to become personal. This cannot become a fight over 'your' design or 'his' design, because no matter who thought of what parts, the robot that ships in 12 days belongs to your team, for better or for worse.

*edit* heed Rick Tyler's words, as he made a lot of good points

Re: Team Argument!
 

First off, I'm tired and did not read through the thread fully. I'm also going to try to keep this short and simple.

From what I understand, you have an auger sitting at robotics waiting for programming and to be mounted, right?

What about your other idea? Is it sitting there waiting to be put on? I haven't heard you mention this at all?

I know when I design a robot, and my idea is not implemented, I feel bad, but I don't make a big argument over it. I go with the what the rest of the team wants.

I understand that your team doesn't want to go this approach though...

Whether or not your team wants to go with the auger design, you guys need to come up with a decision fast. Time is running out. Everything needs to start coming together now. If the other design has not been started yet, you should probably dump the idea. Give the programming team a few days to get something working. Make the robot aesthetically pleasing. Make sure it's wired up properly.

Fighting over a major design of your robot this late in the season is a big 'no no.'

I know if I had a working design sitting in front of me right now, I would definitely consider it.

My 2 cents.

Re: Team Argument!
 

Ok, two people made comments disagreeing with my previous post. One mentioned Apple, the other mentioned Post-its. I'm not going to pretend to be knowledgeable of Apple, though I see no story to connect those dots. Post-its, however has nothing to do with this scenario. Read up on how they were made and they don't apply to this at all.

That said.

As I've read your posts, I've noticed that you are completely dedicated to your team. You seem to believe that your mentor should take one for the team. I agree. However, If he won't...maybe you should. Seems like his design has a lot of work and could still have a lot of learning opportunities. Maybe, going with his idea now and involving the entire team with his design would allow you to get a robot done while the students could all take part. Next year, I would see about getting rid of him. But for now, you must deal with it.

Also, When I read a thread like this, I make a point not to read what team posted. This is for a simple reason, it doesn't matter who posted it. Leave the team's public image out of it and give him your advice.

A note to Rick TYler: When it comes to designs, there is no right or wrong. There is what will work and what won't. I agree that the mentor's design has a slightly better edge at working. However, with that said, if both ideas work...either is as good as the next. And that is when majority rules.

Re: Team Argument!
 

The way it actually works (as I understand it) is that they have 2 designs proceeding independently of each other. The team-chosen and team-built design is dubbed the "wheel". The other design, the "auger", is being built by what could best be termed a "splinter team" or small group that doesn't like the majority decision.

I'm not sure which one works. It is known that the auger isn't operational yet. We haven't been told the status of the wheel at this time. We do know that the OP doesn't want to start work on code for the auger, at least until the design is chosen by the rest of the team.

At this point, with a fuller understanding, but not complete, here is my advice to the OP: You have a choice: give the splinter group a chance or not. They have become resistant to your requests for help, and are apparently trying to build a second robot. Things are getting worse rather than better.

So, my advice is: Make your choice. One choice is to shut down the splinter team. I don't like to do this, but sometimes, it must be done. The other choice, and the one I would choose, is to hold a challenge. Both teams produce their product. Give about a 1-2 day warning. Establish a set of criteria, to determine which is better. Substitute human actuation when necessary to replace a motor. The better design, as shown by the criteria, will go on the robot. Some sample criteria:
-feed rate
-finishability--can it be completed by ship?
-jamming, or lack thereof
-ease of integration
-fill in the blank here--you may have other ideas. Leave out number of people working on the project, though.

Make sure that the entire team knows what the criteria are and has a chance to see them. The best option would be to make them beforehand, along with a note about automatic choosing under cases of no-shows or possibly pressuring one way or the other. Majority wins, and the better design is built by the entire team.

After that, if you still have a splinter team working on a concept that the team doesn't support, they need to wrap it up immediately or leave the team to do it.

This method will give the splinter team a chance to show what they can really do. It will also give you a chance to convince them. Two designs at this time just is not good, and this would be the absolute final choice.

Re: Team Argument!
 

Ok, for the wheel, we currently have the "wheel" operational on a drive base that is motorized, with the eletronics mounted and a completed harvester. We are going to build a conveyor on the top and that is the last thing we have to do. The is auger team is much farther behind.

Also, it's not like we haven't made a choice. We have repeatedly told his team to stop working on it because we wouldn't have enough time to make and implement a back up plan. They decide that they have enough time and money that they can do this on their own, but now the mentor is trying to get more people for the cause...

Re: Team Argument!
 

Ok, being a part of both types of groups, here is my insight:

A splinter group is usually driven by pride in one design. This happened to my team last year. The 4 most experienced students we had (myself included) wanted a shooter design. We KNEW this could be done and built in time and work. Certain people *cough* were in favor of one design which was the design out game mech dept. was forced to build. Being a fabricator myself, I took personal feelings and thoughts aside while I worked to build the team's design. It epic failed, and the shoot was amazing, needless to say those people against the shooter felt really stupid...

That said, being as it is your rookie year and you are the lead programmer, you need to RELAX not to say that you should stop everything, but as a programmer, the robot depends on you, and you need to not be stressed...

Whatever robot you ship, no matter how it turns out, you will have a killer time at Competition...
If you need help there, people will be more than willing to help so in the end you will be fine...

Like everyone else I am drifting...

So what to do now? Well you guys need to patch up the rift. Untied we build robots, divided we end the team (extremes but true)

Finally just remember "DON'T PANIC"

Re: Team Argument!
 

Kuddos!