My name is David and I am an engineer at NASA Dryden Flight Research Center. I have been involved in FIRST for a couple of years, mostly judging websites. But last year, I finally got involved with a team (#399) when my son joined up. I saw in the team great students, mentors, and advisors. I did not know what I could contribute to the team that they already did not have, but as I went through last season, I felt that if the team would take on better system engineering practices, they could achieve so much more. So in my mentoring efforts, I have been discussing system engineering practices that may help the team succeed. They have taken some ideas and laughed at others, which is OK because each team has to develop their own practices and I am just here to help. So I am working on developing a Systems Engineering Plan for robotics that I think might be a help to new teams and new people to FIRST. I thought that if I would start posting my thoughts (design), get feedback (validate), and then post results (implement) I would end up with a better overall plan.
I have seen quite a few posts on manufacturing techniques, electronics, the competition, clues, chairman award, programming, but how does this all fit together? This is a pretty daunting task for any of the new teams and for any rookie on an experienced team. I really feel that what we have learned at NASA, in industry, and universities about system engineering can be applied to FIRST robotics. It is so critical in our NASA programs that we apply good system engineering practices.
My goal in this series of articles (or thoughts and ramblings) is to discuss good system engineering practices throughout the FIRST season (or lifecycle in systems engineering terms) and help teams develop an approach that could help them succeed. I have broken the lifecycle into five distinct phases: Formulation, Organization, Construction, Competition, and Recognition. Each phase has different requirements and objectives that if thought out in your team’s organization and planning may help bring success to your team. Right now my thoughts are to write an article on what is systems engineer and how we can apply it to each of the phases starting with the Construction phase.
So, if you enjoy the writings and find them useful, please let me know.
My disclaimer: These writings are just my thoughts and do not represent any official FIRST position or any team or NASA opinions. You may not always agree, but that is OK because your team has to develop your best practices and I am just here to help.
My first post in this thread outlined my objectives and reasons for wanting to discuss systems engineering:
Develop an understanding of the systems engineering process
Construct a System Engineering Plan
Help teams succeed
Also in the first article I proposed five phases for the Robotics Lifecycle (season).
Formulation
Organization
Construction
Competition
Recognition.
This second article is a general discussion on what is systems engineering and what systems make up a team.
So proceed at your own discretion but please read my disclaimer: These writings are just my thoughts and do not represent any official FIRST, any team or NASA opinions. You may not always agree, but that is OK because your team has to develop your best practices and I am just here to help.
What is Systems Engineering?
You have all heard about Aerospace, Electrical, Civil, and Mechanical Engineers, who specialize in certain area, but what is a system engineer and what do they do? A systems engineer takes a look at the “Big Picture” and defines, develops, and implements the systems. They work with a group of experts in various areas of specialization to achieve a common goal. It is part management and part technical. Many different definitions are out on the web on systems engineering, I Googled (is that a verb in the dictionary yet?) Systems Engineering and got 363 Million hits. Let’s look at a simple example of what a systems engineer would do.
An aircraft manufacture wants to build a huge jumbo jet, bigger than anything else built. It will seat 600 people. They put all their resources into the design and manufacturing but find out that no one will buy it. Why? Well they found out that no airport could accommodate that big of an aircraft, the air space system would have to have larger separation due to wake turbulence (less landings), and loading and unloading the passengers would take way too long. A systems engineer would have looked at the initial design of the aircraft and then all the other systems like the airports, air space, and passenger systems and realized that just building the jumbo jet is not going to make it successful, the infrastructure would have to be redesigned too.
A lot of concentration in robotics is given to the design and building of the robot, but is the robot the only system you have to design? I would say NO, the robot is only one subsystem of the FIRST system at a team level. So what is the FIRST team system? The elements of the FIRST system will be different for each team, but here are some subsystems that I feel need dedicated design efforts. I am only looking at the system from a team level. The Team Handbook on the FIRST FRC website has great discussions on several of the items that I will be outlining in these articles. (http://www.usfirst.org/community/frc/default.aspx?id=966). A must read for rookie and veteran teams alike. So here are my thoughts on the six subsystems that make up the FIRST team system. Each subsystem has its own subsystems that will be discussed in future articles.
**
Safety System: ** Working around the tools, the metals, and the robot could create safety hazards that have to be identified and managed. Establishing a good safety system within your team is important within the total FIRST system. Plan, design, and implement safety in all that you do.
**The Team System: ** The team system is how you are going to design your team. The handbook on the FIRST website is an excellent resource on some team structures. Also part of your team is the mentors, advisors, and community supporters. What is your team philosophy and rules of conduct? The design and building of a great team system is the foundation to your future success. Is your team organization during the construction phase the same as the organization during the competition phase? (I will discuss this in another post) Archive System: What? Well as you are designing your robots, your safety system, and your team, you have to really be thinking about how you are going to document the success and failures. Does your team document its software from last year, what worked for fund raisers; do you have a design notebook that future teams can use? Documentation is vital to a good systems engineering approach to any design, take some time to think about this system and I am sure you will not be sorry. The Robot System: Well this system is probably given the most time and dedication during the course of the year. A good robot system will give your team recognition during competitions and could bring home a competition championship. The ultimate high to win the Chairman’s award will take more than just a great robot. The Outreach System: This system is a little more abstract but how is your team designing your community outreach? Do you have plans for media events, elementary and middle school demonstrations, sponsoring Lego and/or VEX teams. The vision of Dean Kamen is to “…to create a world where science and technology are celebrated…where young people dream of becoming science and technology heroes….” How does your community outreach system inspire others?
**Financial System: **Well this one is required for every team. With potential budgets running from $10,000 to $20,000, a well run financial system will be vital to building a robot, traveling to competitions, recognition banquets, etc… How do you develop your budget, how do you get corporate sponsors, and how do you do fund raising?
Working for the Government, we have tons of acronyms and of course I developed one for the Systems Engineering (SE). So, if you want to be a FIRST STAR OF SE, remember these team subsystems Safety, Team, Archive, Robot, Outreach, and Financial. (well, I thought it was funny)
How do these subsystems work together in each phase of the lifecycle (season)? In further discussion, I will describe how the systems could work together for a successful season during the robot build and competition phases.
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:
Carts must remain in the team pit area when not in use for robot transportation
All carts should fit through a standard 30-inch door
Wheels on the cart must not damage site flooring
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.
System Requirements
Robot Attributes (Conceptual Design Review)
Generate Alternatives
Assess Design Risk
Decide on the designs to take to prototyping (Preliminary Design Review)
Prototyping and Testing
Integration meeting (Critical design review)
Periodic Configuration Control Meetings
Software integration and testing
Combined systems testing
Operational Review
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
Wonderful contribution! This is the type of stuff every student should be required to read. To make these articles stand the test of time, you can save them as a PDF with your favorite word processor, then upload them as a white paper @ http://www.chiefdelphi.com/media/papers/upload/
Team 330 has done a presentation on system engineering at the CSUN workshops at least twice. It’s a powerpoint, so I don’t think it could be a whitepaper as is. I might be able to get the authors to make a whitepaper. If not, I have a suggestion for practicing system engineering: take an old game and develop a strategy and requirements for it. 1999 might be a good example. Then, compare with the winners. Did you get it right? If not, figure out where you screwed up.
First off, I would like to thank David for some useful information.
As a System Engineer major, I would strongly recommend all the teams to use System Engineering Models to create their projects or teams in general. It not only helps highlight the main goals, but also helps carve out the paths to get to those goals.
A good example would be Team 612. This team is based on a system engineering class (backed up by professors from George Mason University, one of the leading school in this field). Within one year, the team has achieve not only achieved the short term but long term goals too (CA and EI awards). Also they kept documenting their success and projects in form of gant charts and other useful material for the coming generation to use for. Some of their work can be found at http://www.wikibotics.org (Systems and Systems Competence)
GREAT stuff!!!
Another similar effort (althiugh not fully “system engineering”)has been put forth by team 365 and is called “MOEmentum FYI”. Thought I’d share the link so you can see what else has been done: http://moe365.org/moementum.php
In discussions with The Team399 team manager and others we have further developed a Systems Engineering Approach Website to FIRST Robotics. This approach has taken a look not just at the construction of the robot, but the whole year broken into the phases that were described in the previous post. It is a work-in-progress and we are looking for your feedback
Less than 10 hours to go till KO…:ahh: :ahh: :ahh: