Re: Examples of when it is not advantageous to be lightweight
 

I was just about to chime in that for bleedingly-high speeds it only makes sense to have an extremely light robot. Though the necessity for such a specialized robot is quite rare, historically.

Re: Examples of when it is not advantageous to be lightweight
 

If you have the resources to design strong and light, then that's fantastic. You have the opportunity to test out how adding weight to different locations on your chassis change the handling dynamics of your robot. I would argue that the location of your weight (most notably your CG) is far more important to drivetrain handling then the actual weight of the machine. Thinking a little bit more into this, there are incredible number of factors that play into "handling". Wheel selection, wheel spacing, chassis rigidity, and even the driver controls.

Being "heavy" is not just about increasing the ceiling of your pushing ability but also your resistance to being pushed, or slowed down. Momentum is a very real thing in FRC games. On FRC558 we design to be "light", and then add weight low to balance our chassis. Also we make sure that our bumpers are just under the limit (its "free" weight in the right place, low to the ground). Again, we believe in having a strong chassis and drivetrain because we believe that defense is just as important as offence in most years.

Re: Examples of when it is not advantageous to be lightweight
 

We have always pushed to 120.00 pounds, with ballast when necessary. In my experience, a low-as-possible CG is always better than coming in significantly under weight.

In 2010, our CG was so low and so centered that we literally couldn't tip over permanently sideways. If our robot fell over, the climbing mechanism would hit the ground while the CG was still behind the bumpers, so it would pivot on the bumpers right back to the upright position.

Re: Examples of when it is not advantageous to be lightweight
 

Aerial Assist was the first year that we designed a robot that didn't have to lose weight to make 120 and it turned out to be great.

Speed was a big part of this game, but since we're not rich and wanted to try it, we used the AM14U kit frame and drive system. We noticed right away that with only about 90 lbs that we had good acceleration, but we also noticed that the kitdrive has gears that are appropriate for a 120lb robot. We resized the gears because pushing was already traction limited; we didn't lose any pushing ability, but we gained both speed and acceleration.

Point is, if you make a lighter robot, you need to be sure to size your gearing to take advantage of it.

Pushing is a great asset, but acceleration and a higher top speed might be better ones. First year we've won a regional in eleven.

Re: Examples of when it is not advantageous to be lightweight
 

It sounds like your real design objective is to have a low CG. Low CG designs come from choosing the right robot architecture, rather than taking weight out of everything that is high.

I would caution against lightening for the sake of lightening. The risk of lightening done poorly is part failure, and it makes it really hard to win matches with a broken robot. Design time is often a bigger bottle neck than manufacturing time, and it takes a lot of time to properly lighten something so it will be at the edge of breaking but not break. We prioritize reliability and robot up-time very highly, and consequently we tend to overbuild things (for instance, our shooter could have stood to loose a few pounds, but it never broke and it was done on time).

Perhaps there is a better way to phrase the design goals, where lightening is one of the means of achieving them when appropriate.

Re: Examples of when it is not advantageous to be lightweight
 

The normal force on your wheels matters for more than just pushing matches. In addition to reducing the amount of force you can apply, wheel slippage due to overcoming your static friction also results in faster tread wear. Depending on your wheel choice, quantity of spares, and drivetrain design, this may or may not be a significant issue.

On a different note, the less your robot weighs, the less inertia it has and the less momentum it builds up in motion. Lowering this is good for a maneuverable robot. However, there have been games in which you wanted a higher inertia. Namely the games involving mobile goals (2002, 2004, 2009), where the more your robot weighed, the better you would be able to control these goals (since you have control over a larger portion of the collective robot/goal mass).

Re: Examples of when it is not advantageous to be lightweight
 

Definitely agree with the structural integrity comment. I would much rather use a thinner material before I use lightening holes. Remember the saying "only as strong as the weakest link"? That applies to structures. Your robot is only as strong as the smallest cross-sectional area. When you have lightening holes, especially ones that are close together, you create a distinct point of failure. If you just design it with thinner material from the start, you can likely avoid lightening holes altogether and maintain a larger cross-section than you would have with a lightened structure.

Re: Examples of when it is not advantageous to be lightweight
 

Always design as light as possible, it's very easy to add weight, especially in places where you want it. If you build heavy it often ends up in places where you don't want it, like at the top of your robot.

Re: Examples of when it is not advantageous to be lightweight
 

The GDC has a way of making every design choice count. Universally scoring aside in robot sumo weight means a lot. Generally the GDC has been good about counteracting the "all in" design choices because when you have one set solution you don't really give students the chance to innovate. Examples of this would include pyramid climbing or balancing. Don't forget that water game thats coming up eventually...

Re: Examples of when it is not advantageous to be lightweight
 

In compression, strength is correlated with geometry not cross-sectional area.

Re: Examples of when it is not advantageous to be lightweight
 

I'm not sure I follow the logic here. I'm saying use the same shape, just a thinner material. Also, I would also say that compressive strength IS related to cross sectional area. It uses the same equations as in tension. Also, in terms of buckling, the point at which something will buckle is related to the cross-sectional area.

Re: Examples of when it is not advantageous to be lightweight
 

I would distiguish between designing the robot to be as light as possible and actually being as light as possible.

Designing to be light* is always a good idea, for the simple reason of it being significantly easier to add weight than remove it.

Whether actually being light is a benefit depends on the game and your team's strategy in that game.

*To paraphrase "As light as possible but no lighter."

Re: Examples of when it is not advantageous to be lightweight
 

Ugh, I'm not a REAL old-timer... but I do remember "Featherweight in the Finals" that our iconic robot, Grace Hopper, won in 2000. If memory serves (and it might not) Featherweight in the Finals was awarded to the lightest robot in either the final bracket or all of the eliminations.

Sort of... it's related to the cross-section inertia of the beam, strictly speaking, not the area. Compressive stress IS related to the XC area, but generally speaking this is very rarely the limiting factor.

Re: Examples of when it is not advantageous to be lightweight
 

i want to do pathfinding this year, and I've figured out that it would be extremely important for the robot to by capable of changing directions quickly and accelerating quickly, so that the robot will be able to follow the path and change paths with almost no smoothing and any overhead of acceleration time.

I think that this means that the robot will need:
-Tons of power in the drivetrain
-Lightweight
-COG: Center, at the bottom!

Re: Examples of when it is not advantageous to be lightweight
 

What you have here is a great recipe for spinning wheels. Would that make accurate path-finding more or less difficult to implement successfully?

Bonus question: how does wheel tread selection play into your goals?