So how do you frame the problem? 

Well when the rules come out, you have to first find all the requirements not start designing your robot.  Requirements are the attributes or sometimes constraints that your robot system has to meet.  Whoa, what do you mean robot system?  Well, a system engineering approach looks at all the infrastructure that will support the actual robot such as the pit, your robot transportation, robot crate, and the control station.  Each of these subsystems could have requirements such as weight, height, width, length, safety, etc…  You need to understand the requirements in order to evaluate the total design.  In the rules and construction guidelines look for words like “don’t” “must”, “shall”, and “should”.  For example in the 2007 manual section 3, there are requirement on your robot transportation cart:

1. Carts must remain in the team pit area when not in use for robot transportation
2. All carts should fit through a standard 30-inch door
3. Wheels on the cart must not damage site flooring
4. Do not add music to the cart.

How do these requirements affect the other systems? 

Your pit area which is only about 10’X10’ has to be kept clear enough so you can fit your cart and robot in it.  The robot has to be able to fit on the cart and through a 30-inch door.

So there are requirements not only for the construction of the robot but for the pit, the transportation, and for the competition.  Make sure you identify all the requirements and use those in your evaluation of the complete system.  Remember systems engineering takes a look at the BIG PICTURE (BP).

 
What are the Possible Robot Attributes? 

You are not designing the how yet, but understanding the what.  What can the robot do?  Last year robot attributes included picking up balls, shooting them in a 3 point goal, shooting them in one point goal, getting up on the ramp, pushing other robots, etc…  This year, our team (#399) designed a matrix (figure 2) that we will work together as a large group to brainstorm all the possible attributes of the robot design. Then we will break into small design teams to rank those attributes based on what the small teams want the robot to do.  We will come back together and average each of the small design team rankings and come up with a group consensus on the primary attributes of the robot.  Offense is how we score points, defense is preventing the other teams from scoring, autonomous is what we can do to score or play defense, and the base robot are items like speed, agility, strength, etc…

Generating Design Alternatives

We now have a matrix of the possible attributes of the robot and know what we would like the robot to do; now we have to generate a set of design alternatives on HOW to meet the attributes.  So the team should get back into the small design groups (4-7people) which work much better than a large group discussion and brainstorm on possible design alternatives and perform a risk assessment. 

What is a Risk Assessment? 

Generating design alternatives is actually pretty easy; there is never an end to outstanding ideas if everyone feels safe that their ideas are not going to cause personal ridicule.   But with all these great ideas, how do you decide?  Well you could do some sort of risk assessment.    It can become pretty elaborate, but a simple risk assessment can be two dimensional.   What impact does the design alternative have to the game?  Impact for your team could be defined as alliance selection; dominating the scoring, or best defense.  The second dimension is the likelihood of completing the design alternative in six weeks which means design, manufacturing, programming, integration, and testing.  So put together a simple table such as shown in the figure below.

Risk Assessment Matrix

Most technical people are more visual oriented, so move from a table to a matrix that is color coded for decision criteria.  You can use this type of matrix for almost every decision you have to make.  Also it is a great tool to use to archive your decision process.

So in this matrix anything in the red which has a low impact and low likelihood of completing you can throw out of your design space.  Anything in the green seems to be a no brainer that you coud put into your design; it is easily done and has high impact to the game. 

THE REST OF THE DESIGN CYCLE

Prototyping Stage

What design alternatives to take to a prototype stage?  Well this is where you have to do some real engineering.  Looking at this matrix, you want to look at how you can reduce the risk to design alternative C and B.  They have medium to high impact but the risk of completing is low.  Doing prototyping would help in seeing if the design is feasible and if the risk could be reduced and increase the likelihood of doing that design.  The risk assessment really depends that you understand the strengths and weaknesses of your team.

Design Integration 

Now comes the fun part of further reducing your design alternatives to a single robot design.  You will have to look at how all the design alternatives integrate together and which have the highest potential of getting done in the six weeks.  How do you do this?

Well here is a suggestion, pick your number 1 attribute that you want your robot to do and it may have changed based on your risk assessment and then look at all the other attributes that can be integrated into the number 1 design.  Some of the best robots only do one thing very well and the other attributes were medium to no impact on the design.  So the suggestion here is to pick your number 1 attribute with a risk that you are willing to accept and design your robot around it.  Have a review with your team members because this is going to be critical to your success that everyone understands the final design and in dividing up the tasks.

In a standard system design you would do CAD drawings and computer simulations to make sure that the integrated robot will work.  But, since the time is a very binding constraint, you may have to start cutting metal and modify your design as you go.  This is where that feedback comes in design cycle.  You design and build, test the system to your target goals, identify the gaps, redesign.  Take your time before you get to your critical design review, and make sure you understand your design.  Reduce that redesign iteration on your robot.   

Configuration Control 

Put your robot under configuration control at this time and have periodic configuration control meetings, where significant changes to the design have to be evaluated for the effects to the other systems.  A mechanical change to move the location of the camera could have significant effects on the programming of the software.  In some organizations,  engineers can not make any changes to the aircraft systems without requesting the change through the Configuration Control Board (CCB).

Software Integration and Testing 

Home stretch now, the robot is “done”.  Really it is never done, but anyway it is done enough to do final integration and testing.  This is CRITICAL to your competition success!  Many teams allow little or no time for the software loading and testing.  Software could be the most time consuming and riskiest part of any system, you need time to do it right.  So please work adequate time into your schedule for software installation and system testing.  When your software is working, you would perform a combined system test with the robot and other systems. 

Operational Review

Before the shipping date, perform one last operational review and it may generate action items that have to be done when you get to your competition.  So in summary, here is a suggested list of items to do for the design process. 

1. System Requirements
2. Robot Attributes  (Conceptual Design Review)
3. Generate Alternatives
4. Assess Design Risk
5. Decide on the designs to take to prototyping (Preliminary Design Review)
6. Integration meeting (Critical design review)
7. Periodic Configuration Control Meetings
8. Software integration and testing
9. Combined systems testing
10. Operational Review
11. Shipping

Schedule

How long to take for each item?  Well that is going to entirely depend on your team’s experience, the risk you accepted for the design, and the amount of time your team can spend on robotics.  But here is a suggestion, only 1 week to get to your PDR and then spend about 2 weeks on prototyping and design.  End of the 3^rd week you have a critical design review then spend two weeks for the final build and subsystem testing.  Spend the last week doing final integration and testing with the Saturday before shipping discussing the operational readiness of your robot system.   It would be nice to have two weeks for final integration and testing, but based on some experience in a FRC construction phase, that might be impossible.  During your configuration control meetings you should look at how you are meeting the requirements such as weight and size.

It is important that during the construction phase that you keep looking at the Big Picture, keep tight configuration control on your robot, HAVE FUN and be the FIRST STAR OF SE!!!!!!!