![]() |
Re: Simplicity Vs. Complexity
There have been some great comments in this. One of the things that I think my team lacks is an understanding of exactly how to prototype - IE. what equipment to use, how to best go about it, etcetera. As a result, our complexity ends up being planned 'as we go'.
Learning, learning, learning. |
Re: Simplicity Vs. Complexity
First figure out what the robot is supposed to do. I know that in the last few years, my team has built robots that were designed before we figured out exactly what we wanted them to do. That resulted in constant redesign throughout the season, all the way up to Nat's.
A little physics can always help to optimize certain systems (especially if you're Ether) but sometimes you want a physical model. Adjustable is my favorite prototyping word, so 80-20, VEX or Tetrix, or sometimes wood, are great. From there, you should try to build a complete robot in CAD. Imagine all the problems you find on your real robot in the season. Now imagine that you figured them out three weeks earlier in a computer and didn't spend another hundred bucks to fix it. Now do a dance because you're so happy. (I'm doing one right now.) |
Re: Simplicity Vs. Complexity
Quote:
Some that are appealing in different ways are 1) Use a VEX or other set of parts to experiment. Some teams successfully spend a week capped by a real-world mini-competition on this approach. 2) Use simulations and CAD tools that let you put ideas into motion, and that do some real-world physics approximations for you. 3) Use students pushed around in chairs at reasonable (safe) speeds by other students to simulate robots operating and competing. 4) Accumulate a large collection of spare parts (structural, motors/pneumatics, sensors, etc.) and use them to create quick (often bulky/heavy) versions of mechanisms that you will implement carefully once you know the idea is sound. 5) Do item #4 in the off-season for core aspects of several past games. Blake |
Re: Simplicity Vs. Complexity
First, what's your front-end process for strategy, requirements, and system design like? Are you happy with how it works? Altering some of this can help facilitate prototyping and get rid of the "plan as you go" mentality.
As for actual prototyping work, Blake's got a great start. We also do an annual "mock kickoff" using a previous year's game. This is mostly about the front-end process, but the method sets us up for prototyping and helps organize our efforts. These efforts vary:
The key is to figure out what you want to test first. Describe your idea. The level of detail here will increase as you go. Understand how you expect this to meet your design requirements; then come up with what variables you can alter. This is everything from dimensions to materials to actuation speed, pressure, sensor placement, etc. Only then do you need to figure out how to do your prototypes. It's best if these are stable, controllable, and systematically alterable. Record your results! And analyze what these mean to your design and the design requirements. |
Re: Simplicity Vs. Complexity
Our team has modified the term 'keep it simple stupid (KISS)' into 'Keep it elegant, stupid'
There are plenty of great ideas that aren't simple. But they aren't convoluted either. |
Re: Simplicity Vs. Complexity
To me (especially looking at 2011), success does not depend (solely) on a simple or complex system.
For example: One of the simplest (scoring) robots I saw this year was 1503, Spartonics. Basic arm w/ pinch claw, 6 wheel drive, could only acquire from the feeder station. Aside from some fancy machining and a nice looking frame, nothing overly special about this robot. Two regionals and a division win later... I'd say they did pretty freaking good. Meanwhile, you had numerous teams (too many to name), who had a (on paper) better design. Elevator and roller claws seemed to be IT this year. Spartonics out-achieved many of them. Now, granted, they had some pretty fantastic partners through the year, but they were the first round pick of all their winning alliances, so they must have been doing something right. Programming does play a part in success. Not necessarily flawless software that makes everything run like butter, but enough to match the design. Software that allows an arm to go and stop where you want it is just as effective as the software that had 254's elevator and wrist operating correctly. If the programming is reliable and gets the design to work properly, it's all you need. What I'm getting at is, complexity doesn't always equal success. Now, obviously, looking at your world champions this year, complexity doesn't mean failure. What determines success is how the design is used. 148's Octocanum drive is a fairly complex system, and they used it to great effect in all of their matches. Meanwhile, teams with 4/6 wheel drive were just as likely to be successful if they applied their design right (a majority of the winners this year were in this boat). I hope this helps! Feel free to ask if you have any questions. -Leeland |
Re: Simplicity Vs. Complexity
In my experience: If you start with a simple concept, it will evolve into a complex design. If you start with a complex concept, it will evolve into a giant complicated mess.
This year the idea of an elevator with a pivoting claw on it was a pretty simple concept. However, looking at many teams who used elevators with claws one would be amazed at the thought put into actually implementing them. The trick to designing a successful robot would be taking a simple concept, designing it into something that actually could play the game, then itterating it down as simple as you can get it while still maintaining all the functionality your origional "simple concept" had. Of course, the definition of "simple concept" changes with the team. 111's idea of simple is different from team 4xxx's idea of simple. The main idea is that designs are always more complicated then ideas, that successful teams understand where their own line is, and that powerhouse teams are continuously expanding that line. Regards, Bryan |
Re: Simplicity Vs. Complexity
To quote Steve Jobs: "Simplicity is the ultimate sophistication."
Make your robot as complex as it needs to be - and no more. Complexity for complexity's sake is only asking for trouble later down the road. With that being said, don't be afraid to innovate and go out of your comfort zone while designing a robot. In 2010, 1124 designed and implemented a successful swerve drive system with no prior experience - and it worked great. The thing was, that was the main "complex" aspect of the robot; no complex manipulator or hanging mechanism. But our robot did what it was designed to do, and it competed very well (Archimedes semis, IIRC). The point is, don't be afraid to try new things and go places you've never gone before. Just try to avoid needlessly complicating things. A simple, efficient machine that does its job well is all you need. |
Re: Simplicity Vs. Complexity
The question isn't "Which is BEST, simple or complex"? It's "Which is best for my team, and if we do choose the tougher one, will we be able to keep it up"?
While I've seen many awesomely advanced complex robots that work like clockwork, there is always the one lone staggering rule: The more complex it is, the more prone to failure it is. The simpler it is, the more reliable it'll be, the less prone to failure it'll be, and it'll be easier to upkeep. Think about it like this hypothetical situation: Your team is going to build an arm to hang tubes this year. You have 3 ideas: A single jointed arm (Like 1868's), that only picks up tubes and swings up to hang them, a double jointed arm (Like ours...), that can move the tubes up and down, and can articulate them further for more angles, and a little more control, or a triple jointed arm (DOn't know any examples), that can move tubes up and down, to any angle imaginable, and can hang backwards. More joints=more motors=more wires=more complex=more failure prone One of our arm motors burnt out at SVR this year, rendering our arm helpless. 1868, on the other hand, had a perfectly working arm the whole time, and ended up getting 2nd place (with us getting 8th). We tried the 'tougher' solution compared to them, and it turned out we weren't prepared for what would happen. Moral of the story: Complex can work great, but only if you have the know how, and the ability to upkeep it. If you don't, then simple can lead you all the way to champs, without a single rebuild or problem. Hope this helps, and sorry for writing a lot! (You should see the team emails I send! :D) |
Re: Simplicity Vs. Complexity
Quote:
|
| All times are GMT -5. The time now is 18:31. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi