Project Summary Post – Template

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:

  1. Arxterra / Classes / Engineering Method, select tab, scroll down to Requirements.
  2. APPENDIX C: HOW TO WRITE A GOOD REQUIREMENT NASA Systems Engineering Handbook (page A:279)
  3. 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

  1. IEEE 29148-2018 – ISO/IEC/IEEE Approved Draft International Standard – Systems and Software Engineering — Life Cycle Processes –Requirements Engineering.
  2. NASA/SP-2007-6105 Rev1 – Systems Engineering Handbook
  3. Bluetooth Special Interest Group (SIG) Standard (supersedes IEEE 802.15.1)
  4. C++ standard (ISO/IEC 14882:1998)
  5. Federal Communications Commission (FCC) Relevant standards for a product implementing a 2.4GHz radio, FCC Intentional Radiators (Radio) Part 15C, and Unintentional Radiators FCC Part 15B for CPU, memories etc.
  6. NXP Semiconductor, UM10204, I2C-bus specification and user manual.
  7. ATmega16U4/ATmega32U4, 8-bit Microcontroller with 16/32K bytes of ISP Flash and USB Controller datasheet section datasheet, Section 18, USART.
  8. USB 2.0 Specification released on April 27, 2000, usb_20_20180904.zip
  9. Motorola’s SPI Block Guide V03.06

Environmental, Health, and Safety (EH&S) Standards

CSULB College of Engineering (COE) Safety Resources.  Start your search for applicable CSULB COE Safety Standards and Procedures here. Please review and acknowledge if any safety issues as defined by the COE applicable to your project. For example, the closest safety constraint for a linear actuator is for use of the Hydraulic Press located in the Engineering Technology (ET) Building Lab. Here is a link to the Hydraulic Press Safety document.

CSULB Environmental Health & Safety (EH&S)

IEEE National Electrical Safety Code (NESC)

NCEES Fundamental Handbook (FE) Reference Handbook

ASTM F963-17, The Standard Consumer Safety Specification for Toy Safety, is a comprehensive standard addressing numerous hazards that have been identified with toys. In 2008, the Consumer Product Safety Improvement Act of 2008 (CPSIA) mandated that the voluntary toy safety standard in effect at that time become a nationwide mandatory children’s product safety rule.

Disposal of Hazardous Waste including Electronic and Solar Cells

CSULB Physical Planning & Facilities Management (PPFM) Environmental Compliance Electronic Waste Handling and Disposal Procedures. These procedures shall be followed for the disposal of all batteries.

Electrical Safety

The National Institute for Occupational Safety and Health (NIOSH) Electrical Safety [1998][page 8] Worker Deaths by Electrocution; A Summary of NIOSH Surveillance and Investigative Findings. Ohio: U.S. Health and Human Services.

Current Level (Milliamperes) Probable Effect on Human Body
1 mA Perception level. Slight tingling sensation. Still dangerous under certain conditions.
5 mA Slight shock felt; not painful but disturbing. Average individual can let go. However, strong involuntary reactions to shocks in this range may lead to injuries.
6 mA−16 mA Painful shock, begin to lose muscular control. Commonly referred to as the freezing current or “let-go” range.
17 mA−99 mA Extreme pain, respiratory arrest, severe muscular contractions. Individual cannot let go. Death is possible.
100 mA−2,000 mA Ventricular fibrillation (uneven, uncoordinated pumping of the heart.) Muscular contraction and nerve damage begins to occur. Death is likely.
> 2,000 mA Cardiac arrest, internal organ damage, and severe burns. Death is probable.

Safe Method for Testing, Storage, and Disposal of LiIon batteries

