View Single Post
  #4   Spotlight this post!  
Unread 16-12-2011, 22:21
Ninja_Bait's Avatar
Ninja_Bait Ninja_Bait is offline
Former Prez of Making Things Go
AKA: Jake Potter
FRC #0694 (StuyPulse)
Team Role: Alumni
 
Join Date: Apr 2010
Rookie Year: 2008
Location: New York
Posts: 650
Ninja_Bait has a reputation beyond reputeNinja_Bait has a reputation beyond reputeNinja_Bait has a reputation beyond reputeNinja_Bait has a reputation beyond reputeNinja_Bait has a reputation beyond reputeNinja_Bait has a reputation beyond reputeNinja_Bait has a reputation beyond reputeNinja_Bait has a reputation beyond reputeNinja_Bait has a reputation beyond reputeNinja_Bait has a reputation beyond reputeNinja_Bait has a reputation beyond repute
Re: Team organization issues and Build Season Schedule

Quote:
Originally Posted by Wing View Post
I'm trying to revamp my team after 2 years of poor performance on the standards of our former mentors and our partner teams, and would like to have some help in determining the build season schedule and organization of our team for this upcoming season
Sounds good, improvement is the way forward.

Quote:
Our team meets on Monday-Friday from 3:454 to about 7:30 or 8, and on Saturday from 10 to 4. Currently, the leader has called for 3 hours on monday after kickoff to determine the game plan for our team. I want to spend at least 2 full days on this, to make sure we have a set game plan that follows the rules and is legal. We can't have a well designed robot without a clear game plan.
Setting up a strategy is wise; it's done by many top teams. Remember that physics is your friend and that every part of the game is important until actual experience tells you otherwise. Do some math and plan a super optimal strategy.

Quote:
After the first day, we create a design matrix with weighted objecives (no designs yet). I wanted this to be done on the third day, since we need to spend 2 days on the game in my opinion. After this, we split into small sub groups and come up with manipulator designs and chassis. We present the ideas the following day, and we use the design matrix to narrow it down to 2 or 3 designs after that.

This is where my main issue is. All Ideas should be prototyped or have a small moving model to see. Some ideas that could be brilliant and simple be easily eliminated if they aren't presented properly or if only drawings exist. I would like to give 2 days of prototyping (or physical conceptualization) with Legos and VEX parts. once the models are done, we can come back together and narrow it down to one design. One major concern with this approach is that the ideas can't be mingled together, and from concept to reality, would be separate. This can be changed by presenting the ideas before hand to the team, and prototyping them after to see the most effective using the design matrix. The remaining leaders on the team do not agree to this approach, and want to eliminate ideas before even seeing a physical model of the idea.
First off, prototyping is not the same as proof of concept. LEGO and VEX are proof of concept materials. They are an easy and quick way to show that an idea is sound and will probably work in reality. Prototyping goes beyond that by requiring careful work and allowing you to optimize dimensions and prove functionality in the real environment.

Second, you can sometimes eliminate ideas without building anything. Some ideas are clearly too expensive/complex/inane, and oftentimes logic and physics (or a proof of concept) will prove that only a handful are viable.

Quote:
Another issue I have with the team is professionally fabricated parts vs student done. My take is that since we are engineers, we do the design and simulation, and we want our parts to be done professionally outside or with our own CNC router. The others want to use our bandsaw and Mill and hand tools to create most of the parts, and only send out the ones that take too long to be done in our CNC router or outside. They want to "Teach people how to use tools". My opinion is that teaching tool use is for the pre-season, and we should all focus on an amazing final product that we as students design and assemble. A part that is cut by an inexperienced student will not be able to align properly unless properly cut, leaving holes when placing the parts together. I would like to see what others think on this issue before placing my arguments
Decide what your team is here for - building an amazing robot or changing lives? What will be better for that goal - outsourcing or engaging?

Quote:
Finally, there has been constant resistance to building another robot. We are lacking in funding due to our treasurer being stolen by Marching Band, but we have plenty of wood, and even if we build a robot out of wood, it gives us that much more practice for driving and developing strategy. I don't know why the others oppose it, but I read on here that the top 10% of teams build a second robot during and ship the second, and the top 40% build a second robot just for practice. I don't think there are any other arguments for it other than the ones I have laid out, but some personal testimonies would be nice.
If you can't pay for a second robot, you can't pay for custom machining. Also, you shouldn't make your second robot if it's not the same as the first. Even little nuances will drastically affect code, driving and strategy. Even though the practice is nice, it will feel like a waste of time and material as everyone adjusts from practice bot to competition bot.

Quote:
True Inspiration comes when students follow the engineering design process correctly, completely, and obtain a final product that allows them to be competitive and celebrate their hard work.
Wrong. True inspiration is when students choose to be good engineers because of the example of mentors and peers. It doesn't come out of good engineering, it leads to it.

As a last note: I've often felt the same way you do, which is that the team is nose-diving into a dump. Encourage these changes, but also act upon them yourself first. Crabbiness doesn't solve problems; leadership by example does. You personally can demonstrate the value of following a good engineering thought process, and others will follow when they see the advantages. Try not to overstep your bounds, however, and remember that you're doing this for the team, not for winning. Good luck with your efforts!
__________________
You can't fix something that isn't broken... but you can always break things that aren't fixed!

Reply With Quote