Last year we one design award after we left the competiton and have no idea how. Now on our new robot we have actually 3 never before done things on it “top secret”. What i’m asking is what really impresses the judges or has helped you win design award if you have won it? Do they care more about innovation or just how we overcame issues to build a efficent robot?
1 Like
The main thing I would suggest is literally reading the criteria judges use for design award. You will find it is far more focused on how you design than what your design is. Notebook and presentation is going to be the key factor in winning the award. It took me a while to realize the focus of design award.
In general about judged awards I will point out that most teams can’t give a presentation to save their lives. If you need a script, sure script it but don’t be surprised when other teams win awards.
Interviews are all about a give and take with the judges.
It is not a speech followed by a few questions!!! If your interview is ever the same twice then you are seriously doing something wrong.
Go up with your team and talk to the judges about cool things your robot can do and cool stories.
For example. If they show interest in your code; go more in depth. If they politely nod when your talking about the code and you think they aren’t that interested then move on. Have the person who knows the most about any particular subject talk about that subject because the judges can definitely tell when a team member keeps glancing at someone else to double check what to say. If a team member “owns” no part of the robot something is wrong with the team dynamic.(most often this is due to members of teams that don’t deserve to be part of the team)
At worlds the judge’s stayed in my pit 20 minutes longer then they were supposed to because they were interested in what we were talking about.
World’s Divisional Judge’s Award
Nevada State Think Award
Nevada State Amaze Award
Nevada State Innovate Award
This. (Emphasis mine) In short, the Design Award is about having a methodical engineering design process, documenting that process (e.g: an engineers notebook, spreadsheets/calculations, online resources, etc), and organizing resources (human and otherwise) to meet your goals.
Source: When I was in high school, my team won 3 Design Awards (1 during Round Up, 2 during Gateway).
Well I don’t think it is all based on the notebook. When I went to my first competition, we showed our notebook to the judges, and it was a great notebook, it documented everything and showed the design process very well, but we didn’t have a great robot. I think the design award is given to a team that shows both that they can use the design process and document their robot, and have a great design for your robot that works. Last year, we had a great robot, but a terrible notebook, but the judges came up to us after the competition and told us that we were their second pick for the design award, so I think it is based kind of on your robot’s design and your notebook. But I could be wrong.
Regarding Notebooks:
I recommend using a binder with tabs for different “sections” of your robot design and/or team. In the past, I believe we’ve used Design, Construction, Programming, Strategy, Outreach, and Journal, along with a (single) cover page that gives a very big-picture overview of the robot.
You may ask: “why include an Outreach section–that’s not design?” True, but at many smaller tournaments, your team notebook is the only written document the judges look at (larger tournaments have separate submission processes). So, it’s helpful to have that in the notebook (but not necessary).
The Design section would consist of a general overview of the current design of the robot, and a couple of the highlights of how your design was modified over time. Include information on why you chose your design, not just the design that you chose. 
Place the calculations that you did to determine motor requirements, etc., in this section. (It impresses judges if you use some form of calculation in your design–even if the only purpose the calculations serve is to provide a very loose estimate of the required torque/force/etc.)
The Construction section would include CAD models (if you have a model of your entire robot or a really intricate model, it might deserve a separate section), notes on material selection (explain why you chose aluminum over steel, plastic over metal, thickness of polycarb, etc.), and pictures of your final construction. If you did anything really cool about the physical embodiment of your robot, put it here.
The programming section should have an overview of the “awesome features” of your code. If LCD autonomous selection is still uncommon in your region (it’s been a while for me, so I don’t know anymore), point that out. If you’ve made “preset” positions, do that. Explain your choice for one vs. two drivers–so many people just seem to make this decision randomly, but it’s very important. Include “maps” of your autonomous routines, as well as results from repeatability testing. It’s also a good idea to put your program in there, but don’t leave that as the only item.
The strategy section should include any type of strategy decisions you made over the season. Divide the field into sections, create “plays” just like a football team, or break the match into different time slices. Explain how the strategy you chose impacted the design you made.
That said, you must have talking points. In other words, know what the best features are about your robot and make sure you cover them. Don’t be scripted, but be planned. If you only respond to the judges’ questions, you’ll leave out great features about your robot.
A note on code: to me, there are three levels of interest a judge can show regarding programming. At the first level, they don’t even care–the robot, to them, is a physical thing, and they don’t want to think about the code behind it. (Like it or not, some judges are that way.) At the other extreme, they want to know every little piece about the code–did you follow good software design principles, or did you just slap together your code? I haven’t run into many judges yet like that, but those who did are typically software developers.
The typical judge doesn’t care about the design of the code, but they do care about what it can do for you. It’s a whole lot harder to explain “I then use tasks to separate lift control from the drive; we follow X, Y, and Z practices regarding data locking, blah blah blah” than it is to say “We use some uncommon features of ROBOTC that allow us to create ‘preset’ positions for our arms. This simplifies driving and helps us score faster.” Only a programmer is interested in the former explanation, but nearly everyone is interested in the latter. If they want more details, you can offer those; but, for most, the big picture suffices.
//Andrew
(I don’t remember exact numbers, but we’ve won Design/Excellence awards, too. :P)
This varies based on the competition. I’m 90% sure there was a team at Worlds a few years ago that won the design award without an operational robot (or, at least, it wasn’t operational for the majority of the tournament). That said, oftentimes a team with a good design ends up with a good robot (the former begets the latter).
Yes, for sure. A very common question you will be guaranteed to be asked in some form (for anything, not just VEX), would be “tell me about your robot”. You want to be able to outline the important and interesting points and get lots of information across, but the judges also don’t want to hear you ramble about very last bit of info.
ahaha… I think that was my team. LOL
Well, cool math like stress analysis and AGMA really impress the judges. Also, you can give the judges written documentation besides the notebook. My team has done this at every judged event we’ve gone to.
1 Like
Math is definitely one of the best things you can do to differentiate yourself from other teams. One thing that my team has found helpful, both for impressing judges and actually learning, is to do research and find sources to justify design decisions or programming. For example: we used this paper to help explain how we developed our code for our x-drive and this book to help us write a derivation for why the PD controller we were using on our lift worked.
Having won 6 design awards and two top 10 places at SkillsUSA Nationals in the last two years I think I can help provide insight on not just how we win the awards but use the process to make our team the best as possible. The first thing a team needs to do is set a goal for the robot to achieve. Honestly your team cannot truly design a robot without a set goal in mind. Our team’s initial goal was to have a 32 point skills robot by the end of our first three tournaments before Winter Break. We then broke down that goal into major robot subsystem goals. For each of those goals we make a Weighted Engineering Table of potential designs. We then took the top two design from the table and both CADed (hand drawings work but CAD programs are available for free to VEX teams) and maximized the Math in order to waste as little time as possible. Both two things were recorded in our notebooks as well as our work on the robots as they were happening. We also include pictures, a Bill of Materials, an overview of our design process, an autonomous flowchart, and each revision of our code in our notebooks as appendages as well. As far as judging goes, we have our students present to teachers and administrators in practice sessions using the questions provided by the RECF. This way the students are more comfortable talking to adults during the competition. We do not sell the community aspect as much until the bigger tournaments due to the fact that our teams are competing against each other at the event. My major piece of advice to the students presenters has always been that they have spent the last months of their lives designing and building this robot and they should sell it as the best robot they possibly could build. The judges will note subconsciously how well you like your robot and how hard you believe you worked on it. If you don’t believe you have an award winning robot then the judges won’t either. Also be professional during the judging periods that means: introduce yourself, spit out any and all gum, answer every question even if you thought you already answered it, and finish by shaking the judges hand and thanking them for their time. Almost all of our design process has been adapted from one of the best Robotics teams in the World, team 148 The Robowranglers. Thanks JVN and crew for providing the resources to help our team blossom! These resources are a great read and a fantastic tool if you are serious about robotics and they can be found here: http://www.robowranglers148.com/resources.html
2 Likes
Having served as a judge, I echo these sentiments. You generally have 10 precious minutes (at most) and the 2 important goals are: 1) to communicate the most important features of your robot and team and 2) to allow the judges to ask you about those areas you’ve shown that they want to explore more deeply. Every judging team will operate differently, and being able to “read” an interviewer and know what they’re most interested in is an important skill. If your judge gets a “glazed eye” look, it’s time to move on. I’ve had teams spend precious time “tutoring” me in the details of the 3 components of PID. It would be more effective to make a general statement like, “We’ve included PID control in our lift, which prevents the weight of the arm from pulling it down when we release the controls, and increases precision and responsiveness.” A follow-up question like, “Do you want to hear more details on how our PID system works?” will allow you to adapt to judges who have differing levels of knowledge.
One technique which I feel increases the efficiency of an interview is the, “Show and Tell” method. You walk into the interview with the robot turned on (and charged battery installed). When the judge says, “Tell me about your robot,” you ask, “Can we demonstrate while we explain?” then do it. For example, one member says, “Our lift uses a reverse double 4-bar lift capable of building up to 6 Skyrises,” while a teammate uses the joystick to lift the arm holding a Skyrise up to the maximum height, and another teammate holds 5 Skyrises, with the robot building the 6th one. You describe the driving base, “We have programmed the base to be able to switch between fast and slow modes, depending on whether we need speed or precision”, while your teammate(s) toggle between the 2 modes. “Show and tell” works best if it’s practiced and prepared, so you don’t say, “Watch me lift the arm to 5 feet,” only to find the that the lift doesn’t work. You should not be repairing the robot during the interview.
The same “show and tell” goes for your notebook. “We especially struggled with tipping, and you can see here in our notebook how we first calculated, then tested different places to mount the arm for balance” is a statement that shows what you tested, why, and what the optimal solution is without losing interest. An example of a poor description: “We tested the rotations for 300, 400, 500, 600, 700, 800, 900 ticks, then narrowed it to 810, 820, … and found the perfect number to be 847” – it loses the judge in detail, but doesn’t tell why you’re measuring rotations and how the other numbers are less optimal. Your notebook should have 2 or 3 sticky notes on your “best discoveries”, but not more than 5 – when you call attention to too many features, the judge will remember none.
When I look at code, I don’t want a line by line description of every (or any program). I want to know things like what autonomous modes you use (and what conditions they account for), how/why you use the sensors you’ve incorporated, what basic elements you included to make life easier for the driver (like multi-speeds, presets, etc.), and whether you used modular code (vs. "spaghetti string), and what you accomplish with each of the most important modules. If you talk me through that as you show the overview of the code, that helps. If your autonomous is especially impressive to watch, bring a Vexnet trigger switch and ask permission to show ONE autonomous routine.
Judges also like to see your small “hacks”, but don’t spend a lot of time on any single one – a simple mention accomplishes your purpose. Showing and telling, “This is is how we keep our wires in order, this small bar helps to prevent tipping, and this fold-out system keeps us safely within the 18-inch cube at start,” takes about 15 seconds, while reminding the judges that you’ve paid attention to multiple aspects of design.
Finally, you can never predict the quality of the other teams attending the event. Sometimes you win an award with a “pretty good robot” because the other robots are less impressive (more likely early season), but you come back with a “knock your socks off” robot at another event and don’t win because there are others that are even more impressive.
Winning a design award can be a goal, but is never a given. If every team felt they’d “failed” if they didn’t win Excellence, Design, or Tournament Champion, 90% of the teams that participate would be “failures”, and we know that’s far from the truth.
1 Like
+1 post on what ManicMechanic posted.
Let me add
Everybody on the team should know these points and be able to spit them out in a coherent way to anybody that walks up.
Lots of events have pit judges that walk around and talk to teams. They often come back with “Whoooo, go talk to 8081, they have something going on over there” If your entire team can do this, even a random drop-in by a judge will go well.