Personal email communication dated May 9, 2018, to Gary Hill, Adjunct Professor, COE Department of Electrical Engineering, from Michael R. Kitahara, CSP, ARM-P, CHMM, Environmental Health & Safety, California State University, Long Beach

  1. Safe Method for Testing  – Most industry maintenance guidelines estimate the typical life of a LiIon battery to be 2-3 years, even if they are unused during this period.   Given that you have a collection that are age-uncertain, in addition to the potential for explosion and/or fires that may result from recharging old, depleted or malfunctioning batteries, we cannot advocate a “safe” method of testing to see if the batteries can still be charged.  Our recommendation would be to start from scratch and physically date each battery with a Sharpie pen.  We do this when opening peroxide containers (one year storage limit as crystals that form on the edge of the container combined with the friction of opening the cap can cause an explosion).
  2. Safe storage – Once you mark the age on the batteries, they should be stored in a manner where the terminals do not make contact.  You can physically isolate the terminals (e.g.  by placing tape or other barrier on them) or isolate the batteries themselves through a storage container (e.g. a cheap, plastic fishing lure or jewelry storage box such as the one below would suffice).
  3. Battery disposal – This one is the easiest to answer.  Tape the terminals of the batteries to be discarded with duct or electrical tape.  If you have a few, they can be dropped off in the recycling container in ECS-662.  If you have many, call or e-mail me and we can pick it them at your location.

Figure 1. Storage Container

Other conditions for storing LiIon batteries:

  1. Barrier protection – a separate, isolated storage room would be best, or if this is not practical, a cabinet or closet.  There should be appropriate signage, e.g. “Lithium Battery Storage – Explosion Hazard” or similar warning.
  2. Periodic Maintenance Checks – Storage containers should be checked regularly (at least once a semester) for battery condition.
  3. Class “D” Fire Extinguisher – Obtaining one is a great idea.  This would be purchased through your department.

EH&S recommends following industry guidelines by disposing LiIon batteries after their useful life, typically 2-3 years.  Storing LiIon batteries on campus after this period would require approval of the campus Risk Manager, Felicia Waynick, cc:ed 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.

Project/Economic

Subcategories: Cost, Extensibility, Interoperability, Maintainability, Quality, Marketability, and Schedule

All 3DoT robots shall be constrained to a not to be exceed Cost of $250.

All project Schedules shall be constrained to a completion date of Tuesday December 18, 2018. Project completion includes documentation and materials purchased by or loaned to the project.

One of the Economic Factors affecting our robots are return rates. To demonstrate the durability and child friendliness of our robot a simple drop test from 1.4 meter shall be performed. The height is defined by the average height of an average 11 year old girl.

Extensibility is designed into the 3DoT board by way of one 8-pin 100 mil connector located on the front of the board and two 8-pin 100 mil connectors located on the top of the board. By plugging shields into these connectors, the 3DoT board can support a diverse set of robots. All robots shall contain one or more custom designed 3DoT shields. The 3DoT shield(s) incorporating interface electronics between the 3DoT board and sensors and/or actuators unique to the robot. Surface Mount Technology (SMT) will be employed unless a waiver for through-hole parts is granted.

Maintainability: Disassemble and Reassemble of the robot shall be constrained to less than 20 minutes (10 + 10 minutes). Disassembly: The 3Dot board is clear of all other electronic and mechanical subassemblies. All electronic and mechanical subassemblies and associated connectors, sensors, and actuators including motors are disconnected. A functional test of the robot is conducted after reassembly to confirm its functionality. All project may reference a cable tree as well as an assembly diagram as necessary. This requirement is demonstrated/verified on the last day of the schedule. Projects may request a waiver with justification.

Social and Ethical

Subcategories: Accessibility, Aesthetics, and Usability

Accessibility by the blind and Marketability of the robots shall be implemented/enhanced by a speaker. The speaker shall generate sound effect consistent with the type of the robot. For example, the Goliath tank would make “track” sounds, the AT-ST sound effects would mimic their Star Wars antecedent.

Wiring Aesthetics shall be nice and clean with the usage of terminal blocks, 100 mil contact pins and headers, 2.0mm PH series JST connectors, and barrel connectors. Handling Precaution for Terminal and Connector will be in compliance with JST documentation.

To enhance Aesthetics, the robot shall be designed in such a way that there are no dangling or exposed wires. Connectors will used between all electronic and electromechanical components. Jumper wires will not be used, ribbon cables are preferred.

To enhance Aesthetics, the form factor of a robot modeled on a real or fictitious robot shall be constrained by the original. For example, Goliath should be a scale model of the real Goliath 302 tank. Projects may request a waiver with justification.

Usability of the robots shall be enhanced by adding autonomous functions and/or by use of the Arxterra phone application as dictated by the assigned mission.

Manufacturability

