S11-FRC Robot Project Lifecycle

#all #systems #engineering #documentation #frc

1 Purpose

The purpose of this document is to explain and standardize the procedures for managing the design and construction of competition robots for FRC.

2 Scope

All Departments and team members.

3 Terms

4 Overview

The Grayson Robotics FRC-robot project life-cycle is based on the NASA Systems Engineering Handbook.

We use the NASA process because NASA system life-cycles are more similar to FRC than the commercial product life-cycles common in INCOSE and other examples.

5 General rules

  1. Use of LLMs or any "Generative AI" is prohibited.
  2. The Systems Engineering (SE) department shall design the robot to fulfil the Season Strategy.
  3. All other departments shall work IAW the designs created by the SE dept.

5.1 Validate designs

Team members shall validate designs using: Prototyping, Standards, prior work done by the team, or prior work from external sources.

5.2 The System Under Design (SUD)

The System Under Design (SUD) is: the robot itself, the driver station, and the cart for transporting the robot to & from the field.

6 Design vs Research

All steps prior to building the final robot can be separated into either design activities or research activities. Generally speaking, design is how you decide precisely what to do and research is how you figure out what you could do. Research includes prototyping, R&D tasks done prior to the season, and researching existing solutions to similar problems.

7 Tractability and Single Source of Truth (SST)

A core goal of a design process is to ensure that everyone always knows where to look to find out what their design effort is supposed to accomplish, and to ensure that there's no conflicting information to that effect.

This requires maintaining a Single Source of Truth for all design work.

Furthermore, the design process must ensure that all decisions are traceable back to the first design decisions; design decisions must be traceable.

7.1 Trace design decisions to the strategy

Team members shall ensure all designs are justified, at least transitively, by the Strategy.

By "transitively" we mean that: even if the design decision isn't directly justified by some part of the Strategy, it must be justified by some part of the system design that is itself justified by the strategy.

8 Prototyping

The most immediate way in which socializing helps the prototype is that other people (experts in the domains you are not) can tell you that it’s wrong. Which is something that often feels forgotten: the purpose of prototyping is to try something in the cheapest format possible, so that we can come to know the ways in which it is wrong.

Pavel Samsonov, UX works through social relationships. AI tools are erasing them.

Prototypes exist to test a hypothesis, and to allow others to provide good feedback on design decisions.

8.1 Document your prototypes

Team members building prototypes shall document:

  1. the hypothesis being tested
  2. the part of the strategy they intend to fulfill
  3. the part of the system design they intend to implement

8.2 Get clearance for resource usage

Prior to building a prototype: team members shall submit for review an estimate of the materials required to the departments responsible for the materials.

9 System architecture model

Throughout the project, the team shall incrementally create a model of the system architecture IAW: S13-System_Architecture_Model.

The System Engineering department shall maintain the system architecture model.

9.1 Use Obsidian to organize the model

The Systems Engineering dept. shall use an Obsidian notebook to organize the system architecture model IAW: S14-System_Architecture_Modeling_in_Obsidian.

10 Interdisciplinary Design Conflicts

The Systems Engineering dept., with a view of the system as a whole, is best positioned to resolve design conflicts between other engineering disciplines. It is the responsibility of all team members to bring design conflicts to Systems Engineering as soon as possible.

If no resolution is evident, this signals a likely deficiency in the teams strategy, requirements, or standards. In this case, revisit requirements, standards, and strategy and amend them where necessary.

10.1 Systems Engineering resolves design conflicts

  1. The Systems Engineering dept. shall resolve design conflicts based on:
  2. All team members shall submit design conflicts to Systems Engineering for resolution.

11 Project Life-cycle Overview

The purpose of the project life-cycle is to organize the robot build effort into discrete steps so as to establish a schedule and efficiently divide work among team members.

The robot project life-cycle is five phases:

  1. Concept Study: understand the problem.
  2. Concept & Technology Development: formulate a strategy and establish the role of the robot.
  3. Preliminary Design & Technology Completion: model how the system will function and prototype it.
  4. Final Design & Fabrication: design the system hardware and software.
  5. Assembly, Integration & Test, Launch: build the system and prepare the operators.

