![]() |
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? |
Re: Simplicity Vs. Complexity
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. |
Re: Simplicity Vs. Complexity
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. |
Re: Simplicity Vs. Complexity
Quote:
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 |
Re: Simplicity Vs. Complexity
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. |
Re: Simplicity Vs. Complexity
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. |
Re: Simplicity Vs. Complexity
Quote:
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? |
Re: Simplicity Vs. Complexity
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.) |
Re: Simplicity Vs. Complexity
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. |
Re: Simplicity Vs. Complexity
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. |
Re: Simplicity Vs. Complexity
Quote:
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. |
Re: Simplicity Vs. Complexity
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.
|
Re: Simplicity Vs. Complexity
Quote:
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. |
Re: Simplicity Vs. Complexity
Quote:
Quote:
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. |
Re: Simplicity Vs. Complexity
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. |
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