My Design Process
Since 2020 I have spent a lot of time thinking about how to teach other students high-level design concepts. Through this effort I have become more aware of my own design process which I have developed through my years of experience designing complex subsystems and assemblies for FIRST Robotics and other projects.
What is Mechanical Design?
To me, mechanical design means finding the optimal set of solutions to a problem. The major aspects of my methodology are:
Establishing the solution space
Exploring the solution space
Following a solution path to its minimally viable conclusion
Iterate
Establishing the Solution Space
When approaching a problem, I define the solution space to be every potential solution to that problem, as well as the problems that solution poses and the solutions to those problems as well. The result is a solution space that branches out like a tree. When first establishing the solution space, the goal is to generate as many initial branches or ideas as possible. These first decisions will not only have the greatest impact on the final design but are also the most straightforward to test so the more of these initial branches we can come up with the better.
There are many different approaches to brainstorming that have been documented elsewhere but I will note here that the effectiveness of these methods are largely dependent on the size of the team. Larger teams will have an advantage at this stage as they are able to generate more ideas faster.
Exploring the Solution Space
The goal of this step is to gain an understand the solution space so you can make an informed decision on what solution path to pursue first. This is where the previously identified ideas are looked at in a greater context with integration in mind. If some solutions would be too difficult to integrate or are well outside the scope of the project or the abilities and resources of the team they should be eliminated here.
In FRC we did this by making simple 2D CAD sketches to figure out how much space we have for certain mechanisms and by testing known, already existing solutions in the context of the new problem.
Following a Solution Path to its Minimally Viable Conclusion
The goal of this step is to validate or invalidate an idea or solution path as fast and cheaply as possible. This could be looking something up, quick mockups with scrap materials, or fully designed prototypes depending on what is being validated and what is required in order to effectively make a decision.
In FRC, early on in the process we frequently used laser cut Masonite and 80/20 aluminum extrusion to mockup ideas quickly. Later in the process we designed prototypes to be cut out of HDPE on our CNC Router when we are testing and refining a design rather than validating ideas.
For the shifting swerve this step was done almost entirely in CAD as for the most part I already had a good idea of what features a good swerve drive should have. This meant the entire process was focused on refining the practicality and functionality of the design rather than trying to validate ideas.
Iterate
Finally go back to the top. Re-establish your solution space by eliminating options based on what was learned in the previous step and adding any options you have discovered. Consider what is keeping you from finalizing a design, prototype to eliminate that gap in knowledge, and repeat. This is an iterative process, and ideally it would be repeated until every solution path has been eliminated except one. However, this doesn’t mean it would be efficient. As you approach the end of the solution space solutions become less impactful and the resources required to explore these solutions increases. Therefore finding the optimal amount to iterate is very important but also very much dependent on the application and timeline of the product. How do I know when to finalize a design? Keep reading.
Additional Thoughts and Ideas
The Optimal Solution is not the Best Solution / How to Finalize a Design
For any problem there exists many optimal solutions and one best solution. Generally I choose to define the best solution as the most elegant design and the most elegant design as the design with the shortest solution path while still satisfying all of the design constraints associated with the problem. The idea that the solution that requires the least number of decisions to be made is the the best, or most natural solution to that problem shows up frequently in design. So if a solution space was graphed vs. the length of each solution path the best solution would be represented by an absolute minimum. Furthermore If the best solution can be represented by an absolute minimum an optimal solution would be represented by a local minimum. Note this also means there are multiple optimal solutions. This optimal solution takes into account the many limiting factors that might effect the problem solving process. So a team with very limited resources but infinite time will theoretically find the shortest solution path they can achieve with the resources they have. A different team also with infinite time but more resources will find a shorter solution path and therefore will get closer to the best solution. However, nobody has infinite time to do anything, so the rate at which a team approaches this local minimum depends on a range of things like the skill and experience of the team or designer, how fast iterations are made, etc. Every time we make an effective iteration, we should ascend the solution space some amount and then descend on a different solution path to get a better idea of how short it is.
Where do Design Constraints Fit Into This?
Instead of thinking about design constraints as external limitations like cost and manufacturing capabilities, I think of design constraints as the constraints we artificially apply to the problem that our solution must satisfy. For example if I am designing a 3D printer and decide through the methods described above the printer should have a dual extruder, that is a design constraint. These are just higher level features, the collection of which will make up the final product and define the solution space. Despite being no different in form, I treat design constraints slightly differently than any other node on the tree, as this is the level at which I find it can be beneficial to prioritize something other than elegance. Generally while trying to solve a problem I find it is helpful to establish a theme, like for an FRC robot it might be performance, or for a product it might be cost effectiveness or marketability. At this level and this level only I find it useful to use this theme to drive what design constraints I set, and everything else is driven by the rules defined above.
Gradient Descent, Generative Design, and Existentialism
Some of the ideas proposed in the above paragraphs describe the problem of problem solving as that of a gradient descent problem. This poses many questions about the potential effectiveness of generative design and the application of artificial intelligence in design. Current generative design algorithms are capable of solving what I would describe as very low level problems. However, the more you zoom out of the fractal that is the design space the faster problems become more complex, so these algorithms quickly reach their limits. Despite this as these algorithms improve they will gradually be able to solve higher and higher level problems, as such is the progression of technology. We typically think of problem solving as something that requires a great degree of creativity, yet the methods detailed above describes an approach to problem solving that requires no such thing. What we think of as creativity might allow someone to more quickly navigate the solution space, recognizing patterns and jumping around the solution space rather than testing literally every possibility and stepping around the solution space. Perhaps creativity is nothing but how good the gradient descent algorithm in your brain is. A bridge too far? Food for thought either way.