Subcategories: Constructability, Size, Weight, and Power (SWAP)

Constructability of 3DoT robots shall be documented at the CDR and approved by the president of the TRC robot company. Constraints imposed by this requirement include the use of bushing or bearings in all moving and rotating parts. Interlocking Hinges with latching mechanism. No gaps greater than 1 millimeter, and immediate access to all external connectors (USB, switches).

Manufacturability of 3D printed robots shall be demonstrated by compliance with the 3/3/3 rule. Specifically, total print of a robot is constrained to 9 hours, with no single print taking longer than 3 hours. Projects may request a waiver with justification.

The Size of the electronics enclosure, shall be constrained to be no greater than the 3DoT board, 3DoT shield(s), and associated mounting hardware.

Power to all 3D robots shall be provided by the 3.7V RCR123A battery included with the 3DoT board or use of the external battery 2.0mm PH series JST connector located on the 3DoT board. The RCR123A is a Lithium Polymer LiPo battery. All Safety regulations as defined in Section 4.3 Hazards and Failure Analysis of this document shall apply to the shipping, handling, storage, and disposal of LiPo batteries.

Back of the envelope calculations and experiments shall be conducted to set the diameter of Power carrying wires. Follow the American Wire Gauge (AWG) standard when defining the diameter of power carrying wires. This work to be completed and documented by the CDR.

Environmental Health and Safety (EH&S) Standards

Subcategories: Environmental Standards, Sustainability, Toxic waste (Solar panels), Health and Safety, Ergonomics

All standards, codes, and regulations as defined in the “Engineering Standards and Constraints” Section of this document shall apply.

Functional 

All 3DoT robots shall incorporate the 3DoT v7 series of boards.

Software shall be written in the Arduino De facto Standard scripting language and/or using the GCC C++ programming language, which is implements the ISO C++ standard (ISO/IEC 14882:1998) published in 1998, and the 2011 and 2014 revisions. Required exceptions to this standard can be found here.

All 3DoT robots shall be in compliance with the 3DoT Command and Telemetry Packet specification.

All 3DoT robots shall be controlled via Bluetooth 4.0 in compliance with the Bluetooth Special Interest Group (SIG) Standard (supersedes IEEE 802.15.1).

Project Level 1 Functional Requirements

Provide a short summary of the Project unique Level 1 Functional Requirements.

System/Subsystem/Specifications Level 2 Requirements

References:

  1. Arxterra / Classes / Engineering Method, select tab, scroll down to Defining Level 2 Requirements.
  2. APPENDIX C: HOW TO WRITE A GOOD REQUIREMENT NASA Systems Engineering Handbook (page A:279)
  3. 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.

Mass Shared Resource Report / Allocation

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.

Power Shared Resource Report / Allocation

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.

Other Shared Resource Report(s) / Allocation

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:

  1. 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.
  2. NASA SE Handbook Sections 4.2, 4.3-2, 6.1-4/5,G-1
  3. Arxterra / Classes / Engineering Method, select tab, scroll down to The Robot Company Work Breakdown Schedule.
  4. 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:

  1. Arxterra / Classes / Engineering Method, select tab, scroll down to Design Process and Modeling.
  2. 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:

  1. Arxterra / Getting Started / Systems Engineering / Missions, Systems and Test Timeline
  2. Week #7 – Product Verification & Firmware Setup
  3. Week #8 – Product Validation & Cable Tree/Cable Routing Diagram
  4. 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.

  1. Project Video YouTube or Vimeo link (see samples linked to here)
  2. CDR (PowerPoint, Prezi, or PDF)
  3. PDR (PowerPoint, Prezi, or PDF)
  4. Project Libre (with Excel Burndown file) or Microsoft Project File
  5. Verification and Validation Plan
  6. Solidworks File (zip folder) Linked to in Mechanical Design Post
  7. Fritzing Files Linked to in Electronics Design Blog Post
  8. EagleCAD files (zip folder) Linked to in Electronics Design Blog Post
  9. Arduino and/or C++ Code (zip folder) Linked to in Software Design Blog Post
  10. Other Application Programs (Processing, MatLab, LTSpice, Simulink, etc.)
  11. 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!
  12. Any other files you generated that you believe would help the next generation of students working on this project.