System Design Requirements

[Greg Woelki]

Originally Posted by Joy4201

Our Team is curious about what general system requirements you all use when designing a robot. We are very interested in non-game specific requirements that are used to guide general robot design. Once a game is released we anticipate these guidelines/requirements may change, but we were trying to gather some best practices together.

Some example requirements we were thinking about are:

% Weight of drivetrain compared to entire robot
Max speed in high gear and low gear
Capture time for game objects

Do other teams have any general requirements that have helped you in the past?

The first two examples you listed are definitely game dependent. Tumbleweed is a great example of this, though there are many less extreme ones as well. If you're looking for general advice though, FRC robots should usually have a traction limited gear, whether it's their low gear or their only gear. As for your third example, "as fast as possible" seems to be the general consensus (see canburglars and bearing-ramps from RR).

Some less game dependent ideas would be things like ease of maintenance and repair. It's always cool to see teams totally trash a complicated mechanism like an arm or a climber in a fall or bad collision, only to pull a new one out of a tote in their pit and bolt it on their robot in between playoff matches. Motors, speed controllers, and solenoids should also be replaceable between matches if possible. To emphasize the importance of replacement parts, here's an example from the best.

Also, Karthik's Golden Rules are pretty okay.

[philso]

You and your team will benefit greatly by studying the Strategic Design video from Simbotics.

[SoftwareBug2.0]

1) Minimize cockpit workload.

Time spent fumbling with controls is time not used to pay attention to what's happening on the field. And if there are fewer steps to be done there are fewer steps to do wrong. On our robot this year it was possible to do a scoring cycle with the gunner only pressing a control twice: once to enable the intake and once to fire.

2) Tolerate failure.

Whether it's wear, a design flaw, or an opposing robot reaching in and riping out wires, failures will happen. We broke several chains in our drive train this year but due to the design none of the breaks did more than unpower one of our eight wheels. Similarly, all the automated functions on our robot could be overridden by the operator, allowing them to adapt to unforeseen circumstances.