[davidfv]

SE and the Construction Phase
I was going to start from the beginning but there is only 2 weeks before KO and I think it would be better to start at the construction phase.

I saw a thread in the forum posted in 2003 asking the question “How do you design your robot” In that thread Ken Wittlief wrote a great post about the engineering design process and so some of the ideas that I am writing here are NOT new, but maybe just a different way of looking at the process and how to evaluate the results. Google engineering design process and you will get millions of hits (201Million on my last Google). So the basic framework of the design process I am going to reference is shown in the figure below:


[As soon as I figure out how to get the figures in the articles I will do it. Meanwhile, I suggest to just look at the attachment.]

The outline of the steps to frame the problem, generated alternatives, prototype, experiment, evaluate results, identify gaps, and repeat. 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 requirements 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.
Now 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).

You have a good grip on the requirements, now 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…
Everyone will have a voice in the rankings and will in turn understand what the robot could do and how the team decided on what it would do… initially.

We understand 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 will get back into the small design groups and brainstorm on possible design alternatives.

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.

What is a 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 3.
Then maybe move it to a more visual matrix that you can make decision. You can use this type of matrix for almost every critical decision you might have to make.
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 are going to put into your design; it is easily done and has high impact to the game. 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.

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 that I saw last year did 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 figure 1. 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.

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. At NASA Dryden, engineers can not make any changes to the aircraft systems without requesting the change through the Configuration Control Board (CCB).

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! I have read many teams allow little or no time for the software loading and testing. I have found that software is 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. 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. Prototyping and Testing
7. Integration meeting (Critical design review)
8. Periodic Configuration Control Meetings
9. Software integration and testing
10. Combined systems testing
11. Operational Review
12. Shipping
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 3rd 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. I would personally like to have two weeks for final integration and testing, but based on my first year actually 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 BP, keep tight configuration control on your robot, HAVE FUN and be the FIRST STAR OF SE!!!!!!!

The teams that have had a long history of success probably already do all of this without even thinking about it. I congratulate them, but if you think it is good information and want more of these articles, just let me know. I have thoughts on what to do during construction for those people not in the design process, how you can optimize your fun and success at the competitions, what to do after the final bell as you enter your recognition phase, and finally what you could be doing during the next season’s formulation stage.

Possible future titles:
Systems engineering and the rest of the systems during construction phase
Systems engineering and the Competition
Systems engineering and the Awards
Systems engineering and the Recognition
Systems engineering and Outreach
Systems engineering and Formulation for next year