12 Concept Study

Concept studies mostly occurs at the game design phase handled by FIRST, but the team is still responsible for setting its goals for the season. We decide and document our season goals before the season starts, as such they are agnostic with respect to the game rules.

The outputs of the concept study phase are: the game manual, team goals, and a preliminary strategy.

12.1 Game Manual

The Game Manual provides three important categories of information: fabrication requirements, game & tournament rules, and field specifications. All team members need to read and understand the rules, as every department has responsibilities requiring knowledge of the game manual.

There are less obvious reasons that team members would need to read the manual, for example:

12.2 Team goals

Team goals are a collection of the goals of each department.

12.2.1 Document the team goals

Grayson Robotics shall document our goals are prior to the beginning of the build season:

  1. Each department shall document goals for that department as a User Story.
  2. The Strategy dept. shall incorporate the goals of all departments into a unified User Story.

12.3 Preliminary Strategy

The Preliminary strategy is a strategy for preparing to meet our Team Goals during the upcoming season.

It can include such activities as courting certain key sponsors, or may outline which events we want to attend.

12.3.1 Create a Preliminary Strategy

The Strategy dept. shall document a preliminary strategy prior to the beginning of the build season:

  1. Each department shall create a draft strategy for their role in achieving theTeam goals in the form of a user story.
  2. The strategy department shall incorporate each departments strategy into a unified User Story.

12.3.2 Decide which events to attend

As part of the Preliminary Strategy, the Strategy dept. shall decide which district qualifying events to sign up for.

13 Concept & Technology Development

The purpose of concept & technology development is to fully understand what the system needs to do. Most systems engineering work happens here.

At this stage, we build prototypes to understand how we can handle game-pieces and nothing else. For example:

We cannot build more involved prototypes until this phase is complete.

The outputs of this phase are:

13.1 Build Practice Field Elements

It is essential that the team prepare to build field elements ASAP so that designers have life-size references and old robot mechanisms can be tested as rough prototypes:

13.1.1 The Manufacturing dept. builds field elements

  1. The Manufacturing dept. shall build all field elements within three (3) days of Kickoff.
  2. The Manufacturing dept. shall prepare before the season starts by using past field specifications to estimate what tools and materials will be needed by kickoff.
  3. The team shall ensure a budget is available on Kickoff for this purpose.

13.2 Handling Analysis

Analyze how game pieces interact with different materials and common mechanisms from prior seasons.

For example:

Team members should not create more involved prototypes prior to approval of the System Needs Analysis, so as not to bias the strategy or system development.

13.2.1 Creating the Handling Analysis

  1. The Systems Engineering and Strategy departments shall maintain a Handling Analysis document as part of the Season Strategy documentation.
  2. All engineering departments shall use this information to check that their designs are feasible.

13.3 Game-Play Analysis

Analyze how long different actions may take. Find the theoretical maximum number of times a team could score via particular methods, and try to estimate what the maximum scores could be based on physical limitations. Use this to set preliminary performance targets, the feasibility of which will be tested by the engineering departments with prototypes.

13.3.1 Creating the Game-Play Analysis

  1. The Systems Engineering and Strategy departments shall maintain a Game-Play Analysis document as part of the Season Strategy documentation.
  2. All engineering departments shall use this information to check that their designs are feasible.

13.4 Degrees of Freedom (DoF) Analysis

A DoF is An axis of rotation or translation of a part of the robot. game piece, or field element.

In the context of FRC we're concerned with the minimum, discrete, and (per the game manual) unavoidable motions required to acquire, transport, and score game pieces or the robot.

Analyze and document every DoF required to acquire and score a game piece.

#todo

13.5 Season Goals

Season goals are a list of things the team wants to accomplish at competitions and in matches given knowledge of the game.

Season goals extend and incorporate the Team goals.

13.6 Season Strategy

A strategy is a plan to meet certain goals. Likewise the Season Strategy is our plan for meeting our Season Goals.

To create a strategy we have to use the Handling Analysis, Game-Play Analysis, and DoF Analysis to figure out a plan to meet our Season Goals. At a minimum, the strategy must set priority between different scoring methods, and state our plans for how we will approach competitions.

