Lack of Prior Knowledge

If a kid wants to be a basketball player, he knows he’ll need to be able to dribble, pass, shoot. If a kid wants to be a softball player, she knows she’ll need to have the skills to hit, catch, throw, run.
Robotics, and particularly coopetitive robotics (the FIRST family, VEX, etc.) don’t really have that prior knowledge for new recruits. People either have no idea at all, or preconceived notions based on (what they think are) similar activities. Thinking one is going to do battlebots, star wars, Wall-E, or computer programming is not necessarily wrong, but it is woefully incorrect.
What does your team do to build a foundation of knowledge within your team, new recruits (student or adult), or the general public so that going into build season, they have an idea of what they’re expected to accomplish, and how to go about doing so?

tl;dr: How do you prevent the “let’s put a buzzsaw and squirt gun on the robot” comments during brainstorming?

How do you stop the “strap a buzzsaw on a go cart and add a flame thrower”, we use QFD to initialize our brainstorming process. QFD stands for Quality Functional Deployment, a process used by top companies to build in quality into their products. See the QFD tab in our website: theflyingtoasters.org

We adapted the Ford Quality system in our rendition of QFD. We attribute our very successful third year with FIRST to the use of QFD; Chairman’s award, District Winners, Michigan State Championships-Qualifying for Worlds, 17th in our division at Worlds, 2nd Seed team at MARC, and IRI.

QFD helped our team to focus on the Whats and Hows. If you want more information, check out our website or contact me.

Three words: Public Outreach Events.

This helps get the word out about FIRST, the competition(s), the challenges, and any required skills (mostly the ability to think!). We take the robot into the public at events and give demonstrations and answer questions. We’ve also gotten some news coverage in our local paper to help promote the team and the mission.

We don’t, they’re fun :stuck_out_tongue:

To answer your question though, we hold workshops where we teach the new guys the basics of robotics and FRC, and major rules that don’t change (like no ruining other teams’ robots). We also show them many robots (pictures and videos, we don’t keep our bots) from different years and different teams. While that’s not enough to make them understand which kinds of mechanisms are useful and which aren’t, but they get the general idea.

To eliminate those kind of things we do a few things. For the whole Houston/Texas community we have a mock kickoff in December (should be the 14th this year) that walks teams through the engineering design process. For our team in particular we make sure that everyone has seen a lot of match video before we even get close to kickoff. We also meet the Thursday and Friday before kickoff to do last minute preparations and go over our design strategy with everyone.

This year we are trying something new in the fall to get younger students up to speed. Our plan is to do a full FRC build but stretched over three months. We are building for our mock game. The idea being it should give us more time to really work through problems and do a lot more teaching. Also the robot will never compete so it’s okay if it doesn’t get finished or if it isn’t perfect (it also probably won’t be painted and no practice robot). This will be happening concurrently with our veteran students building for VEX Toss Up and also acting as teachers when the younger students run into problems during the build. We have two new mentors to train as well so they will be heavily involved in this process too.

We don’t stop them, but for a different reason than just “they’re fun”.

Before the “mature” brainstorming session, we open up the floor for ridiculous ideas. We openly tell the students (and mentors) to throw out any over-the-top ideas they can think of. One students suggested strapping a rocket to the back of the robot and just driving up the side of the pyramid.

The reason we have team members throw out these ideas is that the most ridiculous ideas can have just a bit of brilliance in them. We thought about that student’s suggestion and thought… “Why can’t we just drive up the side?” This led us to brainstorming, prototyping, and designing a climbing system very similar to 118’s mechanism from their reveal video. We had the system mostly ready to go before abandoning it. We’re just not a team with the resources to make it work.

Don’t discount the ridiculous suggestions. I guarantee, one of the “legendary” teams got their first incredible design off of a “dumb” suggestion. Just remind students that when the time to work comes, to be focused on the task. Once they’ve been properly introduced into the program and understand that this is the one time where adding flamethrowers and buzzsaws doesn’t solve your problems, things should simmer down. But NEVER toss out the ridiculous suggestions.

As for strengthening “prior knowledge”, I find off-season events to be your best friend. There is no substitute for seeing FRC live and in-action. Use an off-season event as both a way to improve your existing students, and kick start your new students. If you don’t have the money, time, or interest to attend an off-season event, introduce them to the program in length. Something I’ve wanted to try for years is to do a presentation of different FIRST games and give the students examples on “How to do robots” by showing them the best robots of that year. In short, experience is the best way to handle this.

