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).
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.
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!
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. "
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.
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.
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.
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.
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.
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.
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).
Sparx would like to keep things as simple as possible but usually that is not the case like Dylan said. Sometimes we have simple mechanisms and sometimes we have complex ones. Our first couple days of the build season are rough becasue thats when we decide between simple or complex mechanisms.
What is simplicity? What is complexity. Is there any defined metric that can measure a device and evaluate if it is complex or simple. I don’t think so. These concepts rely on subjective evaluations by humans. What is complex to me may be considered simple to a top notch engineer. This falls in to the realm of philosophy and metaphysics. So how do you go about achieving simplicity? It’s a difficult subject and can be debated to no end. Kind of like the god and religion thing. Then again we have all at some time looked at a mechanical device and appreciated it’s elegant simplicity.
Simplicity has limitations and complexity doesn’t.
If a simple design won’t cut it, then step it up. Yet, make it only as complex as it needs to be.
Simplicity doesn’t necessarily mean reliability.
Cars have become extremely complex over the last ten years with stability control, GPS, adaptive cruise control, drive by wire etc. Yet, they are still more reliable than the previous generations. It just takes more effort to achieve the extra reliability.
I personally believe that you should build things overly complex in the off season with extra features, then dial it down to your needs for the real season.
Again, as the previous post said, its all relative.
Team 766 tries to keep things simple for budget limitations and our lack of a machine-shop to make the parts usually need in a complex design.
For us simple has worked wonderfully well. Our 2005 robot had a single joint arm that lacked an active gripper at the end and it could only be human loaded, yet we were part of the Archimedes division champions with 217 and 245 that beat the complicated yet effective 233 and their alliance (sorry, I forgot who partnered with 233).
