I would like to know exactly how you guys go about your design process at the beginning of each season. For instance I can see a lot of teams have gone straight in at modelling and testing ideas. Other teams start by having loads of meetings and design meetings before even touching a Vex part.
Secondly i would like to know what you guys think is the subsystem to start on when building. We have always started with building the drivetrain first but have found often that our intake just didn’t fit. I think this year we will build our intake first. What are your thoughts on the matter?
Strategy is a good (probably the best) place to start. Decide what you need to be able to do, how important different tasks are, etc.
Think about what you want to build in order to accomplish your strategy goals. For example, what to use to launch balls? Flywheels? Flywheel? Catapult-thingy? Fly-conveyor? Or What to use to elevate partner? Ramp? Lift? Pully-thing? Self-elevating-stand-thing?
Then, probably do some prototyping to see which designs are feasible/work best. The idea that you liked the most might simply not work that well, so I think it’s important to start building and testing sooner rather than later.
Then design/build a whole robot (perhaps with some other stuff in between these steps)
I would say launchers and elevating mechanisms would be a good place to start, since those are probably the main challenges this year. Drive and intake aren’t that hard and should probably be able to conform to whatever shooter & elevator you end up with. (That being said they are of course still important and not to be neglected)
Using the design process is the best way to go about designing a new robot. (Plus the judges look specifically for the design process such as the one I posted earlier in this thread). First you need to:
Define the problem: This means figuring out what obstacles you will have to overcome and what your robot is going to have to do specifically.
Brainstorm: Then you come up with all of your ideas with your team for each subsystem of the robot.
Research and Generate Ideas: Here you will search on the internet for ideas as most people have already started and you just look for other ideas that people have already come up with.
Identify Criteria and Constraints: This is where you will look very carefully over the rules and figure out what your robot can and cannot due during the match and make sure you know these specific rules because they will be important in making your robot.
Explore possibilities: This is where you will look through your materials and see what can you possibly make using the vex materials. You must determine what is realistic?
Select an approach: Here you will gather your best ideas and then decide using a decision matrix which is your best idea for each subsystem of the robot.
Developing a design proposal: This isn’t very necessary.
Model or prototype/Test and evaluate: This is where teams have designed flywheels and launchers to see what works. Just mess around with things, do some tests and see what does an doesn’t work.
Refine: This is obviously modifications done to the robot.
And so on…
I HATE design processes. But here’s my super generalized process:
void iterate() {
Start:
// CAD
while(true) {
think();
play();
experiment();
if(result not better than previous)
goto Start;
if(looksAcceptable())
break;
}
// Physical
build();
test();
if(resultsSuck())
goto Start;
else if(resultsGreat())
return;
else
iterate();
return;
}- Spend time brainstorming, prototyping and testing.
- Make your idea.
- Watch videos of other robots that are better than yours.
- Completely ditch your old idea and get “inspired” by the better robot.
- Build their robot.
- Repeat from step 3 all thought the season until worlds.
As posted previously by my coach in response to a similar question during Skyrise:
The below process is very similar to what I use as an engineer in industry, what I was taught in engineering school and what our team has used for the past 5 years. This process has netted us what I believe to be competitive robots as well as 3 [5 as of 2015 Worlds] World Championship Design Awards and a few local awards over the years. There are absolutely other ways to go about this that can be very successful, I am just sharing what I’ve been taught and used.
Request for Proposal (RFP): This is often called a problem statement. In industry a company, a government entity or a person will issue a request for proposal. An oil company needs a new drill site. The deparment of energy needs a new nuclear power plant. Vex needs robots for its competition. In this document, the client will request certain items. Some of their requirements will be absolute and others will be ideal (more on this later). For VRC, we treat the game manual as our RFP. It lays out the game, scoring, meta-info (if you will), and hard requirements (eg. the robot shall not be larger than 18”x18”x18”). From this our team has a pretty heavy discussion about what we want our robot to do in order to win. This year, that discussion largely revolved around what would have a larger impact on the game, skyrises or cubes. From this discussion, we move on and get these ideas down on paper.
Requirements Document (Req Doc): We create a formal document in google docs so all members of our team can view it and modify it. One critical item we do in this document is define our robot’s subsystems. These are typically something like chassis, lift, intake and logic. This year, we tried to define things a bit further by looking at chassis, lift, skyrise intake, cube intake, wiring and controls. For each subsystem, we lay out as extensive and as explicit requirements as possible. We use two distinct types of statements “should” and “shalls.” The former are items that would be advantageous but may not be 100% required for the success of the robot; something like “the robot shall be able to intake, hold and score at least 3 cubes.” “Shalls” are much more stringent and an idea or design will be discarded if it fails to meet these requirements. Some of our “Shalls” come from the RFP like the 18” cube mentioned above or they can be imposed by the team. For example, our team felt strongly that “the robot shall be able to score at least a 6 tall skyrise.” It is important that requirements be measurable and attainable (realistic). This is a living document which we revise many times over the course of a season. If a given requirement is unrealistic, change it. If your robot doesn’t meet a realistic requirement, change your robot.
Design alternatives: Once our Req Doc is complete, we get our whole team into a room with a big white board. We throw out all the ideas we can come up with based on what weve seen in past years, what weve seen on reveals on the forum mechanisms weve seen in real life, and anything we can dream up. These are listed along the y-axis. Then we come up with critical design criteria; things like cost, ease of implementation, motor usage, scoring capability, speed, reliability, etc. get placed along the x-axis. We then start a lengthy discussion of each designs qualifications. We score each design for each category on a scale of 1 to 5, 5 being most likely to succeed and 1 being extremely unlikely to succeed. There is often the desire to pick fractional numbers, but the scale is intentional designed to make you pick on way or another. You can scale certain factors based on your needs. For example, if you need a skyrise intake for tomorrow’s tournament, a rotating piston actuated intake will likely lose to a passive intake of some sort due to weighted ease of implementation. We perform design alternatives for each subsystem we laid out in our req doc.
FEED CAD: FEED stands for Front End Engineering Design and is something that is done on many large scale projects in engineering to validate a big question: will this work? This year we used Autodesk Inventor to draw out
FEED CAD of our top three design alternatives for each subsystem. This aided our design alterative system and then gave us something to work off of once we know which design we wanted to move forward with.
Prototyping: If you do not wish to use CAD, you can start prototyping your designs. You’ll see many examples of prototyped subsystems on the forum early in the year. Think back to the skyrise intake that used cut-off flaps or the passive claw 323z had up. One risk we have seen with prototyping is that the build quality may not be 100%, then the system makes its way onto the robot, then it falls apart mid tournament.
Detailed Design: Where the FEED CAD/design step wanted to know if something might work, now you’re trying to figure out exactly how this is going to go together, screw for screw. 3946W started the year with an elevator lift and was able to use JPearman’s write up of that lift as the detailed design. Our other teams use extensive CAD to lay all of this out.
Build: Now that you know what your robot is going to look like and how its all going to go together, you can start building. There is a thorough art to building a high quality robot. I suggest you look at a lot of robots and see what works. Nylock nuts are a huge improvement over keps nuts for most applications. Also, find a way to secure electrical connections whether that’s zip ties or electrical tape or whatever works for you. I tell my team to build something like you will need it to work in match 3 of the finals at state/nationals/worlds every time, because you could just be in that situation.
Design Document: This is the next document we produce and it tends to get pretty long. In this document you will describe your robot and all of the decisions that went into making it that way. Another student or parent or judge should be able to pick up that document and understand the progression of your robot and how you arrived at your current design. There will be an additional section for each new iteration of your robot. Inside of each robot iteration, we include a description of each subsystem. Sometimes this is as simple as “not changes made from previous iteration” and sometimes it’s a 2 page write up of what we changed and why.
Testing and Verification Document: We have included some requirements in our req doc that require either testing or analysis to validate. One thing we’ve had challenges with over the years is the gearing on our arm; you’re always lifting numerous game objects and you want to lift them as quickly as possible. We typically have a requirement like “Gears shall not be subjected to more than 90% of the yield strength of Delrin. If a gear is subjected to more than 80% of the yield strength, its fatigue life shall be computed and an inspection plan shall be put in place.” In the Testing and Verification document, we would list this requirement, complete the AGMA gear stress calculation and the subsequent fatigue analysis if required. On our newest lift, the number of gears we were planning on using came in above the yield strength and consequently we tripled up our gears to achieve a safety factor we were happy with. Another requirement we addressed was the speed of our robot. We timed it traveling across the field and noted its speed (which met our requirement). We documented the procedure and results of this in our Testing and Verification Doc.
Iteration: A key aspect of the design process is that you must iterate. The first robot you build very early in the season will not be the one you compete with at worlds (even the top teams in world don’t do this). There will be other successful archetypes that emerge and you’ll want to prototype them. One major requirement we have changed heading to worlds is that our robot shall be able to score two cubes at a time. We were runner up at our state championships because we couldn’t score cubes fast enough. This spawned another iteration in our design process. We changed a requirement, re-evaluated our design alternatives, revisited our CAD, then rebuilt and are now retesting the robot.
Design notebook: This is the journal you keep every practice that documents where you are in this process. I was always taught this document should be kept in pen and it must be a bound notebook. The reason for these two items are that if you were to try to patent something (granted no one is patenting their robot), you could submit your notebook as a legal document and consequently it needs to be sequential and cannot have been altered after its daily entries. We put our CAD, analysis, pretty pictures, etc. in our design doc. You should take as much care as possible in the daily entries, but it is also a journal. If there are kind of messy diagrams or sketches, that is fine. The notebook should also communicate to the rest of the team what exactly you did on a given day and what you need to do at the next practice. We try to complete entries as we go, but we also dedicate the last 10 minutes of practice to summarizing everything we’ve done. Finally, the preparer will sign off on the document and another student will then review the entry to make sure it’s accurate and complete and they will sign off on that entry.
I know, TLDR. We’ll try to get all our docs and a scan of our notebook up after worlds. You can also stop by and see the stuff listed above from 3946W in the high school division and 3946R in the middle school division.
A,B,C,D,E
Assess your capabilities and analyze the game to determine the goal
Brainstorm and plan ideas to accomplish goal with your resources
Construct Prototypes
Develop Robots based off the prototype
Elaborate/expand on systems
Then figure out how to improve and repeat as needed
Thanks for the great feedback. I can use this to help the teams i ‘mentor’/hinder as well.
This thread also talks a lot about design, and might also be helpful.
https://vexforum.com/t/where-to-start-on-robot-design/28871/1&highlight=Robot+design
It sort of depends whether you want a design process that gets you to your goal (presumably winning Vex matches), or whether you want a design process that will win design awards.
If you’re going for the former, then you shouldn’t look for a step by step process to follow to get to a design. A design process is about managing your resources effectively (people, communication, parts, time, field access, etc). Different teams have different resources, so different teams need to follow different processes. A team that has lots of time but not many parts might choose to cad everything before they build to avoid cutting anything they don’t need to. A team with lots of parts but not much time might choose to build a few robots simultaneously even though they only need one, so that if the design they thought was best turns out not to work they have the next best design ready to go. A team of ten people who often work at different times will need to keep detailed records of what they do and what needs to be done, whereas a team of two people who always build together and communicate a lot when they aren’t building might not need to write down anything at all. So it helps to have a sort of meta-design process before your design process.
If you want to win design awards, then something like what mwang17 describes above is a good idea. Judges can only judge you based on what they can see, which is your notebook. You should also talk to some judges and read the judging documents so that you know what they are looking for - they want to know how you managed your time and resources, how you designed and built your robot, and how your design and strategy evolved during the season.
Strategy really shouldn’t be the very first thing that is done. Or at least if it is done first you will have wasted a large amount of time because you will be doing strategy almost immediately after.
Strategy is all about weighing cost and benefits and going in to the season you don’t know the cost and benefits of each design. This means that right after you have a solid grasp of the difficulty and successfulness of each design you will be going right back to strategy to actually pick one.
The first step to any new game is to play with the game tasks. Build an intake, build a catapult, build a flywheel, build anything you can imagine. Then choose after you have the knowledge of how hard it was, how much space it took and especially how well it worked.
Jack and Steve from 2915 usually have full functional competition robots by the middle of May so maybe there is even a reason not just to build prototypes but to actually pump out a first draft robot.
If you want to bypass the entire testing phase you could always wait a few months and then make strategy decisions based off of what other people do but that is not recommended.
Example
Imagine if your entire strategy last year(before testing anything) was to make a cube denial robot but everyone that had tested the cubes sliding and the way they fall from the pyramid knew that denying every cube wasn’t possible. Where does that put your team.
I was not talking about weeks or even days spent on strategy. You don’t have to spend very much time at all on it before you start thinking about what to build.
A team could talk enough about strategy and some ideas that you want to build by the time you even get back to your school from worlds. So no time wasted at all.