This template is saved under “Final Blog Post Template”
Your Project Name Here Generation Number Summary Blog Post
Author/s:
Verification:
Approval:
Table of Contents
Executive Summary
Imagine hearing the rotors of a helicopter. Shortly thereafter, the CEO of the company steps into the conference room apologizing for being late; he/she steps to the podium and tells everyone how important the project is to the future of the company. Unfortunately, the CEO has to fly off to another meeting. He/She will read about your project on the helicopter as it flies to the airport. That means you have just a few moments to convince him/her not to cancel your project. Shortly thereafter, you hear the rotors of the helicopter spin-up and he/she is gone. Write your executive summary with this scenario in mind.
Program and Project Objectives
Program Objectives
The Robot Company (TRC) will be debuting its 2019 line-up of toy robots and associated games at the Toy-Invasion 2019 convention in Burbank CA on January 6, 2019. Your team’s assignment is to make the 3D printed and/or laser-cut prototypes to be showcased at the convention, prior to production starting in the second quarter of 2019. The robots will feature our new ArxRobot smart phone application and the Arxterra internet applications allowing children to interact and play games around the world. In addition, the robots should be able operate autonomously in game mode. See game(s) (i.e, mission objectives) assigned to your robot by the Game Division. To decrease electronics cost, interoperability between all TRC robots will be maintained by incorporation of the 3DoT board, developed by our Electronics R&D Section. Modification of downloadable content is limited to software switch setting and robot unique graphics of the smart phone and Arxterra applications. Modifications of electronics is limited to custom 3DoT shields as required by the unique project objectives of your robot. The Marketing Division has set our target demographic as children between the ages of 7 and 13, with a median (target) age of 11. To decrease production costs, please keep robots as small as possible, consistent with our other objectives. As with all our products, all safety, environmental, and other applicable standards shall be met. Remember, all children, including the disabled are our most important stakeholders. Our Manufacturing Division has also asked me to remind you that Manufacturability and Repairability best practices must be followed.
Project Objectives
Hexapod Fall 2013 Example Text.
The TRC Hexapod project will offer an opportunity to study the limitations of a robot over a realistic terrain. A hexapod robot offers increased maneuverability and improved stability over traditional rovers. Its low center of gravity allows the robot to move over terrain that might limit a tracked or wheeled rover. Its six legged jointed design will allow the robot to change height permitting it to overcome taller obstacles that would otherwise obstruct its path. Its integration with an Android phone and open-sourced control boards allows for future builders to easily recreate or improve on the Hexapod design.
Mission Profile
Provide a short summary of the Mission Objectives with a link to the formal definition of the mission.
Project Features
This section should include at least one annotated figure. The figure may be an annotated System Block Diagram, Photo, Illustration, or exploded 3D Model showing the major subsystems/components/features of the design. Text should talk to this figure(s). This is the last section the CEO will be reading.
Requirements
References:
- Arxterra / Classes / Engineering Method, select
tab, scroll down to Requirements. - APPENDIX C: HOW TO WRITE A GOOD REQUIREMENT NASA Systems Engineering Handbook (page A:279)
- IEEE Guide for Developing System Requirements Specifications
After reviewing the above material, write your introduction here.
Engineering Standards and Constraints
Review and show compliance with constraints on the project imposed by The Robot Company (i.e., CSULB) and Project Stakeholders. Specifically include University and applicable environmental, health, and safety standards and those safety standards specifically associated with the product (e.g., Children’s Toys).
Applicable Engineering Standards
Add material from the “Applicable Engineering Standards” section of the “Add material from the “Program Constraints” section of the “The System Engineering Method” lecture as applicable to your project here.” lecture as applicable to your project here.
Environmental, Health, and Safety (EH&S) Standards
Add material from the “Environmental, Health, and Safety (EH&S) Standards” section of the “Add material from the “Program Constraints” section of the “The System Engineering Method” lecture as applicable to your project here.” lecture as applicable to your project here.
Program Level 1 Requirements
After establishing which requirements apply to your robot provide a consistent numbering system (for example L1-1, L1-2, …) allowing traceability to dependent Level 2 requirements. Please review the Requirements lecture material to learn more about Requirements Traceability.
Add material from the “Program Constraints” section of the “The System Engineering Method” lecture as applicable to your project here.
Project Level 1 Functional Requirements
Provide a short summary of the Project unique Level 1 Functional Requirements.
System/Subsystem/Specifications Level 2 Requirements
References:
- Arxterra / Classes / Engineering Method, select tab, scroll down to Defining Level 2 Requirements.
- APPENDIX C: HOW TO WRITE A GOOD REQUIREMENT NASA Systems Engineering Handbook (page A:279)
- IEEE Guide for Developing System Requirements Specifications
Provide a short summary of Derived Design dependent Level 2 Requirements. These level 2 requirements must provide links to the original level 1 design independent requirement(s) upon which they are “derived.”
Recommended subsections include: Mission, Systems, Electronics, Software (includes Firmware), Mechanical/Manufacturing, and Safety and Quality Assurance.
As you document your level 2 requirements, apply a consistent numbering system (for example L2-1, L2-2, …). Show traceability to the Level 1 requirement(s) from which they are derived.
Subsystem A (e.g. Mission) Requirements
Subsystem “A” derived design requirements.
Additional Subsystem Requirements
Additional subsystem derived design requirements.
Allocated Requirements / System Resource Reports
Allocated requirements, also known as resource reports, are written and tracked by the System Engineer. The types of resource reports are based on the project. For example, power allocation/estimate for each subsystem module of a spacecraft would be important, while a more loose tracking for a toaster would be in order. Each resource should have a margin attached to it based on the uncertainty in the estimate. It should also show contingency, where contingency is defined as the project allocation minus the estimate plus total margin.
This section is comparable to the previous power allocation section however, dedicated to the updated mass of the project. Also in a tabulated format, it should contain the expected weight, measured weight, percent uncertainty, and margin for each respective resource being used in the project. Lastly, it should contain total expected weight, total margins, project allocation, and contingency.
Section shows updated useable capacity of the power source selected for the project. Typically represented in a tabulated format, it should include an expected current drawn, measured current drawn, percent uncertainty, and margin for each resource consuming power. Lastly, it should contain total expected current, total margins, project allocation, and contingency clearly showing the power source selected will support the project.
Any other resources tracked by the system engineer. For example, 3DoT projects using a 3D printer have an 9 hr. (3/3/3) resource requirement that must be tracked.
Project Report
Introduction to the section.
Project WBS and PBS
Project Work Breakdown Structure (WBS) and Product Breakdown Structure (PBS).
References:
- Chapter 4, section 3 of the NASA Systems Engineering Handbook titled “Logical Decomposition” includes a section that briefly covers the Product Breakdown Structure (PBS.) Chapter 6, section 1 titled “Technical Planning” includes a section that explains the relationship between the Work Breakdown Structure (WBS) and the PBS. The PBS is the responsibility of the systems engineer. There is not quite enough information between these two sections to create a long presentation; instead focus on first going over the info, and then work with your division members to create an example PBS during the meeting.
- NASA SE Handbook Sections 4.2, 4.3-2, 6.1-4/5,G-1
- Arxterra / Classes / Engineering Method, select tab, scroll down to The Robot Company Work Breakdown Schedule.
- WBS and PBS PowerPoint by Avi Sharma
Cost
This section should contain an updated table listing all of items purchased for the project including prototype cost, parts and implementation, PCB manufacturing cost etc. Like all allocated resources (see Mass and Power), this chart should contain the expected cost, actual cost, percent uncertainty, and margin for each item listed in the table. Lastly, it should show the total expected/final cost, total margins, project allocation, and contingency.
Schedule
This section should contain an updated schedule, generated through programs like ProjectLibre or Microsoft Project, showing the system and subsystem tasks that have been completed or are still in progress. It is important to include the project’s critical path (visually representing the critical path in the schedule diagram is recommended).
Burndown and/or Percent Complete
Summarize schedule status including percentage complete and if available a burn down diagram.
Concept and Preliminary Design
Introduction to the section.
Literature Review
Provide theoretical background, concepts involved in the design process and a summary of the key literature and online resources (e.g. Arxterra – Project Summary Post) that has been researched and used in the design effort. A summary of similar previous designs can also be discussed to show strength and weakness of your design compared to others.
Design Innovation
Creative solutions introduced with this generation.
Conceptual Design / Proposed Solution
Provide details of the proposed solution that meets the project specifications while best satisfying the applicable constraints. Provide block diagram representation of the proposed system, discuss each subsystem in detail and provide any preliminary results including simulation or analytical results to support your hypothesis. Also provide an initial budget estimate and timeline for the completion of the project.
System Design / Final Design and Results
Present and discuss the final design along with any modifications made to the conceptual / preliminary design.
Subsequent sections should cover….
Discuss the major subsystems in the design and the purpose and features of each subsystem. Provide schematic drawings, simulation results and experimental results if any and discuss the comparison between the two. Demonstrate that the designed project meets all requirements. Provide sufficient details of the design for reproducible. Discuss the operation of the project in terms of safety and fail-safe mechanisms that are incorporated in the design.
Detailed System Block Diagram(s) of the design. This is an updated and more detailed version of the block diagram presented as part of the conceptual design. Identify connectors, numbers of wires in a bus, and when practical, the names of the wires and busses. As part of your write-up, walk the reader through each subsystem/component block and how they are interconnected (i.e., subsystem and interface descriptions).
System Block Diagram
Detailed System Block Diagram(s) of the design. This is an updated and more detailed version of the block diagram presented as part of the conceptual design. Identify connectors, numbers of wires in a bus, and when practical, the names of the wires and buses. As part of your write-up, walk the reader through each subsystem/component block and how they are interconnected (i.e., subsystem and interface descriptions).
Interface Definition
This section is an updated version of the Interface Matrix presented at the PDR and CDR. An additional section should discuss the Cable Tree (i.e. wire harness, wiring diagram, etc.) developed in concert with the E&C and MFG showing how the wires, cables, and connectors were integrated into the final product.
If your project has includes and Interface Control Document (ICD), it would go here: top level explanation of MST communication, E&C connections, MFG mating and fastening → to be covered in detail later in the presentation during respective sections.
Modeling/Experimental Results
References:
- Arxterra / Classes / Engineering Method, select tab, scroll down to Design Process and Modeling.
- IEEE Guide for Developing System Requirements Specifications
Section includes is a table showing the title of all modeling originally planned and completed. Completed tasks should provide name and link to associated posts.
Following sections should showcase a few modeling tasks. Refer to Model Grading Scale to help you to determine which modeling tasks to highlight. Show what you did to arrive at a design solution to a system, subsystem, and/or component design problem. Did experimental results and observations meet Design Requirements? For example; show how you went from requirements, to a trade-off study, to a simulation and then to a set of experiments in order to select a component.
Figure 2. Fuzzy Model Grading Scale
Mission Command and Control
3DoT Robots
This section provides a systems level look at the software modules employed by 3DoT robots. This section represents a collaborative effort by the system and electronics/control engineers.
| Hardware | Software |
| Personal Computer | Arxterra Control Panel |
| Smartphone | ArxRobot App |
| 3DoT Board | Arduino and Robot3DoT Library |
This section should provide a general block diagram of the software system, followed by the Arduino software modules responsible for communicating with the Arxterra App, specifically Command and Telemetry decoding and encoding.
While this sections covers use and customization of the Arxterra Control Panel and ArxRobot App in detail, it only the defines custom 3DoT call-back handlers. The actual firmware code is in the electronics section.
Non-3DoT Projects: Highlight commands being implemented by the user at a top level. Provide any feedback systems that are user-facing. This could be through notification LEDs, haptic feedback, etc. at the system level (E&C will expand on the details during the respective section to follow).
User Input (Command) → [black box] → Notifications (Telemetry)
Electronic Design
This section of the presentation should bring attention to the Electronic Components and serve as an introduction to this field. You should present some details about the custom parts in your design as well as the ICs you chose and why you chose them. As an example you should provide information which IMU you used or which type of rotary encoder you used (where applicable). This should lead into the firmware portion of the presentation.
PCB Design
This is section shows the progression of the design from Fritzing diagram (optional), to physical breadboard photo, to PCB schematic, PCB layout, and finally a photo of the completed board; preferable integrated with the product itself.
You want to review the PCB Design fuzzy grading scale. and show this during the mission demonstration.
Figure 3. PCB Fuzzy Grading Scale
Firmware
Describe and document the code implementing the firmware modules defined in the “Mission Software” section. Specifically, how the code controls and provides feedback (telemetry) for the sensors and actuators defined in the introduction to the “Electronics” section.
Provide Pseudo-code and/or flowcharts as well as short C++ samples to help illustrate the firmware. You should go into detail about any key aspects (such as shifting the center of gravity, running two motors 180 degrees out of phase, or reading of EMG sensors) of the design.
All Arduino and C++ code samples must include descriptive comments.
Mechanical/Hardware Design
This section includes all SolidWorks generated 3D Models of the design. Annotation is recommended. If available the Manufacturing Engineer include photos of the Prototype/Production Parts.
Verification & Validation Test Plan
Reading and Resources:
- Arxterra / Getting Started / Systems Engineering / Missions, Systems and Test Timeline
- Week #7 – Product Verification & Firmware Setup
- Week #8 – Product Validation & Cable Tree/Cable Routing Diagram
- Sample Verification and Validation Plans
Present your strategy for verifying that your design meets design requirements and how you will validate (i.e., the mission plan) that you built the right product for the mission. The next section should present your project’s verification test plan as an overview/summary level. The Verification and Validation Test Plan should be uploaded to BeachBoard and provided in printed form at the day of the mission.
Concluding Thoughts and Future Work
This section includes your thoughts on how the next generation product could be improved, lessons learned the hard way or how would you do things different if you could go back in time.
References/Resources
These are the starting resource files for the next generation of robots. All documentation shall be uploaded, linked to, and archived in to the Arxterra Google Drive. The “Resource” section includes links to the following material.
- Project Video YouTube or Vimeo link (see samples linked to here)
- CDR (PowerPoint, Prezi, or PDF)
- PDR (PowerPoint, Prezi, or PDF)
- Project Libre (with Excel Burndown file) or Microsoft Project File
- Verification and Validation Plan
- Solidworks File (zip folder) Linked to in Mechanical Design Post
- Fritzing Files Linked to in Electronics Design Blog Post
- EagleCAD files (zip folder) Linked to in Electronics Design Blog Post
- Arduino and/or C++ Code (zip folder) Linked to in Software Design Blog Post
- Other Application Programs (Processing, MatLab, LTSpice, Simulink, etc.)
- Complete Bill of Materials (BOM) with vendor names for both mechanical and electrical parts. Create in Excel or your favorite spreadsheet application. Upload as PDF. Do not post receipts, which may contain sensitive information including your name, address, and credit card information. Do not simply draw a black box over material in Word. Hackers can easily remove!
- Any other files you generated that you believe would help the next generation of students working on this project.