Quote:
Originally Posted by MysterE
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