KISS -- More Complicated than it Appears?

[Joe G.]

I wanted to start a discussion about the deeper meaning of design simplicity, and its use as a design quality metric. Everyone knows, loves, and follows KISS. Good engineering practice, right? Simple is better. And everyone can point to a few shining examples in FIRST of simplicity that paid off. 4334 in 2012. 1503's single joint, no floor pickup 2011 robot. And I know that teams and engineers around the world, as they should, use simplicity to measure the quality of a design, especially in the earlier steps of the design process. A robot that accomplishes the task with 2 degrees of freedom is inherently simpler than one that does the same with 3. Tank drive is simpler than any type of omnidirectional drive. And so on.

These types of comparisons are easy to make when considering a subsystem's design as a standalone element, and comparing alternative concepts designed to fulfill the same task. But it is my experience that using a quantified value, or even a qualitative representation of "simplicity" becomes much more difficult when you consider multiple parts of the greater system, or even multiple domains (ie, mechanical vs. software) of the same system. We can all agree that unnecessarily complex systems, systems whose exact functionality can be replicated with fewer parts, should be simplified. But what about systems which could be simplified if considered as standalone devices, but at the expense of simplicity in another area?


As an example of this which lead me to think more about these things and create this thread, here's a project I helped complete recently for a college robotics course. Two features of this robot immediately jump out at people: The X-style holonomic drive, and the nine bar linkage lift. At first glance, the absolute embodiment of complexity and design for "cool factor." But that wasn't the rationale. We chose the design to minimize software complexity and required testing time, identifying the limitation that our team had a primarily mechanical background. We chose the holonomic drive to enable us to translate while line following, and execute "square to line" functionality to start each line follow parallel to and centered on the line. This in turn made the algorithms for our actual follow line function dead simple, and tuning the function was done in under 15 minutes, compared to weeks of testing and iteration by teams with "simpler" drive systems.

Likewise, the linkage was carefully synthesized to accomplish the desired objective (straight line vertical lift to specified height, then 90 degree pivot to horizontal). This was chosen over alternative mechanisms because the linkage only needed to rely on it's own kinematics and mechanical hard stops, 3 limit switches, and a single motor input to accomplish a very complex motion (If there's interest, I'll post a detailed writeup on this linkage, I'm pretty darn proud of it. ). At first glance, a nine bar linkage is WAY more complex than an elevator with wrist joint. But it reduced code size and development time, motor count (which we needed), and its precision allowed us to employ a simple passive gripping mechanism.

Because of the robot's intricate physical appearance, nearly everyone whose seen it has suggested that, while impressive, the task could have been accomplished in a simpler way. Mechanically simpler? Certainty. Overall? I'm not so sure. Looking back, I don't have any major regrets about the design we chose; sure there are a few incremental improvements that could be made, but I doubt I'd make any major concept changes if we did it over again. The linkage and drive did take a lot of time to design, but they paid off, not through the small performance gains often used to justify complexity, but by making other parts of the robot, the ones you don't see, simpler, and easier to develop.


The same could certainty happen in FIRST. Is a two position pneumatic arm simpler than a motor powered one, if it requires you perform dozens of gripper iterations to make the most of the limited range? What about a two degree of freedom arm, which allows the use of a pinch claw, vs. a single degree of freedom arm that would require a roller claw for tube rotation. Can a mecanum, or even a swerve drive be simpler than a tank drive in the grand scheme of things, if they dramatically reduce the number of steps required in an autonomous mode, or allow the robot to square against objects it couldn't before? Is a turret worth it if it simplifies aiming code? Separate actuator for feeding balls to your shooter, or lots of time perfecting an incredibly finicky ball path that would theoretically allow you to do it with one? On the flip side, is a wheeled shooter with complex control algorithms for velocity control worth it, if the alternative is a mechanically complicated catapult?

Thoughts? How do you compare apples to oranges when it comes to simplicity, and lack thereof? How would you answer some of the questions above if they came up in your design process, and what other factors need to be considered to answer them? Do we tend to over-consider mechanical complexity in FIRST, because it is more visible, and for most teams, represents the bulk of the build effort? How do you explore the more subtle effects choosing to simplify one mechanism may have? Is the very idea of trying to quantify simplicity flawed? Should the essence of design simplicity instead be considered through other means? Am I just really overthinking all this?

In particular, I'd love to hear any stories you have about things "done in the name of simplicity" that didn't pay off because they created complexity elsewhere, or systems which appear complex at first glance which actually serve to dramatically simplify things. Or fantastic examples of getting the balance right, and the thought process in regard to some of these issues that went into some of the most successful simple/elegant robots in FIRST.