Our team is investing in developing better design skills this offseason. Our lead mech design & engineering mentor led a class already this spring taking students through a design process including…
understanding problem/requirements/constraints
assessing options through geometry analyses
narrowing to a mech design direction via strength/weight/joints/bearing analyses (& if I am a successful influencer, also by looking at what robot archetypes & mechanisms were successful in past games with similar game pieces & tasks )
defining structural parts & joints
reviewing forces & power required for needed movement/work, and performing calculations needed to decide about power sources (e.g. pneumatics or motors/gearing) & transmission (chain, belts…)
mechanism design refinement once above decisions made, including detailed mechanics, motor & bearing mounts, locating control sensors
integration of mechanism with rest of robot, including attachment to chassis, wiring, pneumatic tubing if applicable
production, including CAD model (developed along the way), list of parts, which ones will be purchased vs. manufactured, individual part drawings for parts to be manufactured, and finally assemble, test, find problems, update design, update parts, iterate…
It’s all valuable, and I’m grateful he put in the time to develop and run the class. Looking at the long list above and thinking of the time pressure of build season (even with no bag day), a question that has been on my mind is…
When is deep engineering analysis needed & when can time be saved by simply applying experience instead? For example, if my mailbox post breaks, I don’t need to do a deep analysis to determine a 4x4 post solution will work, because I see 4x4’s holding up mailboxes in every direction. On the other hand, in the 2018 game, if I wanted to design a winch + scaffold system for climbing with 2 other robots, some rigorous engineering analysis was warranted. Of course, with drivetrains, arms, elevators… it is appropriate to do calculations to figure out motor(s) and gear ratio options. But, for example, what about the decision to use 1/16 vs 1/10 vs 1/8 wall thickness aluminum tube (or maybe the new polycarb tube) for a given application? It seems like many teams just use 1/16 or 1/10 for most things nowadays because experience informs them it will be strong enough (rather than an engineering analysis being done). So what do you think… What requires deep material/dynamics/engineering analysis? And what doesn’t?
This topic was sort of touched on way back in 2005 in this thread (sharing it because it seems like a classic discussion and area of debate): Mechanical Reliability
When you know that a solution you have on hand will be overkill, you don’t need to do the analysis.
When you aren’t sure, do back-of-the-napkin analysis to see if you’re in the right ballpark.
When you are attempting something for the first time, do as much analysis as necessary to be comfortable doing it.
For something like material sizing, you’ll want to look at things like expected impacts, expected forces to carry, and if past experience says it’ll work.
Good topic. This comes up all the time in “real” engineering jobs too. The short answer is you can “go with your gut” in two scenarios:
Your uncertainty in the design is nearly zero, either because you have a ton of directly applicable experience, or because the design is so conservative that you have a ton of room to be wrong.
Your risk tolerance is high. If you’re just prototyping, quickly iterating, hail-marying a long-shot idea, or other scenario where the consequences of failure are small, it may not be worth the time to evaluate all the unknowns.
In most scenarios though, doing the math first is best. It will save you future lost time, and give you an opportunity to teach design principles. Even when the above exceptions apply, most jobs will ask engineers to document the reasons why you don’t need to prove the design.
Deep analysis is rarely needed in FRC. But there are times where it can be quite useful.
In 2018, midway through the season, our captain decided that we needed to ditch the 2 side ramps that we had originally designed to lift our alliance partners and switch to a back ramp. He designed the ramp arms in CAD but before sending the parts to be waterjet cut, he ran an FEA analysis to determine if the ramp arms would be stiff enough. I believe he made a couple of minor tweaks to the design based on the results of that analysis as it showed that the deflection was a little too high and there were some areas where some more generous radii and slightly higher thickness was needed.
Why did he run an FEA? Frankly, I did not even know that he knew how to do it until he was presenting the results to the mentors during the final design review. But he had decided that this was an area that was a bit outside our experience. He had seen other teams with successful back ramps at that point in the season, but he knew that the loads were challenging and if the ramp flexed too much, the partner would not get high enough for the ranking point. Also, we did not have a lot of weight margin so we could not just over-design it. So he decided to run the analysis. In the end, it was highly successful. He learned a lot and that analysis probably helped influence the judges as we won the Engineering Excellence award at the DCMP which was the first tournament where the ramps were installed. Oh yeah - we also won DCMP…
Was it strictly necessary? Probably not. But it is probably one of the times where I felt that it had actually helped achieve a better design that we would have gotten through trial and error or by just over designing it.
As JVN has famously said, iteration is the soul of engineering.
Iteratively prototyping will teach, but it teaches more if you start in a useful direction. Doing the math makes that more likely. A few iterations of math can make your first prototype pretty good.
So learn the math. If it didn’t help, engineering degrees would be a waste of time. My experience has been that they are useful, much more often than not.
Having a solid understanding of the physics is often more important than doing the math. Unfortunately, it seems that physics is not taught until Grade 12 in many of the local schools here.
I found the students on the team I mentored this year could do the math but had no exposure to the concepts behind basic machines such as levers, pulleys and gears. Words such as “torque” and “leverage” drew blank stares. Ironically, the top level FLL teams I have worked with all had several team members who had a qualitative understanding of the physics but did not yet have the math…
So as others have said, a deep engineering analysis is rarely required for FRC purposes. You shouldn’t be doing a load analysis of the kop drive shafts… the longer you’re involved with FRC, the more your “gut instincts” will take the place of rigorous engineering. I’ve noticed that a lot of experienced engineers that are new to FRC will overkill the engineering side of things and can really put a team behind schedule if there aren’t experienced FRC students/mentors to speak up. As with everything there’s a learning curve to this program.
One thing I haven’t seen mentioned is rigorous engineering pre and post build season. 4607 has started to put a lot of engineering effort into our Process Failure Mode and Effects Analysis (pFMEA) and Design Failure Mode and Effects Analysis (dFMEA). You can find more information about each of those on our website. I highly recommend checking it out, it’s been a transformative thing for our team that has drastically improved our competitiveness on the field. It certainly falls under the category of “rigorous engineering”, but in this case I think it’s worth the effort, and the students learn a ton through an implementation of this program.
Hehehe. That’s true. But I’ve also noticed experienced FRC alumni recommended silly things with 1/2" hex shaft and # 25 chain*. A quick math check can save you schedule if you can prove the design will break.
*Ask dozens of teams who tried and failed to build 4 bar climbers this year with gear ratios approaching 1000:1 where they ran into the limits of FRC tribal knowledge.
If you don’t know what you don’t know, you can’t do the rigorous analysis anyway - prototype, test (at a safe distance), and iterate.
If you pretty much know everything (yes, we handled a similar load at that distance from the axle two years ago…), you can usually fall back on experience to get you pretty close.
If you don’t know several things, but you know what you don’t know, doing the analysis will answer those “don’t knows” faster and much less expensively than proceeding directly to prototype.
I remember talking to 148 in 2018 about their bar hook. They did a FEA analysis to iterate before testing to make sure the poly carbonate was going to be strong enough. Could they just have gone for it and tested it once it was built? Probably. But did the kids learn something and at the same time validate their own design? Yes. In times like this where there is uncertainty on whether or not something will work, deep analysis can help avoid the guesswork.
148, especially in recent years, has been doing some very out of the box things with polycarbonate and weight optimization in general. They’ve reached the point where there are relatively significant benefits to preforming a deeper analysis of certain components, and often demonstrate the exception that makes the “rule” in FRC. Other teams may find this effort is better to be directed to other areas of robot design, but it certainly doesn’t hurt to experiment.
I am a big proponent of at least doing some math first. Probably not needed for things like the drive train especially if its on we have done already multiple times. But a climber or elevator or lifting mechanism needs it just alone to make sure to pick the right motor or motors. On more than one occasion it has shown that the initial motor was not strong enough and a different one or 2 were needed. As for our 3D Printing adventure we are currently in the process of getting our numbers like what is the layer adhesion at certain temperatures and layer thickness etc. So for example if you take Nylon you can break it parallel to the layer lines - takes quite a bit of force but it will break if you go 90 degrees to the layer lines you can hit it with a sledge hammer - you will deform it but it wont break. So once we got all that data which we hope to have before the next build season starts we should be building stronger parts
Have you considered using Root Cause Analysis and PDCA to drive your iterative process? I’m working with a student on my design team right now to use those two along with FMEA to better structure our iterative process. I’ll definitely check out how you guys implement FMEA to learn a thing or two. Thanks for being willing to share.
I can’t say I remember being involved in any root cause analysis or PDCA sessions but I’m definitely not the right person to ask on the team about this topic. @Kris might have a better answer though!
Oh goodness, these measures are a constant concern for 4607. The issue with any upper-level engineering process is how the students will not only understand (they can), but will be willing to absorb and utilize appropriately (they may not want to, depending on the students).
This is where we lean on our mentors to carry the processes forward. This is why the mentors are so dang important. Luckily we have a solid group of mentors and students that understand the importance of dFMEA, pFMEA, RCA, and PDCA.
We are finishing up our second year of these processes, but it has paid incredible dividends. 4607 will see even more integrations of FMEA, Root Cause Analysis, and PDCA in the coming seasons.
We are working to produce more information in coming seasons on how these engineering processes impact our team.
It must be noted in all of this - students are the variable, the mentors are the constant. The teams that lean on the students to be both are in a hard spot throughout FRC. Since 2017 I have made sure to embed mentors into all of our departments, processes, and decision making. In my belief this has made a huge difference in our success over the last 2 seasons.
Another difference for FRC 4607 has been bringing on more qualified Mentors.
We nearly made the 1/2” shaft four bar climber mistake this year. A student did the stress math and we revised the design to drive it another way. A great example where a calculation can save you!
Yes, CIS uses Root Cause Analysis (RCA) and PDCA as a part of our pFMEA. In dFMEA, we identify potential issues, run calcs if needed, verify and address as needed to keep things moving to the fun stuff yet address actions. We define our process as after bag and tag and that’s where we focus on RCA, 5 whys, at build or right there in the pit, with short term and long term actions feeding into a PDCA. We have spreadsheets you can download and play around with on our website as well as a presentation we’ve given on our thought process and system. We don’t want to overengineer either so this process is streamlined on one spreadsheet and so ingrained in our way that I don’t think most even realize we are even doing RCA and PDCA! We keep this as fun for the students as possible and they easily run this program themselves with incredible dividends, as Chief Hedgehog stated. We have many ideas going forward with this!
Ah very good topic, and question… I asked something similar to my mentor let me share this with you:
“Let me ask for some advice as I made a design mistake… how do you know when to design a mechanism using math approach vs. using prototyping… is there some guideline to this? Is it always prototyping?”
“Always prototyping, but that may be crayola cad for like an arm or something. For the most part, math will get you close, but assumptions used will make the final answer wrong. Prototyping based on the math should close you in on the last 5%. Now, there are always caveats like geartrains. We never prototyped the climber gearing. We did prototype the winch tube and Velcro (the interaction with the outside world).”
in chapter 16 strength of materials in the machinist handbook… There is a passage written that is similar to this response… to summarize: Consequently many machine parts cannot be designed on merely by mathematical or strength calculations and their proportions should if possible be based upon experience…
I hope these answers help… I asked them back in 2017, since this time I’ve found online column, beam, and JVN calculators, and found that it doesn’t really take that long to do some crude math computations. Finally I can’t help but notice every season involves some kind of lifting the robot, that is a hint… maybe I should do the math for something like this.
That is very cool. Maybe if our teams regional schedules line up at the Double Decker again like they have in the past, we can see if some of our students can spare time to compare our continuous improvement efforts and hopefully both of our teams would learn a thing or two.
)