View Full Version : 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?
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.
Andrew Schreiber
21-11-2011, 10:13
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.
Brandon Holley
21-11-2011, 10:28
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?
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
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.
Drivencrazy
21-11-2011, 10:45
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.
Jon Stratis
21-11-2011, 10:50
[...]Jobs had aimed for the simplicity that comes from conquering complexities, not ignoring them. "It takes a lot of hard work," he said, "to make something simple, to truly understand the underlying challenges and come up with elegant solutions."
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?
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.)
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.
JamesCH95
21-11-2011, 11:30
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.
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.
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.
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.
Ninja_Bait
21-11-2011, 15:19
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.
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.
Chris is me
21-11-2011, 15:22
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.)
We sure have learned a lot this year.
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.
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.
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.
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
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.)
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
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 (http://wiki.team1640.com/index.php?title=Team_1640_2011_Fall_Practice_Kicko ff). 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 (http://wiki.team1640.com/index.php?title=File:DB4_Bachmann_McKown_proto_080 107_csm_3.jpg), VEX (http://wiki.team1640.com/index.php?title=File:DB4_drive_proto_team_080107_c sm_4.jpg) and overhead carts (http://wiki.team1640.com/index.php?title=DEWBOT_IV_Week_Two_Build_Season_Ph oto_Gallery).
I'd also recommend making a miniature field (http://wiki.team1640.com/index.php?title=File:DB7_Field_mock_up_110109_csm_ 1.jpg). 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 (http://wiki.team1640.com/index.php?title=DEWBOT_III_Arm) (more wood (http://wiki.team1640.com/index.php?title=File:DB7_new_prototype_110117_csm. jpg)), 80-20 (http://wiki.team1640.com/index.php?title=File:DB4_Stumpo_Murphy_catapult_08 0112_csm_1.jpg), regolith (http://wiki.team1640.com/index.php?title=File:DB5_Davis_hopper_test_090118_ csm_2.jpg), PVC (http://wiki.team1640.com/index.php?title=File:DB6_Murph_Siri_kicker_100116_ csm.jpg), etc. These can get pretty large (http://wiki.team1640.com/index.php?title=File:DB7_Molley_Kulick_110117_csm. jpg) and sophisticated (http://wiki.team1640.com/index.php?title=File:DB7_Molley_claw_110115_csm_2. jpg), even under manual control.
Another good trick is making "proxy" parts of your robot. For instance, in 2010 we started the kicker in wood (http://wiki.team1640.com/index.php?title=File:DB6_Week2_20100123_SMW_0011.j pg) but evolved into a metal "proxy" robot front (http://wiki.team1640.com/index.php?title=File:DB6_Siri_Deaver_Jen_kicker_te st_100214_csm_3.jpg) 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 (http://wiki.team1640.com/index.php?title=File:DB4_fork_proto_080108_csm_2.j pg) or even on your current one (http://wiki.team1640.com/images/d/dc/DB6_robot_crab_100216_csm.jpg) 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 (http://wiki.team1640.com/index.php?title=File:DB7_claw_pneumatic_test_11012 3_csm_5.jpg). (Unfortunately, it couldn't pass inspection.) We also used CIM motors on our 2005 shooter prototype (http://wiki.team1640.com/index.php?title=File:DB2_shooter_prototype_060123_ csm_2.jpg). Drills also make a great rotary power source.
VEX (http://wiki.team1640.com/index.php?title=Team_1640_2009_Summer_Program) 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 (http://wiki.team1640.com/index.php?title=Team_1640_2009_Summer_Program) as starting point for our unicorn drive (http://wiki.team1640.com/index.php?title=DEWBOT_VII_Drive_Train#Pivot_devel opments_since_the_2010_season). We did something similar (http://wiki.team1640.com/index.php?title=6wd) 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
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
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
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
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
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
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... ;)
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.