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
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.
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.
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)
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.
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 Requirementslecture material to learn more about Requirements Traceability.
Based on the block diagram and should be traceable to L1 requirements.
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.
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.
The PBS shows the items needed for Proposal Bot to function and the person responsible for each task. Text..
Figure 2. Product Breakdown Structure
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.
Expected Cost ($)
Actual Cost ($)
Stepper Motor Driver
12V Li-Ion Battery
3mm Steel Wire
Total Expected Cost
Total Actual Cost
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.
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.
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).
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.
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
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.
Arxterra Control Panel
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)
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.
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
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.
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.
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.
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.