13.6.1 Season Strategy requirements

  1. The Strategy dept. shall create a draft Season Strategy.
  2. The Strategy dept. shall seek approval from each department for this plan.
  3. The strategy shall include:
    1. Scoring priorities.
    2. Competition plans.
    3. Game-Play Analysis
    4. Handling Analysis

13.6.2 Scoring Priorities

Set priority levels between different scoring methods rather than detailing individual match plans. Setting priority between scoring methods helps the team set priorities between design and manufacturing efforts.

13.6.3 Competition Plans

Competition plans should seek to answer, at a minimum, these questions:

Competition plans are User Stories, usually in the form of a Brief Use Case Structure), collected from each department that detail their plans for each competition.

13.6.4 Strategy Verification

All team members review the draft and each department approves it. If they don't, the Strategy dept. revises the strategy until all departments approve.

13.6.5 All departments approve the strategy

Approval is per department not per member.

  1. All team members shall review the draft Season Strategy.
  2. Each department shall approve it or, if they do not, the Strategy dept. shall revise it.
  3. Each department shall use its own internal method for deciding weather to approve the strategy.

13.7 Using the Operational Analysis (OA)

The OA depends on the strategy but the Systems Engineering dept. can start work, using the FRC Game Manual, before the strategy is approved.

OA documentation takes the form of Detailed Use Cases and Implementation requirements, where the scope is the team rather than the System Under Design (SUD) which include the robot, driver station, and the field operators (drive team).

13.7.1 Moving from Strategy to OA

After the team approves the strategy: the Systems Engineering department shall complete the OA.

13.7.2 Consider all operations in the OA

The Systems Engineering dept. shall consider everything the team will need to do at a competition (not just what happens during matches) in the OA.

13.7.3 Create match plans during the OA

Create a Detailed Use Case Structure for every match scenario we need to be able to carry out to achieve our goals. The scope should not be the SUD at this stage, rather, we would write the user story as if the team is the scope, even where we predict that the SUD would perform most or all of the tasks. Match plans should be specific and granular. In 2025 that would mean enumerating the specific pegs and order to place coral.

#todo

13.8 Using the System Needs Analysis (SA)

Create use cases that reference and rewrite OA use cases where the robot is the scope.

If you recognize that there are new scenarios that arise from considering the SUD separately from the team, add those as use cases in the SA. This would be the time to add scenarios that cover things that the Game Manual mandates be done with the robot or driver station, though these should not be considered separately until the PA.

If a Use Case needs to be rewritten or split, the Systems Engineering dept. shall write a new Use Case(s) that references and supersedes the old one.

Software development for the main robot can start using the completed SA.

13.8.1 Reference the Game-Play Analysis

The Systems Engineering dept. shall reference the DoF identified in the Game-Play Analysis when assigning functions to the robot.

13.8.2 Allocation of OA Use Cases to the SA

The Systems Engineering dept. shall designate which requirements created as part of the OA will be fulfilled by the robot.

13.9 Acquire-Deposit Prototypes

Acquire-Deposit prototypes are sub-systems that can acquire game pieces and deposit them in ways that meet the strategy. This means, for now, ignoring how the pieces will be stored and transferred through the robot. The goal is to create several alternatives that we can select our final design from later.

This should start as soon as the SA is complete. Use the SA to weed out prototypes that won't be needed prior to the next design phase.

14 Preliminary Design & Technology Completion

Use prototypes to figure out what's feasible for the robot to do and finalize a concept.

Set final performance requirements using the prototypes to ensure that the requirements are feasible.

The outputs of this phase are: interface prototypes, Logical Architecture, and Prototype Selection.

14.1 Interface Prototypes

Prototype the mechanisms that will transfer game pieces from intake sub-systems to scoring sub-systems. This should start as soon as the System Needs Analysis is complete as we will want to be sure that the robot will need the mechanism.

14.2 Using the Logical Architecture

The LA guides prototyping by giving component designers clear goals for what prototypes need to do, so that they can then select which prototypes to use to guide the final design.

