View Single Post
  #4   Spotlight this post!  
Unread 06-05-2012, 20:12
LeelandS's Avatar
LeelandS LeelandS is offline
Robots don't quit, and neither do I
AKA: Leeland
FRC #1405 (Finney Falcons)
Team Role: Tactician
 
Join Date: Nov 2007
Rookie Year: 2005
Location: Webster, NY
Posts: 545
LeelandS has a reputation beyond reputeLeelandS has a reputation beyond reputeLeelandS has a reputation beyond reputeLeelandS has a reputation beyond reputeLeelandS has a reputation beyond reputeLeelandS has a reputation beyond reputeLeelandS has a reputation beyond reputeLeelandS has a reputation beyond reputeLeelandS has a reputation beyond reputeLeelandS has a reputation beyond reputeLeelandS has a reputation beyond repute
Re: Plans for the future

Hi! First off, I congratulate you on taking this step. A lot of teams I've talked with are not willing to do a total overhaul of their process and team in general. It can be a great way to get a team to reinvent themselves and start down a different path if they're not liking their current one.

First off, I wouldn't advocate the "two teams, two robots" deal. It's in interesting thing to consider if you have a very large team and an insane amount of resources, but otherwise, you're going to have two robots that are half as good as one could be. So I'd recommend having your entire team come together and work on one robot.

Here are a few notes I remember when considering how I'd run a team and designing a robot:
- Break into groups. Put students and mentors into assigned sub-groups that focus on a single aspect of the robot (drive system, game piece manipulator, end game device, etc.). It's easier to facilitate design and production on a smaller group, so long as they're not TOO small. Make sure all students on the team are able to suggest designs.
- K.I.S.S. "Keep it simple, stupid." Don't over complicate things. The process I follow most is start with your design. Then iterate it, making it more robust and effective each time, without adding too much complexity.
- Built within your resources. In addition to K.I.S.S., don't build a design your team can't support. Unless you have the manpower, time, experience and resources to design, build, manufacture and maintain a system, don't do it. I've seen a lot of teams try and build something beyond their resources, and the result is not terribly pretty. This includes both physical systems and anything related to programming. Don't overburden your programmers.
- Play for the game. Consider everything you want to do in this game. From drive system to game piece manipulator, make sure your system plays the game. If you're designing for this game, you may want a drive system with high traction for bridge traversal. Things like that are what you want to consider.

These are the basic points I consider. I'll post more later when my laptop battery isn't on the verge of death.
__________________
My heart will forever lie with SparX
1126: 2008 - 2011; Where it All Began.
1405: 2013 - Present; A Wanderer is Born.

Work hard, play hard. And maybe someday...
Reply With Quote