Simplicity Vs. Complexity

[EricH]

You are done with designing something, not when there's nothing more to add, but when there's nothing left to remove.



I'll post back with a further explanation later.

[Andrew Schreiber]

In the startup community there is something known as a minimal viable product. You should start by identifying what the minimal viable product for the game is. For Logomotion it was to be able to move and pickup a tube from either the player station OR the ground and to deploy a minibot.

Build an MVP then focus on making it a more viable product and building it out.

[Jon Stratis]

[...]Jobs had aimed for the simplicity that comes from conquering complexities, not ignoring them. "It takes a lot of hard work," he said, "to make something simple, to truly understand the underlying challenges and come up with elegant solutions."

Quote from Steve Jobs by Walter Isaacson.

The key to a winning robot isn't simplicity and it isn't complexity. It's about finding an elegant solution that is only as complex as it needs to be. Start by redefining the problem you're trying to solve - what are the critical elements? What will be the difference (in terms of capability, speed, accuracy, etc) between a winning robot and everyone else? What sort of design delivers everything you need? How simple can you make it before sacrificing some of those critical elements? Complexity takes time, and we only have 6 weeks.

Take this year, for example. What are the underlying challenges? Was it picking up tubes quickly? Was it raising them from ground to the top row quickly? Was it accuracy of placement? Was it a fast minibot? Was it being able to lineup and deploy the minibot quickly? Was it all of these?

[gblake]

Let's add in another dimension to the discussion.

Consistency and predictability, in the sense of doing what the driver/software tell it to do, without unpredictable variation will make either a simple or complex more successful in FRC.

The most sophisticated and valuable part of the FRC system you deploy on the field, is the drivers and coaches. When they know what the machine will/won't do, then they can wring its full potential out of it. If not, its a mess - sometimes a complex mess, sometimes a simple mess.

All other things being equal, it is generally easier to create a consistent and predictable simple robot than it is to create a consistent and predictable complex robot. However, don't mistake simplicity for consistency and predictability.

Blake
PS: To say this another way, in many important senses, I don't care one bit whether a design/implementation for accomplishing some task is simple or complex, so long as I can rely on it to do what I tell it to do, when I tell it to do it, every time I tell it to do it. Simple vs complex might be the wrong question.

[JamesCH95]

I will echo the sentiments "as complicated as it needs to be, but no more."

I guess the general answer is make your robot "3 weeks complicated" i.e. be able to comfortably build the robot in 3 weeks, but no longer. This will vary depending on your team's ability. I like the season outline: design/strategy for 1 week, build for 3-3.5 weeks, test/tune/tweak for 1.5-2 weeks.

I will add that a thoroughly optimized simple system generally works WAY better than an unoptimized complex system.

[JackS]

Don't let the powerhouses fool you. Just because a robot looks simple, doesn't mean it is. Oftentimes, teams spend years designing and perfecting systems to ensure minimum part count and maximum reliability and some of these design concepts can actually be rather complex. (i.e. 190/233/1323/254 ramp in 2011)

True simplicity in FRC means looking for the "low hanging fruit." This means finding the simplest task worth the most amount of points to your alliance. For example: In 2011, a first place minibot on a strong defensive robot could net an alliance 35-40 points. Whereas, a low hanger with no auto could net an alliance 12 points max. (The defensive robot with a minibot on an alliance with one good tube scorer would have almost guaranteed a win in a week 1 or 2 regional.)

[Chris is me]

Originally Posted by JackS

True simplicity in FRC means looking for the "low hanging fruit." This means finding the simplest task worth the most amount of points to your alliance. For example: In 2011, a first place minibot on a strong defensive robot could net an alliance 35-40 points. Whereas, a low hanger with no auto could net an alliance 12 points max. (The defensive robot with a minibot on an alliance with one good tube scorer would have almost guaranteed a win in a week 1 or 2 regional.)

We sure have learned a lot this year.

Originally Posted by Ninja_Bait

The truth is, simple is always easier to "do right." That's why more teams build a mecanum drivetrain instead of a swerve. Is simple always better than complex? It depends on the applications.

It's easy to be simple. It is NOT easy to make a simple design good. But it is certainly easier than making a complex design good.

Mecanums are the PERFECT example. Mechanically, simple as can be. But you can count on 1 finger the number of mecanum drives in the division finals. The teams that rose near the top with mecanum (2826) are the teams that took the simple concept of mecanums and perfected them.

[EricH]

Originally Posted by EricH

You are done with designing something, not when there's nothing more to add, but when there's nothing left to remove.



I'll post back with a further explanation later.

OK, now I'm back.

The question you need to ask yourself, for a given set of requirements, is, what is the simplest design that will still meet all the requirements? This involves doing some analysis of the problem (do we go top row, middle row, bottom row, or all three, or some other combination? What about minibots? Do we need 5 speeds or just one?). For example, sometimes, a 6WD swerve is found to be necessary (1625 in 2010) and sometimes it's just a liability (they didn't use it in 2011).

There are a few quotes that apply here. In addition to KISS, there is the old "Make it as simple as possible, but not simpler". And one from Woodie Flowers at the 2007 Kickoff (I think it was Woodie) that was something about "finding the simplicity on the other side of complexity".

One other thing to note: A box on wheels is simple, but it can easily be beaten by a slightly more complex robot with a scoring device. A multi-degree-of-freedom arm is complex, but can be beaten by a slightly simpler design (say, a few fewer degrees of freedom). It's not all about how simple or complex it is, it's how you use it.