I have more students wanting to be on our high school team than I have room for, so I need to have some kind of try-out process to weed out some of them, unfortunately. I plan to ask for teacher recommendations and look at grades, but what kind of performance task could I do to help determine weaknesses to help me decide who to cut? They all have enough experience that they should be able to recognize all the parts and be able to build, but having them build a bot would be time-consuming, and we won’t know what the new game will be until after try-outs. Any thoughts? Thanks!
Any way you could make more room?
How many “extra students” will you need to get rid of?
I’d try to design a test of sorts that could show abilities in all the areas a competition team needs. For instance:
Build - Following directions! A very simple robot build (could even be just a base or mechanism) with specific directions. As a sub-test on this, could have them build it twice (or do 2 builds) - first is specific directions (including things like screw size), second is loose directions (attach piece a to piece b; see what choices they make in terms of hardware). If you do 1 then 2, you can see if they carry their experience from 1 over to their build for 2, if they try to take quicker shortcuts (like use an excessively long screw just because it is readily available), or if they try to make it a bit better / cleaner.
Program - Then programming some limited functionality to that build; again, maybe part 1 would be with some programming directions and part 2 would be more on their own.
Design - Then maybe a list of potential design changes that they would undertake to achieve some specific goal.
Eng NB - As part of the above, they should document those design changes. You can get a feel for what sort of documentation they think is adequate.
Even more points for then modifying the structure to achieve one of their self-stated design changes (or, if they are leaning towards being a solid builder but limited design expertise, a modification for someone else’s change).
The point of these tests wouldn’t be to “fail” anyone but rather to find out areas of potential greatness and potential pitfalls. For instance, what if 8 people are adequate builders but 1 is a phenomenal builder and 1 can’t build at all but can program well or has an intuitive knowledge of what to document and how to do so? At least that gives you a sense of what they can do, which you can then fit with your current needs.
Had we done such testing at various points, we could have avoided many issues such as:
- The one who couldn’t follow directions. AT ALL. No matter how straight-forward they were, it seemed. You could lay 5 pieces down on a table and provide step-by-step instructions and come back awhile later and the person would still be struggling on this project.
- The one who said they had programming experience but really meant they’d played Minecraft a lot.
- The one who criticized every other team member’s design thoughts but kept coming up with design options that were … not great…
- The one who was in charge of meeting notes and when we looked at them afterwards the notes written down were things like “ate snacks” and “built robot” (with no additional info).
- Most of all, the ones who don’t have the patience and determination to even bother with trying the tasks. In fact, even if they don’t do any of the tasks particularly well just being willing to sit down and give it a solid try with a good attitude can be immensely valuable! I’ve seen teammates who are excellent at a particular task but who have such a poor attitude that it drags the rest of the team down, and ones who finish their task quickly but then interfere with anyone else trying to get something done. I’ve also seen teammates who finish their task and then smoothly move over and start helping other people with their tasks, or move immediately onto the next thing that needs doing, or come and ask you for additional work; try to get more of them!
Adapt this idea for prioritizing spots:
If it is good for DRow, it should be good for you:)
Here is my experience from having coached for a few years:
- Don’t rely too much on grades. A kid can struggle in academics but be really gifted when it comes to robots. Robotics might be their “thing” that motivates them to keep their grades up so they can compete as sports does for some other kids.
- What does matter is reliability, perseverance, and ability to work with others
Keeping these facts in mind, here is the “try out” process that has worked well for us in the past. Tryouts are a full week after school. Some may find that excessive, but the fact of the matter is that good teams need commitment from their members. If a kid doesn’t care enough to come every day for a week, they probably wouldn’t have the level of commitment that we are looking for from our team members. This process does a lot of the “cutting” kids for me. Many kids will decide that it’s not for them and stop coming mid-week. Perfect. Better to have them quit mid week of tryouts than mid-season when their team needs them. For those that do make it through the whole week, this is the schedule:
- Day 1: Design Explain what robotics is, show them the game reveal video, explain how notebooks are used to document the EDP, and pass old notebooks around. Kids fill out a Google Form application, and turn in a one-page explanation and sketch of what kind of robot they think would be best for the game
- Day 2 and 3: Build Days Kids are put in small teams and given a CAD drawing of a mechanism to try to build in 20 minutes. Usually these are things like a 6 bar lift, a simple chassis (without wheels or motors), etc. There are 6 total mechanisms. Each team will build 3 day one, and the other 3 day two. This makes it very obvious how well kids work with others and which kids have leadership potential
- Day 4: Program and Drive kids are split in half and half get to try to program a simple robot to drive a short pattern autonomously given a starter program with some functions pre-written, and a cheat sheet about how to call them. Meanwhile the other half are timed driving a simple robot through a maze. Then the groups switch
- Day 5: Interview The captains and I have panel interviews with the kids who have stuck around all week. After the interviews, the captains and I sit around a table together and figure out which kids should go on what team
-Behavior- Built in to previous suggestions, look at how students treat eachother while they work. Being a good programmer doesn’t matter if you damage parts, and being a good builder doesn’t matter if you can’t take feedback. Most students interested in robotics in my school are removed due to this factor.
We do this program, it works well in weeding people out and educating the ones the persevere and stay.
I don’t think taking grades from kids is the most sensible thing to do, I have friends on my team who don’t do very well at school, but when it comes to doing the robot they help a lot, I can’t think of another idea that isn’t make them compete, so you can see how each child is performing in all areas
Just some random thoughts:
Personally I find that grades are not a good criterion...
I’ve never had the best grades, but
In CAD class, I can easily finish before everyone else and have an efficiently created model.
In coding class, my code was unusual to the point where the professor often had to look over it several times to understand how it worked.
In electrical engineering labs, I was almost always the first one done and out.
In measurements, I easily had the most complicated final project that put everything we learned in the class to use.
Try having them build something off a CAD model (it doesn't have to be complicated), but intentionally hide mistakes in the model to see who catches on.
It’s a good way to see who’s actually paying attention and can realize that something doesn’t add up.
IMO it’s better to have someone who can point out mistakes, illogical things, and/or improvements than someone who blindly follows instructions.
Try the good old "How many ways can you use a paperclip?" question
It’s always good to have divergent thinkers on the team who can think up of multiple solutions to a problem (or rather, designs for a VEX game). During brainstorming, it’s quantity over quality.
See who dedicates time.
I’ve lost track of how many times we’ve pulled all-nighters in our lab to get something done.
For programmers, I know Google uses programming challenges as a sort of interview, so maybe try something similar for programmers? You could also try logic based puzzles for those who are new to programming.
I wish we had had this on my team. This would be helpful With weeding kids out and also assigning people to jobs that there good at as supposed to what they want to do once they see the game.(most people in my group wanted to drive so it was hard to find programmers.)
My school would have the kids build robots for a mini challenge, and choose which students made the cut based on how well they worked together and the quality of their design and their execution of it, and if they could drive or program well that was a plus. We’d give tutorials on how to build beforehand, as well as examples of drivebases, lifts, and other mechanisms. The main issue with this was that it could easily take three weeks, so we ran tryouts at the end of the year. This of course meant that students would only be able to compete for three years of high school, but we only really had enough to support 2 teams so this was usually okay.
These are all great ideas, but one thing to note is robotics (and more generally STEM) is about learning. The only pre-requisite a student needs is an unrelenting curiosity. Limiting the scope of your team to only those that have had experience with these kinds of challenges is a disservice to those that haven’t yet had the opportunity to learn but want to learn.
If my team had a tryout based on how well I can assemble a robot, I would never have made the cut. Because they allowed people to participate regardless of their initial level of competence (in the long run) I ended being one of the most involved and successful members on the team (and I say that humbly).
TL;DR In the vast majority of cases, it turns out that the willingness to learn is a much better gauge of competence than a student’s initial level of understanding.
Here is an exercise that I would recommend. This method would be cheap and very fun for kids! All you need is one piece of paper per 2 people, two largersized textbooks or blocks of wood, and a bunch of pennies!
The objective is to fold and create the strongest bridge between the two object with the single piece of paper. You test this using pennies. Just remember the textbooks need to be around an inch or two apart.
As another exercise,
you could supply each group with 4 pieces of paper scissors and 10 pieces of tape all same length. The objective is to make the tallest free-standing tower that doesnt fall over.
LMK what you think
I think that’d be a simplistic oversight into what it takes to be a good member of a robotics team. I think an essay, and possibly an interview is a much more holistic ways of viewing a candidate. An essay question could be as simple as “why do you want to do robotics?” or “how would you approach this problem?”.
That could be useful for more programming type people in my opinion. People who are good with hands-on activities usually are good at building. You could always have someone right a short paragraph on why they want to participate but this way the instructor can see peoples collaboration abilities
You make an excellent point, and although I didn’t mention it in my post, students are not selected based off of their ability to complete the “challenges” we give them correctly, but rather their attitude towards doing something that is likely rather hard for them, and how they treat one another as they do it. We give them a “taste” of what robotics will be like not really so we can judge how good they are at it, or their previous experience, but rather so that they have an opportunity to make an educated decision as to whether or not this is something they want to be a part of, which is important.
We are looking for teamwork, willingness to learn and try, and how they deal with frustration. How to build a quality robot can be taught easily to a kid who wants to learn. If they come in thinking they already know everything and treat others poorly, well, that is VERY hard to un-teach.
Ah, I missed the point of that exercise. Yes, in that case, a group challenge would be a really good way to see how well a student works in a team environment.
These are good criteria, I agree. I think these challenges in tandem with a written piece and an interview would be a good way to choose between candidates in a sufficiently large pool of applicants.
I feel like using a shorter screw would be a shortcut
Lol . Could be, in some circumstances! It was just the quickest example I could think of (I’m remembering a team member who once chose to use a very long screw - since it was right next to him - where a fairly short one was ideal and then being very confused as to why it seemed to keep catching on everything and messing up other areas of the build).
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.