Proposal Bot Generation 1
Summary Blog Post

Author/s: Ethan Thiessa
Verification:
Approval:

Executive Summary

by Ethan Thiessa

Many people struggle with trying to find the perfect or unique marriage proposal for their significant other. Proposal bot solves this issue by providing the person with a unique, fun way to propose with a small robot. This omnidirectional robot will autonomously draw out on a piece of paper “Will you marry me?” while playing a little jingle. When the bot is done drawing out the message, a box on top of the bot will pop open revealing the engagement ring.

Program and Project Objectives

Program Objectives

The Robot Company (TRC) will be debuting its 2020 line-up of robots and consumer technology at the Bridal Wedding Expo 2020 convention in Los Angeles, CA on May 8, 2020. 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 2021. The robots will feature our new ArxRobot smart phone application and the Arxterra internet applications allowing people to easily control their new robots. In addition, the robots should be able to operate autonomously in draw mode. 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 men between the ages of 20 and 30, with a median (target) age of 25. 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 men, 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

The purpose of the Proposal Bot project is to use it’s drawing capabiliites to appeal to a new market of consumers: people who plan to be engaged. The Proposal Bot intends to offer an interesting and unique method of proposal to this market. The project will also offer an opportunity to study the movement and precision of an omnidirectional robot to draw out a proposal message. The omnidirectional wheels of the bot will provide better maneuverability and speed to write the message versus normal wheels.

Mission Profile

The mission of the Proposal Bot is to write out the message “MARRY ME?” on a piece of paper. In addition, the user shall be able to enter a text message using the Arxterra app to tell the Proposal Bot what to write. When the robot completes the message, a box will automatically open revealing an engagement ring. If time allows, Proposal Bot will also be capable of writing in cursive for better presentation.

Initially Proposal Bot will move omnidirectionally under ArxRobot Application (v1).

Next, Proposal Bot will draw a predefined message using block letters and at the end of the message open a small box. (v2)

Finally the Propoal Bot shall write a user defined message. The message should be written in cursive.  (v3)

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

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

The Level 1 Functional Requirements describe the functions and characteristics that Proposal Bot will have….

L1.1 – Proposal bot will have a custom motor driver shield that features a buck converter that powers two servos.

L1.2 – Proposal Bot shall be able to rotate, move backwards, move sideways, and move at a 45 degree angle in order to write block letters.

L1.3 – Proposal Bot shall draw the proposal message “MARRY ME?” in block letters on a poster or large sheet of paper

L1.5 – Proposal Bot shall traverse on any conventional writing surface

L1.6 – Proposal Bot shall have a servo powered pen plotter mechanism that lifts and lowers the pen enabling it to write

L1.7 – Proposal bot shall write a message autonomously after given the letter instructions

L1.8 – A ring box shall open up when Proposal Bot is done drawing the message

L1.9 – Proposal Bot shall be able to be controlled using Arxterra app via bluetooth

L1.10 – Proposal Bot should write the proposal message in cursive utiliizing bezier curves

L1.11 – User should be able to input a message using their phone for Proposal Bot to write out

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

Level 2 Requirements

The level 2 requirements will…

Based on the block diagram and should be traceable to L1 requirements.

L2.1 –

L2.2

l2.3

… 

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

Below is the Project Work Breakdown Structure (WBS) and Product Breakdown Structure (PBS). The WBS shows the work that needs to be done to complete Proposal Bot and the person responsible for those tasks. The WBS and PBS show the basic tasks that need to be done to complete the Proposal Bot and the Excel sheet linked below displays the complete task list to complete the project.

Complete Task List

Figure 1. Work Breakdown Structure

The PBS shows the items needed for Proposal Bot to function and the person responsible for each task. Text..

Figure 2. Product Breakdown Structure

Cost

The budget allocated for the construction of Proposal Bot was $200.00. Each team member has to keep track of the budget during the time of the project. A lot of money was saved on this project by already having a 3-Dot board and using common stepper motors that were easily salvageable. 3D printing cost was minimized by attempting to consoladate as many 3D models into one printer space as we could.

Resource Quantity Expected Cost ($) Actual Cost ($) Uncerntainty(%) Margin
Electrical Components
3-Dot 1 80.00 0.00
Stepper Motor 4 40.00 36.00
Stepper Motor Driver 4 15.00 10.50
12V Li-Ion Battery 1 20.00
Servo Motor 2 5.00 4.00
PCB 1
Arduino Mega 1 35.00
Mechanical Components
M4 Screws/Bolts/Washers 16 7.50
M3 Screws/Bolts/Washers 16 7.50
3mm Steel Wire 3 9.91
Rollers 40 12.36
Inner/Outer Shell 4 21.63
Box Frame 1 5.00
Pen Plotter 1
Ring Box 1
Totals Cost ($)
Project Allocation 200.00
Total Margin
Total Expected Cost
Contingency
Total Actual Cost

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

Blog 

Coding – software section

Pen Plotter – software section

Servo versus Stepper Motors – here

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.