Simplicity or Complexity?

[RoboMadi]

Its more of a strategic opinion. I think that the first 4 days of building season are always the hard ones, as a team decides to pick a path to move on too and build a robot. Options are endless (within the rules and kit part), some teams decide to keep it simple, while others use different methods to make it more complex (mainly drive systems, or any other mechanism).

So what do you think in terms of Simplicity/Complexity of making a robot?
One of the cardinal rules of engineering is to keep things as simple as possible while solving a problem. But on the other hand, sometimes complexity comes handy too (from learning and strategic point of view).

[Cory]

Sometimes the complex can be done very simply.

[Lil' Lavery]

Originally Posted by Cory

Sometimes the complex can be done very simply.

Exactly
Simple design, complex mechanisms

[DonRotolo]

Complexity for the sake of complexity is the wrong path.

If the simplest way to do something just ahppens to be complex, then, well, complexity wins.

For example: Controlling the speed of the shooter. You can use a gear tooth sensor in a feedback loop to maintain a certain speed, or just let it run open loop with a fixed value to your victor. Both accomplish the task, and unless the open-loop version has a quantifiable drawback significant enough to affect performance, it is the better solution.

Rememberm adding complexity also adds to cost, time, and detracts from reliability.

My 2 cents advice is to define the tasks, design the basics as simple as possible to accomplish the tasks, verify the system, and go. IF (and only if) there is still time (and weight!) you can 'fancy up' the system.

For the learning experience, that's what the off season (i.e., right now) is for, sop you don't have to figure out how to make it work during build season. Get the GTS code working now, not in February.

Don

[Dylan Gramlich]

well SparX has always wanted to keep things simple(always a nice thought), sometimes certain mechanisms are simple, other times not. i have seen some simple robots make it very far such as 195 this year, even 968 could be considered simple. i feel simple elegance is a good way to go but if you can get a robot done but make it complex more power to you!

[Koko Ed]

Just remember the more complex things are designed the more things there are to break.

[RoboMadi]

Originally Posted by Don Rotolo

My 2 cents advice is to define the tasks, design the basics as simple as possible to accomplish the tasks, verify the system, and go. IF (and only if) there is still time (and weight!) you can 'fancy up' the system.
Don

And just to back up Don's opinion, i would like to bring up Occam's Razor theory.
"Occam's razor states that the explanation of any phenomenon should make as few assumptions as possible, eliminating, or "shaving off," those that make no difference in the observable predictions of the explanatory hypothesis or theory. In short, when given two equally valid explanations for a phenomenon, one should embrace the less complicated formulation. "

[Alex Golec]

In all honesty, the choice between simplicity and complexity depends on two main factors: 1. what you want to get out of the system, and 2. what resources (time, skill, money, etc.) you have available.

1. What You Want:
How much do you want the system to actually do? Is it necessary? For example, as Jay TenBrink brilliantly pointed out in this thread, sometimes even a common function such as shifting is not crucial to the game and can be spared from the design process. "If it ain't complex, don't complicate it" (Somebody has probably made that into a quote by now)
Of course, feedback and intuitive controls are almost required of the higher-level systems in order to make the best of their functionality. During OCCRA (local robotics tournament in Michigan), I initially designed a double-jointed arm but did not design the controls or feedback for that system, and ultimately had to scrap it in favor of a simpler stick-arm for the sake of controllability.

2. What You Have:
The more pressing factor will certainly be your team resources - how many and what type of machines you have, the skill level of your machinists and designers, and the funds to cover the cost of unique parts will all influence the decision on design. Given that, it is critical to know your capabilities before the season begins in terms of who's available and if there are any companies you know that might donate services for your team. Knowing the limits of your capabilities will assist you in judging the scope of your project.
My team does not have CNC machines readily available nor any sheet metal benders, so we generally design our parts to be - at the most complex - capable of being made on a standard mill or lathe. Often times, you won't need the ridiculous complexities of an uber-precise system- most everything that was designed like that resulted in a maze of intricate parts. Don't forget the potential benefits of prototyping to determine the viability of a system!

To summarize, what you design will depend on your resources (best if found out before the season starts) and your demands for the system (to be determined after the game is revealed). It will be a matter of where you want to go with the design process this year. Just last week, I was talking w/ Francois (Frenchie on the CD forums) about design complexity, and he brought up an interesting point: crazy ambitions will lead to the students going beyond what they plan and will keep them focus on continuously improving the robot. Every team and every student will have their own challenge to overcome this season.

Well, I think I've used up my essaying capacity for the day, I hope this helped.

_Alex

[Nitroxextreme]

Originally Posted by Don Rotolo

Complexity for the sake of complexity is the wrong path.

If the simplest way to do something just ahppens to be complex, then, well, complexity wins.

For example: Controlling the speed of the shooter. You can use a gear tooth sensor in a feedback loop to maintain a certain speed, or just let it run open loop with a fixed value to your victor. Both accomplish the task, and unless the open-loop version has a quantifiable drawback significant enough to affect performance, it is the better solution.

Rememberm adding complexity also adds to cost, time, and detracts from reliability.

My 2 cents advice is to define the tasks, design the basics as simple as possible to accomplish the tasks, verify the system, and go. IF (and only if) there is still time (and weight!) you can 'fancy up' the system.

For the learning experience, that's what the off season (i.e., right now) is for, sop you don't have to figure out how to make it work during build season. Get the GTS code working now, not in February.

Don

You are making very important points. The complexity of the robot should not be the top priority.

The team should decide on tasks that they want to accomplish and then they need to figure out how they want to accomplish them. Once they come up with some ideas they will see which ones are complex and which ones are not. It is up to them to make a conclusion on the road that they decide to take.

The game each year presents teams with enough of a challenge that they do not need to go out of the way so that their robot can be too complex. This also applies to the amount of tasks a team attempts to accomplish. For it is better to do one thing very well than it is to attempt to do many things at a lower caliper.

[sanddrag]

Simplicity or Complexity? I'll take neither. Elegance is what I strive for.

We started with a simple design, but it kept getting more and more complex trying to keep our simplistic design.

[RoboMadi]

Originally Posted by trilogism

We started with a simple design, but it kept getting more and more complex trying to keep our simplistic design.

Well a robot is indeed a complex system. Every sub-function or sub-system is dependent on another system, which makes it more and more complex. But i think that complexity can be minimized by cutting down the dependency on each system.
For example, last year couple of robots have the same system shooting and dumping the balls. So if in any case that system failed, robot can't do either function. Instead if different systems are designs for different functions, dependency can be minimized; or just stick to one function (shoot or dump).

As simple as we try to be, Robot is a complex machine one way or another, and that complexity, what makes F.I.R.S.T. more about celebrating technology.

[Jack Jones]

Originally Posted by Cory

Sometimes the complex can be done very simply.

I think they call that Simplexity?

[camtunkpa]

As a rule thumb the Tigertrons have always used those days to design a robot that can do almost every if not every aspect of the game. The rest of our six weeks are spent designing and building a machine as simple as possible to efficiently achieve our goal. If this doesn work for your team make sure not to overlook the importance of a relaible and powerful drivetrain. You can have the best manipulator in the game but if you can't move you're nothing but a place holder with a huge scoring potential. Anyway hope this helps, and as always with robot design don't forget about the COG.

[Rich Kressly]

To me, the real focus should be on solving the problem by:
-Figuring out "what" you want to be able to do
-Prioritize the "what" by Need, Want, and Wish
-Stick with the list in priority order throughout
-Your "how" is determined by time, materials, and resources

Remember, people are your most important resource and, to me, an up front focus on the complexity/simplicity issue make no sense without first having a priority list (need, want, wish).