System Design Requirements
 

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?

Re: System Design Requirements
 

Neither of the teams I've worked with had these explicitly. All of our system requirements were game dependent (derived from the robot actions in the game that we decided were of the highest priority).

To address the examples you gave:

1. Weight was generally allocated based on necessity and priority. Necessity was generally based on prior knowledge and experience of mentors to who worked with similar systems in the past.

2. Speeds were optimized around a distance we thought would be the most traveled without interruption (for example, if you were a low goal robot, optimizing to minimize time from the outerworks to the batter).

3. As fast as possible. Touch it, own it.

Re: System Design Requirements
 

A couple of design-drivers from my time on 330:

--Shall comply with all rules.
--Shall move. (It should be noted that the specific attributes of the motion were dependent on year.)
--All deployables shall be retractable.*


*There have been exceptions--generally, it's because there isn't a good retract method available AND the deployable doesn't get in the way when deployed.

Re: System Design Requirements
 

Establish your capabilities first. Then design within them.

It is easy to get carried away with outsourced parts. Make sure you have the ability to build a robot in-house that will meed your minimum needs. Only then do you start calling your waterjet sponsor.

Re: System Design Requirements
 

Our technical requirements (how fast, how strong) derive from our functional requirement (score 6 boulders) which derive from the game rules. The only one that we could probably call up front is that the trickiest manipulator must weigh no more than 20-25 pounds, so that we can fit it and a few other neat things in our 40 pound withholding bag. Then, we can keep tweaking it up until competition.

Re: System Design Requirements
 

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.

Re: System Design Requirements
 

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

Re: System Design Requirements
 

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.