I was wondering how other teams design their robots as well as different formats for Engineering Notebooks.
In years past we have jumped right into building he robots right after a day of discussing the new game. This coming year we are talking about using our school provided iPads and the app Notability as our notebooks. We had one team this past year that we will model years to come off of because they were very good at their design process. They broke their team up into a software, drive, and scoring design team. The drive and score teams got together and discussed their robot and then built it as the software team programed the features. If they were a committed team, which they were not all, then they could have done well. We are going to model years to come off of this and have a mentor for each team that will help the teams, and also make up their own team. This is 6419’s proposed ideas for design and notebooks.
My team’s design process is a bit intense and I only recommend it if you have plenty of spare time to dedicate solely to note-booking. (I really like note booking sorry for the long post)
- contrary to popular belief, Pencil is better than Ink. Pencil is erasable this allows a) spelling errors to be corrected b) Ink bleeds through pages making the next page look messy and harder to read. c) drawing in ink is a nightmare. I have found that a nice mechanical pencil works better than ink. If you have really light handwriting use a softer pencil led. This will make the writing readable
- DO NOT make the team member with the runic scribbley handwriting write in the notebook. it does not end well
-Letters should be large and leave no blank space on any page.
- Number the pages in ink before starting.
- Consider investing in one of those notebooks with one side graph paper and the other side regular lined paper
- USE A RULER WHEN DRAWING LINES. It annoys me when there are messy lines. Drawings look way nicer if a ruler is used.
- Make any sketches huge. odd are if your notebook is as long as mine, the judges will skim. Make the important stuff bold and colorful to draw their attention.
- Keep a rough idea notebook. I will occasionally write rough copies of entries and sketched before putting them in the real notebook.
- outline entries before writing them. Like an English paper, notebook entries need to be planned out. A quick outline on a scrap piece of paper can ensure entries are coherent.
- Invest in some nicely printed photos on photopaper. My team orders photos online then picks them up at the nearest grocery store. We print so many pictures that we probably save money in printer ink. The shiny photopaper gives the notebook a finished look.
So… On to the actual design process. The design process I was taught in my engineering classes is
1: state the problem
- what needs to be solved?
- WHY is this a problem
2: Outline some criteria the solution needs to meet
- how heavy does the design need to be
- should it be fast or be strong
3: do some research
- look at previous robots and other sources for insperation.
- the vex fourms are really good for this look at robot reveals from previous years
- a good brainstorm should have a large, neat scale sketch depicting the important parts of the design
- label the sketch to make it easy to read
- DESCRIBE WHY you think that the brainstorm may meet the goals set out in step 2
5: Decide on a design
- outline pros and cons of each brainstorm
- consider making a constraint table
6: After choosing a design
- Outline why that design is the best.
- draw very very detailed sketches
- list possible parts (make sure you have everything before building)
- make a virtual 3-D model in Autodesk Inventor. It helps. Trust me
- create a loose schedule for building
7: build the design
- document every stage of building.
- LOTS of pictures.
- if you change the design, say why
8: test it
- does it work?
9: the inevitable redesign.
- what went wrong?
- WHY (consider using physics and math to back up your reasoning)
- ex. if a drive shaft twists like crazy look up the math that
- sumerize the whole process and show off your final design.
About Advanced content: Make sure you fully understand any advanced concepts you include in the notebook. if you use PID you should know what PID stands for, how it works, why it works and any tuning methods involved.
The biggest secret to a successful design journal is …
DEDICATION. The journal if done correctly, takes a really long time. Dont be afraid. It is totally worth it. During Sack Attack, I had the most pathetic robot ever (teammates quit mid-season and I was on my own ) but I made it to worlds by winning the design award due to the intense documentation of the not so awesome robot. AND AT WORLDS, I won the judges award with the most pathetic robot ever just because I diligently wrote in the journal.
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 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.