This year we are trying something new in the fall to get younger students up to speed. Our plan is to do a full FRC build but stretched over three months. We are building for our mock game. The idea being it should give us more time to really work through problems and do a lot more teaching. Also the robot will never compete so it’s okay if it doesn’t get finished or if it isn’t perfect (it also probably won’t be painted and no practice robot). This will be happening concurrently with our veteran students building for VEX Toss Up and also acting as teachers when the younger students run into problems during the build. We have two new mentors to train as well so they will be heavily involved in this process too.

Seconded. There really isn’t anything like building a robot for a competition to get ready to build a robot for a competition. We’ve been designing and hosting the BunnyBots competition in Oregon for the last five years just for that reason. We split our team up into several subteams and each builds a robot from whatever is laying around the shop. We invite local teams to do the same and have a good-natured one day competition the first day of Winter Break.

If anyone wants to host one of these locally PM me.

Three letters… FLL.

Start’em in grade 4 (or earlier in JrFLL) By the time the student gets to high school, they already have the tools, the drive, the discipline to perform well on a FTC/FRC team.

Before we start brainstorming in earnest I say something like this: “if your idea is not gracious or professional then keep it to yourself” and that usually puts an end to the ‘killer robot’ sort of comments.

I agree with this. I grew up with Odyssey of the Mind and there we had to come up with the most ridiculous ideas, because the emphasis was on crazy and creative ways to complete the task (2011-2012 Ooh-Motional Vehicle: build a vehicle that travels a course and displays human emotions).

My OM team was taught to start brainstorming with the most ridiculous and insane ideas, write them down, and draw lines connecting ideas that inspired each other. After we stopped laughing we would go through the list and narrow down the most feasible and appropriate solutions. We found the first part to be more helpful than we thought, because we went back to our old brainstorming sheets and saw that a lot of our best ideas were spawned from the craziest ones.

I admit that this is not necessarily the best process for FRC, but I vehemently abhor discarding ideas because they are “dumb” or “stupid”. I feel that it sends the wrong message and is against the spirit of science and engineering. You can see throughout history that great inventions came from both mundane and fantastical inspirations (velcro, cell phones, among others). It’s wrong to scuttle someone else’s boat because you don’t think it’s seaworthy. You probably don’t know that what you were seeing will be called a submarine, and you never know what new submerged continent, sunken civilization, or new species they will discover.

Get it out of their system at the beginning?

I agree that discarding ideas is a terrible idea. One good example of an idea I wish we hadn’t discarding was lifting up the whole robot to push down the bridge instead of using a mechanism to do so. While this wouldn’t have worked for the bridge, some notable teams used it as a fast way to get over the bump(254, 971, 111, and I’m sure others). Furthermore it allowed them to keep their bumpers low which has both offensive and defensive advantages.

Some notable robots have been created from out of the box ideas. The 71 2002 robot is utterly dominant from what I have heard(even though I wasn’t around at that time. The 469 2010 robot was also very dominant while using a very out of the box idea. Thinking creatively is definitely very important in the brainstorming stage.

2010 right? Not 2009?

-RC

Thinking creatively is definitely a critical stage in the design process for FIRST teams. One strategy that I find effective is to try to focus early stage brainstorming to ideas for tasks or actions that a robot can do. How that task is done can be saved for later brainstorming, as ideas can often go through numerous iterations before settling on a final product.

The going over the bump idea that 971 used in 2012 stemmed from trying to find a way to travel anywhere on the field rapidly. Several designs were thrown out and prototyped before we designed the final version.

Fitting the decision to robot task ideas can help shape brainstorming discussions and help team members think creatively at how to accomplish those tasks at the same time.

Correct. I edited my original post

Seconded. We sponsor and mentor several JFLL, FLL, and FTC teams in the area, and these are our “farm system”.

The downside is that we start each season with something like 120 students. It is challenging to ‘herd’ that many [strike]cats[/strike] students.

These suggestions will be out there, every time, as I have learned, despite what is taught/what you are told.

Even our sponsor offers to outfit our robot will flamethrowers and chainsaws every time we see them, despite us telling them, every time, that that would not be legal.

People find it funny/fun, and it is hard to stop it without looking like a grinch.

On 240, we all have a preseason project that we work on from November to kickoff. Each subteam will have a different project chosen (mostly) by the team leads. For example, build made a device to pick up pool noodles last year. This teaches new members basic skills, tools, and a creative approach to a given task. It also prepares them for the more intense build season. Electrical, CAD, and programming do similar projects.

This way, everyone on the team has a basic knowledge of what they are doing and less time is spent during the build season teaching basic concepts. We still get the ridiculous suggestions (some coming from me…), but our team likes them.

Sure, you aren’t going to put that buzzsaw on, but maybe it’s attachment, per say, is plausible and relevant to a game mechanism you’ve been struggling with.