Simplicity Vs. Complexity
 

Hello everyone,

I've been doing a lot of thinking lately about the nature of designing a 'power-house' robot. For Logomotion, our team designed a fairly complex robot for a second year team. We used mecanum wheels and a 100% pneumatic arm assemblage. In the end, we were one of the Bayou Regional winners and were able to attend the World Championship more from fluke than design. Our robot happened to be bulky enough, and our drivers quick enough, to allow us to play some pretty decent defense.

Still - this was a bit of an aligning of the stars. With that in mind, I've been looking at a number of Bots and I cannot figure if simplicity is the best option or if better complexity can yield higher results. Is the simplest option usually the best - IE. using an elevator lift rather than a pneumatic arm, or is it simply needing the programming to support more complicated options?

Thoughts?

Re: Simplicity Vs. Complexity
 

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.

Re: Simplicity Vs. Complexity
 

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.

Re: Simplicity Vs. Complexity
 

First and foremost- I don't know exactly what you mean by elevator lift vs. pneumatic arm, but in almost every scenario I'm picturing in my head, the pneumatic arm is simpler. Now thats just a matter of opinion based on my experiences, yours may be different.

To answer your more important question- there is no one answer here that covers all situations. The fact is, the answer to that question is dependent on a enormous number of variables unique to each and every team/team member. The best answer I can give is that you need to work with what is best for your team.

One shouldn't aim for "complex", however if a "more advanced" robot is something your team is comfortable doing, you should work towards that goal. You should be aiming to create the best robot your team possibly can each and every year. To do that, it requires each subsystem to be properly thought out, designed, prototyped, manufactured, tested and refined. "Complexity" is always going to be a negative in a design. However, some designs require inherent complexity to become more effective.

A quick example from 2011: Roller claws vs. Pinch claws. Each team will go through a different evaluation of each design, but I would say the majority of teams would indicate that a roller claw is more complex than a pinch claw. For some teams, pulling off a roller claw is very much within reach, while for others it may be just beyond their capabilities. For the team in which a roller claw is a bit of a stretch, what would make a more effective robot, the roller claw that was not properly designed, prototyped, etc. or the pinch claw that was nicely executed?

The way I look at it is similar to the evaluation of prospects in sports (specifically baseball). Each prospect is usually tiled with a "ceiling". That is, the maximum possible performance this player could have. For a starting pitcher, this could mean being an ace of a staff in the best case scenario to being a fringy #4 or 5 starter on a small market team. With this ceiling is also a probability factor. That is, what is the probability of this player reaching their ceiling. Obviously the higher the ceiling, the lower the probability of reaching it, however for all the intermediate cases, this becomes an interesting debate. Is the prospect whose ceiling is higher more valuable, or is the prospect with a greater probability of reaching their ceiling more valuable?

This same concept can apply to engineering, and robot designs. For the roller claw, the ceiling is definitely higher. However, what is the probability of your team reaching that ceiling? This is the question you should ask yourself about each subsystem as you move through the design process. You want your robot to have a balanced system. Maybe your drivetrain is a lower ceiling system, but has an extremely high probability of being successful. You combine that with a mid-level ceiling of an arm design your team came up with that has another relatively high probability of success. Then, you roll the dice on a high ceiling, high risk roller claw design. If you can pull that off, you end up with an extremely strong robot overall. You have mitigated risk as much as possible (in systems you are comfortable with) and have taken a risk on higher potential subsystems.

This is just the way I view the simplicity vs. complexity tradeoff. Everyone is different, and every team is unique. Hopefully this insight helps your team get a picture of how it fits into the grid.

-Brando

Re: Simplicity Vs. Complexity
 

Make things as complex as they need to be - not any more.

A common thread I've seen in the "powerhouse" designs is to take a very complex task, and engineer it so that the task is done by a series of simple, effective, and elegant mechanisms. Overall, the machines can be very complex, but when broken down into the individual parts, it's either an innovative use of a simple concept or a complex idea that has been refined over multiple seasons and years (i.e. swerve drive).

Another common thread I've seen in the "powerhouse" designs is the use of aids to help the designer/driver/operator/programmer. Well-placed sensors and switches, hard mechanical stops, visual cues, and feedback devices help propel a simple implementation of a simple design into an effective, elegant machine.

A team that works within its means and within its design will create a winning robot. Don't be afraid to stretch your boundaries and grow, but know your limitations.

Re: Simplicity Vs. Complexity
 

In my opinion the simplest design that meets the design requirements is best. This being said it is the design requirements that your team decides upon that will determine what is the best option.

For example, in Logomotion, if your team determined that creating some type of tube lifter that needed to use no motors then a pneumatic arm may have been the simplest solution given your design constraints. However had your team decided for one reason or another that keeping your CG in relatively the same spot then perhaps some linear elevator would have been the best for you.

If there is a way to keep from adding complexity to a design, it will generally improve the robustness of the mechanism and keep it easy to maintain. So I would say that simplicity and elegance will generally be better than complexity.

Re: Simplicity Vs. Complexity
 

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?

Re: Simplicity Vs. Complexity
 

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.)

Re: Simplicity Vs. Complexity
 

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.

Re: Simplicity Vs. Complexity
 

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.

Re: Simplicity Vs. Complexity
 

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.

Re: Simplicity Vs. Complexity
 

Does it count as complexity if you incorporate a large number of nuanced design choices into each mechanism? It seems like the powerhouses do that, irrespective of the number of moving parts they decide to use.

Re: Simplicity Vs. Complexity
 

No, that counts as "doing it right." Whether a design is complex or simple is irrelevant when you consider the quality of the design instead. Was it well thought-out? Do things fit right? Or is it riddled with holes and filing marks from constant trial-and-error?

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.

Re: Simplicity Vs. Complexity
 

We sure have learned a lot this year.

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.

Re: Simplicity Vs. Complexity
 

Complexity can be better, if you can handle it. This does not mean that complexity is better if you can handle it.

This leaves two things to worry about: whether your team can handle the complexity, and whether it's worth it. Answering these requires several insights:
1) a strong strategic understanding of the game
2) good prototyping and testing work
3) a realistic understanding of your team's abilities

Also, understand that there's a difference between difficult design requirements and a mechanically and/or programmatically complex robot. In the same vein, there's a huge distinction between technical complexity and construction difficulty--in fact, it's a rather strong inverse proportionality. Smart teams, regardless of their level, work to minimize what I call "degrees of failure". (These are like degrees of freedom, only more general and with a stronger eye towards what can do wrong.) This is not a simple process, but it should yield a simple-as-possible robot.

Anecdote:
We built a unicorn drive this year. This is basically a 4-wheel, independently driven & steered, continuous turn swerve drive. Our arm was a fibreglass pultrusion 4-bar linkage.
We won the Philadelphia Regional. Did we win the Philadelphia Regional because of our swerve drive or 4-bar? Not so much, chiefly because we didn't use it very well. We won because of our minibot, our alliance partners, and a very hefty helping of luck.
We also won an off-season. Did we win this because of our swerve drive and 4-bar? In part, heck yes. Our minibot helped and our alliance was awesome, but we were a capable scorer and a strong defender, too.
Same robot, same complexity, same outcome -- different cause. A lot of this is about how you use it.