Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)
-   -   Simplicity Vs. Complexity (http://www.chiefdelphi.com/forums/showthread.php?t=98370)

MysterE 21-11-2011 16:51

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.

Ninja_Bait 21-11-2011 17:12

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

gblake 21-11-2011 17:13

Re: Simplicity Vs. Complexity
 
Quote:

Originally Posted by MysterE (Post 1086032)
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.

Lots of options are sure to be mentioned here.

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

Siri 21-11-2011 19:19

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:
  • Alpha prototypes (your first, simple iterations) can be out of anything: coffee cans, VEX and overhead carts.
  • I'd also recommend making a miniature field. We use this in the mock kickoffs as a visual tool and to think about dimensions and clearances. We've made game pieces out of legos and use cardboard cutouts of robots.
  • For life-size mechanisms, you can use wood (more wood), 80-20, regolith, PVC, etc. These can get pretty large and sophisticated, even under manual control.
  • Another good trick is making "proxy" parts of your robot. For instance, in 2010 we started the kicker in wood but evolved into a metal "proxy" robot front to test both the kicker and the possessor. This also helps with workflow, as people can work simultaneously.
  • In addition to the "proxy" parts, you can stick things on old robots or even on your current one when you get that far.
  • You can enhance these prototypes by adding powered control where it's important. For instance, to test our 2010 claw prototype, we needed to know if the pneumatic speed and grip was appropriate, so we built our first LogoMotion robot. (Unfortunately, it couldn't pass inspection.) We also used CIM motors on our 2005 shooter prototype. Drills also make a great rotary power source.
  • VEX is great for detailed prototypes in which we want to study a replicable mechanical system or property. For instance, we used it in the summer of 2009 as starting point for our unicorn drive. We did something similar with 6wd.

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.

Grim Tuesday 21-11-2011 19:32

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.

LeelandS 21-11-2011 19:43

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

BJC 21-11-2011 21:11

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

plnyyanks 21-11-2011 21:21

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.

Andrew Lawrence 21-11-2011 22:07

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)

Andrew Lawrence 21-11-2011 22:09

Re: Simplicity Vs. Complexity
 
Quote:

Originally Posted by plnyyanks (Post 1086073)
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.

That's like what 254 did this year (and I think most years). A simple, West Coast Drive (WCD), and an advanced, complex, elevator and hanging mechanism. I hear it worked pretty well for them... ;)


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