Plans for the future

[thenomnivore]

When it comes to CADing, during what portion of the design process does this come into play? And how long does it take to CAD a robot?

[IanW]

Originally Posted by thenomnivore

When it comes to CADing, during what portion of the design process does this come into play? And how long does it take to CAD a robot?

You can start using Computer Aided Design very early on in the design process. A lot of teams use 2D sketches done on CAD programs to broadly lay out their robot and to analyze interactions between their robot and game pieces/the field. Making these drawings on CAD software allows them to play around with specific dimensions, taking some of the guesswork out hand drawings. In this way, if your CAD team is fast enough, it can even be used for prototyping.

Once you have an idea of what features you want on your robot, you can begin more detailed design. Some teams start out with blocks that represent parts (I know 148 has done this), adding detail later once they know their exact layout. Others will start designing individual parts. Either way, the end goal is the same: a complete digital model of a robot.

As for a time during the build season that it happens, it really varies from team to team. For example, my team started making major decisions about our robot's design on day 1/kickoff. This is because we needed to have our design finished by the end of week 1, as fabrication and assembly take a lot longer for us than many other teams. As you may have heard before, this is a point where you must "know thy team" and the resources at your disposal.

Similarly, the amount of time it takes to design a robot in CAD depends on many factors unique to your team. How complex is your robot? How big is your CAD team? How experienced is your CAD team? For my team, it took me (working alone) one week to create a well developed model, minus parts we were still prototyping/iterating on. However, as far as I can tell, I am a very efficient CAD user, largely due to interning at Autodesk last summer.

Sorry for the wall of text, hope it was helpful.

[thenomnivore]

Originally Posted by Al Skierkiewicz

I suggest you read "Behind the Design". I question your decision to change the team marketing and look. We did that one year and no one could find us. We are tie dye forever now. We start brainstorming after we take a break when the kickoff ends. We don't stop for the next several days. We play the game, work on strategy, play the game some more, finalize strategy and then make a lost of what it will take to win the game. Then and only then do we start to design the robot. We take input from everyone during this phase, students mentors and parents. No idea is turned down. Each year we do this part a little different depending on who is leading. We often break into small groups and then report back when all the groups get together. Then we build a prototype and start testing. We modify the design throughout the build and sometime right up to Champs.

On your opinion with changing my teams look, the whole reason we are changing that aspect is because we don't have that strong of a presence during the competition. It currently makes it hard for people to find us actually xD
What do you mean by your team plays the game specifically?

[Alexa Stott]

Originally Posted by thenomnivore

On your opinion with changing my teams look, the whole reason we are changing that aspect is because we don't have that strong of a presence during the competition. It currently makes it hard for people to find us actually xD
What do you mean by your team plays the game specifically?

I can't speak to what 111 does, but, for us, it means running through every scenario we can think of happening...and then more.

So for this year's game, you'd try to think of everything that could happen. What happens if one team crosses the bump to play defense? What if none of your alliance partners can get the bridge down? What happens if they try to starve your alliance of balls? If there are balls stuck in the corner, can you get them? What about under the bridge? How are you going to line up your shots? What if someone pushes you? Is a turret worth it? What if your partner falls over/stops moving in front of your bridge? Are you able to cross the bump and get on from the other side? Would you be able to shoot over another robot in front of you? Then you think of how you could better your design to deal with these issues. Of course, don't get caught up on solving every single problem. Don't try to do too much, but you also don't want to have to rely on a specific set of circumstances for your machine to perform well. This year, we focused mainly on being an effective shooter. Thankfully for us, we use more or less the same drive train each year so we already knew climbing the ramp and crossing the bump wasn't going to be a huge challenge for us.

One example of when "playing the game" benefitted us:

Looking back this seems obvious, but many people designed their robots to shoot only from the fender. Now, that's fine against teams who can't cross the bump or drive over the bridge (or elect not to), but what happens when you face that defense? We took this into consideration and designed our robot to shoot from both the key and the fender. At the start of the season, you'll probably notice we primarily shot from the fender. As teams wised up to this and started playing more aggressive defense, we were able to adapt to that and back up to the key. And we didn't have to change our machine at all because we had already planned for that.

[Al Skierkiewicz]

We will make mock matches using old robots, students, parents whatever. We will time out in 10 seconds increments and try to simulate the game play. This is very useful in a game design that provides for defense as well as offense.

[Alex.q]

I know almost nothing about your team, so I can't give comments directly to your situation, but I will describe ours this past year. We are one of if not the largwest FRC team in Minnesota with about 50 kids that show up on a regular basis. Every year it seems we have re-structured our build plan and leadership. This past year, we considered the same idea with two different robots, and decided it would be a lot of wasted effort because much of the work would be redundant and it would not create any opportunity to iterate. The idea then became 1 chassis with two competing manipulator teams to see who could design the best manipulator. (While we did not use this approach, I think it would have worked well for a subsystem like the shooter, but I'm not sure if it would have meant a catapult and a wheeled shooter or two different but similar designs.) Anyway, we decided that it could be hard to decide which one was better (at what point do you decide, and at the deadline point the truly better manipulator is still waiting to get its essential part in the mail) and could also create hard feelings within the team. We also considered employing large number of students to build more prototypes. I'm not exactly sure of the approach we chose, because as soon as we started the build season, the approach changed to create our traditional build subteams (chassis, manipulator 1, manipulator 2). (As a sidenote here, I remembering vehemently opposing this, having experienced in lunacy compartmentalized subteams who failed to properly integrate their subsystems. Beware of this.)

In short, instead of 2 robots, build 1 chassis 2 different yet similar subsystems that will employ the same game strategy. (It would be hard to compare good ball collector to a mediocre shooter). OR Build 2 robots and iterate upon the first version to improve it. This is probably the more popular method.

I have been thinking about how to once again restructure the build process, and this is what I am currently considering. Everyone as a team decides what strategy they want to employ. Then groups break out into subgroups (chassis and manipulator) to brainstorm possible ideas for the sub-assembly on which they will specialize. Ideas are presented to the whole team, some shot down; a select few will be prototyped. A smaller group of students will work as the design team to do the detailed design work. As they do this, they will assign build tasks to the builders (prototype what amount compression will be needed on the ball). Once an iteration of the robot is designed, everyone works to build it. Its tested, evaluated to see waht could be improved. Re-design flawed systems, continue to test v1.0 while designing and building 2.0.

*Keep in mind I am accustomed to a large team, with a smaller team, I am sure you would adapt this structure.