Prototyping is complete when the LA is complete and there's at least one prototype to fulfil the role of each LA Component.

14.3 Prototype Selection

Select the combination of prototypes that will ultimately be combined into a final robot design. This will constitute a complete robot concept.

Consider these factors for comparing prototypes:

14.3.1 Systems Engineering selects the sub-system prototypes

  1. The Systems Engineering dept. shall select which sub-system prototypes will become the prototype robot.
  2. The Systems Engineering department shall describe the selections in the Physical Architecture documentation.

15 Final Design & Fabrication

Construct a prototype robot from the selected prototype sub-systems.

For the competition robot, document, at the greatest detail possible, what specific components will be used through both 3D CAD and written technical documentation.

The outputs of the phase are: the Physical Architecture, prototype robot, and a final CAD model.

15.1 Using the Physical Architecture (PA)

We use the PA to: document prototype selection, refine our understanding of the expected behavior of the final versions of prototypes, and model the physical interactions between the real components.

Using the prototype selection: allocate abstract components in the LA to the physical PA sub-assemblies, and rewrite the linked LA use cases to describe interactions between the physical components.

The first use of the PA is, by writing out all the interactions between the PA components, you are able to find edge cases and requirements that may have been missed. The second use is to create documents that will be useful for maintenance and operator instructions.

PA components will become the first level sub-assemblies in CAD.

15.2 Prototype Robot

The prototype robot needs to be useful for drive practice and code testing, and remain so throughout the season.

15.2.1 The PA to describes the prototype robot

  1. The Systems Engineering dept. shall describe how the prototypes interact with each other in as much detail as each engineering department requires.
  2. The Systems Engineering dept. shall update the PA throughout the Final Design & Fabrication phase as more refinement becomes necessary.

15.2.2 Build a prototype robot

The team shall construct the prototype in accordance with the PA.

15.2.3 Update the prototype robot to match the competition robot

  1. Engineering and manufacturing departments shall update the prototype robot to match the PA and competition robot.
  2. The Programming dept. shall write code with abstractions that allow them to share logic between the prototype and competition robots, despite non-functional differences between the two physical systems.

15.3 Final CAD

The final CAD should include details down to individual components expected to be assembled or manufactured by Grayson Robotics. Furthermore, components should have material properties set or have their mass manually entered to ensure accurate weight and center of gravity estimation.

The model should generally exclude individual wires and connectors except where the Electrical dept. expects the connector to be disconnected as part of normal operation. Routing paths for wire harnesses should be modeled (as massless 3D spaces) to ensure that designers consider what paths and surfaces are safe for wires and where wires are expected to flex with a moving mechanism.

15.3.1 Set material properties for parts

  1. Where a part is a single homogeneous material with an entry in the CAD software's material library: designers shall set material for the part.
  2. Where a part is a single homogeneous material without an entry in the CAD software's' material library: designers shall manually set the mass of the part.

15.3.2 Set mass for composite parts

Where a part is a composite or a simplified model of an assembly: designers shall manually set the mass of the part.

16 Assembly, Integration & Test, Launch

This is the final phase of the build. The team should minimize changes, focus on developing operations and training documentation, and facilitating operator practice.

16.1 Initial Competition Robot

The team shall ensure that an initial competition robot is ready for practice no less than one (1) week before the first district qualifier to allow time for: testing, practice, and adapting operations equipment (e.g. the cart).

16.2 Upgrades

Designers shall test upgrades on the prototype robot before the competition robot whenever possible.

16.3 Plan rollbacks before integrating upgrades

The sub-system or component designer and the Systems Engineering dept. shall produce a plan to restore the robot to its prior state before integrating any upgrades after the first district qualifier competition.

17 Project Schedule 2027

The Strategy and Systems Engineering dept. shall updated this section to reflect the next year by the last day of November in the year prior.

[!NOTE] Note This schedule assumes we need to robot to be ready to compete in the first week of March 2027 and is currently preliminary.

17.1 Concept & Technology Development Schedule

17.2 Preliminary Design & Technical Development Schedule

17.3 Final Design & Fabrication Schedule

17.4 Assembly, Integration & Test, Launch Schedule