KISS -- More Complicated than it Appears?
 

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.

Re: KISS -- More Complicated than it Appears?
 

I have to say, before reading your whole post, that 341's 2012 design should probably be on top of the list for the KISS award. The most stupidly simple machine/design that worked incredibly well. :D

Re: KISS -- More Complicated than it Appears?
 

It's a really good point that complexity in one area can allow for simplicity in another.

Take 1717's swerve for example - incredibly complex, but made maneuvering, and therefore ball pickup, extremely simple to execute.

It's one of the reasons why we're investing time and energy in swerve - after a few iterations, a complex drive base can be made reliable enough that its complexity isn't a crutch, and allow for a lot more flexibility in designing other mechanisms.

Re: KISS -- More Complicated than it Appears?
 

I'd like to suggest that "simple" is perhaps a poor choice of words for the concept you are conveying, simply because simple isn't simple.

Oooh... sorry about that.

Simple is what we recommend to teams with limited resources. Simple is kitbot. Simple is direct driver control with limited feedback and sensors. Simple is doing one thing right. Simple is an AndyMark order form away.

"Simple" is about staying within boundaries.

I'll suggest "elegant" is perhaps a better word. An elegant design will appear simple, in retrospect (ie 1114 in 2008) but will be darned difficult to achieve working forward.

Aside from semantics (which I think are important) I agree with you 100%. Achieving a successful "simple" is amazingly difficult to do.

Jason

Re: KISS -- More Complicated than it Appears?
 

Simple... or, as Woodie so elegantly put it in 2007, "Simplicity on the other side of complexity"?

I think the question could be phrased this way: What is the minimum X device to do Y function effectively, given that Z group can't do anything beyond A complexity? If you go below the minimum X, you fail--Y isn't effective. If you go beyond A, you fail--Z can't do it without risking pain in terms of time, weight, or cost. If you are at the minimum X and at A, you have a simple, and quite possibly elegant, machine. (Going beyond X can result in greater complexity or greater capability, depending on the manner. For example, scissors lift versus linear elevator versus single-joint arm versus multi-joint arm in the 2007 game.)

Re: KISS -- More Complicated than it Appears?
 

That's actually a quote from Oliver Wendell Holmes Jr., and was repeated by Einstein.

"I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity."

Re: KISS -- More Complicated than it Appears?
 

In 2007, Woodie applied it to FRC robot designs. There were quite a few complex mechanisms that year, and then there were the simple ones that just appeared complex (looking at 1114 and 1717 as good examples). Those found the simplicity on the other side of complexity, I think...

Re: KISS -- More Complicated than it Appears?
 

I think any discussion of KISS in 2012 must include Team 67.
They had one device to pick up balls, lower the ramp, and assist with balancing. When I finally had a chance to look at this machine up close at IRI, I was floored by its elegance.

Re: KISS -- More Complicated than it Appears?
 

I second this.

Re: KISS -- More Complicated than it Appears?
 

Since I began in FIRST in 2003, I have found that it is much more difficult to keep a design simple than making it complicated. In our engineering applications, it is easy to want to make something that "looks cool" and completes the game challenge at hand. There is a natural desire to create a mechanism that is complicated to wow the audience.

Over the years, I have found that some of the "simplest" designs have given me the wow factor. It is amazing to see how affective some robots are when they accomplish a game challenge so easily. That always comes with the thought, "Why didn't I/we think of that?"

Do our minds automatically start to think about the complicated designs instead of the simplest ones?

This is a great conversation to have on CD and I am looking forward to the discussion.

Matt

Re: KISS -- More Complicated than it Appears?
 

Blaise Pascal once wrote in a letter, "The present letter is a very long one, simply because I had no leisure to make it shorter." Over the years, similar quotes have been attributed to several others including Mark Twain, Henry David Thoreau, Martin Luther King, etc. But the basic concept is the same. Simplicity is not easy and takes more time than many give it credit. Sometimes simplicity is a lucky coincidence. But most of the time it is born of much hard work and endless revision. When you see it, take time to consider the many failures and experiments that ultimately led to a successful design.

In my own experience I find that if you aspire to simplicity of design then you should seek the broadest skill set possible. Often when a really good mechanical or electrical engineer approaches a problem they only see the solution from the perspective of their own discipline. This is great for a well partitioned problem. But often a better understanding of a variety of disciplines is needed to find a truly efficient solution.